4.1 Sources of Estimation Uncertainty

How much does a new house cost? It depends on the house. How much does a Web site cost? It depends on the Web site. Until each specific feature is understood in detail, it's impossible to estimate the cost of a software project accurately. It isn't possible to estimate the amount of work required to build something when that "something" has not been defined.

Software development is a process of gradual refinement. You start with a general product concept (the vision of the software you intend to build), and you refine that concept based on the product and project goals. Sometimes your goal is to estimate the budget and schedule needed to deliver a specific amount of functionality. Other times your goal is to estimate how much functionality can be built in a predetermined amount of time under a fixed budget. Many projects navigate under a happy medium of some flexibility in budget, schedule, and features. In any of these cases the different ways the software could ultimately take shape will produce widely different combinations of cost, schedule, and feature set.

Suppose you're developing an order-entry system and you haven't yet pinned down the requirements for entering telephone numbers. Some of the uncertainties that could affect a software estimate from the requirements activity through release include the following:

When telephone numbers are entered, will the customer want a Telephone Number Checker to check whether the numbers are valid?
If the customer wants the Telephone Number Checker, will the customer want the cheap or expensive version of the Telephone Number Checker? (There are typically 2-hour, 2-day, and 2-week versions of any particular feature—for example, U.S.-only versus international phone numbers.)
If you implement the cheap version of the Telephone Number Checker, will the customer later want the expensive version after all?
Can you use an off-the-shelf Telephone Number Checker, or are there design constraints that require you to develop your own?
How will the Telephone Number Checker be designed? (Typically there is at least a factor of 10 difference in design complexity among different designs for the same feature.)
How long will it take to code the Telephone Number Checker? (There can be a factor of 10 difference—or more—in the time that different developers need to code the same feature.)
Do the Telephone Number Checker and the Address Checker interact? How long will it take to integrate the Telephone Number Checker and the Address Checker?
What will the quality level of the Telephone Number Checker be? (Depending on the care taken during implementation, there can be a factor of 10 difference in the number of defects contained in the original implementation.)
How long will it take to debug and correct mistakes made in the implementation of the Telephone Number Checker? (Individual performance among different programmers with the same level of experience varies by at least a factor of 10 in debugging and correcting the same problems.)

As you can see just from this short list of uncertainties, potential differences in how a single feature is specified, designed, and implemented can introduce cumulative differences of a hundredfold or more in implementation time for any given feature. When you combine these uncertainties across hundreds or thousands of features in a large feature set, you end up with significant uncertainty in the project itself.