When software projects go out of hand, estimators are often blamed for not doing their job correct. While there is no question about the negative consequences of hasty estimates, how do you identify if an estimate is good (or bad) in the first place? And to what extent can we relate a failed software project to its estimate?
Here are the characteristics of a good software project estimate:
- Based on a well defined and credible effort/cost model (estimation technique).
- Detailed enough so that the coverage of the full scope is verifiable and leads to no ambiguity.
- The validity, relevance and credibility of historical data used and expert judgment are maintained high.
- Assumptions are clearly mentioned and verified with the client. Tendency of assumptions not to hold true is evaluated - failures are either tackled as risks or added to the Terms and Conditions of the contract.
- Risks identified, their impact assessed, and incorporated into the estimate.
- Facilitates future revision without much burden.
Apart from the above, a good estimate needs to be accepted and supported by the development team, project manager and other stakeholders of both the development company and the client.
In short, a good software project estimate is one that helps create a realizable development plan and that's it (It should also support realizable plan revisions anyway.). This point is important. So read this paragraph again.
If a project fails even with such a good estimate, there's no point of blaming the estimators. It's a matter of not following the initial plan that was expected and conceived to be realizable. As we already know, there are many other reasons for software project failures.