How to estimate task durations

Every duration on a project plan is a prediction about the future, which means every one of them is wrong. The useful question is not how to be right — you will not be — but how to be less wrong, and how to build a schedule that survives the error you cannot remove. Most plans fail at both. They treat a hopeful guess as a fact, attach it to a calendar, and act surprised when reality disagrees.

Good estimating starts by accepting that durations are uncertain and getting deliberate about the uncertainty. That single shift — from "how long will this take?" to "what is the range, and what is it most likely?" — does more for a schedule than any tool.

The planning fallacy

People are not randomly wrong about how long things take; they are wrong in a consistent direction. We imagine the smooth version — no sick days, no waiting on a reply, no rework, everything in the right order — and estimate that. Psychologists call it the planning fallacy, and it is remarkably stubborn: even people who know their last ten projects ran over still underestimate the next one. The fix is not to "try harder" to be realistic. It is to use methods that route around your optimism, because willpower loses to this particular bias every time.

Top-down and bottom-up

There are two directions to estimate from, and mature plans use both as a cross-check.

• Top-down starts from the whole and divides. "Projects like this take about three months, so the build phase is roughly six weeks." Fast, rough, and useful early when you have no detail — but it inherits whatever bias is baked into the round number you started with.
• Bottom-up estimates each small task and adds them up. More accurate, because small things are easier to picture honestly — but it tends to under-count, because the integration, the handoffs, and the things nobody listed simply are not in the sum. A work breakdown structure is the usual scaffold for a bottom-up estimate.

When the two disagree — and they will — the gap is information. A bottom-up total well under your top-down gut feel usually means you have forgotten tasks, not that the work shrank.

Three-point and PERT estimates

The most practical antidote to single-number optimism is to give three numbers per task instead of one:

• Optimistic (O) — everything goes right.
• Most likely (M) — the realistic, typical case.
• Pessimistic (P) — the things-go-wrong case (not the apocalypse, but a bad-but-plausible week).

You can then collapse them into a single expected duration. The simple triangular average is (O + M + P) / 3. The classic PERT weighting leans on the most-likely value: (O + 4M + P) / 6. For a task estimated at 2 / 4 / 12 days, PERT gives (2 + 16 + 12) / 6 = 5 days — notice it lands above the most-likely 4, because a long tail of bad outcomes drags the expected value up. That asymmetry is exactly what a single "4" hides. PERT grew out of network-scheduling work in the 1950s; the PERT versus Gantt comparison covers where the wider method still fits.

Analogous and parametric estimation

You do not always have to reason from first principles.

• Analogous estimation borrows from a similar past job: "the last data migration took nine days, this one is a bit bigger, call it twelve." It is only as good as the analogy and your memory of it — which is why writing down actuals matters.
• Parametric estimation uses a rate: "we translate about 2,000 words a day, the document is 18,000 words, so nine days." When you have a reliable unit rate and a real measure of scope, this is the most defensible method going, because it scales with the actual size of the work rather than a feeling about it.

Use your own history

The cheapest accuracy upgrade available is to record how long things actually took and compare it to what you guessed. Almost nobody does this, which is why the same teams underestimate the same way for years. You do not need a fancy system — a column of "estimated" beside a column of "actual" reveals your personal bias fast. Many people discover a steady multiplier: a team that habitually finishes at 1.5x its estimates can simply multiply by 1.5 and stop pretending otherwise. Your own logged data beats any industry benchmark, because it already contains your tools, your interruptions, and your definition of "done".

Estimate in ranges, commit in ranges

A single number implies a precision you do not have. "Five days" sounds like a promise; "four to eight days" tells the truth. Carry the range as far into the plan as you can, and when you must commit to a date, commit to one that reflects the pessimistic end of things that matter — particularly anything on the critical path, where a slip moves the whole project. Off the critical path, you can afford the optimistic end, because those tasks have slack to absorb being wrong.

Padding per task versus one project buffer

Here is where most schedules quietly go wrong. People hide a safety margin inside every single task — a "five-day" task that is really three days plus two days of private insurance. It feels prudent, but it backfires twice over. First, the padding vanishes: work expands to fill the time allowed (Parkinson's law), and a task with secret slack will reliably consume it. Second, when one task finishes early, the gain rarely gets passed forward — but when one runs late, the lateness always is. So buried buffers are spent but never banked.

The alternative, drawn from critical-chain thinking, is to strip the padding out of individual tasks — estimate them at something like the aggressive most-likely figure — and pool all that removed safety into a single visible project buffer at the end. One shared buffer is statistically smaller than the sum of the per-task ones (because not everything goes wrong at once), and crucially it is visible: you can watch it being consumed and see trouble coming. A buffer you can see is a management tool. Padding you have hidden in twenty tasks is just twenty places for time to leak away.

Account for the time you do not work

A task that takes "three days of effort" almost never takes three calendar days, and conflating the two wrecks more schedules than bad estimates do. Three things eat the difference:

• Non-working time. Weekends, public holidays, and leave. A five-day task starting Thursday finishes the following Wednesday, not Monday. Let your tool work in working days so the calendar does this for you.
• Interruptions. Nobody gets eight uninterrupted hours. Meetings, email, support, and context-switching mean a "full day" of a task is often three or four real hours. Effort estimates assume focus you will not get.
• Part-time allocation. If someone is on your project half-time, their three days of effort take six calendar days at best — and longer, because split attention is less efficient than whole attention. This is the most common reason "small" tasks drag on for weeks.

Re-estimate as you learn

The first estimate is made when you know the least about the work, so it is the worst one you will ever make. Treat estimates as living. As a task gets close, or as a similar one finishes, revise the numbers that depend on what you have just learned — this is sometimes called the cone of uncertainty narrowing. A plan that still shows the original day-one guesses halfway through is not stable; it is stale. Re-estimating is not admitting failure. It is the difference between a forecast and a wish, and it is what keeps a schedule honest enough to act on. When the revised numbers push past the deadline, you are no longer estimating — you are handling slippage, which is a different job with its own moves.

Frequently asked questions

Should I estimate in effort (hours) or duration (calendar days)?

Estimate effort first — how much work the task contains — then convert to duration by accounting for who is available, at what allocation, around non-working time and interruptions. A Gantt chart schedules duration, but the conversion is where most estimates go wrong, so do it explicitly rather than assuming a day of effort equals a calendar day.

Is the PERT formula better than a simple average of the three points?

For most work, yes, slightly. The PERT weighting (O + 4M + P) / 6 leans on the most-likely value, which usually reflects reality better than the plain triangular average (O + M + P) / 3. Neither is precise — the real benefit is forcing you to think in three points at all, which surfaces the optimistic bias a single number hides.

How much buffer should a project carry?

There is no universal figure, but a single visible project buffer of roughly a quarter to a half of the critical-path duration is a common starting point, tuned by how uncertain the work is and what your own historical estimate-versus-actual data shows. A pooled buffer you can watch being consumed is far more useful than the same time hidden inside individual tasks.

Why do my estimates keep coming in too low even when I try to be realistic?

Because the planning fallacy is a cognitive bias, not a lack of effort — we naturally picture the smooth version of work and estimate that. The reliable fixes are structural: estimate in three points, use your own logged actuals to find your personal multiplier, and pool safety into a project buffer rather than trusting yourself to be realistic in the moment.