the planning fallacy

The planning fallacy is the well-documented tendency to underestimate how long a task will take, even when you know from experience that similar tasks usually run long. It happens because people estimate by imagining the best-case path through a task — everything goes as planned — rather than by looking at how long comparable work actually took in the past.
The fix isn't "try harder to be accurate." It's structural: use a process that forces a range instead of a point, and ground that range in real history instead of imagination.

three-point estimating (pert)

Instead of asking "how long will this take?", three-point estimating asks for three numbers per task:
  • Optimistic (O) — everything goes right
  • Most likely (M) — the realistic, typical case
  • Pessimistic (P) — real but plausible complications show up
The PERT formula combines them into a single weighted estimate that leans toward the most likely case while still accounting for the tails:
Expected duration (E) = (O + 4M + P) / 6
The spread between O and P also gives a rough sense of how uncertain the estimate is — a task with O=2 days, M=3, P=4 is a much safer bet than one with O=1 day, M=3, P=10, even though both might produce a similar expected value.

buffers: where the slack actually goes

The instinctive way to handle uncertainty is to pad every individual task — add 20% to each estimate "just in case." This tends to backfire: padded tasks often still run late (work expands to fill the time available), and the padding is invisible, so nobody can tell how much real contingency the plan actually has.
A more effective approach is to estimate each task realistically (using three-point estimating) and then pool the contingency into one or a few explicit buffers — a block of time placed at the end of a chain of tasks, or at the end of the project, sized using the aggregated uncertainty of the tasks that feed into it. The buffer is visible, tracked on its own, and consumed only when a task actually runs over — not by default.
This is the core idea behind critical chain project management: strip the hidden padding out of individual task estimates, and put a single sized buffer where the risk actually accumulates.

a short example

A data engineer estimating a database migration task gives O = 2 days (script runs clean, no surprises), M = 4 days (typical case — a couple of schema mismatches to fix), P = 9 days (a legacy table has undocumented triggers that break the migration mid-run, which has happened on a past project). PERT gives an expected duration of (2 + 4×4 + 9) / 6 ≈ 4.5 days. Rather than quietly estimating "5 days" and hoping, the team records the full range and adds the tail risk to the project's shared contingency buffer instead of hiding it inside this one task's number.

practical notes

Estimate using reference class forecasting when possible — look at how long the last three similar tasks actually took, rather than starting from a blank mental model of this specific task.
Watch for anchoring: if a stakeholder floats a number first ("can we do this in a week?"), estimates tend to cluster around it regardless of the underlying work. Ask the team to estimate before any target date is mentioned.
An estimate is a forecast, not a promise. Re-estimate as a task is underway and new information appears — clinging to the original number after learning it's wrong just moves the surprise later, when it's more expensive to absorb.

related topics

reference