The Cone of Uncertainty represents uncertainty that is inherent even in well-run projects. Additional variability can arise from poorly run projects—that is, from avoidable project chaos.
Common examples of project chaos include the following:
Requirements that weren't investigated very well in the first place
Lack of end-
Poor designs that lead to
Poor coding practices that give rise to
Inexperienced personnel
Incomplete or unskilled project planning
Prima donna team
Abandoning planning under pressure
Developer gold-
Lack of automated source code control
This is just a partial list of possible sources of chaos. For a more complete discussion, see Chapter 3, "Classic Mistakes," of my book Rapid Development (McConnell 1996) and on the Web at www.stevemcconnell.com/rdenum.htm .
These sources of chaos share two commonalities. The first is that each introduces variability that makes accurate estimation difficult. The second is that the best way to address each of these issues is not through estimation, but through better project control.
| Tip #15 |
Don't expect better estimation practices alone to provide more accurate estimates for chaotic projects. You can't accurately estimate an
|
Requirements changes have often been
The first challenge is that unstable requirements represent one specific flavor of project chaos. If requirements cannot be stabilized, the Cone of Uncertainty can't be narrowed, and estimation variability will
The second challenge is that requirements changes are often not tracked and the project is often not reestimated when it should be. In a well-run project, an initial set of requirements will be baselined, and cost and schedule will be estimated from that baselined set of requirements. As new requirements are added or old requirements are revised, cost and schedule estimates will be modified to reflect those changes. In practice, project managers often neglect to update their cost and schedule assumptions as their requirements change. The irony in these cases is that the estimate for the original functionality might have been accurate, but after dozens of new requirements have been piled onto the project—requirements that have been agreed to but not accounted for—the project won't have any chance of meeting its original estimates, and the project will be perceived as being late, even though everyone agreed that the feature additions were good ideas.
The estimation techniques described in this book will
| Tip #16 |
To deal with unstable requirements, consider project control strategies instead of or in addition to estimation strategies. |
If you do want to estimate the effect of unstable requirements, you might consider simply incorporating an allowance for requirements growth, requirements changes, or both into your estimates. Figure 4-5 shows a revised Cone of Uncertainty that accounts for approximately 50% growth in requirements over the course of a project. (This particular Cone is for purposes of illustration only. The specific data points are not supported by the same research as the original Cone.)
Figure 4-5:
A Cone of Uncertainty that allows for requirements
This approach has been used by leading organizations, including NASA's Software Engineering Laboratory, which plans on a 40% increase in requirements (NASA SEL 1990). A similar concept is incorporated into the Cocomo II estimation model, which includes the notion of requirements "