---
title: "How to estimate task durations: methods, a worked example and the mistakes to avoid"
description: "How to estimate task durations: effort vs duration, analogous, parametric, bottom-up and three-point (PERT) methods, a worked example and P50/P80 dates."
url: https://planitude.app/blog/how-to-estimate-task-durations
language: en
---

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

Analogous, parametric, bottom-up and three-point estimates explained for small teams, with a PERT example calculated step by step and a way to turn estimates into a finish date you can defend.

by Planitude Team · Published October 13, 2026

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.

> **Key takeaways**
>
> - Estimate **duration in working days**, separately from **effort**: a task that needs three days of work can easily take two weeks on the calendar.
> - Use **three-point estimates** (optimistic, most likely, pessimistic) on the tasks that matter: the PERT mean (O + 4M + P) / 6 is usually longer than the most likely value.
> - A single finish date hides the uncertainty. A **Monte Carlo simulation** turns your ranges into P50, P80 and P95 dates, so you can choose how much confidence to promise.

## 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?":

| Quantity | What it measures | Example |
| --- | --- | --- |
| Effort (work) | Person-hours or person-days of actual work | 24 hours of analysis |
| Duration | Working days between start and finish | 5 working days |
| Elapsed time | Calendar time, weekends and holidays included | 7 calendar days |

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

| Technique | How it works | Best for | Watch out for |
| --- | --- | --- | --- |
| Analogous | Start from a similar past task and adjust | Early phases, little detail available | The "similar" task may not be similar |
| Parametric | Multiply a quantity by a rate (rooms × days per room) | Repeatable work with reliable rates | Rates measured in different conditions |
| Bottom-up | Split the task into pieces, estimate each, add them up | Detailed planning of near-term work | Forgetting integration and review time |
| Three-point | Optimistic, most likely and pessimistic values | Uncertain tasks on or near the critical path | Pessimistic values that are not really pessimistic |

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](https://planitude.app/blog/when-to-split-task-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

| Task | O | M | P | PERT mean |
| --- | --- | --- | --- | --- |
| Design the data mapping | 2 | 3 | 6 | 3.3 days |
| Migrate the data | 4 | 6 | 14 | 7.0 days |
| Validate with users | 2 | 3 | 7 | 3.5 days |
| Total (in sequence) | 8 | 12 | 27 | 13.8 days |

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](https://planitude.app/blog/project-baseline-variance-guide) 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](https://planitude.app/features#planning), 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](https://planitude.app/features#ai) suggests a duration, an assignee and a predecessor, which you accept with Tab or ignore.

For uncertain work, open the [Risk tab](https://planitude.app/features#risk): 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.

**Try Planitude with your own plan** [Try Planitude free](https://planitude.app/signup)

## Frequently asked questions

### What is the difference between effort and duration?

Effort is the amount of work, in person-hours or person-days. Duration is the number of working days between the start and the finish of a task. With part-time availability or waiting time, duration is longer than effort.

### What is the PERT formula?

The PERT mean is (O + 4M + P) / 6, where O is the optimistic, M the most likely and P the pessimistic estimate. The spread is commonly estimated as (P − O) / 6.

### Should I add a buffer to every task?

Usually not. Buffers hidden in every task tend to be used up. It is more effective to estimate tasks realistically and keep one visible buffer at the end of the project or before an important milestone.

### Which date should I promise to a client: P50 or P80?

P50 means a one-in-two chance of finishing late, which is rarely acceptable for an external commitment. P80 is a common choice; P95 is appropriate when a late delivery has serious consequences.

### How many tasks need a three-point estimate?

Not all of them. Focus on long tasks, tasks nobody has done before and tasks on or near the critical path; the rest can use a default range.

## Sources

The official pages cited in this article, checked in October 2026.

[^1]: [Malcolm, Roseboom, Clark & Fazar (1959): Application of a Technique for Research and Development Program Evaluation](https://doi.org/10.1287/opre.7.5.646)
[^2]: [PMI Lexicon of Project Management Terms](https://www.pmi.org/standards/lexicon)

## Try Planitude with your own plan

Create a free account, import your .mpp file or start from a template: within minutes you will see the Gantt chart with dependencies, calendars and the critical path.

[Try Planitude free](https://planitude.app/signup)