Estimating software honestly

Every software estimate is wrong. This is not cynicism, it is arithmetic: you are forecasting work that has not been specified in detail, by people who have not started it, against requirements that will change.

The useful question is not how to be right. It is how to be wrong in a way that is visible early and cheap to correct.

Where the number comes from

We break work into pieces small enough that someone has built something comparable before, estimate each in a range rather than a point, and add explicit contingency for the parts nobody has done.

Then — and this is the part that actually matters — we write down what the number assumes.

A real example, lightly redacted:

Five months, assuming: the payment provider's sandbox is available by week two; one nominated decision-maker with authority to sign off designs; existing customer data matches the 500-row sample provided; no requirement for offline support on the driver app.

Four assumptions. Each one is a thing that, if wrong, changes the forecast — and each one is now something the client can check this week rather than discover in month three.

What changes when assumptions are visible

Two things, both good.

The client can argue. In that example the client read assumption three and said the sample was from their cleanest region; the rest was considerably worse. We added a data cleansing workstream before starting. That conversation happened in week zero instead of month two.

Overruns become conversations rather than accusations. When an assumption breaks we point at it: this is the one that changed, here is the revised forecast, here are the options. Nobody is defending anything. The alternative — a single unexplained number that quietly slips — turns delivery into a relationship problem.

Re-forecasting is not failure

We re-forecast every two weeks. Sometimes the date moves out. Occasionally it moves in.

The industry norm is to hold the original date publicly while everyone privately knows it is gone, then announce the slip as late as possible. This preserves comfort for a few months and destroys trust in one afternoon.

Moving a date early, with a reason, is a much smaller conversation than moving it late.

What we will not do

Estimate without discovery. A number produced from a two-page brief is a guess wearing a suit. We will give a range based on comparable projects and say plainly that it is a range.

Absorb scope silently. When something is added, it either replaces something or it moves the date. Quietly absorbing changes is how teams end up working weekends to protect a date nobody re-examined.

Quote to win. If our honest number is higher than a competitor's, we would rather lose the work than win it on a figure we do not believe. Winning on an undeliverable estimate just relocates the argument to month five, and by then both sides are trapped.

The measure that matters

Not whether the first estimate was right — it will not be. Whether the client was ever surprised.

On our last twelve engagements the average variance from the post-discovery estimate was about nine percent, and in every case the change was flagged in the fortnightly forecast before it materialised. Nobody found out late.

That is what an honest estimate buys. Not accuracy. Predictability.