How to estimate task durations: methods, a worked example and the mistakes to avoid

A schedule is only as reliable as the durations it is built on. Dependencies, calendars and the critical path all do their job correctly, but if the numbers going in are wishful, the finish date coming out is wishful too, and it looks precise enough that nobody questions it.

This guide covers the difference between duration and effort, the four estimating techniques worth knowing, a three-point (PERT) example worked out step by step, and how to turn a set of uncertain estimates into a finish date you can commit to.

Why duration estimates go wrong#

Estimates rarely go wrong because people cannot do arithmetic. They go wrong for predictable, human reasons:

• Optimism. Daniel Kahneman and Amos Tversky introduced the term planning fallacy in 1979 to describe the tendency to predict that one's own tasks will go to plan, even when similar tasks in the past did not.
• Anchoring. The first number spoken in a meeting, often a deadline someone already has in mind, pulls every later estimate towards it.
• Parkinson's law. C. Northcote Parkinson observed that work expands to fill the time available. Generous estimates are not automatically safe: the slack tends to be used up instead of saved.
• Missing work. Reviews, rework, approvals, hand-overs and waiting for answers are real work that rarely appears on the task list.

The techniques below do not remove these biases, but they make them visible and give the team a common method instead of a negotiation.

Duration, effort and elapsed time are not the same#

Three different quantities hide behind the question "how long will it take?":

A schedule needs duration. If a business analyst has 24 hours of work on a task but is available half-time, the duration is six working days, not three. If the task finishes on a Friday before a public holiday, the elapsed time grows further, but that is the calendar's job, not the estimate's.

Ask people for effort and availability, then derive duration. Asking directly for a date mixes the three quantities and invites anchoring.

Four estimating techniques and when to use each#

In practice the techniques are combined. A small team planning a website relaunch might use analogous estimates for the whole project to check feasibility, parametric estimates for content migration (pages × time per page), bottom-up estimates for the next four weeks and three-point estimates for the two or three tasks nobody has done before.

Bottom-up estimating works best when the tasks are the right size. If a task is too large to estimate with any confidence, that is a signal to split it into subtasks.

Three-point estimates and PERT, with a worked example#

Three-point estimating asks for three values instead of one:

• O, optimistic: everything goes well, no rework.
• M, most likely: what usually happens.
• P, pessimistic: things go wrong in realistic ways, short of a disaster.

The Program Evaluation and Review Technique (PERT), published in 1959 by Malcolm, Roseboom, Clark and Fazar for the US Navy's Polaris programme, combines them into a weighted mean, (O + 4M + P) / 6, and estimates the spread with (P − O) / 6^[1]. Three-point estimating and PERT are part of the standard project management vocabulary used by PMI^[2].

Example: a data migration

For "Migrate the data": (4 + 4 × 6 + 14) / 6 = 42 / 6 = 7.0 days, one day more than the most likely value. The spread is (14 − 4) / 6 ≈ 1.7 days.

The chain as a whole tells the more important story. A plan built on the most likely values says 12 working days. The sum of the PERT means is 13.8 days: almost two days more, simply because the risks are lopsided. Things can go a little better than expected, but they can go much worse. That asymmetry is invisible when each person gives a single number.

From single estimates to a finish date you can commit to#

Adding up PERT means gives a better expected duration for a single chain, but a real plan has parallel paths that merge, and a merge point waits for the latest of its predecessors. Arithmetic by hand stops working quickly.

A Monte Carlo simulation solves this by brute force: the plan is recalculated thousands of times, each time drawing a random duration for each task between its optimistic and pessimistic values, while respecting dependencies and calendars. The result is a distribution of finish dates instead of one date:

• P50: half of the simulated runs finish by this date. A coin toss, not a commitment.
• P80: four runs out of five finish by this date. A reasonable target for an external commitment.
• P95: almost every run finishes by this date. Appropriate when lateness is very expensive.

This is also the honest way to size a buffer. Instead of adding 20% "just in case" to every task, where Parkinson's law will consume it, keep the task estimates realistic and place one visible buffer at the end of the project, sized by the gap between the P50 and the date you promise.

A checklist for estimating a task#

1. Is the task small enough that one person can explain how it will be done?
2. Has the person who will do the work been involved in the estimate?
3. Is the estimate expressed in working days, separately from effort and availability?
4. Do reviews, approvals and rework appear somewhere in the plan?
5. For uncertain tasks, are there optimistic and pessimistic values, and is the pessimistic one genuinely pessimistic?
6. Is there a past task to compare against, and how did it actually go?
7. Are holidays and part-time availability handled by the calendar rather than padded into the duration?
8. Has the estimate been written down with its assumptions, so it can be revisited when they change?

Common estimating mistakes#

• Estimating to the deadline. Working backwards from a date and dividing the time among tasks produces a plan that fits, not a plan that is true.
• Padding every task. Hidden contingency is spent, not saved. Keep contingency visible and in one place.
• Confusing effort and duration. Forty hours of work is not five days if the person is on three projects.
• One number for an unknown task. A task nobody has done before deserves a range, not a point estimate.
• Never comparing estimates with actuals. Without looking back at a few finished tasks, the team's estimates never improve. A saved baseline makes that comparison easy.

How to do it in Planitude#

In Planitude, durations are entered in working days and the engine calculates dates from dependencies and calendars, so holidays and closures never need to be padded into an estimate. As you type the name of a new task in the Gantt or List view, the AI assistant suggests a duration, an assignee and a predecessor, which you accept with Tab or ignore.

For uncertain work, open the Risk tab: you can set an optimistic and a pessimistic duration on the tasks that need them, while the others use the project's default range. The Monte Carlo simulation (PERT or triangular) returns P50, P80 and P95 finish dates, the probability of meeting the planned finish or the deadline, and the risk drivers: the tasks whose uncertainty moves the finish the most. Those are the estimates worth refining first.

Frequently asked questions#