Did the IT project really fail?

You've all read the stories about the large number of projects that fail. Some reports say that half or more of all projects fail--perhaps as many as 80 percent! However, as you look at the projects in your company, would you really say that 80 percent of them are failures? Would even 50 percent be considered failures?

To answer the question of how many failed projects there are, you first need to understand the definition of a failed project. The concept that plays a key role is the idea of tolerances. If you estimate that a project will cost US$230,000, is your project a failure if the actual cost is US$230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within US$500 on a US$230,000 budget, your project was not a failure. In fact, you should be lifted on the group's shoulders and paraded around the company as a hero.

Your company needs to establish the tolerance level that it considers to be reasonable for projects. At some companies, for instance, the tolerance level is set at -10% to +10% of budget and schedule. If your budget was US$230,000, this means you could have gone over-budget by US$23,000 and still be considered successful. If you complete a nine month project within three weeks, that might be considered very successful as well. (Your original budget and deadline also are adjusted if you had approved scope change requests.)

So, what is a troubled project? Consider the following project characteristics as examples. These criteria would definitely be outside tolerances:

• The project is trending 30 percent or more over its estimated budget
• The project is trending 30 percent or more over its estimated deadline (although this may not be as important if the budget is not also over by 30 percent or more).
• The project appears within tolerances, but only by deferring the completion of one or more major deliverables.
• The project appears within tolerances, but only by compromising on quality to the point that the value and integrity of the deliverable are called into question.
• The clients are extremely dissatisfied with the performance of the project team. If the clients had to do it again, they would not use the same project team.
• The client-project team relationship is dysfunctional. This could include situations such as the client and sponsor losing interest in the success of the project, major animosity between the project team and the client, deliberate sabotage by one party to make the other party look bad, etc.

The criteria for describing a troubled project in your organization may be different. However, the point is that you need to validate whether the project is just in "a little trouble" or whether there is a real disaster brewing. Before you go to the trouble of performing a project rescue, make sure the project is really in serious trouble.