In many projects we find ourselves with the need for more time to work on the estimate, which makes it easier to contain less uncertainty and to glimpse more details of the project, but the reality is that the accuracy of the software estimate depends on the level of refinement of the software definition, that is, it depends entirely on the information that the product owner or the client has. The more refined the definition, the more accurate the estimate. The reason why the estimate contains variability is that the software project itself contains variability. The only way to reduce variability in the estimate is to reduce variability in the project itself.
An important and difficult concept is that the cone new zealand telegram data of uncertainty represents the best possible accuracy in software estimates at different points in a project.
Another way the cone represents a better estimate is that if the project is not well controlled or if the estimators are not very accurate, the estimates may not improve as shown by the cone. The following figure shows what happens when the project is not carried out in a way that reduces variability: Uncertainty is not a cone, but rather a cloud that persists until the end of the project. The problem is not really that the estimates do not converge; the problem is that the project itself does not converge—that is, it does not eliminate enough variability to support more accurate estimates.
In many cases we inadvertently sabotage ourselves by making commitments too early in the cone of uncertainty .
If an organization makes commitments at the time of Initial Concept or Product Definition, it has a factor of 2x to 4x error in its estimates. Commitments made too early in a project undermine predictability, increase risk, increase project inefficiencies, and impair the ability to manage a project to completion.
Significant commitments are not possible in the early, wide part of the Cone. The solution is to delay commitments until the necessary work has been done to force the Cone to narrow. One of the most effective solutions is to conduct a pre-development consultation to ensure initial concept and product definition. Significant commitments should be made approximately 30% of the estimated project time to be reasonable and accurate.
The cone of uncertainty and iterative development
In many projects, teams settle on a middle ground where most requirements are defined at the start of the project, but design, development, testing, and production are done in short iterations. In other words, the project progresses sequentially to the “User Interface Design Complete” milestone (approximately 30% of the project schedule time) and then switches to a more iterative approach from that point forward. This reduces variability from the Cone to approximately ±25%, which allows for good enough project control to achieve a goal while still taking advantage of the major benefits of iterative development. Project teams can leave an amount of planned time for yet-to-be-determined requirements at the end of the project. This middle ground supports long-term predictability of cost and time, as well as a moderate amount of flexibility in requirements.
Conclusion
The cone of uncertainty is a valuable tool for understanding and managing variability in software project estimates. By recognizing and managing this variability, development teams can make more realistic commitments and achieve greater accuracy in project planning and execution. Adopting iterative practices can help balance long-term predictability with flexibility in requirements implementation, thereby enabling more effective and successful project control.