You have all read the stories about the large number of projects that fail. Depending on the report you read, half or more of projects fail - perhaps as high as 80%. According to the reports, the larger the project, the greater the chance that it will be a failure.
Let’s assume that the number of failed projects is 50% - the low number. What is interesting is to try to relate that number to my personal experience. Where are all of these failed projects coming from? Can you say that half or more of the projects that you managed were failures?
It’s All in the Definition
The idea of a failed project starts with understanding the definition. You may have a perception of what it means to manage a failed project. Your company should have a definition as well, and if they do, your definition should be the same as theirs. One major concept that plays a key role is the idea of tolerances.
Define a Reasonable Cost and Duration Tolerance Level
If you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within $500 on a $230,000 budget, you should be lifted on your manager's shoulder and paraded around the company as a hero.
Your company needs to establish the tolerance level that they consider to be reasonable for projects. For example, the tolerance level may be -10% to +15%. That is, if you deliver the project 15% over budget, it is still considered a success. For the $230,000 project, that means you could have gone overbudget by $34,500 and still have been considered successful. The baseline budget should also include any formally approved scope changes. For example, if your original budget was $200,000, and the client approved an additional $30,000 in scope changes, then the $230,000 is the number that you get held accountable for, plus your tolerances.
Normally there is some room for tolerances with your deadline as well. If the projects are internally focused, the end dates are in many cases arbitrary. Your original deadline must also be extended if scope changes were approved. Of course, not all projects have that flexibility. The YR2K 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 your tolerances (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 does not 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? For instance, was there good communication? If the client had another project (and a choice), would they ask you to work on it again? We call this "performance excellence".
Other factors may be important for specific projects. For instance in a construction project, safety might be a key success component.
A Project Scorecard can be used to establish the formal criteria for success.
Declaring Success from a Company Perspective
Declaring success from a project perspective is normally what the project team is asked to be accountable for. However, from a company perspective, success would also be based on whether the company received the business value that was promised. If the project was a failure from a project perspective, it is normally a failure from a company perspective as well. (Although this is not always the case.)
However, 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 tolerances, there is usually nothing else that can be done from their perspective. However, it is possible that the return on investment calculations were faulty, or the marketplace was misjudged, by the client and sponsor. It is 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.
We believe that success against the project business value, as defined in the Business Case, is ultimately the responsibility of the sponsor - not the project team.
Summary
Every organization should have some general rules about how to declare project success or failure. Your project isn’t 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 acceptable quality. This is what the project manager and project team can be held accountable for. |
