Do a search on “project estimation” on the internet and you will get over 800,000 results. Sample some of the search results and you will find some are white papers spruiking a particular method, some are excellent articles examining different methods and some are scholarly research papers on inherent inaccuracies.
We’ve all seen various statistics over the years on the dismal accuracy of most project time and cost estimates. Not surprisingly projects tend to run over initial time and cost estimates. So why is project estimation seemingly so difficult and what are our tips for more accurate estimation?
One common reason projects go over initial time and cost estimates is the massive temptation to ‘oversell’ during formative stages. Benefits are talked up – especially intangible benefits – and costs and timeframes are played down. Whether this is due to a vendor trying to ‘make a sale’ or purely internal pressure from someone trying to launch a ‘pet project’.
A second major contributor to projects going over time and over budget is a misunderstanding of the estimation process and therefore a misuse of initial estimates. Most projects have a large element of ‘discovery’ to them – not just at the start of the project but throughout the project’s life. Consider the following diagram.
At the start of a project you will estimate based on what we know. For instance, you will know you need to build certain pieces of code and certain interfaces, test these, train users, etc. and you have a fairly good idea how long these things will take based on past experience.
We also must acknowledge there are things we don’t know yet. You know that you might need to partially rebuild a particular interface or rework a bit of translation code. If that’s required then the time required could vary so it’s difficult to estimate but not impossible – especially if we are allowed to include some contingency for such work.
Whilst we can workshop at the start of the project to try to work out what we don’t know, there will always be things that nobody expected. If you’re running a project and know that the exact same project has been run multiple times in the past then perhaps these unknown unknowns are minimal. But most projects are doing something for the first time. Even if the Project Manager and the vendor claim they’ve done the same thing many times in other organisations, no two organisations are the same and neither are any two projects. There are simply too many variables.
So how do you estimate the time and cost to overcome obstacles that are totally off any radar? The answer is you can’t. You can however have someone experienced involved in the estimation process that won’t just estimate the plain-sailing path to completion but has been around the block enough to know what an appropriate buffer is for all the unknowns that will doubtless arise.
Now to touch on some other terms and estimation techniques you may come across.
| Estimation term | Explanation |
| Top Down | This is not really a valid technique for estimating time and cost. Instead, this fits a situation where the sponsor or senior stakeholder has a preconceived capped amount that can be spent and/or a fixed timeframe in which something needs to be achieved. The estimation in such circumstances is more about the scope of what (if anything) can be achieved for the preconceived cost and timeframe. |
| Bottom Up | Essentially the opposite of ‘Top Down’, this technique starts with breaking a piece of work into small elements / tasks, estimates each of these low-level elements and sensibly summing the total of all low-level elements into an overall estimate. The trick will always be how low a level you need to go, how well you can break things down, how accurate your low-level estimates are and how to account for the unknowns. |
| Expert judgement | Whilst there are estimation techniques like Function Point Analysis that strive to be completely objective and rely solely on use of metrics rather than expert judgement, the reality is that some form of judgement (hopefully from an expert!) is involved in any form of estimation. |
| Range or three-point estimation | This is a technique whereby, instead of coming up with a single estimate for a particular task or element, the estimator comes up with either a range (between X and Y) or 3 different estimates (being pessimistic, optimistic, and most likely). |
Consider the diagram below. Regardless of how the estimates were derived, it is normal to have a range of estimates and to have a range in which you have a high degree of confidence and then a diminishing smaller range where the outcome is possible but less and less likely. The question is, in this situation, where do you draw the lines as to what the project budget should be and what sort of contingency is appropriate?
For maximum certainty we would advocate for having a budget without contingency at point A and a budget with contingency at point C. However the reality is that the ‘tail’ of bell curves such as this can often be very long and a point B is often preferred as the budget with contingency. Point B being a point we are around 90% to 95% certain the project budget will fall under.
Note: The exact same approach can be used for project duration estimation as well.
So how can you increase project estimation accuracy? How can you make the ‘bell’ in the bell curve as narrow as possible? Our top 5 tips for improving project estimation are:
- No substitute for experience
Not just the project manager or whoever is in charge of the overall estimation process but the experience of individuals estimating their particular areas – whether that be the Business Analyst estimating the requirements and design phase, the development lead estimating coding and unit testing, test managers estimating test effort or a Change Manager estimating effort involved in training, comms, etc.
- Use ranges or three-point estimation
Referring again to the bell curve diagram above, forcing someone to pick a single number estimate for a project (with no contingency) will almost always lead to them picking point B or C. In other words, you will get the pessimistic estimate for everything. If there are unknowns, it’s only natural for anyone to estimate within a range – whether that’s for small elements of the project, larger elements or at an overall level.
- Include some contingency
Some organisations frown on the notion of having contingency for a project but we see it as essential. If there is no contingency allowed then people will naturally want to build it into the estimates they provide. Or, if forced to adopt most likely or optimistic estimates, the project will be in constant danger of change requests. Much better to pick a lower number to aim for and strive not to use contingency than to have no contingency in the first place.
This is not to say that use of the contingency need be entirely at the discretion of the project manager. Contingency may be maintained separately and only available on request from a Steering Committee or other governance entity.
- Workshop the project risks
As noted above, you should have experts estimating different aspects of the project and each of them will have a different perspective on the risks the project may face. For the Change Manager it may be that additional training slots might need to be made available if not all users can make the first tranche of training. For developers it might be complications in the coding or longer than expected test support. All these risks should be fielded, included in a risk register and thought be given as to what contingency should be built into the project in case the risks arise.
Try to consult Post Implementation Reviews that were conducted at the organisation recently for similar projects and see if there are points raised in these reviews that should be considered in the estimation for your project.
- Don’t oversell, be open and honest
There is usually pressure to paint a positive picture with the business case when seeking approval for the project. In other words, to sell the project in the best possible light. Your job as estimator is not to be part of this sales team – especially since the one facilitating the estimation is often the project manager that will be responsible to deliver to the estimates.
If there is pressure to reduce or eliminate certain elements of the project (e.g. a specialist Change Manager) then be clear what the risks are of this approach. Agitate for an increased contingency if you feel there are short cuts being taken and explain why.
There’s nothing worse as a Project Manager than taking on an under-estimated project and being expected to deliver an outcome.
Finally, remember that project estimates are just an educated guess at a point in time. When a project first starts, the forecasts will essentially equal the budget – i.e. the initial estimates. As time passes, the project is underway and we discover more, the accuracy will increase, forecasts will change and the amount held in contingency can likely be reduced.
Think of a project as a long trek to some mountains you can dimly see in the distance. It’s hard to judge the distance from the very start and impossible to see some of the obstacles that are hidden from you along the way. As you go along you can make better judgements about how fast the team can travel per day, you put some terrain behind you and what’s in front becomes progressively easier to see.
