Project failures are less common than you think

by Tom Mochal | Dec 17, 2002 8:00:00 AM

Tags: Tom Mochal

Takeaway: Whether your project succeeds or fails depends largely on how you and your company define success and failure. Take a look at what goes into creating that definition and then reevaluate your own project success and failure rates.

Research would suggest that the vast majority of IT projects fail. One example is The Standish Group's 1998 report that stated that the success rate for that year was only 26 percent, which was an improvement over 1994’s success rate of 16.2 percent. This translates into a 74 percent failure rate for 1998. The numbers are shocking, but it’s hard to know if they are truly representative of the situation.

In my own experience, I have not had anywhere near 74 percent of my projects fail. I haven’t had 50 percent of my projects fail. In fact, of all the projects I managed or that were executed by project managers who reported to me, I can remember only one project that I would actually call a failure. That project was finally completed, but it was dramatically over budget, over its deadline, and the original implementation did not meet client expectations.

To help illuminate the reality behind the project failure research, I’ll take a closer look at the definitions of project success and failure. Because the fact of the matter is, whether your project succeeds or fails depends heavily on how you and your company define success and failure.

Define a reasonable cost and duration tolerance level
One major concept in determining this success/failure definition is the idea of tolerances. Think of it this way, if you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? Not if that number falls within your company’s tolerance level.

Your company needs to establish the tolerance level that it considers to be reasonable for projects. At a company I used to work for, the tolerance level was -10 percent to +5 percent. That is, if you delivered the project for 5 percent over budget, it was still considered a success. So, for our $230,000 project, we could have gone over budget by $11,500 and still been considered successful.

On the other hand, if the final cost was under budget by greater than 10 percent, that was a problem too. The company wanted to deliver projects within expectations, which meant that projects too far under budget were not acceptable. If the sponsors had known that the project would actually cost a lot less than estimated, they could have made other decisions with the unused budget.

The cost estimate should also include any formally approved scope changes. If your original budget was $200,000, and the client approved an additional $30,000 in scope changes, then the final $230,000 is the number for which you would be held accountable, plus your tolerances.

Normally there is some room for tolerances with your deadline as well. In probably two-thirds of the projects that I managed, the final deadline was based on what my estimated deadline was. That is, since the projects are internally focused, the end dates were in many cases arbitrary. If I estimated a project at three months, and it was completed in three months and one week, that was normally acceptable. Your original deadline must also be extended if scope changes were approved.

Of course, not all projects have that flexibility. The Y2K software projects for instance, typically had to be completed by the first time they ran in the New Year. A week late was not going to work.

Declaring success from a project perspective
Once you understand what your tolerances are (if any), you can start to evaluate success from a project perspective. Generally, the project team members can declare success if:

• The project is delivered within the estimated cost, plus or minus the tolerance.
• The project was delivered within its deadline, plus or minus the tolerance.
• All of the major deliverables were completed. (Some minor ones, or minor functionality, might not be delivered.)
• The overall quality is acceptable. (It doesn’t have to be perfect.)

Some companies also look at whether the project team was easy to do business with. That is, did the client and the project team work well together? Was there good communication? If the client had another project, would they ask that project team to work on it again?

Declaring success from a company perspective
The project team is normally accountable for declaring success from a project perspective. From a company perspective, success would also be based on whether the company received the value that was promised from the initial ROI calculations. If the project was a failure from a project perspective, it’s normally a failure from a company perspective as well. Although, this isn’t always the case: In the example of my project that failed, we actually completed the project, and the company is gaining value over the lifetime of the product.

There are also many examples of projects that were successfully delivered yet are not delivering the value promised. If the project team delivered successfully within the tolerance levels, there’s usually nothing else that can be done from the team’s perspective. However, it is possible that the ROI calculations were faulty or that the client and sponsor misjudged the marketplace. It’s also possible that this project was part of a larger initiative. Although your project may be successful, the overall, larger initiative may be a failure.

Every organization should have some general rules about how to declare overall project success or failure. Your project shouldn’t be labeled a failure if you miss the budget by a dollar and deliver a day late. Normally a project will still be considered successful if it delivers within cost and deadline tolerances and delivers all major deliverables within the acceptable quality. From an overall business perspective, another set of questions should also be answered as to whether the business value was achieved as promised.

With this information in mind, would you calculate your success and failure rates differently (not counting the higher level business value question)? Do you still find that the majority of your projects are failures? Post your comments and let us know.

Print/View all Posts Comments on this article

Error in statistical calculation DC Guy | 12/17/02

Interesting points... ponderworks@... | 12/17/02

Whose Failure Ken@... | 12/18/02

Absolutely correct net-help | 12/30/02

Playing with Tops - the spinning kind PMP'sicle | 12/19/02

Playing with Tops - part 2 PMP'sicle | 12/19/02

Playing with Tops - part 3 PMP'sicle | 12/19/02

Very nice exposition, thanks! DC Guy | 12/19/02

Based on mission Prefbid II | 12/20/02

If reality was reasonable... C.N. Moore | 01/06/03