Padding Estimates in Project Schedules: Why It Backfires and What to Do Instead

Padding Estimates in Project Schedules: Why It Backfires and What to Do Instead

More like this

Anyone who has run a project knows the temptation. A teammate says a task will take three days, and you quietly write down five. Everyone does it, and in the short term it feels safe. But padding every estimate is a surprisingly poor way to protect a schedule. This article explains why padding tends to fail, what the research and project-management literature suggest instead, and how a small team can build realistic estimates without hiding extra time in every line.

What padding is, and why people do it

Padding means adding extra time to an estimate to protect against things going wrong. Sometimes the person doing the work pads their own number. Sometimes a manager adds a margin on top, and sometimes a project manager adds a third layer before sending the plan to a client. The motive is understandable: people expect to be held to their estimates, and surprises are common.

The reason surprises are common is well documented. Psychologists Daniel Kahneman and Amos Tversky introduced the term "planning fallacy" for the tendency to predict that a future task will take less time than it turns out to need. A later paper by Roger Buehler, Dale Griffin and Michael Ross, published in the Journal of Personality and Social Psychology in 1994, examined why people underestimate their own task completion times. In short, we plan around the best case and discount what has gone wrong before.

So padding is a reaction to a real problem. The trouble is that it does not solve it very well.

Why padding backfires

Work tends to expand to fit the time

In 1955 the naval historian C. Northcote Parkinson published a satirical essay in The Economist that gave us Parkinson's law, usually quoted as "work expands so as to fill the time available for its completion." It was written about bureaucracies rather than project plans, but the idea is familiar to anyone who has watched a two-day task stretch to fill a week. If an estimate includes hidden slack, the slack tends to get used, and the person who finishes early often does not report it.

Deadlines far away get ignored until they are close

Eliyahu Goldratt's critical chain method, introduced in his 1997 book Critical Chain, treats a related habit, often called "student syndrome", as one of the reasons tasks overrun their estimates: people put off starting until the deadline is near, which can consume the safety margin before any problem has appeared. A padded estimate therefore delivers less protection than it appears to. By the time a real problem shows up, the margin has already been spent.

Padding stacks up and distorts the plan

When estimates are padded at several levels, the total schedule can grow far longer than the work requires. Stakeholders see the long schedule and push back, which encourages people to trim their numbers in the next round, and the cycle repeats. Padding also makes the estimates hard to read: no one knows which part of a number is real work and which is insurance.

A better approach: pool the safety time

Critical chain project management, which Goldratt introduced in Critical Chain, takes the safety margin out of individual tasks and gathers it in buffers. Tasks are planned using realistic, roughly 50 percent probability durations, and the extra time is collected into two kinds of buffer. A project buffer sits at the end of the critical chain, and its end date is the one given to outside stakeholders as the delivery date. Feeding buffers sit where a chain of tasks joins the critical chain.

You do not need to adopt the full method to benefit from the idea. A small team can apply three principles:

  1. Ask for an honest typical estimate. Make clear that the number is what the person expects, not a promise. Separate it from the commitment you make to a client.
  2. Add one visible buffer. Instead of hiding extra days inside each task, add one clearly labeled block at the end of a phase or the whole project. Everyone can see that it exists and that it is shared.
  3. Track how the buffer is used. If it is half spent when the project is a quarter done, you have an early warning. If it is untouched, you may have been too cautious.

Three-point estimates: capture uncertainty without padding

Another way to avoid padding is to ask for a range. In three-point estimation, each task gets three numbers: a best case (a), a most likely case (m) and a worst case (b). The PERT approach combines them as expected value E = (a + 4m + b) / 6. A simpler alternative that weights the three numbers equally is E = (a + m + b) / 3.

Suppose a task has a best case of two days, a most likely case of three days and a worst case of eight days. The PERT formula gives (2 + 12 + 8) / 6, which is about 3.7 days. The equal-weight formula gives (2 + 3 + 8) / 3, which is about 4.3 days. Neither number is magic, and which formula you choose matters less than what the exercise reveals. The wide gap between the best and worst case tells you that this task carries real risk, which is worth discussing before the project starts.

Practical habits for small teams

  • Estimate in ranges. "Two to four days" is more honest than "three," and it tells the reader that the number is uncertain.
  • Break large tasks down. Big tasks hide big surprises. Smaller pieces are easier to estimate and easier to track. Our guide to agile project management for small teams covers ways to slice work into manageable units.
  • Compare estimates with what happened. After each project, note the estimated and actual duration of the main tasks. Over time you learn your team's own pattern, which is more useful than a generic rule of thumb. Do not rely on a fixed percentage that you picked up elsewhere.
  • Keep the plan visible. A shared board or tracker lets the team see where time is going. If you are choosing a tool, see our overview of project management software selection.
  • Do not punish early finishes or late warnings. People pad when they fear blame. If a teammate reports a risk early, treat it as useful information.
  • Prioritize the work that matters. When time is short, the answer is rarely to stretch every estimate. Our piece on daily task prioritization shows how to protect the important tasks first.

When some padding is appropriate

Padding is not always wrong. Some projects have fixed external dependencies, such as a vendor delivery or a legal review, where a margin is sensible. The point is to make the margin explicit, to tie it to a named risk where you can, and to keep it in one place rather than spreading it across every task.

Summary

Padding every estimate feels safe but tends to waste the margin it creates, because work expands to fill the time and people delay starting. A more reliable alternative is to ask for honest estimates, use ranges or three-point numbers, pool the safety time into one visible buffer, and compare estimates with actual results after each project. Over a few projects, those habits make plans shorter, clearer and easier to defend.

Sources

Contact Us