There are two reasons why Project Estimation is a big deal for project managers. First, it’s extremely hard to do well. And second, poor estimates are often a primary reason for a project cost or schedule over-run.
So, in this article, we’ll take a careful look at project estimation, to help you learn how to master the art and craft of doing it well.
We should always start by defining our terms. Estimating is:
Making a quantitative assessment of how much benefits, cost, resources, effort, or duration that a part or all of your project needs for completion.
There are at least four things that make estimating for projects a difficult discipline:
In any commercial or quasi-commercial* environment, you’ll find two competing pressures on your estimates. These presures push you to either side of a knife edge. Getting it right means walking that knife edge.
[*By quasi-commercial, I mean a non-commercial environment like the public or voluntary sector, which imposes financial or schedule pressures in much the same way as a commercial environment.]
We’ll start by looking at traditional project estimations methods and tools. Then, in the next main section, we’ll take a brief look at the Agile domain. In this section, I’ll separate our methods into three chunks:
These are the methods that every project manager should be aware of and understand.
Broad brush scaling estimates are often the starting point for determining whether a project even looks viable. Usually this accesses experience and simple real-world comparisons.
This is the first of a number of ‘experience-based’ approaches to estimating. It is more formal and structured than OOM estimating. It calls on an expert to apply their judgement and document their assumptions and reasoning.
This is often a source for expert judgement. If we know that it takes 15 minutes to lay 10 ricks, or that we can lay 43 bricks an hour, then we have the basis for estimating how long it will take a wall with a fixed number of bricks per square metre.
This takes the project and breaks it into parts, so that we can make estimates for the major areas of the project, often with contingency for each.
This approach has other names: Comparative or Analogous Estimating. It uses knowledge of past projects to inform your estimates of the current one. It is another example of applying experience, but here we access real data rather than tacit knowledge. A big part of skill here is to find suitable reference sources. It’s also important to include unplanned events from those projects into your estimates, otherwise you’ll simply repeat the original estimating errors. Finally, a large enough sample will give you valid statistics. A single analogous project is interesting but far from rigorous.
Three-point estimates are a major feature of the PERT Method for project planning and estimating. You can learn more about this in our short video, What is a PERT Chart? and get a more detailed insight, in our guest article by William Davis, ‘Make Your Project Estimation More Reliable, Using the PERT Method’.
An excellent approach to acquiring real data for a rigorous estimate, is to do trial or pilot work, and sample that experience for parameters and references to inform your full estimates.
The most rigorous approach is to make individual estimates for each item at the bottom-tier of a carefully-prepared Work Breakdown Structure, or WBS. This allows you to accumulate your estimates, and subject each to scrutiny. It’s a good corrective to some of the more common biases, but is a time-consuming approach. However, for serious project managers, this is the gold standard, and a steping stone for robust testing of your plan.
Once you have your estimates, it can be tempting to move on quickly. But slow down. Your job involves prudence, and even caution. So here are some tips for how to do that.
All estimates and forecasts are rooted in a set of assumptions. There’s nothing wrong with that. But what can be a problem is untested assumptions. More so still, embedded assumptions that you aren’t fully aware of. So:
One estimating method, carefully applied, is good. Two are better, and three is best. The approaches I’ve listed above (and the less common ones below, are not exclusive choices. Many of them complement one-another. Any differences you get from using two or more will be enlightening, and may point you to errors, omissions, or dodgy assumptions.
It’s said that civil engineers multiply the tolerances of bridges and other structures by 3. I don’t know if it’s true, but I am prepared to bet that they do apply some such scaling factor for safety. You must do likewise with your project estimates. Add extra funds to your budget, extra materials, additional people, and more time to your schedule. How much is a matter of judgement and will depend on the nature of the project (or each workstream). For example:
If you structure your project – especially the early part – into phases, you can pause, take stock, and learn from experience. This will let you check your estimates and revise them if necessary. Add to this the idea of prioritisation, starting with the most important components, and you have some of the basics of the Agile philosophy.
…and at milestones during delivery. Even if you don’t introduce phases for the purpose of testing your estimates, you will have project stages anyway. Use these, and you major milestones, as a chance to review your estimates.
Here’s a round-up of my own favorite ways to strengthen your project estimation process.
The main reason I like engaging stakeholders in my project estimation process is simple. If they are a part of the estimating process, then they’ll find it harder to assertively criticize the estimates, if events cause them to be wrong.
But, since what we really want is better estimates, this approach is invaluable. Stakeholder are often a diverse mix of experts and non-experts. By engaging a broad cross-section, and then aggregating your estimates, you can access Wisdom of the Crowd. The Wisdom of Crowds (US|UK) is the title of one of my all time top book recommendations to serious career project managers.
The Delphi method is a structured way to pool the opinions of many experts to reach a group solution. It was developed in 1969 by the Rand Corporation to facilitate technological forecasting. It has the benefit of overcoming the bias introduced by some voices being more dominant than others – by virtue either of personality or eminence.
Here is a process for using the Delphi Method for estimating.
Review your estimates in the context of the scale and complexity of the project. Both elements introduce additional cost and time overheads to your project. In particular, if you double the number of team members, work-packages, or stakeholders, for example, you can quadruple the time and cost of managing communication, validation, and other interface-based activities.
One way to reduce complexity of your project is to break it up, as much as possible, into discrete, free-standing components, with minimal interdependencies. not only does this make your estimates more reliable, it also reduces time and cost.
At the completion of your estimating process, hand over all your calculations and assumptions to the smartest, most critical people you can find. Invite them to test and challenge everything. The more holes they find in your calculations, assumptions, and methods now, the better. It’s only later that you will have lost the chance to fix them.
This is a computationally-intense simulation process. I shall say nothing more here, as we have a full length feature article by expert, William Davis.
Agile project estimation techniques are designed to be fast, as a deliberate trade off against accuracy. Because, Agile practitioners don’t aim to predict the future, believing that estimation is a non-value adding activity. So, they try to minimize it as much as possible.
The fact that they do it at all, seems to be a recognition that it is necessary!
This has spawned a trend to try to avoid giving cost and schedule estimates. On Twitter, practitioners give it the hashtag #NoEstimates. They argue for this with the question, ‘when is an estimate ever right?’ The answer some of us give is ‘when you do it carefully.’
The Agile alternative is to broadly size the project tasks and get on with the project. That sounds great to them: you don’t need to provide estimates; you just keep spending until you run out of cash.
If you can get away with that, good luck. You don’t need this article.
But, in my experience, clients demand to know how much their project is going to cost. This will let them create a business case, so they can compare costs with benefits, and calculate if it’s worth doing. For that, they’ll need a cost estimate. And, where’s the money coming from? If it goes ahead, they’ll need to budget for your project. For that too, they’ll need a cost estimate.
As with much else in Agile, its estimation techniques are collaborative. In Scrum, for example, the whole Scrum team participates in estimating the effort it will need to put into the Product Backlog Items. The other feature of most Agile estimation techniques is that they use relative units. They try to avoid estimating dollar costs or days directly. Instead, they use point schemes or qualitative labels to compare the items they are estimating with one-another. This harnesses our human ability to compare the sizes of things more accurately than we can estimate absolute values.
Let’s start to wrap up this article with a consolidated project estimation process.
Finally, here’s a quick summary of which tools are best for each level of detail in your planning process:
We’d love to hear from you in the comments section below. Tell us what your approaches are, and what you find difficult. I’ll respond to every comment.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.