If you are involved with project management, chances are you have heard of the Chaos report published by the Standish group. The Chaos report delivers shocking results about the overwhelming failure of most projects. In the initial report that was published in 1994, just 16 percent of all projects were considered successful and this number has varied over the years, sometimes going as high as close to 40 percent successful projects, which is still disappointing considering the maturity of the project management profession.
In my experience, I don’t see such low rates of project success. On the contrary, I hardly ever come across a failed project. While I have encountered many troubled projects, these are still eventually completed to stakeholder satisfaction.
I have seen that project sponsors are reluctant to admit that a project has failed, considering how invested they are in its success. Projects that run massively over budget or significantly over schedule are still considered successful once they are completed. Projects that deliver less than promised are also sometimes declared as successful with some vague excuse as to why it was not possible to deliver as promised. When projects that were difficult and that ran over time and budget are finally completed, everyone is so relieved that – at last, after so much struggle – something is delivered, they are officially declared successful.
Based on my observation that most projects are eventually successful, where does the Chaos report get its findings that so many projects fail? I believe the difference is in the definition of project success or failure.
In the Chaos report, failed projects are considered those that were cancelled before they were completed. While it is true that a cancelled project may be a failed project, in my opinion this is not necessarily always the reality. Sometimes, a project can be cancelled for reasons that do not imply failure of the project itself. For example, if the project funding was discontinued, it could indicate that the priorities in the project portfolio have shifted or that the reason for the project no longer exists. Cancelling the project in such circumstances is the right thing to do, in order to avoid further sunk costs and ultimately delivering something that would not be needed any longer.
Definition of project success and failure
A widely used definition of a successful project is that a project must deliver within the planned budget, schedule and quality; and it must deliver the benefits presented in the business case. This is a very strict definition, but is it realistic?
If key stakeholders agree that a project must exceed its initial budget due to a valid unforeseen reason, then the budget is increased and by the above definition, the project would be successful as long as it was within the approved increased budget. On the other hand, if a project delivers everything that was in the detailed project design, it could still fail if it didn’t fulfill actual requirements that the key stakeholders needed regardless of what was included in the detailed design.
Definition of a successful or failed project is not so much a strict black and white rule, but rather a judgement call that is agreed among the project stakeholders. For example, a project board may make the decision that a project has failed to deliver as promised as part of project closure activities. In other words, a project is a failure if its stakeholders consider it a failure.
What PMBOK says about project success or failure
Let’s have a look at the definitive source, the Project Management Body of Knowledge (PMBOK) published by PMI to find out what it says about project success and failure. Actually, according to PMBOK, there is no such thing as project success or failure, the book addresses only how a project is ended: “A project’s end is reached when the objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists.”
So what are project objectives? PMBOK says that “An objective is defined as an outcome toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed.” Most notably, there is no mention of project schedule or budget.
When we think about it, this makes sense. A project doesn’t suddenly go over budget nor does it suddenly become late. The project manager’s job is to proactively anticipate trouble, not to wait until the end and retroactively report trouble. When a project steers toward delays or budget overruns, the project manager should report this to the stakeholders as soon as possible, for example together with the next project status report or any other means of agreed project communication. A decision about how to proceed and to gain stakeholder buy-in should be taken during project execution, thus avoiding massive schedule and budget overruns at project completion.
It doesn’t make sense to declare a project as unsuccessful when it overran the schedule or went over budget because a project’s budget was either increased in agreement with the stakeholders – in this case it doesn’t overrun the budget as the increased budget is agreed and is therefore expected; or the project funding is discontinued – in this case the project is terminated prior to completion due to insufficient funding. Again, does this represent success or failure? If the project objectives were to deliver a critical functionality that will not be available as a result of the project not being completed, then yes, it is a failure. But what if the project was terminated so that it would not use up additional unplanned budget? From the point of view of the stakeholders this could be considered a success, because a much larger failure was prevented.
In summary, defining project success or failure is relative and there is no strict rule. The Chaos report just reports the data according to their own definition of project success or failure, but this may or may not reflect the point of view of anyone else who is measuring project success rates.
References
Johan Eveleens, Chris Verhoef, “The rise and fall of the Chaos report figures”, IEEE Software Volume 27, Issue 1, Jan.-Feb. 2010