Suppose you go to your friend Stan, who's an architect, and say that you want to build a house. You start by asking Stan whether he can build a three-bedroom home for under $100,000. He'll say yes, but he'll also say that the specific cost will vary depending on the detailed characteristics you want. (See Figure 8-1.)

If you're willing to accept whatever Stan designs, it will be possible for him to deliver on his estimate. But if you have specific ideas about what kind of house you want—if you later insist on a three-car garage, gourmet kitchen, sunroom, sauna, swimming pool, den, two fireplaces, gold-plated fixtures, floor-to-ceiling Italian marble, and a building site with the best view in the state—your home could cost several times $100,000, even though the architect told you it was possible to build a three-bedroom home for under $100,000.

Figure 8-1. It is difficult to know whether you can build the product that the customer wants in the desired time frame until you have a detailed understanding of what the customer wants.

How much does a new house cost? It depends on the house. How much does a new billing system cost? It depends on the billing system. Some organizations want cost estimates to within ± 10 percent before they'll fund work on requirements definition. Although that degree of precision would be nice to have that early in the project, it isn't even theoretically possible. That early, you'll do well to estimate within a factor of 2.

Until each feature is understood in detail, you can't estimate the cost of a program precisely. Software development is a process of making increasingly detailed decisions. You refine the product concept into a statement of requirements, the requirements into a preliminary design, the preliminary design into a detailed design, and the detailed design into working code. At each of these stages, you make decisions that affect the project's ultimate cost and schedule. Because you can't know how each of these decisions will be made until you actually make them, uncertainty about the nature of the product contributes to uncertainty in the estimate.

Here are some examples of the kinds of questions that contribute to estimation uncertainty:

As you can see, the uncertainty about even a single feature can introduce a lot of uncertainty into an early-in-the-project estimate. Multiplied across an entire project, literally thousands of specification, design, and implementation decisions have to be made before the ultimate cost of the project can be determined. As you do make a greater percentage of those decisions, however, you can narrow the estimation range.

Researchers have found that project estimates fall within predictable precisions at various stages of a project. The estimate-convergence graph in Figure 8-2 shows how estimates become more precise as a project progresses.

Figure 8-2. Estimate-convergence graph. For any given feature set, estimation precision can improve only as the software itself becomes more refined. Source: Adapted from "Cost Models for Future Life Cycle Processes: COCOMO 2.0" (Boehm et al. 1995).

Figure 8-2 captures the reason that software estimation is hard. At the time when developers are typically asked to provide a rough estimate, there can be a factor-of-16 difference between high and low effort estimates. Even after requirements have been completed, you can only know the amount of effort needed to within about 50 percent, and by that time most organizations want their estimates to the dollar. The estimation ranges implied in Figure 8-2 are summarized numerically in Table 8-1.

As the data in Table 8-1 suggests, your estimates throughout a project should start general and become more refined as the project progresses.

These ranges are broad, but even so, there are some extreme cases that they won't catch. No out-of-the-box estimation ranges can account for the case where your customer insists on the equivalent of floor-to-ceiling Italian marble.

To use the factors in the table, simply multiply your "most likely" single-point estimate by the optimistic factor to get the optimistic estimate and by the pessimistic factor to get the pessimistic estimate. You can then present your estimate as a range rather than as a point estimate. If your "most likely" estimate is 50 man-months and you've completed the requirements specification, you would multiply by 0.67 and 1.5 and estimate a range of 34 to 75 man-months. Sometimes your customers will insist on a "most likely" estimate, and you'll feel that you have to give it to them. But if that doesn't happen, you don't need to publish the single-point estimate except in your own notes.

For reasons explained later in the chapter, the optimistic and pessimistic factors for schedule estimates are different than the factors for effort and size. They assume that you estimate the schedule by first creating an effort estimate and then computing the schedule from that. (The procedure for doing this is explained later in the chapter.) If you have estimated the schedule by simply eyeballing it, you'll be better off using the ranges listed under "Effort and Size" than the ranges listed under "Schedule."

Most software customers initially want more than they can afford. As Figure 8-3 suggests, that means that they have to bend either their ideas about the product or their ideas about the resources they are willing to commit. Sometimes the customer will want to bend both the resources and the feature set to meet each other halfway.

Figure 8-3. Most software projects start with a mismatch between desired feature set and available resources. The feature set or the resources (or both) must be bent to meet the other.

How can the feature set be bent to meet the available resources? In the case of building a new house, you might tell your friend Stan, "I might not know exactly what I want, but I do know that I don't need a sauna or a swimming pool, and I don't need the best view in the state. I don't have expensive tastes. I just want a normal house. Considering that, can you build me a house for $100,000?"

Stan will say, "I can definitely build you a house for $100,000, but you'll have to give me a lot of control over how the house is built. I'll have to use plans that the builder is already familiar with. I'll have to use standard doors, windows, appliances, and fixtures. I'll be able to give you only a small number of choices of countertops, rugs, and linoleum. You might not end up with the house you want."

"Fine," you say, because $100,000 is your limit.

Software builders face a choice between estimation accuracy and project control. If you can be flexible about the product characteristics, you can have some control over cost and schedule and can "build to budget." But each time you have to choose between putting a feature in or leaving it out, you'll have to leave it out. Each time you face a choice between implementing the better feature or the one that costs less, you'll have to choose the one that costs less. And you'll have to follow that pattern consistently. If you implement the better feature sometimes and the one that costs less other times, you're not building to budget. You're doing normal software development. If you can't accept the discipline and the trade-offs involved in a build-to-budget approach, you simply have to accept a lot of imprecision in early-in-the-project estimates.

So far, the estimation story has focused on all the reasons that you can't provide the precise estimates that people want. These reasons are good reasons; however, the people who want those precise estimates also have good reasons for wanting them, and I think that means we have an extra responsibility to offer as much estimate-related information as we can.

Help your customers by telling them about the parts of the project that you are able to estimate. If you can estimate the end of your current phase, tell them that. If you know when you'll have a better estimate, tell them that. Don't leave them feeling completely adrift. Tell them where the next landmark is.

Help your customers understand your strategy for the whole project by mapping out the whole set of estimates you intend to provide. Tell them that you'll update your estimates at the end of the product-definition, requirements-specification, product-design, and detailed-design stages. Offer to try to build to budget, if that will help, but be sure that your customers understand all the trade-offs that that approach involves.

If your customers still ask for more precise estimates than you can provide, tell them that you can't give them what they're asking for because you don't know yet yourself. But make it clear that you want to cooperate. Tell them, "As soon as I know, you'll know."

Convergence Between Estimates and Reality

Customers have a role to play in cooperating, too. If customers want the shortest possible schedule, they should not pressure you to lower your estimates or to provide them with misleadingly precise estimates.

As Figure 8-4 on the next page shows, the shortest actual schedule results from the most accurate, planned schedule (Symons 1991). If the estimate is too low, planning inefficiencies will drive up the actual cost of the project. If the estimate is too high, Parkinson's law (that work expands to fill available time) will drive up the actual cost of the project.

Figure 8-4. Relationship between estimated effort and actual effort. An estimate that is either too low or too high will result in a longer-than-optimal actual schedule.

The trick is to try to estimate neither high nor low, but right on the money. The goal of estimation is to seek a convergence between your estimates and reality. By definition, estimates and reality converge upon the software's release. The sooner the two track together, the better the business and product decisions you and your customers can make; the tighter all of you can plan your project and its interdependencies; the better the relationship between developers, managers, customers, marketers, and end-users will be; and the more rapid a development schedule you can attain.

To tell the estimation story, you need to explain these four points:

Case Study: Careful Project Estimation at the end of the chapter provides an illustration of how the estimation story can be used on a live project.