The structural problem
An estimate is produced when the least is known and treated as a commitment thereafter. The work then reveals what it actually contains, and the variance is blamed on the estimator rather than on the sequence.
Uncertainty is not evenly distributed
Some tasks are genuinely predictable: a form, a report, a page. Others contain unknown unknowns — integrations with systems you don’t control, migrations of data you haven’t inspected, anything depending on a third party. Averaging the two produces a number that describes neither.
Estimate the known work. Investigate the unknown work. Don’t average them into one confident number.
Timebox the investigation instead
For the genuinely uncertain parts, commit to a fixed period of investigation rather than a delivery date. Two days spent looking at the actual API and the actual data converts an unknown into an estimate — the same principle as a two-week proof of concept.
Give ranges, and say what moves them
A range with named drivers — “four to seven weeks, longer if the legacy export lacks history” — is more useful and more honest than a single number. It also tells the client which decisions are theirs to make cheaply.
Most overruns are scope, not speed
Projects rarely take longer because the work was slower; they take longer because more work appeared. That is why an explicit out-of-scope list does more for predictability than any estimation technique.
Re-estimate as you learn
The estimate should improve as the unknowns resolve. A number quoted in week one and defended in week six is being treated as a promise about the world rather than a forecast, which is how both sides end up unhappy.