Editor’s note:This article originally appeared on our sister site, TechRepublic.com.
Research suggests that the vast majority of IT projects fail. One example is The Standish Group’s 1998 report that cited 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 have 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 deadlines, as well. In probably two-thirds of the projects that I managed, the final deadline was based on my estimate. 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 are approved.
Of course, not all projects have that flexibility. 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 functionality might be cut from the project.)
- The overall quality is acceptable. (It doesn’t have to be perfect.)
Some companies also look at whether the client and the project team worked 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 promised by initial ROI calculations. If the project was a failure from a project perspective, it’s normally a failure from a company perspective, as well. However, 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 but 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’s 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? Do you still find that the majority of your projects are failures? Post your comments below or e-mail us here.