Glossary
Cost of Change Curve
cost curve of change, change cost curve
The cost of change curve describes how sharply the cost of a change rises the later in a project it is made. Correcting a requirement during the concept phase costs almost nothing; the same correction after sign-off costs a multiple of that.
The reason lies in the amount of work that builds on a decision. As long as a requirement sits in the concept, changing it affects one document. Once it sits in the design, it affects the design and everything derived from it. Once it is built and accepted, rework, retesting, documentation and communication come on top. That is why the curve rises exponentially rather than linearly.
What the same change costs per phase
Relative cost of a correction, depending on when it is found
Cost of the change
Concept1x
Designabout 5x
Buildabout 20x
After sign-offabout 100x
The figures go back to Barry Boehm, who derived them from project data in "Software Engineering Economics" in 1981. For classic projects with expensive execution, in construction, plant engineering or events, the relationship still holds. Whatever is changed on site costs a multiple of what the change would have cost during planning.
In software development the curve has become considerably flatter. Automated tests, continuous integration and small releases cut the cost of a late change substantially. Kent Beck turned that into the counter-thesis: if the curve is flat, committing early no longer pays, because you can then decide at the point where you know the most.
The shape the curve takes therefore depends on the undertaking, not on the method. It rises steeply where execution is expensive and results build on one another, as in construction or migrations. It stays flat where corrections are cheap and can be verified automatically. The slope determines in which phase of the project life cycle a commitment holds its value.
