The Estimation Game

This conversation happens on every project. The client wants a number. The developer gives a range. The project manager splits the difference. The contract says four weeks. The feature takes seven. Everyone is disappointed. Nobody should be surprised.

Enterprise estimation isn't science. It's negotiation. And the sooner everyone involved accepts that, the better the outcomes get.

Software estimation is difficult for the same reason weather forecasting is difficult: too many variables, too many unknowns, and the system is sensitive to initial conditions.

A feature that looks straightforward reveals a data model incompatibility in week two. A dependency on a third-party API that was supposed to be stable changes its response format. The requirements were clear but the edge cases weren't, and there are always more edge cases than anyone expects.

The estimate was made with the information available at the time. The information was incomplete. It's always incomplete. The question isn't "why was the estimate wrong?" It's "how do we plan for the fact that the estimate will be wrong?"

Never give a single number. Give a range. "Four to six weeks" communicates both the expected duration and the uncertainty. The width of the range is itself information. A range of "three to four weeks" signals low uncertainty. A range of "two to eight weeks" signals high uncertainty that needs to be resolved before committing.

The client plans for the top of the range. The team aims for the bottom. If the feature lands somewhere in the middle, everyone is close to their plan.

The estimate for any significant feature should include a discovery phase. One to three days of technical investigation before the implementation begins. The discovery resolves the biggest unknowns. The estimate after discovery is narrower and more reliable.

Discovery isn't wasted time. It's risk reduction. A day of discovery that reveals a database migration requirement saves weeks of surprise work later.

After every project phase, compare estimates to actuals. Not to blame anyone. To calibrate. If your team consistently estimates 20% low, apply a 20% buffer to future estimates. If certain types of work are harder to estimate than others, budget more uncertainty for those types.

Our data shows that integration work (connecting to external systems) is consistently underestimated by 40-60%. UI work is typically within 15% of estimate. Backend business logic falls in between. Knowing these patterns improves every future estimate.

Here's the part nobody says out loud. Enterprise estimation is a negotiation between what the work requires and what the budget allows.

The developer estimates six weeks. The client has budget for four. The project manager proposes cutting scope to fit four weeks. The developer says the remaining scope still takes five weeks. The project manager proposes four weeks with a "phase two" for the rest. Everyone agrees. Phase two never gets funded. The feature ships at 80% completeness and nobody calls it a scope cut.

This dance is the reality of enterprise delivery. It's not dysfunction. It's the mechanism by which finite budgets meet infinite requirements. The dysfunction comes when the dance is hidden - when the estimate says four weeks because that's what the budget allows, not because that's what the work requires.

Be honest about the negotiation. "The work requires six weeks. The budget allows four. Here's what we can deliver in four and what we're deferring." That transparency protects everyone.

Estimates are guesses. Informed guesses, refined by experience, but guesses nonetheless. Treat them accordingly. Plan for the range. Budget for discovery. Track accuracy. And stop pretending that anyone knows how long a feature takes before they build it.