The short answer
A single number presented as an estimate hides the uncertainty rather than removing it. A range with stated assumptions tells you considerably more and is more honest.
The estimate improves as the work is understood, which means re-estimating is a sign of a healthy project rather than a failure.
Why estimates are wrong
| Cause | Effect |
|---|---|
| Requirements not fully known | The largest single factor |
| Integration with systems not yet seen | Highly variable |
| Data in unknown condition | Frequently underestimated |
| Decisions waiting on people | Wall clock time, not effort |
| Optimism about things going smoothly | Systematic, in every estimate |
The bottom row is consistent across the industry. Estimates describe the path where nothing surprising happens, and something surprising almost always does.
What makes an estimate more useful
- Break the work down until each piece is small enough to reason about.
- Give a range rather than a point.
- State what has been assumed, explicitly.
- Identify the most uncertain part and do it first.
- Re-estimate as understanding improves.
Point four removes uncertainty fastest. Building the uncertain part early converts the largest unknown into a known, which narrows everything after it.
Read an estimate properly
- What was assumed about your involvement
- What is excluded
- What happens if an assumption is wrong
- Whether data migration is in or out
- Whether it covers testing and deployment
Data migration and deployment are the two most commonly excluded items, and both are substantial. Check rather than assume.
A defended estimate is a warning sign
An estimate that never changes as the project progresses is being defended rather than maintained. The pressure that creates usually comes out in quality.
Re-estimating with an explanation is a better signal than a figure that has held constant while the scope moved.