Retrospection: Why do projects fail to deliver within budget?
I need to come clean. On several occasions, I have not delivered projects within budget. In this blog, I ponder and analyze the reason for my failure. Could it be that in the pursuit of keeping the stakeholders happy I intentionally:
- Allowed new requirements to creep into the scope?
- Fail to effectively establish and enforce a change control process?
- Did not consider the phenomenon of planning fallacy?
- Did not build adequate cost contingencies?
- Did not set stakeholder expectations?
After much reflection, I have come to the conclusion that all of the above could be the reason for cost overruns. However, I believe my cost overruns were primarily due to the fact that I did not set appropriate stakeholder expectations during the initiating phase of the projects. Let me explain.
Traditionally, stakeholders expect an upfront cost estimate for a project. This, however, is difficult to do in software development projects. An estimate provided at this phase is invariably highly inaccurate because:
- It is impossible to gather all requirements at the start of a project
- The requirements that have been collected are guaranteed to change by a certain degree over the course of the project, AND
- There will always be new requirements that cannot be accommodated within the cost constraints.
In addition, there is a high risk that any benefit realization calculations based off an early estimate would be inaccurate. PMI’s 2017 Pulse of the Profession highlights:
“A growing attention to benefits realization management, the process of identifying benefits at the outset of a project and ensuring, through purposeful actions during implementation, the realization of those benefits.”
These recommended early benefit realization calculations used in strategic planning and value management, put an increased focus on capturing accurate cost estimates so estimated long-term project benefit is realistic.
Enter the Cone of Uncertainty
It has been my experience that quite a large percentage of project team members are not familiar with the concept of the Cone of Uncertainty.
The prudent project manager, me going forward, should make a point to explain the evolutionary nature of uncertainty in a project to all stakeholders, including project team members, the project sponsor, as well as external vendors early in the project.
During the initiating phase of software development, there is much ambiguity about the requirements, with the client and team only possessing a general idea of what they want. There is a high degree of uncertainty at this stage.
As the project team continues to gather requirements through the process of elicitation using tools such as wireframes, swim lanes and interviews, they begin to form a better understanding of the requirements thereby leading to a reduction in the level of uncertainty and increase in the accuracy of estimating.
By the time the requirements gathering/planning process is completed, the level of uncertainty dramatically reduces such that the business analysts, developers, solution design architects and the project manager have a much better understanding of the scope of the project. At this stage, the project manager can appropriately gauge the internal and external/vendors resources needed to complete the project with a high degree of confidence.
The Optimum Achievable Solution
So, based on the lessons I have learned, I believe that one should be upfront and honest with the stakeholder and inform them that in the early stages of the project it is not possible to provide an absolute estimate.
Consider asking for phase based incremental funding with low initial funding, followed by higher funding during the executing phase once the degree of uncertainty has reduced. Alternately, one could provide the stakeholder with a 3-point cost estimate ranging from optimistic, pessimistic or most likely.
I conclude that by providing an absolute estimate in the initiating phase of a project, that the project manager is only setting himself/herself up for failure. In retrospect, that is no fun for anyone.
For further information on this article and MI-GSO | PCUBED