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:

1. Based on a well defined and credible effort/cost model (estimation technique).
2. Detailed enough so that the coverage of the full scope is verifiable and leads to no ambiguity.
3. The validity, relevance and credibility of historical data used and expert judgment are maintained high.
4. 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.
5. Risks identified, their impact assessed, and incorporated into the estimate.
6. 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.

Grady Booch interviewed by Software Engineering Radio highlighted the essentially needed qualities of a valuable/good/great software developer:

1. Being a good abstractionist
2. Being a good team player with good communication skills

Who is a good abstractionist?

A person’s decision on what is good and what is bad is contextual. And hence, among other factors, the reactions and dynamics of people in a workplace are much determined by the organizational culture. Culture sets a base for the people to reason and guides them in determining what their reactions should be for various forces external to the individual. Thus, growing the concept of egoless working in an organizational culture may prove to be fundamental as a technique in boosting the performance of individuals and the organization in general.

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: