Mastering Project Estimation: Simplified Techniques for Reliable Scheduling

When planning a new project, your boss, your client, or your project sponsor will want to know…

“How long is this going to take?”

So, you need to give an answer. The problem is that projects are unfamiliar and uncertain. The Project Management Institute defines a project as “a temporary endeavor undertaken to create a unique product, service, or result.” By definition, there can be no data on exactly how long this unique effort will take.

The solution, of course, is estimating.

There is a whole science to estimation, and it would be possible to go very deeply into this. But that’s not what 90% or more of Project Managers need. We need simple techniques that get us close enough.

But before we start, let’s tackle the Estimation Elephant in the Room….

#NoEstimates

Agile projects are fast and adaptive. The estimation techniques they use are a deliberate trade-off between speed and accuracy. Agile practitioners don’t aim to predict the future. As a result, many believe that estimation adds little or no value. So, they try to minimize it as much as possible.

This created a trend of refusing to offer cost and schedule estimates – or to resist it. On X (formerly Twitter), practitioners give it the hashtag #NoEstimates. The argument for this approach is that estimates are rarely correct.

I’d argue that this misses the point of estimates – and that, with care, we can give valuable decision-making information. More to the point, our clients and sponsors need this data.

The Agile approach to estimation is therefore beautifully simple. Agile estimation will broadly size the project tasks (in time and in cost) and then get on with the project.

Tee-Shirt Sizing

This agile estimation technique starts by breaking the project into discrete components of work. Each one will deliver something of value. We then make estimates of how long it will take, by comparing the sizes of each task. These are then described as one of a small number of “tee-shirt sizes,” such as small, medium, large, or extra-large. We would associate a certain number of days with each size. Agile practitioners often use Fibonacci numbers for the durations.

Fibonacci Numbers in Schedule Estimation

One of my favorite innovations from the Agile community is the use of Fibonacci numbers for scaling our estimates. Instead of estimating durations at 1, 2, 3, 4, 5, 6…units of time, we need to recognize that this level of precision is rarely merited by our level of understanding. The Fibonacci numbers, 1, 2, 3, 5, 8, and 13 follow a progression so that each subsequent gap is larger than the previous one. It nicely represents the imprecision in our estimates, and avoids the trap of mistaking precision for accuracy.

Planning Poker

Another schedule estimation method that uses Fibonacci numbers is planning poker. This introduces a process for crafting a shared understanding of schedule estimates, based on the different perspectives of team members.

Each person makes an estimate on their own and selects an appropriate special playing card with a Fibonacci number on it. When they have made their choice, they place it face down on the table. When everyone is done, they reveal the cards and discuss their reasoning. From the discussion, a deeper understanding can grow, from which a consensus emerges.

Order of Magnitude Estimating

Before we used Fibonacci numbers, we used an even more rough and ready approach – sometimes referred to as “back of the envelope” estimation. This focuses on getting the right order of magnitude. That is, the correct number of zeros! Will this take a few days, a few tens of days (weeks), or a few hundreds of days (months or even years)?

These scale estimates are often the starting point for determining whether a project even looks viable. Usually, we base this approach on our experience and simple real-world comparisons.

We can go further by calling upon experts to make the estimates. This “expert judgement”can be at Order of Magnitude precision or can develop more detailed estimates. While all estimates require us to document our assumptions and reasoning, we can expect expert judgement to be more thorough.

**Parametric or “Rules of Thumb” Estimates**

Expert judgement often starts with simple rules of thumb. It takes two days to commission one unit, so it will take ten days to commission five. The proper name for this is “parametric estimating” because it starts with assumptions about the parameters that go into the calculation.

Top-Down or Bottom-Up Schedule Estimation?

Simple schedule estimates are usually top down. We start with the whole project and break it into successively smaller parts, until we have component activities that we can understand, and for which we can make estimates – maybe parametric or using tee-shirt sizes, for example.

We use bottom-up estimating when we don’t properly understand the whole project and need to start by listing everything we think we need to do. The dangers of this should be evident – we can easily miss a whole class of tasks. However, as a check on other methods, this is an excellent additional step.

Multiple Estimators

All the evidence suggests that if several people make an estimate, the average is likely to be more accurate than any one estimate. The exception is when everyone makes the same systematic error.

So, get two or more independent estimates, and then compare them. If the core assumptions and methods are similar, then take the average. If there are differences in approach, discussing and understanding them can lead one or more estimators to change their approaches.

Gathering Data

There are many ways to gather data to feed into our estimates and to size the parameters of our parametric estimation. We can do sample tasks (sampling) or look for data in past, comparable projects (reference classes or comparative estimation). We can even test the market by checking the costs in catalogues or seeking competitive tenders or quotations.

This can be a simple way to improve estimates – or simply to test the estimates we have made against something real.

Sense Checking

You should always review the estimate for a non-trivial project for “common sense.” Better yet, get someone else to do the review. The reviewer should check the assumptions and re-work the calculations. They should also do a back-of-the-envelope order of magnitude estimate of their own, to see if the primary estimate is plausible. Does the final estimate seem about right? If not, is the reason apparent?

Contingency

Any estimate will be wrong. What is important is that there is enough “rightness” in it to be useful. One way to make it more “right” is to add contingency. That is, add an extra allowance of time to account for estimating errors like:

Bias – most common of which is optimism
Missing something
Unpredictable events

I’ve heard that civil engineers multiply the tolerances of the structures they design by 3. I don’t know if it’s true, but I’m sure they do apply a scaling factor for safety. You must do the same with your project estimates.

Add extra funds to your budget, extra materials, additional people, and certainly more time to your schedule. How much to add is a matter of judgment. Largely, it will depend on the nature of the project (or each workstream). For example:

How familiar or novel is your task? The less familiar you are, the harder it will be to get estimates right.
What is the level of risk? Greater risk means the need for more time to fix problems.
How complex is the task? More complex means more uncertainty from the interdependencies.
How big is the task? Bigger means more things can go wrong.

The two main approaches to contingency are:

Adding extra amounts of time to each part of your estimate.
Multiplying each part of your estimate by a number bigger than one.

And, because each part of your estimate may be subject to different uncertainties, complexity, and scale, you may use different contingency amounts or factors for each part.

Unless the work you are doing is is very familiar, expect a contingency in the range of 10% – 30% or maybe even higher for very new types of projects. Then consider additional work on risk reduction. This will increase the amount of work (and cost) but will allow you to reduce the contingency.

Finally, a few reminders.

Things We Often Miss in Schedule Estimates

This is not, of course, a complete list, but I have seen these ten items missed on many occasions:

Management overhead – the time it takes to manage the project and in organizational change management.
Non-productive time like holidays, company events, absences, or core administration.
Contingency that is consistent with the confidence level attached to the base estimate and reflects the level of project risk.
Time for briefings, training, familiarization, and even project meetings
Procurement time – especially for negotiations, internal approvals (both yours and the contractor’s), and delivery times.
Faults and errors – the time to find them through testing and the time to diagnose and fix them.
Scope creep – managing effective change control at best, and the unplanned and un-managed changes in scope at worst.
Maintenance of tools, equipment, and (most often) computing resources.
Where your project has a technical component, the commonly underestimated items include the challenges of integration and data preparation, clean-up, back-up, and migration.
Project administration can often take up far more time than we expect – and we often fail to budget for it. This is es especially so at the close of the project when your team is more focused on what’s next than on closing off this project!

Summary

Schedule estimation is a challenge for any project manager. However, with the right approaches, you can make simple estimates for a range of projects quickly and effectively. As long as you understand their limitations, check for basic errors, and add a sufficient contingency, your estimates will be a sound basis for robust decisions.

Mastering Project Estimation: Simplified Techniques for Reliable Scheduling