Estimating software you have not built before

The estimate everyone knows is wrong

A client asks what a platform will cost. The honest answer at that moment is a range spanning a factor of several. The commercially convenient answer is a single number, and the industry has largely settled on the convenient one — then built an apparatus of change control and variation orders to manage the consequences.

The single number does not reduce risk. It relocates it, usually onto whichever party is less able to argue.

Estimate the shape, not the point

Uncertainty narrows predictably as work proceeds. At concept, a wide band either way is normal. After discovery it narrows considerably. Once the first increments are in production, a tight band becomes achievable and tends to hold.

So estimate in the shape the uncertainty actually has:

• Discovery is fixed price. Small, bounded, and it is the phase that collapses the uncertainty.
• The roadmap is costed per release with a confidence range, tightening as releases complete.
• The first release is fixed once discovery is done, because by then it is genuinely knowable.
• Everything after is re-forecast each increment against actuals, with a stop point at every boundary.

Decompose until it is boring

The most reliable predictor of estimate accuracy is not technique but granularity. Estimates built from items of a few days are consistently better than estimates built from items of a few weeks, because a multi-week item is where unknowns hide.

The decomposition is also diagnostic. If a feature cannot be broken into small pieces, it is not understood well enough to estimate — and that is worth knowing before it is worth costing.

The four things that inflate estimates

Overruns cluster in the same places, and none of them is the feature work:

1. Integration with systems nobody can fully describe. Budget generously and get access early. “We cannot get a test environment for that system” is worth more than any design document.
2. Data migration. Always worse than expected, because legacy data encodes years of undocumented exceptions. Estimate it separately and treat it as its own project.
3. Sign-off cycles. Elapsed time rather than effort, but it lands on the same delivery date. Named approvers and agreed turnaround are contractual matters.
4. Non-functional requirements discovered late. Accessibility, performance targets, audit logging and retention are cheap when designed in and very expensive when retrofitted.

The most valuable output of a good estimation process is occasionally the recommendation not to proceed — which is only credible from a supplier willing to say it.