Somewhere between the engineer who says "about three weeks" and the slide that says "delivery: 21 days", an estimate stops being a forecast and becomes a promise. Nothing about the underlying uncertainty changed. Only the formatting did.

This is the root of most estimation conflict. The engineer gave a median. The plan recorded a deadline. When the work lands outside the median, as roughly half of all work must, it is read as a failure rather than as the expected behaviour of a distribution.

Estimate ranges, and say what drives them

A single number discards the most useful information you have. "Three to six weeks, and the difference is whether the legacy billing export is documented" tells a planner far more than "four weeks". It also tells them what to go and find out to narrow the range.

The range is not hedging. It is an honest statement of what is known, and it converts an argument about a number into a conversation about a risk.

Separate the estimate from the commitment

There are legitimate reasons to commit to a date: a regulatory deadline, a trade show, a contract. When that happens, the correct response is not to compress the estimate until it matches. It is to decide what scope fits the date and to say so explicitly.

Fixing time and fixing scope simultaneously fixes the third variable by default, and the third variable is quality. It is the only one that can be reduced silently, which is exactly why it is the one that gets reduced.

Re-estimate as you learn, and publish the change

An estimate made at the point of least knowledge should not survive unchanged to delivery. Revisit it when something material is discovered, and share the revision immediately. A schedule that moves in week three is a planning input. The same movement disclosed in week eleven is a crisis.

Teams that hide slippage are not usually being dishonest. They are hoping to recover it, which occasionally works and, when it does not, removes everybody else's chance to react.

Track how wrong you were

Very few teams compare their estimates with their actuals, which means very few teams improve at estimating. Recording the ratio takes minutes per item and, after a few months, produces something genuinely valuable: a personal multiplier grounded in evidence rather than optimism.

The goal is not to be right. It is to be predictably wrong in a known direction, because a bias you can measure is a bias you can correct for.

None of this makes estimation comfortable. It does make it honest, and an honest forecast that moves is worth considerably more than a confident one that quietly stopped being true.

Written by the Global IT Solutions engineering team. Have a project this touches on?

Start a conversation