An estimate is a range, or it’s a bid

A client asks what it will cost. The honest answer at that moment is a range wide enough to be unsatisfying. So firms give a number, everyone treats it as a commitment, and the rest of the project is spent defending or renegotiating it.

The dishonesty isn’t in being wrong. Estimates are forecasts and forecasts are wrong. The dishonesty is in presenting a forecast with a precision it doesn’t have.

The cone of uncertainty is real¶

Before requirements are understood, software estimates are routinely off by a factor of four in either direction. That range narrows as you learn, which means the fastest way to a useful estimate is not more estimating, it’s more learning.

That is what discovery is for. Two to four weeks of process observation, domain modeling, integration mapping and a technical spike against the riskiest assumption will narrow a 4× range to something like 1.4×. You cannot buy that narrowing with a longer meeting.

None of this is a consulting affectation. The federal government’s own cost-estimating standard treats sensitivity and risk analysis as a step in producing a credible estimate rather than as an optional refinement, and it exists precisely because programs that presented a single confident number went on to overrun it. A buyer is entitled to ask for the same discipline from a software vendor.

What we actually hand over¶

• A range, with the confidence attached. 'Between $280k and $390k, and here is what would push it to either end.'
• The assumptions, written down. Which systems have usable APIs, which data is as clean as claimed, who is available for decisions and how fast they are.
• The risks, priced. Not a heat map: an actual statement that if the ERP integration turns out to require a vendor engagement, that is four to six weeks and a cost.
• A sequence of independently valuable slices, so that the decision to continue is made repeatedly with new information rather than once with none.

Fixed price isn’t safety¶

Fixed-price contracts feel like risk transfer. They are actually risk repricing: the vendor adds a contingency you cannot see, and both parties now have an incentive to argue about scope rather than to build the right thing. Every change request becomes a negotiation, and the relationship becomes adversarial precisely when it needs not to be.

We do offer fixed price, after discovery, when the uncertainty is genuinely small enough that we can carry the risk without padding it beyond recognition. Offering it before discovery would mean either gambling or overcharging, and usually both.

The alternative that works¶

Fix the budget and the date; vary the scope. Ship the most valuable slice first and review at every boundary. This gives you something a fixed-scope contract structurally cannot: the ability to stop when you have enough, which is more often than anyone expects.

Several of our engagements have ended early because the third release solved the problem and the remaining backlog turned out not to be worth building. Under a fixed-scope contract we would have built it anyway, and both parties would have been worse off.