10 Deadly Sins of Software Estimation
Whenever I open my book and see the quotes from Steve McConnell’s 10 deadly sins of software estimating I am struck that everyone should be aware of these sins. So here they are again:
Steve McConnell, in “10 Deadly Sins of Software Estimation,” has defined ten common mistakes people make in estimating the scope of a software project. In the first scenario described above, the project team committed almost all of his “sins.” In the second, the project team was nearly flawless. The sins are:
1. Confusing estimates with targets: Targets such as trade show or sales are set without any analysis. Target setting is a very important step in software estimation. Best treated as an iterative process that brings target and estimate into alignment.
2. Saying yes when really meaning no: Vigorous, job-defending estimation with little data or quantities. Problems in schedule negotiation between young, junior, introvert software engineer and sales person who is more experienced, senior, and extrovert.
3. Committing too early with lots of uncertainties: “Cone of uncertainty” means that the uncertainties decrease as the project comes near to the end. Early in the software development lifecycle there is a tendency to underestimate.
4. Assuming underestimation has no impact on project result: Overestimation shows linear impact on project according to Parkinson’s law (“Work expands to fill the time available”) whereas underestimation brings higher, non-linear impact.
5. Estimating in the “impossible zone“: Estimations are probability statements, not single-points. Schedule compression increases the total cost or effort for the project. “Impossible zone” is a compressed schedule with a zero chance of success.
6. Overestimating savings from new tools or methods: Payoff is less than expected. Assume the productivity loss from initial use of new tools or methods considering learning curve and error-proneness.
7. Using only one estimation technique: Estimate with different ways and looks. Multiple approaches contribute to Brook’s “vigorous defense”.
8. Not using estimation software: It can bring more credibility. Science of estimation is supported in the tools.
9. Not including risk impact: New technology does not meet expectation at times. Team members can get sick or have family emergencies. Government regulation can change. Risk exposure is where “risk buffer planning” starts.
10. Providing off-the-cuff estimates: Treat estimation as a mini project. Simple arithmetic is better than guessing or intuition. Define a standardized estimation procedure (multiple approaches, description of imprecision, re-estimate schedule, point of estimate becoming commitment). Decompose big estimates into smaller ones (system-modules).
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Related posts:
- Ten-step Project Estimation Process
- Software Testing Effort Estimation Bottoms-Up Article
- 10 Step Estimation Process Overview
- Why Do Estimation Webinar With Geoff Hewson and Dan Galorath
- Viable Software Estimation Modeling: A Key Component Of Software Risk Management
Related Posts Computer Generated
Comments
5 Responses to “10 Deadly Sins of Software Estimation”
Leave a Reply
[...] 10 Deadly Sins of Estimation (on Seer) [...]
[...] 10 Deadly Sins of Estimation (on Seer) [...]
[...] 10 Deadly Sins of Estimation (on Seer) [...]
[...] 10 Deadly Sins of Estimation (on Seer) [...]
Thats a great article which provides us with a handy 10-point checklist with info on where the software estimation went wrong.
Visit: http://technologyandleadership.com/project-estimation/ for a recent post on project estimation