Your Estimates Are Padded, and Your Projects Are Still Late

Ask an experienced person how long a task will take and, quietly, they give you two numbers. There is the time they honestly expect it to need, and there is the number they say out loud. The second is larger, because they have been burned before. They pad the estimate so that if something goes wrong, they are still safe.

This is sensible behaviour by every individual involved. It is also why so many carefully estimated plans, full of protection, still finish late.

The safety is not missing. Most plans contain a great deal of it. The problem is that safety added to each task in isolation is systematically consumed before it can protect the thing that actually matters, which is the delivery date of the whole project. Understanding how that happens, and what to do instead, is one of the highest-leverage shifts available to anyone running projects under uncertainty.

The safety is real, and it is everywhere

Start by seeing how much protection is already in the plan.

A task that genuinely takes about three days, on a good run, rarely gets estimated at three days. It gets estimated at five, or six, because the estimator is not quoting the time it usually takes. They are quoting a time they are confident they can hit even on a bad day: when the environment breaks, when the specification turns out to be wrong, when the one person who knows the answer is on leave. To be safe most of the time, you quote closer to the worst case than the typical case.

The gap between those two numbers is safety. And it is not small. Across a chain of tasks, it is common for half the estimated duration to be protection rather than work. The plan is not lean and optimistic. It is deeply padded, task by task, with every estimator independently buying themselves insurance.

So the puzzle is not why projects lack protection. It is why projects drowning in protection still slip.

Three ways the safety disappears

The safety is consumed by three behaviours, and none of them is laziness or bad faith. They are what rational people do inside a system built on task-level dates.

It starts late. When a task carries comfortable safety, there is no urgency to begin. The deadline is far away, other things are burning, so the work waits. Then, at the last responsible moment, it starts, and the safety that was supposed to absorb problems has already been spent on delay before any problem arrives. This is Student syndrome, named after every essay written the night before it was due. The margin existed. It was consumed at the front, on nothing.

It never finishes early. Suppose a padded task does finish ahead of its estimate. In most organisations that early finish is never reported and never passed on. The next task is not ready to start, the person moves quietly to something else, or the estimate is simply treated as the real duration and the slack evaporates. Work expands to fill the time available, which is Parkinson's Law. The result is a ratchet: overruns are passed down the chain in full, but underruns are absorbed and lost. Safety only ever leaks in one direction.

It gets lost where paths merge. Most projects are not a single line of tasks. Several streams of work run in parallel and have to come together at an integration point or a milestone. When they merge, the milestone cannot start until the last of the feeding paths arrives. So if five paths feed a milestone and four are early but one is late, the milestone is late. The early finishes bought you nothing; the one late path set the date. Across many merge points, delays accumulate and early finishes do not, because a convergence takes the worst of its inputs, never the average.

Put the three together and the pattern is clear. Local safety protects each task on a bad day, but the mechanisms of delayed starts, unreported early finishes, and merging paths ensure that the protection is spent locally and never reaches the finish line. Each estimator got their insurance. The project got almost none of it.

Why more padding cannot fix it

The instinctive response, when a padded plan slips, is to pad harder. Add contingency to each task. Quote the worse case. Build in more room.

This makes the problem worse, for a reason that is arithmetic rather than attitude. Bigger local safety means more comfortable deadlines, which means later starts and stronger Student syndrome. It means more room for work to expand into. And it lengthens every path, so the plan gets longer while remaining exactly as exposed at the merge points, because those still take the worst input regardless of how fat each input is. You have paid for more insurance and changed which pocket it leaks out of, not whether it leaks.

There is also a real cost to all that padding, of the same kind the rest of this series keeps returning to. Safety time on a task is capacity that has been reserved and, when consumed on delay, returns nothing. It is the temporal cousin of a queue of half-finished work, or of protective capacity burned by running a constraint flat out. The organisation is holding a large, invisible inventory of safety, paying for it in extended timelines, and getting very little protection in exchange. And because delay carries a measurable price, the projects that slip anyway are destroying value while the plan reads as prudent.

Pool the risk instead

The fix is not to remove protection. It is to stop attaching it to individual tasks and pool it into one shared buffer that protects the whole chain.

Concretely: strip the padding out of each estimate and ask instead for the aggressive-but-achievable duration, the roughly fifty-fifty number, the honest typical case. Then take the protection you removed, and instead of scattering it across every task, place a single buffer at the end of the chain, sized to defend the completion date against the variability of the whole path.

The reason this works is the mathematics of pooling risk, the same principle that lets an insurer cover a thousand houses with far less than a thousand houses' worth of reserve. Individual variations are partly independent. Some tasks run long, others run short, and across a chain those swings partly cancel. In statistical terms, variances add but standard deviations do not, so the uncertainty of the total grows with the square root of the number of tasks, not in proportion to it. The safety needed to protect the whole chain to a given confidence is therefore much smaller than the sum of the safety you would need to protect each task individually.

The effect is large and concrete. Nine tasks each carrying a week of private padding hold nine weeks of local safety. A shared buffer of roughly three weeks can protect the whole chain to the same confidence, because it only has to cover the combined variation, not the sum of every worst case. That frees around six weeks. The project both commits to a shorter timeline and is better protected, because the buffer is now positioned where it defends the only date anyone cares about, and it can absorb an overrun anywhere on the path rather than being trapped inside the task that happened to have a good day.

Manage the buffer, not the dates

Pooling the safety changes what you measure. Once protection lives in a shared buffer, the health of the project is no longer a wall of task-level dates coloured red and green. It is a single question: how fast is the buffer being consumed relative to how much of the chain is complete?

If you are forty percent through the work and have used twenty percent of the buffer, you are fine, even if several individual tasks are nominally late, because lateness against an aggressive estimate is expected and that is exactly what the buffer is for. If you are twenty percent through the work and have used sixty percent of the buffer, you have a genuine problem that no dashboard of individual dates would have flagged this early, because each task still looks roughly on track. Buffer consumption is an early-warning signal precisely because it aggregates. It sees the whole path draining before any single task has visibly failed.

This is a different discipline from chasing task deadlines, and a calmer one. You stop interrogating every task that runs a day long, because you have accepted upfront that individual tasks will vary, and you start intervening when and only when the shared protection is draining faster than the work is progressing. Attention goes to the one signal that actually predicts the outcome.

The same logic runs the portfolio

Everything above concerns a single project. In a multi-project organisation the same reasoning scales up and becomes, if anything, more important.

The shared resource that limits your delivery needs protection too, not from the variability of one task but from the collision of many projects arriving at it at once. That protection is a capacity buffer on the constraint, and it is subject to exactly the same failure mode: if every project quietly reserves its own private safety on the shared specialist, the specialist is over-committed on paper, over-loaded in practice, and protected nowhere. Aggregating that protection, and defending it, is the portfolio-level version of the shared buffer. It is also why multitasking a constrained specialist across everything at once is so destructive: it is the mechanism by which shared safety gets shredded into useless local fragments.

And buffer status is the metric a portfolio function should be watching. A Value Management Office does not need every project to report a confident date, because those dates are padded fictions that go green until the week they go red. It needs to know which projects are consuming their protection faster than they are consuming their work, because that is where value is quietly draining and where intervention still pays back. This is the difference between reporting on delivery and managing it, and it is another face of the Project Illusion: the belief that a plan full of individually safe tasks is a safe plan.

The shift

The intuition that each task should carry its own safety is natural, humane, and wrong at the level that matters. It produces plans that are long, padded, and still late, because the protection is spent locally and never survives the journey to the finish line.

Take the safety off the tasks and pool it where it defends the date. Estimate honestly, buffer the chain once, and manage by how fast that buffer drains rather than by policing every task against a padded deadline. The plan gets shorter and safer at the same time, which sounds like a trick and is really just the arithmetic of pooled risk. Protection scattered everywhere protects nothing. Protection gathered in one place, and watched, is what actually gets projects home.

---

Flow Economics is the discipline of understanding how value actually moves through an organisation when its resources are constrained, and of making decisions that maximise what the whole system delivers rather than what each part looks like on its own. If your projects are full of safety and still finish late, the Flow Economics framework is a good place to see the full picture.