Estimating in software projects has always been a disaster. Over 30 years ago even NASA found out that at the beginning of the software development process estimations are so inaccurate that you have to assume that you have miscalculated by a factor of 4.
My search by googling “Cone of Uncertainty”, actually showed, that on this topic there is practically nothing of use available on the internet. The German article on Wikipedia was totally unuseable (worthless). The English Wikipedia article was considerably better. My assessment that people simply ignore this knowledge is therefore correct. The Wikipedia article says:
“The original conceptual basis of the Cone of Uncertainty was developed by Barry Boehm (Boehm 1981, p. 311). Boehm referred to the concept as the “Funnel Curve” (Stutzke 2005, p. 10). Boehm’s initial quantification of the effects of the Funnel Curve were subjective (Boehm 1981, p. 311). Later work by Boehm and his colleagues at USC applied data from a set of software projects from the U.S. Air Force and other sources to validate the model. The basic model was further validated based on work at NASA’s Software Engineering Lab (NASA 1990).”
The first time the name “Cone of Uncertainty” was used to describe this concept was in Software Project Survival Guide (McConnell 1997).” [1]
The article continues with:
“Original research on the Cone of Uncertainty stated that in the beginning of the project life cycle (i.e. before gathering of requirements) estimates have in general an uncertainty of factor 4 on both the high side and the low side (Boehm 1981). This means that the actual effort or scope can be 4 times or 1/4th of the first estimates. This uncertainty tends to decrease over the course of a project, although that decrease is not guaranteed (McConnell 2006, p. 38).”
Agile estimation methods like our Magic Estimation [2], fulfill the claims that result from Boehm’s research:
- Estimates (e.g. on duration, costs or quality) are inherently very vague at the beginning of a project
- Estimates and project plans based on estimations need to be redone on a regular basis
- Uncertainties can be built into estimates and should be visible in project plans
- Assumptions that later prove to be a mistake are major factors in uncertainty
But even these which McConnel maintains in his book Software Estimation are considerably more reliable cannot disguise: They are still only estimations.
[1] http://en.wikipedia.org/wiki/Cone_of_Uncertainty
[2] Boris Gloger, Scrum – Produkte zuverlässig und schnell entwickeln, Hanser, 3. Auflage, 2011