Estimating Something Nobody Has Built

Three kinds of unknown

1. Known unknowns we can research. An undocumented API, a data set nobody has profiled. Answerable in days.
2. Known unknowns we cannot resolve in advance. Whether a model reaches the accuracy needed; whether users adopt a new flow.
3. Unknown unknowns. What contingency exists for.

Different responses for each. The mistake is treating all three as one and adding a percentage.

The spike

A short, fixed-price investigation with a written finding as the deliverable. Three to five days, a defined question, and an answer you own whether or not you proceed.

• “Can we get the data we need out of this system, and in what shape?”
• “Is this data clean enough to migrate, or does it need work first?”
• “Can this API support the volume we need within its rate limits?”
• “Does an off-the-shelf model reach the accuracy this needs on your real data?”

A five-day spike that prevents a fifteen-thousand-pound wrong turn is the best-value work we sell, and clients almost never ask for it unprompted.

Ranges, stated with their reason

Where a spike is not proportionate, we quote a range and say what would move it to each end. “£18,000–£26,000; the low end if the supplier data is consistent, the high end if we have to reconcile duplicates.”

A range with a stated cause is information. A range with no explanation is hedging, and clients are right to be sceptical of it.

Staged commitment

1. Commit to phase one only, fully priced
2. Phase two priced provisionally, confirmed after phase one
3. A decision point between them where either side can stop
4. Nothing in phase one that is worthless if phase two never happens

This is how genuinely novel work should be bought. It caps your exposure to a bad assumption at one phase rather than a whole programme.

How we handle being wrong

On fixed-price work, an overrun caused by our estimate being wrong is our cost. That is what fixed price means and it is why the estimate deserves care.

What we will not do is absorb an overrun caused by a documented assumption turning out to be false. Those are listed in the proposal precisely so that conversation is about a written record rather than about memory.

Reference class, not imagination

The most reliable estimating technique we know is comparison to similar work we have actually delivered, adjusted for the specific differences. Bottom-up estimates from imagination are consistently optimistic; comparisons to real projects are not.

This is also why we ask what looks like a strange question early on: “what is the closest thing you have seen to what you want?” It locates the project in a reference class faster than a requirements document.

Frequently asked questions