Our website uses cookies. By continuing to use our website you are agreeing to our use of cookies.
Close this message.

eLearning Log in

Login here using your username and password

Forgotten login?

How do I develop project estimates?


A good plan violently executed today is better than a perfect plan next week.’
George S. Patton Jr

Projects tend to suffer from an optimistic bias, as people to tend to have high expectations about the outcome of planned actions. This includes overestimating the likelihood of positive events and underestimating the likelihood of negative events. It is also reflected in overestimation of benefits.

There are a number of reasons for this. These include:

  • Lack of experience in the type of change
  • Leadership that enforces the ethos of ‘just do it’
  • Lack of willingness to face up to the reality of how long it will take or how much it will cost
  • Capability of the organization to deliver the change
  • No basis for estimation, and therefore no basis on which to improve.

When making estimates, it is a common failing to think in terms of how long it will take to get the job done rather than the amount of effort it will take to do the job. These are completely different concepts yet they are often used within projects without this being recognized.

This extract has been reproduced with permission from A Practical Guide to Project Planning, TSO 2016.  If you’d like to read more you can purchase the copy of the book here.


As part of estimation, we need to understand whether we are talking about 5 days’ work, or 1 day’s work that will be completed within 5 days. Without this understanding we cannot properly estimate the cost or time required.


To produce effective estimates it is necessary to understand what tasks are required, and what activities need to be undertaken to deliver an output.

As well has having capital costs, each task will take a certain amount of resource effort, and there will be a timeframe within which that resource effort will be undertaken. There are a number of ways of estimating both effort to do the task and the likely period of time (or duration) needed to complete the task.

There is no substitute for experience when developing estimates. This can be gained from investigating:

  • Previous projects
  • Other organizations and reference sites that have done this type of project before
  • Expertise on the topic area.

All three of these sources are valuable input into the techniques.

There are a number of techniques for estimating, some basic and some more advanced, and these are outlined in the sub-sections below. The project board should be heavily involved in making the decision about which approach to estimating should be used. For example, top-down estimating carries significantly more risk than bottom-up estimating, so the approach selected will reflect the board’s appetite for risk and potentially the consequences of failure.

There are areas where the project team may assume that the stakeholder resources will be available and not include them in the estimates, but whether they are available or not could have a big impact on the operational performance. This is why the stakeholders must be involved in the estimation process and sign up to their commitment to the resource levels. Before the project goes forward, they must also re-affirm that commitment.

Before estimates are finalized you should agree who is responsible for the following aspects involving stakeholders:

  • Meetings to assist with specifications or estimates
  • Training
  • Workshops for risk or stakeholder analysis
  • Testing
  • Travelling to the above
  • Commenting on documents
  • Calls and emails.

Estimating techniques: basic

Top-down estimation

Top-down estimation recognizes that there are limitations to what can be achieved and takes the position ‘What can we do in x timescale and with y budget?’. The estimate should include things that simply must be done, plus the highest priorities for whatever time/budget is left over.

Back-cast planning

Back-cast planning is useful for ‘softer’ projects, where the destination is clear but the journey is proving difficult to construct, or there is an immovable deadline imposed externally.

It asks the question ‘What will we need to have in place to achieve xxx outcome?’ Some people find it easier to work backwards to work out what has to be done. As the technique focuses on the ‘must-dos’ it can avoid distractions and unachievable requirements and establish the minimum that has to be done and, in effect, the critical path.

Any additional outputs that the project delivers will be negotiable or can be delivered after the non-negotiable deadlines have passed.


Timeboxing is a technique common in planning projects (typically for software development), where the schedule is divided into a number of separate time periods (timeboxes, normally 2 to 6 weeks long), with each part having its own deadline, deliverables and budget.

Timeboxes are used as a form of risk management, especially for tasks that may easily extend past their deadlines. The end date (deadline) is one of the primary drivers in the planning and should not be changed as it is usually linked to a delivery date for the output. If the team exceeds the deadline, the team has failed in proper planning and/or effective execution of the plan. This can be the result of the wrong people on the wrong job (lack of communication between teams, lack of experience, lack of commitment/drive/motivation, lack of speed) or underestimation of the (complexity of the) requirements.

Bottom-up estimation

The bottom-up approach takes a detailed look at the outputs that need to be produced and works out the time and cost to deliver the stated objectives.


Product-based planning is a bottom-up approach.

Where the estimates exceed the time or cost estimates of the project board, a structured and systematic approach to deciding what must stay in scope and what can be removed needs to be undertaken until the plan meets the aspirations of the board and can be included in the business case. At this point, bottom-up estimating meets top-down estimating.

Three-point estimation

Three-point estimation is a popular technique used to estimate the outcome of future events based on very limited information. It should be used for either top-down or bottom-up approaches as a way of establishing a reasonable likelihood of events.

In three-point estimation, three figures (BC, LC, and WC) are produced initially for every activity that is required to complete the task, based on prior experience or best guesses:

  • Best-case estimate (BCy)  Here it is assumed everything goes according to plan, none of the risks materialize and there are no issues.
  • Most likely estimate (LC)  This allows for some risks and issues materializing but assumes that contingency plans work and no major unexpected events happen.
  • Worst-case estimate (WC)  Here everything that could go wrong does, risks materialize, issues are worse than expected and other unexpected events occur. This estimate will reflect the maximum amount of contingency that will be required to deliver the output.

We can then apply a simple formula to achieve the estimate (E):

E = (BC +LC + WC)/3.

The dividing number can change as your experience increases, this works for the first time you do a task, because each option has an equal value. If you have done the task 20 times, then your likely case is based on experience, so you might wish to weight it accordingly to show the increased confidence in the estimate.

Estimating techniques: advanced

There are two more statistically elegant techniques that can be used. These are the programme (or project) evaluation and review technique (PERT) and the Monte Carlo simulation technique.

Programme (or project) evaluation and review technique

PERT is a statistical tool used in project management that is designed to analyse and represent the tasks involved in completing a given project. It is commonly used in conjunction with the critical path method where the performance of a task consumes time and requires resources (such as labour, materials, space, and machinery). It can be understood as representing the time, effort and resources required to move from one event to another. A PERT activity cannot be performed until the predecessor event has occurred. The estimated duration (TE in the PERT tool) is the best estimate of the time required to accomplish a task, accounting for the fact that things do not always proceed as normal (the implication being that the expected time is the average time the task would require if the task were repeated on a number of occasions over an extended period of time). The estimate is represented by the formula:

TE = (O + 4M + P)/6, where:

O (optimistic time) is the minimum possible time required to accomplish a task, assuming everything proceeds better than is normally expected.

P (pessimistic time) is the maximum possible time required to accomplish a task, assuming everything goes wrong (but excluding major catastrophes).

M (most likely time) is the best estimate of the time required to accomplish a task, assuming everything proceeds as normal.

Be aware that if this is the first time you have done the project or task, the likelihood of best and worst case are similar, so the use of ‘6’ as the division is assuming that the task has four previous occurrences to draw from. Therefore in previous iterations the likely case has happened 4 times, but the best and worst case could still occur, so consequently it is divided by 6.

When the technique is used across a group of activities to achieve a task, it should give a more balanced view of the total time because it will balance the risk of things going well and badly. It is still based on guesstimates if there is no previous experience to draw on, but it reduces the bias described earlier that can affect planning estimates during periods of early optimism!

Monte Carlo simulation technique

If we have a critical path network with known dependencies and estimates for optimistic, most likely and pessimistic durations, and we can input any distribution of probabilities, then we can simulate an implementation based on a random assessment of duration for each task. The result is recorded and another simulation is done, and a new recording made. This Monte Carlo simulation calculates the model hundreds or thousands of times, each time using different randomly selected values. When the simulation is complete, we have a large number of results from the model, each based on random input values. These results are used to describe the likelihood, or probability, of reaching various results in the model. We can see the likely durations in a distribution curve showing percentile probabilities of ranges of durations. This method is likely to be used in major engineering projects.


A simple example of three-point estimation for someone undertaking a journey is shown in the table below.

Three-point estimation example


Using the formula given above and the figures from the table, the estimate for the journey would be:

E = (2 + 4 + 8)/3

which would give a prudent estimate for the journey of 4 hours and 40 minutes.

Advanced example

For the figures given in the table above, PERT would give:

TE = (2 + (4 × 4) + 8)/6 = 4 hours 20 minutes.

On this page