Why estimates are wrong (and how to make them less wrong)

Estimates are always wrong. The skill is knowing how wrong and narrowing the cone of uncertainty.

The first thing every new project manager learns is that their estimates will be wrong. The second thing they learn is that nobody wants to hear that. The tension between honest uncertainty and organisational demand for precision is the defining challenge of project estimation.

The cone of uncertainty is a useful mental model: early in a project, the range of possible outcomes is very wide - a feature might take anywhere from two weeks to two months. As the project progresses, the cone narrows. By the time you're actually building the thing, you know within a narrower range. The mistake managers make is treating early estimates as firm commitments.

Better estimation comes from three practices. First: always express estimates as ranges, not single numbers. 'Two to four weeks' is honest. 'Three weeks' is a guess you've committed to. Second: use reference class forecasting - what did similar work actually take in the past? Historical data beats expert intuition every time. Third: re-estimate at each stage. The estimate you gave at project kickoff is obsolete by the time you reach the build phase. Update it openly.

The most important habit: when an estimate is wrong, don't defend it. Explain what changed, what you learned, and what the new estimate is. PMs who treat estimates as commitments they must defend destroy trust. PMs who treat estimates as forecasts they update build it.