> ## Content Index
> Fetch the complete content index at: https://www.scopecreep.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Why your estimate was right and the project was still late
- URL: https://www.scopecreep.co.uk/why-your-estimate-was-right-and-the-project-was-still-late/
- Published: 2026-09-15T06:44:48.000Z
- Updated: 2026-09-15T06:44:48.000Z
- Author: Jamie Wright
- Tags: Project Management

Here's a scene every delivery person knows. The project lands late. The retro convenes. The estimates are exhumed and examined, and the strange thing is, they were mostly fine. Task by task, the team guessed well. Nobody sandbagged, nobody was wildly optimistic, the individual numbers hold up. And yet the project missed by six weeks, and everyone leaves the retro with the vague conclusion that "we need to get better at estimating", which is the one lesson the evidence doesn't support.

The estimates weren't the problem. The problem is what we do to estimates the moment they're written down: we treat a probability as a promise.

## The arithmetic nobody runs

An estimate, honestly given, is a statement of odds. When a developer says "about a week", they mean something like: a week is the most likely outcome, it could be less, it could be more, and I'd give it decent odds. Call it 80% likely to land on time, which is a genuinely good estimate. Most are worse.

Now chain ten of those tasks together, each one honestly 80%, each depending on the last, and run the arithmetic that no project plan ever runs: 0.8 multiplied by itself ten times is about 0.11\. An 11% chance the sequence lands on time. Every individual estimate was right. The plan built from them was a coin toss you'd refuse in any casino, and the project didn't fail its estimates; the plan failed its arithmetic. This is the entire mystery of the accurate-but-late project, and it's not a people problem, it's a maths problem, which is good news, because maths problems have fixes.

## Why the overruns don't cancel out

The natural objection: surely some tasks finish early and it all comes out in the wash? It doesn't, for two reasons with delightful names.

Parkinson's law says work expands to fill the time available, so a five-day estimate that could have finished in three rarely does; the spare days get absorbed into polish, or the next task simply isn't ready to start. And student syndrome says that when we're given comfortable deadlines, we start late, spending the safety margin before the work begins rather than keeping it for the surprises at the end, which is where surprises live. Between the two, early finishes evaporate and late finishes accumulate. The distribution of task outcomes has a short left tail and a long right one: a task can only finish so early, but it can finish very, very late. Chain enough of those together and lateness isn't bad luck. It's the shape of the system.

## What to do instead: four changes

**Estimate in ranges, out loud.** Replace "two weeks" with "two weeks at 50% confidence, four at 90%". This feels awkward for about a fortnight and then becomes the most honest sentence in your planning meetings. The gap between someone's 50% and 90% numbers tells you more than either number alone: a narrow gap means a well-understood task, a wide one means uncertainty that deserves a conversation *before* it deserves a deadline.

**Buffer the project, not the tasks.** When individuals pad their own estimates, Parkinson and the students eat the padding privately, task by task, and you get all of the delay with none of the protection. Strip task estimates back to their honest 50% numbers and pool the safety into one visible buffer at the project level, owned by you. Now early finishes *actually help*, the buffer absorbs the overruns that were always coming, and you can watch its burn rate as a live health metric, which beats any RAG status ever coloured in.

**Track actuals, gently.** Keep a quiet record of estimated versus actual, not for blame, for calibration, because the ratio is remarkably stable per team and per type of work. If frontend tasks land at 1.4x their estimates for three months running, you don't have an estimating problem, you have a multiplication problem, and now you know the multiplier. The past is the only estimation tool that doesn't run on optimism.

**Say the odds to stakeholders.** The bravest change, and the one that pays best. "We'll hit June" is a promise you'll break three times out of ten at best. "June at 70%, end of July at 95%, and here's what would move the odds" is a forecast, and it transforms the conversation, because stakeholders can plan around a forecast. What they can't plan around is a promise that quietly meant "70%" to you and "signed in blood" to them, which is the actual root cause of most deadline fury: not the lateness, the surprise.

## The weather forecast, not the contract

The deep fix is a change of metaphor. We treat estimates like contracts: fixed, binding, morally loaded, their breach demanding a culprit. They were never contracts. They're weather forecasts: honest statements of probability given current information, expected to update as fronts move in, useful precisely because they're allowed to change.

Nobody bollocks the Met Office for revising Tuesday's forecast on Monday; the revision is the service. A project that updates its landing date every week as evidence arrives isn't a project losing control, it's a project telling the truth at a higher refresh rate. So the next time the retro reaches for "we need to estimate better", offer the alternative reading: the estimates were right, the plan just believed in them too literally. Then fix the arithmetic, pool the buffer, and start forecasting the weather. The rain was never the forecaster's fault. Planning the picnic without checking? That one's ours.