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.
It was the final day of the Agile Processes And Project Management training carried out at PPSL. As recommended for agile teams, I introduced couple of tools to improve the team performance. One was to use a web based content management system (like Drupal, Wiki) to establish communication needs and maintain software models created and documentation of projects only to a sufficient degree.
Note: This article carries humor and the estimations techniques given below have nothing to do with CMMI levels (Except for the fact that I am trying to find similarities between the real estimation techniques and the humorous techniques as found in Weinberg’s post.). But I have given some of my “true” views on estimations at the bottom. - Kamal
Weinberg the Great would write in his post Estimating Projects: A History of Failure about the mantic art of project estimation suitable for different CMMI (Comprehensive Magistrate of Magical Integrity) levels of maturity. I could digest it up to this level: