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.
In this article, we’ll look at:
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 pressures 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.]
This is not as silly a question as it may seem. There are some Agile Practitioners who argue that estimating is pointless – and there is a whole hashtag of debate around #NoEstimates.
However, there are often very good reasons to take the time to make robust estimates. And here, I shall list some of the key reasons:
One of the strongest aspects of the new, 7th Edition of PMI’s Guide to the Project Management Body of Knowledge, is the short section on estimating in the Planning Performance Domain section of the chapter on Project Performance Domains.
This section offers us an excellent summary of the principles behind estimating. Your main response to the challenges of estimating is to understand how estimation works. Do take a look at PMBOK 7 here, but I will approach things in my own way.
An estimate is… and estimate. It is not reality, so there is some (maybe a lot of) uncertainty. As a result, an estimate only has value when we also express with it the level of confidence we have. Confidence is the inverse of uncertainty. Experience, data, rigor, checking, and review all decrease levels of uncertainty and increase our confidence levels. Novelty, volatility, ambiguity, and complex stakeholder environments decrease our confidence in any estimates we make.
We often express uncertainty or confidence in a range:
Where we have a range, we can also associate probabilities with different parts of the range. We would naturally assume, of course, that the central figure is the ‘most likely’ estimate. But that only means that it is more likely than any other single estimate.
And single estimates on their own – sometimes called deterministic estimates – are a poor practice that I would only endorse for smaller, less complex, or less important projects. The single number – a cost of $12,000 or a duration of 32 days – tells us nothing about how reliable we believe the estimate to be.
Accuracy refers to how ‘right’ your estimate is – how close it is to reality. Precision relates to how narrow is the range you place on your estimate. A 5 percent range is more precise than a 30 percent range. But the estimate itself may be no more accurate!
When I started in project management, almost all estimating was absolute: a number of elapsed days, a cost figure, an effort in person-hours…
The rise of adaptive (agile) project management approaches has seen a rapid growth in the popularity of relative estimating. This places the estimate of bone thing in terms of an assumed estimate of something else. For example, this piece of work will take 3 times as long as that one. We’ll look at examples of tools for this, below.
We’ll start by looking at traditional project estimation 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 judgment and document their assumptions and reasoning.
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 is a form of top-down estimating and is often a source for expert judgment. 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 approach has other names: Comparative Estimating 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 the 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.
Three-point estimates use estimates of:
the commonest ways of aggregating them are symmetric:
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. It is sometimes referred to as analytical estimating, because there are other approaches to bottom-up estimates, such as the Delphi method, below.
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 stepping stone for robust testing of your plan.
Strictly speaking, this is not estimating. If you have a completed bid or, better still, a contracted service, you have final costs for a component of your project. You can feed these into your estimates.
This too is not strictly estimating. You can access some elements of your cost from your suppliers’ published prices. You may still need to estimate quantities (or price increases over the duration of a long project). But this is hard data to reduce the risk in your estimates.
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 judgment 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 prioritization, 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 your 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. Stakeholders 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 is the title of one of my all-time top book recommendations for 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 the 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 the 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.
These are examples of a wider class of methods, known as ‘Affinity Grouping’. This is a Relative Estimating process that involves classifying each item into a group with others of the same size or within the same size range. Often, the size ranges relate to one another through the Fibonacci series of numbers:
1, 2, 3, 5, 8, 13, 21, 34
These numbers are widely used in all four methods, above.
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 14 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.
Powerful Negotiation Skills: Your Guide to How You Can Win
Failing Project: Do You Know When it’s Time to Pause Your Project?
How to do a Basic Agile Project | Video
Project Quality Management: Principles and Practices You Need to Know
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.