Padding An Estimate Is Not Lying: How To Add Buffer You Can Defend

You add a bit to every task because you know the plan will not go perfectly, and then someone asks why a two day job takes three. You cannot answer without admitting the padding, so you cut it, and the plan goes out with no room in it at all.

The fix is not more padding. It is to take the buffer out of the tasks and put it on the plan as one visible line, attached to named risks. Buffer you can point at survives review. Buffer hidden inside estimates never does.

Why hidden padding always loses

Padding spread across tasks has three problems.

It is indefensible. When each task is inflated a little, every task looks slightly wrong, and you cannot justify any single one without describing the whole scheme.

It gets spent early. Work expands into whatever time it is given, so the slack inside a task is usually gone by the time it is needed, and the risk it was protecting against arrives with nothing left.

It gets cut uniformly. When someone trims the plan, they trim everything by the same proportion, which removes protection from the risky tasks and the safe ones equally. The safe ones did not need it. The risky ones now have none.

Buffer as a line item

Estimate every task honestly, as the time it takes when things go normally. How you arrive at that honest number is a separate choice between gut feel, past averages or breaking it down. Then add one line to the plan called buffer, or contingency, or whatever your organisation calls it, and put the protection there.

That single line has properties the hidden version does not.

• It can be explained, because you can say exactly what it covers.
• It can be tracked, because you can see how much is left.
• It can be released, because if the risks do not happen, the plan finishes early and you gave back time instead of absorbing it.
• It can be argued about honestly, which is better than being cut silently.

Tie each part of the buffer to a named risk

A buffer with no reason attached is padding with a nicer label. Break it into pieces, each with an owner.

• Client feedback arriving late. Based on how long the last round took.
• A dependency on another team whose schedule you do not control.
• An unfamiliar piece of work where the approach is not yet proven.
• A known absence, a holiday, or a person shared with another project.
• An integration or approval that has gone wrong before.

Write each as a sentence: this many days, held against this specific thing, because of this specific history. Now the conversation is about risks rather than about your honesty, which is the conversation you want.

The conversation where someone asks you to cut it

It will happen. Someone will look at the buffer line and ask for it back. Here is how it goes when the buffer is named.

You do not defend the number. You ask which risk they would like to remove. If they can shorten the client feedback loop, that part of the buffer goes. If they can guarantee the other team's delivery date, that part goes too. If they can commit that nobody will be pulled onto another account, another part goes.

Each cut is now a trade with a named owner, recorded. Either the risk gets managed, which is a real gain, or the buffer stays, which is also a real gain. What does not happen is the number quietly disappearing while the risk remains. Quiet is the expensive option here, which is what the cost of a missed deadline nobody mentions adds up to.

How much, and when to release it

There is no correct percentage, and anyone quoting one is guessing at your conditions. Size it from your own history: look at the last few projects, see where time went that was not in the plan, and hold enough for the things that keep recurring.

Then set rules for spending it. Buffer is released against a risk that actually happened, not against a task that ran long for ordinary reasons. Review what is left at each checkpoint. If most of it is gone at the halfway point, that is the earliest honest signal that the date is in trouble, and it arrives while there is still time to act. The next signal comes later, when the last ten percent starts eating the schedule.

Keeping the evidence in one place

The reason most teams cannot size a buffer from history is that the history is scattered. Old plans sit in an archived tool, absences sit in the HR system, and the reason a project ran late lives in someone's memory.

SicherOne is our enterprise workspace. It puts project management, HR and AI agents on one set of records, so a plan knows who is on leave, and an agent drafting a risk list works with full context. A human approves what the agent produces before it ships. It is sold per seat with separable modules, and private models can be self hosted.

A defensible buffer is built from evidence. Keep the evidence somewhere you can find it, and the conversation gets much easier the next time.