By Lynda Bourne
In my last post, The Real Estimating Challenge Isn’t Calculating the Cost, I suggested that calculating a project cost estimate is the easy bit. Having the estimate accepted by either a client or your management—or both—and then delivering your project on budget is far more difficult. In this post, I want to look at the challenge of delivering on budget.
Knowing what a project is likely to cost is important from every perspective: personal, professional and organizational. But developing a realistic and achievable cost estimate has two components: first you develop the baseline estimate, then you need to develop a realistic contingency. Most people do step one; very few even think of step two.
The baseline estimate should be realistic, and there are many valid approaches to creating one. But what comes next?
If you simply stop at the net cost estimate based on expected resource usage and known cost rates, your project will inevitably overrun its budget. There are no allowances for risks, which will inevitably arise during the course of the work. No project is ever risk-free.
Risks are uncertainties that matter. From a cost perspective this includes both variability in estimates and performance, and uncertain events that may or may not occur.
Variability is inevitable. The work might be completed quicker or slower than planned, people might change and cost more or less per hour, etc. The only certainty is that the actual cost outcome will vary from the estimate.
The key question is: by how much? Use past performance as a guide to size this part of the contingency appropriately.
Managing Uncertain Events
This type of uncertainty is the realm of the risk register and its list of identifiable uncertainties, overlaid by other risk events that were not foreseen. These are the known unknowns and unknown unknowns of risk management.
This type of risk can be mitigated or reduced by good practice, but neither of the unknowns can be eliminated entirely. Residual risks always remain. The important question is: How do you compensate for the remaining risks in your business case or cost estimate?
One approach is to pad the estimate and hide the costs within the overall price. The problem with this approach was identified by Eliyahu Goldratt in Critical Chain (1997). He stated that when the contingencies are hidden, they tend to get absorbed by the work and are generally larger than needed. This is not a good way of working. For example, in developing software every test may fail, but only some will identify bugs that need fixing. Padding every test with some allowance for failures hides the money, and it is likely to get used anyway to cover all sorts of other events.
The better approach is to price each test on the assumption that the test will pass, and then create a contingency for bug fixes. This allows the cost of rectification to be seen, monitored and controlled independent of the costs associated with testing. If the number of bugs is too high, this becomes obvious and allows management to consider ways to improve processes.
Calculating the amount of money needed to adequately cover the risk exposure of the project is complex. It requires expertise. But once this has been done, the values calculated should be divided into two distinct parts:
- The project contingency, held within the project budget to compensate for variability and other known unknowns that will occur to a greater or lesser extent. The project manager should be responsible for looking after the expenditure of this money but is expected to report to senior management on each use.
- The management reserve, held outside of the project budget for use by senior management to offset the effects of unknown unknowns.
These are not slush funds. They are calculated and held for explicit events that may occur and the use of the funds is constrained, controlled and reported on throughout the life of the project.
Developing a sensible level of contingency and reserve is a complex process and beyond the scope of this article. The message is simple, though: If you do not include contingencies, you will overrun your project budget!
The bigger challenge is to convince management to accept the need for a properly evaluated contingency in every project. Achieving this requires the solutions outlined in my last post, linked to a concerted program of support from both the organization’s PMO and its portfolio management team.
The challenge is not insurmountable. Large parts of the U.S. government under the auspices of the Government Accountability Office are mandating this approach, and the U.K. treasury has its Green Book. Your challenge is to inspire similar attitudes within your organization’s senior leadership team.
How does your project team develop realistic contingency plans?