Clients deserve to know how the number was produced. Here is our actual method, including where it fails.
Decompose until each item is under three days
Anything estimated at "two weeks" is a task nobody has thought about properly. Breaking it down usually reveals it is either four days or six weeks — and which one it is matters enormously.
Estimate three points, not one
For each item we record optimistic, likely and pessimistic. The expected value is (O + 4L + P) / 6. The spread matters more than the midpoint: a task estimated 2/3/15 days is telling you there is an unresolved unknown, and that is a signal to go investigate rather than to average it away.
Add explicit, named risk buffers
Not a blanket 20%. Named risks with named costs: "third-party payment gateway documentation is poor — 5 days"; "client legacy database schema undocumented — 8 days". Named buffers can be discussed, challenged and retired as risks resolve. A blanket percentage just gets negotiated away.
Where estimates actually go wrong
1. Integration with systems nobody controls
Our code is predictable. A partner's undocumented SOAP API, with a sandbox that behaves differently from production and a support queue measured in weeks, is not. This is the single largest source of overrun in our history.
2. Decision latency on the client side
We can build in two days something that takes three weeks to get approved. Estimates assume decisions arrive within a stated turnaround; when they do not, the schedule moves even though the effort did not change. We now state this assumption explicitly in every proposal.
3. Requirements that were never really agreed
Two stakeholders with different mental models of the same feature, neither aware of the disagreement. It surfaces at UAT, which is the most expensive possible moment. This is exactly what discovery and a signed blueprint are for.
We would rather give you a range with the reasoning attached than a single confident number we both know is fiction.