Demystifying the Black Art of Software Estimation: What Is an "Estimate"?
It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.
You might think you already know what an estimate is. My goal by the end of this chapter is to convince you that an estimate is different from what most people think. A good estimate is even more different.
Here is a dictionary definition of estimate: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one’s impressions; opinion. (Source: The American Heritage Dictionary, Second College Edition, 1985.)
Does this sound like what you are asked for when you’re asked for an estimate? Are you asked for a tentative or preliminary calculation—that is, do you expect that you can change your mind later?
Probably not. When executives ask for an “estimate,” they’re often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better.
Estimates, Targets, and Commitments
Strictly speaking, the dictionary definition of estimate is correct: an estimate is a prediction of how long a project will take or how much it will cost. But estimation on software projects interplays with business targets, commitments, and control.
A target is a statement of a desirable business objective. Examples include the following:
“We need to have Version 2.1 ready to demonstrate at a trade show in May.”
“We need to have this release stabilized in time for the holiday sales cycle.”
“These functions need to be completed by July 1 so that we’ll be in compliance with government regulations.”
“We must limit the cost of the next release to $2 million, because that’s the maximum budget we have for that release.”
Businesses have important reasons to establish targets independent of software estimates. But the fact that a target is desirable or even mandatory does not necessarily mean that it is achievable.
While a target is a description of a desirable business objective, a commitment is a promise to deliver defined functionality at a specific level of quality by a certain date. A commitment can be the same as the estimate, or it can be more aggressive or more conservative than the estimate. In other words, do not assume that the commitment has to be the same as the estimate; it doesn’t.