Estimating in ranges, and defending them
Single-number estimates are a promise nobody can keep. Ranges with named assumptions hold up much better under pressure.
A client asks how long the project will take. You say twelve weeks, because saying ten-to-sixteen sounds evasive. Twelve becomes the date in the plan, the date in the contract, and eventually the date you miss.
What the range is actually made of
The gap between the ends of a range is not padding. It is the list of things you do not know yet: how fast their review cycles are, whether the legacy API is documented, how many stakeholders have veto rights. Name those, and the range stops sounding like hedging and starts sounding like analysis.
- State the optimistic case and what has to be true for it
- State the pessimistic case and what would cause it
- List the three unknowns with the largest spread
- Say when you will re-estimate, and then actually do it
Re-estimate out loud
Ranges narrow as unknowns resolve. If you never revisit the estimate in front of the client, you lose the only mechanism you have for moving the date without it feeling like a failure. We re-forecast at the end of every second cycle, in writing, whether the news is good or not.