What is the NASA requirements vs cost overrun finding?

Internal NASA analyses (most-cited from the 1990s and re-published in NASA Systems Engineering Handbook editions) found a strong inverse relationship between effort invested in requirements definition and final cost overrun. Projects investing only 5% to 10% of total cost in requirements ran approximately 40% to 50% over budget, while projects investing 15% to 20% in requirements held overruns to roughly 10% or less.

Where can I find the original NASA data?

The figure originates with NASA cost analyses circulated within the agency in the 1990s and reproduced in NASA SP-2007-6105 (NASA Systems Engineering Handbook, Revision 1, 2007) and the related NASA Cost Estimating Handbook. NASA-STD-7009A (Standard for Models and Simulations) cites adjacent figures. Original raw data is not openly available, but the curve is reproduced in the published handbooks.

Does this requirements-effort finding apply outside aerospace?

Adjacent work in software engineering (Boehm, Cone of Uncertainty) and large IT projects (McKinsey-Oxford 2012) supports the same direction: more rigorous early definition correlates with lower late-stage overrun. The exact percentages vary by domain. For commercial software the equivalent inflection is usually around 15% of effort in discovery and architecture; for hardware-software systems closer to NASA's 20%.

NASA Requirements vs Cost Overrun: The 5-10% vs 20% Curve

One of the strongest pieces of evidence for "invest early to save late": NASA found that spending 5-10% of effort on requirements yields ~50% overrun, while spending 20% holds overrun to ~10%.

~50%

overrun when only 5-10% of effort goes to requirements

~30%

overrun at 10-15% of effort on requirements

~10%

overrun when 15-20% of effort goes to requirements

The curve in full

% of total effort spent on requirements	Average cost overrun observed	Average schedule overrun observed
1-5%	about 75%	about 60%
5-10%	about 50%	about 40%
10-15%	about 30%	about 25%
15-20%	about 10%	about 10%
20% or more	close to 0%	close to 0%

Reproduced from NASA Systems Engineering Handbook (SP-2007-6105, revision 1, 2007), Figure 1.4-1. Underlying data is internal NASA cost analyses from the 1990s.

Why the curve is so steep at the low end

The intuition is that requirements errors discovered late are vastly more expensive to fix than requirements errors discovered early. Boehm's 1981 cost-to-fix curve (a separate finding) showed defects cost about 5x to fix in design, 10x in build, 20x in test, and 100x in operations. NASA's requirements-vs-overrun curve is essentially Boehm's curve applied at the project level: starve the requirements phase and you bake in expensive rework.

For project managers, the practical reading is: budgets that allocate only 5-10% of effort to discovery and requirements are not lean. They are pre-committing to 30-50% cost overrun. The cheapest insurance against overrun is to fund the front of the project properly.

How to cite

NASA (2007). NASA Systems Engineering Handbook, NASA/SP-2007-6105 Rev 1. NASA Headquarters, Washington DC. See Figure 1.4-1 and related cost analyses.

Source: NASA-STD-7009A (PDF) and the NASA Systems Engineering Handbook at nasa.gov.

NASA Requirements vs Cost Overrun: The 5-10% vs 20% Curve

The curve in full

Why the curve is so steep at the low end

How to cite

Related references on this site