Project Estimation: Master the Art and Craft

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.

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.

Why is Project Estimation so hard?

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

Project Estimation – Master the Tools and Techniques

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, dar by, events.’
2. Quantitative
   Assessing the sot 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.
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, that 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 by powerful stakeholders, or just from a personal desire to please.

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

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

1. the desire to allocate adequate budget, resourses, 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 maximise the chances that it will go ahead.

The Estimation Knife Edge

Methods and Tools for Project Estimation

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:

• 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 judgement and document their assumptions and reasoning.

Parametric or ‘Rules of Thumb’ Estimates

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.

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.

Reference Class Forecasting

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 Estimating

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

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

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 for 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 judgement 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 prioritisation, 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 you 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. 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 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. Analyse 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 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 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 three simple tools Agilists often use:

• Tee-shirt sizes
  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.
• Bucket method
  Set up buckets of relative sizes. Place the first item in a mid-size bucket and then deiscuss each sbsequent item in terms of which higher or lower size bucket it belongs in.

Sources of Error in Project Estimation

The Project Estimation Process

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

1. Understand the context for your project
   This will give you an idea of political pressures.
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.
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?
   Analyse dfferent scenarios, and see how your estimates and contingency will fare.
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.

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.