Deadline confidence: the number clients actually want
Clients do not want an earlier date. They want one they can plan around. Padding every task by 20% quietly costs you both — a worked example.
Why padded dates leak
Ask a client what they want and most say "as early as possible." Watch what they do and the answer is different: they want a date they can book people, budget, and launch around. An earlier date that slips costs them more than a later date that holds.
The standard response is to pad. Add 20% to every task estimate and hope the buffer survives contact with the project. It rarely does. Parkinson's law fills the extra time, and student syndrome — everyone starts when the deadline gets close — means the padding is spent before the work is. You do not get the buffer back at the end. You only get a longer estimate and the same slip.
A promise kept beats a promise hoped
There is a cleaner way to talk about dates: state the confidence. Instead of "we finish mid-March," say "we are 90% confident we finish by March 14." The client gets the planning number. You get an honest commitment you can actually defend.
That number is a percentile of your finish-date distribution, not a guess. The deadline confidence calculator turns three-point estimates into exactly this kind of statement before you commit to a single date in a proposal.
A worked example: twelve tasks
Take a twelve-task project with one resource stream and real dependencies — task four cannot start until task three ships, and so on. Add up the optimistic estimates and you get 24 working days. Add up the medians and you get 31. Which do you quote?
Neither, on its own. The project also carries three discrete risks that the task medians ignore:
- A client review cycle that runs five days long instead of two, with a 30% chance of happening.
- A key person taking four to seven days out, with a 20% chance.
- An integration surprise worth three to ten days, with a 25% chance.
Each risk is modeled independently, so the same project can finish in 28 days if nothing fires, or stretch past 45 if two of them do. That spread is the part a single "we finish by X" date hides — and it is exactly the part clients feel when a date slips.
Run the schedule a few thousand times — once for each combination of which risks fire and how long each takes — and the distribution appears:
| Finish percentile | Working days | Calendar date |
|---|---|---|
| P50 (median) | 33 | March 6 |
| P80 | 39 | March 18 |
| P90 | 43 | March 24 |
The optimistic 24-day date has effectively no probability mass behind it. Quote it and you are promising something the project almost cannot deliver.
What you actually communicate
Now the proposal writes itself. "We are 80% confident we finish by March 18" is a date a client can take to their own planning. You can even show where the remaining 20% of risk lives — the three named risks above — which turns a vague fear into a list a client can act on. Fix the review cycle and the distribution shifts left. The reasoning behind all of this lives in the methodology.
Notice what you did not do. You did not hide a padded date inside a confident tone. You gave a real percentile, named the uncertainty, and kept the buffer in the schedule model where it can actually protect you.
The takeaway
Clients buy certainty, not earliness. A date you keep nine times out of ten beats a hopeful date that slips — and it is the honest one to put in writing. Padding every task by a fixed percentage is the most expensive way to fake confidence, because the padding gets absorbed and the risk stays unmanaged. Estimate the distribution, quote the percentile, and name the risks. The app runs this simulation on your real schedule, risks and all, and tells you the date you can actually promise.