Past projects as a reference, and one shared buffer

Padding means each owner hides a private margin inside their own task. Every single choice is sensible: Danylo adds days because his estimate was once cut in half in a meeting; Vira gives her bad case so she isn't the one everyone waits for. Together the margins push Klasna's chain to 54 working days when only 43 are left to opening.

Worse, padded tasks still finish late. With a margin inside, people start later, polish longer and report "done" on the planned day, so the work spreads to fill the time given. A task that finishes early rarely hands its spare days to the next one, while a late task pushes everything after it. The margins disappear; the delays add up.

So padding makes the plan look later without making the work any safer. The fix isn't blaming effort or demanding more padding: it is moving the margin out of the tasks.

A plan built task by task from what each owner imagines is the inside view. The outside view asks a different question: how long did similar projects actually take?

Klasna has three earlier launches with 17 tasks recorded, and in each retrospective owners said whether their estimate already held a private margin. The summary is blunt: 142 working days estimated, 168 actual, and every launch ran over. The six padded tasks never finished early and were still 9 % over. Tasks without padding ran about 30 % over. Expert reviews were the worst kind of task, 1.69 times their estimates.

Read the evidence for what it supports, and no further. It says padding didn't buy punctuality and honest estimates were too low; it doesn't say "pad more". It also doesn't make every past launch equally relevant: a mostly-platform build tells you less about a new subject than the two subject launches do.

A forecast from past projects is only as good as the projects you compare with. So the core choice is: which launches are most like this one?

Klasna's physics launch has a curriculum, an expert review, demo lessons and tutor onboarding. The two earlier subject launches, exam math and programming for teens, had the same parts. The math exam simulator was mostly a platform build, so it says less about a new subject.

For the two subject launches alone: 93 working days estimated, 113 actual, a factor of 113 ÷ 93 ≈ 1.22. That ratio is the outside view's starting point: if nothing named is different, expect the physics tasks to run about a fifth over their honest estimates too.

Two cautions. Keep the comparison set small but relevant rather than large and mixed. And use the ratio by kind of task when you have it: reviews overran far more than the average.

People underestimate their own work even when they know similar work ran late. This pattern is called the planning fallacy: the details of your own plan feel convincing, and the surprises haven't happened yet, so they aren't in it.

Thinking harder about the tasks doesn't fix it; more detail only makes the inside view feel more solid. The fix is to start from how similar projects went, then adjust only for what is truly different, and to say exactly what that difference is.

Vira objects that physics isn't programming. Fair, so name the difference. "This time it will go better" is not a difference. "The reviewer has already read half the draft" is one, and it justifies a shorter review than the past average. Without such a named reason, the past overrun is your best guess for this project too.

The fix for padded estimates has four steps, in this order.

1. Ask each owner for the most likely value of their task, not a safe one. At Klasna that gives 4, 6, 11, 7 and 4 days.
2. Plan the chain with those values: 32 days.
3. Put the gap to the fixed date as one buffer at the end of the chain: 43 − 32 = 11 days, visible to everyone.
4. Give the buffer one owner, the lead, who records every use and compares it with progress each week.

The weekly comparison is the early warning. Half the chain done with a quarter of the buffer used is fine. A quarter done with half the buffer gone means trouble, weeks before the date is at risk.

The margin hasn't disappeared: it moved from five private pockets into one shared one that only the tasks that actually run long draw on.

Once each task is planned at its most likely value, the buffer is simply what is left between the planned chain and the fixed date.

At Klasna: 4 + 6 + 11 + 7 + 4 = 32 working days of planned work, and 43 working days to the 29 January deadline, so the buffer is 43 − 32 = 11 days. The owners' padded numbers added up to 54, so 22 days of hidden margin came out of the tasks. Half of that comes back as one visible buffer, and the plan now fits.

Is 11 enough? That is a separate question, and you answer it from two sides: from the inside, with three-point estimates and their spread; from the outside, with how far similar tasks overran. If the buffer is clearly too small, that is news for the sponsor now: cut scope, add help where it really shortens the chain, or move the date.

Once tasks are planned at their most likely values, about half of them will run over. That is not failure: it is what "most likely" means. The shared buffer exists exactly to absorb it.

At Klasna the curriculum draft took 6 days instead of the planned 4. Two days come out of the buffer, which drops from 11 to 9. The lead notes why and keeps watching the buffer against progress. The opening date doesn't move while the buffer lasts, and nobody is recorded as late.

Two tempting reactions bring padding back in another form. Making Vira "make up" two days on her review squeezes the next task, so its owner will pad again. Cutting a day from every remaining task does the same across the board. The promise that makes owners give honest numbers is precisely this: landing inside your range is never blamed; telling the lead early is expected.

Splitting the buffer sounds fair, "everyone gets their share", but it undoes the whole fix. A share given to an owner is a private margin again, and private margins get spent: the work spreads to fill the time, early finishes aren't passed on.

A shared buffer works differently. Only the tasks that actually run long draw on it, and because tasks over and under their likely values partly cancel out, one pool covers the chain with fewer days than five separate margins would need.

It also gives the lead a signal no split can: each week, compare how much of the chain is done with how much buffer is gone. If Vira's review behaves like past reviews, it takes a big bite, and the lead sees it in December, not in January.

How it fits together: honest likely values, the outside view and one owned buffer give a date that holds. The next lesson does the same for money: Hanna's 600,000 by month, two kinds of reserve, and one quick check of work done against money spent.