It is likely that you will end up on a failing project at some point in your career. Of course, that’s something we’d all like to avoid. Failures are demotivating at best and career-threatening at worst. If you could take action to save a project, you probably would. Unfortunately, unless you are the project manager, you may have little opportunity to affect the success or failure of the project. You can, however, learn to spot impending problems so that you have a chance to land on your feet.

This article looks at three business-related warning signs to help you recognize that a project is headed for trouble. While not exactly scientific, these signs can provide some early warning. And although you probably won’t be able to save the project, you may be able to save yourself. Included at the end of the article are some recommended actions you can take if you find yourself on a failing project.

The stats
The statistics for successful IT projects are not encouraging. According to a report by The Standish Group (a business research organization), nearly one-third of all Information Systems (IS) projects are cancelled before completion. In addition, one-half of all projects overrun their budgets.

Surprisingly, the reasons for failure are rarely technology related. In the software management book Peopleware: Productive Projects and Teams, coauthor Tom Demarco notes that the overwhelming majority of projects fail for reasons other than technology. But if it isn’t the technology, what’s causing these projects to fail? The reasons are people- and process-related. Ironically, the average developer is more comfortable dealing with technology-related problems and less so with people- and process-related issues.

Problem # 1: Lack of a compelling business case
Surprisingly enough, some projects get underway without a compelling business case to support them. A business case is important because it provides the foundation for the project. It should offer a cost-benefit analysis and will often consider business risks and the impact of external events on the project. Organizations use business cases to prioritize their limited resources for those opportunities that will provide the greatest return.

So how does a project get started without a business case? This can happen because the business owner for the project “just wants it” and is powerful enough to make it happen. Another possibility is that IT organizations think the business unit needs it, so they build it.

In the last two years, many Web-related projects were started without business cases because organizations believed that they had to do the project to remain competitive. There was a sense of urgency, of getting out in front of the wave. The dot-com crash has meant a return to business basics, including business cases.

What you should do: Find out if your current project is supported by a business case. Get a copy of the business case and read it. What are the business drivers for the project? Is the business case logical and understandable? What assumptions underlie the business case? What are the risks? What external events could affect the business case? If you do not find an understandable, compelling business case for your project, find out why no business case has been developed.

Problem #2: No agreed-upon requirements or system specification
Lack of requirements can indeed be a dangerous thing. In the Standish Group report, the three most-common factors in challenged projects were requirements related. Requirements suggest the size and shape of the system being built. They define what the system should and shouldn’t do.

Requirements management is the process of defining, documenting, tracking, and managing requirements throughout the project life cycle. This helps to ensure that the final solution meets the needs of the users.

What you should do: Keep a close eye on your requirements management process. If no one seems to be managing a list of requirements for the system, or if the requirements seem to be constantly changing, then you may be headed for trouble.

Problem #3: Lack of a current, published project plan
Amazingly enough, some projects are still being run without a project plan. This is like building a house without a blueprint. Every project is a unique undertaking and each should have a project plan. Period. Plans are essential for communications with all stakeholders, for providing an indication of progress, and for determining the work remaining to be completed.

One argument against having plans is that people don’t need to be told; they somehow “know what to do.” This approach may work on a project team of one but is untenable with anything larger. People do need to be directed. They want to know the priorities. They don’t want to have to guess at what is most important.

Having a plan is only part of the battle: The plan should also be kept current. Have you ever been on a project where the kickoff was held in a room wallpapered with fancy Gantt or PERT charts, only to find that those same charts remain on the walls for months or years without any change? That is not a current plan. To be current, the plan must reflect actual work completed and offer a realistic forecast of what remains to be done. Plan updates should be done no more frequently than once a week and no less often than every two weeks. The plan should accurately reflect the time and cost to complete the project. Only then can the plan be considered current.

Just as frightening as having an out-of-date plan is one that changes each week. I have monitored projects where each week that passed caused the end date to extend out by one week. The plan was up to date each week, but the project was still out of control.

What you should do: If there is not a published plan, ask for one. If you are told that you can’t see the plan because the information is considered confidential, take that as a serious warning sign. Unless you are working on developing the next generation of the nuclear bomb, there is probably no good reason for a confidential plan. Keeping the information secret is usually an indication that the management knows there is a problem with the project and they are trying to keep it under wraps.

Make sure the plan is updated at reasonable intervals. It shouldn’t be a moving target, but it must be up to date. If you can’t get a current, published plan, start to worry.

My project is failing—now what?
What if you find yourself on a project with one or more of these warning signs of failure? Your response will depend on your personal situation. If you feel you can help the situation by taking action, by all means you should do that. Talk to the project manager, the client, or the other members of your team. Discuss your concern in a factual, nonthreatening way. Try to be as positive-minded as possible. See if you can affect the needed change.

If that fails and you find you have no control over the situation, try to find a way off the project. You may be able to find a better project in the same organization or you may have to leave the organization. In either case, leave the project on a positive note. This is not the time to tell anyone how little he or she knows about running projects.

If you are truly stuck on the project or if you are waiting to leave it, try changing your perspective. Treat it as a learning experience. What can you gain from the situation? What specific actions would you take to change the situation if you were empowered? How can you avoid being on a project like this in the future? Take from the situation everything you can that will be helpful to you on future projects.

Just the beginning
These three issues all have to do with business and planning, but of course, there are many more factors that can signal a project’s demise. Next time, we will look at four factors that involve users and stakeholders and see how they can be a further warning of bad things to come for your project.

Have you been on a failed project?

What has your project experience been? Have you ever been able to positively affect an ailing project you were on? Send us an e-mail with your thoughts and experiences or post a comment below.