Project Estimating Skills: How to Master Successful Project Estimation

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:

1. What is Project Estimation?
   And why is it so hard?
2. Why do We Need to Make Estimates?
3. Response to the Challenges: Understanding Estimation
4. Methods and Tools for Project Estimation
5. How Project Managers apply Caution to our Estimates
6. Some Less Common Methods for Project Estimation
7. Agile Methods for Project Estimation
8. Sources of Error in Project Estimation
9. The Project Estimation Process

What is Project Estimation?

We should always start by defining our terms. Estimating is:

Estimation:
Making a quantitative assessment of how much benefits, cost, resources, effort, or duration that a part or all of your project needs for completion.

The Challenges: Why is Project Estimation so Hard?

There are at least four things that make estimating for projects a difficult discipline:

1. Future
   First, it requires you to look into the future. And that’s an uncertain future, where shift happens. When asked what worried him most, British Prime minister, Harold Macmillan, answered: ‘Events, dear boy, events.’
2. Quantitative
   Assessing the sort of things you’ll need to do and the kind of time and effort it will take is easy. But putting numbers to them… That puts many of us out of our comfort zone. Especially as the level of uncertainty leads us to be certain of just one thing – our estimates are unlikely to be accurate.
3. Bias
   I’m not talking about deliberate bias or the need to conform to pressure (which is up next), but the in-built biases in the way our brains process information. The most relevant here is the optimism bias, which leads us to believe things will go as they ought to go; as we plan them. D’oh!
4. Pressure
   You may not deliberately adjust the figures on your project (though many do), but you will someday come under pressure to do so. This may be from powerful stakeholders, or just from a personal desire to please others.

Where does the pressure come from? The Knife-edge

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.]

The ‘Knife-edge’ represents the two competing pressures of:

1. the desire to allocate adequate budget, resources, and time, to ensure the maximum likelihood of delivering within your estimates. In a truly commercial environment, this is the only way to assure that your project is profitable.
2. the wish to reduce your cost and schedule estimates, to ensure your project is appealing to its sponsors and stakeholders, and thereby maximize the chances that it will go ahead.

Why do We Need to Make Estimates?

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:

• Investment decisions demand an indication of costs and benefits
  Without them, there is no way to assess the value and therefore the reasons to or not to invest. They may also require a robust time estimate to understand if the project solution can properly address a need.
• Planning requires estimating
  Estimating durations cannot be separated from understanding resourcing, which in turn drives cost estimates. Cost and schedule estimates are deeply interdependent. And therefore, without them, we cannot plan. And, without a plan, there is no confidence.
• Organizations need to set and approve budgets
  This is clearly related to investment decisions and to planning. But it is also a pragmatic response to established organizational practices and business cycles.
• Every estimate is wrong
  What matters is how wrong or, put differently, how reliable it is. We’ll look more at confidence and uncertainty levels below. Here, I want to focus on the role of estimating in risk identification, analysis, and management. Estimates contain assumptions and assumptions create risks… that they are wrong.

Response to the Challenges: Understanding Estimation

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.

Confidence and Uncertainty Levels and Ranges

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:

• Cost estimate = $100,000 +/- 12%
  Note this is an example of a symmetric confidence range
• Schedule estimate – 30 September +20 days / – 10 days
  Note this is an example of an asymmetric confidence range

Probabilistic versus Deterministic Estimates

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 and Precision are Different

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!

Relative and Absolute Estimating

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.

Methods and Tools for Project Estimation

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:

• The Main Methods
• How Project Managers apply Caution to our estimates
• Some Less Common Methods

The Main Methods for Project Estimation

These are the methods that every project manager should be aware of and understand.

Order of Magnitude Estimates (OOM)

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.

Expert Judgement

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.

Top-down Estimates

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.

Parametric or ‘Rules of Thumb’ Estimates

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 bricks, 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.

Reference Class Forecasting

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 Estimating

Three-point estimates are a major feature of the PERT Method for project planning and estimating.

Three-point estimates use estimates of:

1. Low estimate (L)
2. Mid estimate (M)
3. High estimate (M)

the commonest ways of aggregating them are symmetric:

• Triangle Estimate E(T) = (L+M+H)/3
• Beta or PERT Estimate E(b) – (L+4M+H)/6

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’.

Sampling

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.

Bottom-up or Analytic 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.

Tenders and Contracts

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.

Catalogs and Pricing Schedules

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.

How Project Managers apply Caution to our 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.

Be clear about your assumptions

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:

1. Articulate and document all of your assumptions
2. Test each of them for validity or at least plausibility
3. In the latter case, check the impact of applying a different assumption

Multiple approaches

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.

Contingency

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:

• How familiar or novel is what you are doing?
• What is the level of risk?
• How complex is the task?

Phasing to learn from progress

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.

Reviews at ends of phases

…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.

Some Less Common Methods for Project Estimation

Here’s a round-up of my own favorite ways to strengthen your project estimation process.

Formal Stakeholder Engagement

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 Technique

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.

1. Select your panel of ‘experts’
2. Develop your initial set of questions, and send them to all participants. Ensure that, as well as asking them for their estimates, you also elicit their reasons
3. Analyze and tabulate the results, including the reasons.  Based on these, prepare a second set of questions
4. Return the results to each participant along with the reasons and the new questions
5. Continue looping back to step 3 until little or no change occurs.  Then prepare your analysis and report

Relative Scale and Complexity Factors

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.

Red-team Review

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.

Monte Carlo Method

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 Methods for Project Estimation

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!

#NoEstimates

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.

Good if you can get it

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.

Collaborative Project Estimation

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.

Here are four simple tools Agilists often use:

• Tee-shirt sizes
  The relative sizing of work components as Small (S), Medium (M), Large (L), or Extra Small (XS), Extra Large (XL), and even XXL
• Planning Poker
  This is based on the Delphi Technique, in that it hides each person’s estimates until everyone has made their own estimate. Team members make their estimates by playing special cards face-down on the table, instead of speaking them aloud. Then, they reveal the card and discuss the estimates and their reasoning. For more on Planning Poker, we have a video: What is Planning Poker? | Video
• Bucket method
  Set up buckets of relative sizes. Place the first item in a mid-size bucket and then discuss each subsequent item in terms of which higher or lower-size bucket it belongs in.
• Story-pointing
  Allocating a score, typically on a scale of 1-100 story points, to represent the size of the task represented by delivering each user story.

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.

Sources of Error in Project Estimation

Technical Reasons

1. Test and Fix
   We often make the implicit assumption that the test stage will find nothing more than minor problems. This is often not the case, so allow extra time, resources, and money for remediation and re-testing.
2. Integration
   We often budget and schedule our projects as if they are free-standing. The reality, of course, is that it is important to integrate what we hand over into the existing infrastructure. And sometimes that time and cost fall on the project. If you’ve missed it out of your estimates, you will get a last-minute over-run.
3. Tweaking and polishing
   It always amazes me how much time we spend on the very last bit of each deliverable, tweaking and polishing it.
4. Maintenance
   Projects are about getting things working. Maintenance is an operational, steady-state activity. But in long projects, you’ll sometimes need to budget for maintenance prior to handover.
5. Complexity
   I discussed this above, to often we neglect the complexity of our projects and pay for the omission in schedule over-runs.
6. Scope Creep
   You know it happens. So, why do so few project managers add its effects into their whole-project estimates?
7. Snags and glitches
   Nothing ever goes quite as planned, so estimate extra contingency for the minor snags and frustrations that are inevitable in any project.

People-related Reasons

1. Politics
   It’s too easy to forget the impact that one or two people playing politics can have on your project. It can drain your time and that of other senior people. Worse, it can trigger re-work and changes in direction.
2. Meetings
   We often show meetings as a milestone on our Gantt Charts. But milestones have zero resources and zero duration. Oh, if only! If you have a lot of meetings, if your meetings are long, and if they involve lots of team members, they can be a big drain on planned resources and timelines, unless you add them into your estimates explicitly.
3. Familiarization / induction
   There’s an implicit assumption in many project estimates. We assume that new members join the team and get started with productive work straight away. It never happens. And it’s not just downtime for them. It’s also downtime for you and any other colleagues involved in welcoming and briefing new people
4. Distractions
   How many days do you spend completely focused on what you set t to do? And, what about your team members? Add an allowance for this ‘distraction time’ and its associated costs, to your estimates.
5. Arrogance and bias
   Finally, we all think we are the best – or at least, better than average. Yet half of us are less skilled, less efficient, and less motivated than average. If you base your estimates on what you think you can achieve, you will be prey to the bias that you are better than average. Most likely, you are around average. And so too are many of your team. So, here’s my tip. Base your estimates on what a colleague in a similar role to you could do. We’re far more objective about other people’s capabilities!

The Project Estimation Process

Let’s start to wrap up this article with a consolidated project estimation process.

1. Understand the context of your project
   This will give you an idea of political pressures and external dependencies.
2. Understand history
   Look for reference projects and parametric data you can use.
3. Understand the requirements
   Do your research on what the stakeholders need. And also look at how differing requirements among stakeholders can lead to conflict and future political pressures that can affect costs and schedules.
4. Document your assumptions
   That way you’ll be able to test them later and change them if you need to.
5. Top-level estimate
   Start with a high-level initial estimate (see below).
6. Detailed estimate
   The most structured approach is to break your project down to parts with a WBS.
7. Confidence level
   Add confidence levels to your estimates, to get a sense of how certain or not you are. This will inform…
8. Contingency
   Add extra time or budget to your estimates, based on how confident you are about your estimates.
9. What if?
   Analyze different scenarios, and see how your estimates and contingency will fare. Select a range of plausible scenarios – including some your team may consider to have a low likelihood.
10. Checking and review
    Always check your arithmetic. And compare your estimates with a simple Back of the Envelope estimate as a simple sense-check.

The Sequence of Project Estimating Approaches

Finally, here’s a quick summary of which tools are best for each level of detail in your planning process:

1. Initial estimate
   OOM, top-down, parametric, or experience-based
2. Outline Planning estimate
   Parametric, sampling, three-point estimates, cautions
3. Detailed planning
   bottom-up

Have Your Say

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.