Glossary
Cost of Change Curve
cost curve of change, change cost curve
The cost of change curve shows 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; by Barry Boehm's rule of thumb, the same correction after sign-off costs about a hundred times as much. The curve explains why projects clarify requirements early and review them before every phase gate.
Why does the cost of a change rise over the project?
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
Where does the curve come from, and does it still hold?
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.
What does the curve mean for project planning?
- Clarify requirements early: A written statement of work and a review before every phase gate move clarification to where it is cheap.
- Close phases with milestones: In the waterfall model, every milestone marks a decision the next phase builds on.
- Put a number on late changes: Every change shifts cost, schedule or scope within the triple constraint. Quantify that effect before you approve it.
Example: During construction of an office building, the client wants to move a partition wall. At the design stage, the architect changes one drawing. Once the wall is built, demolition, a new wall, electrical work, plastering and painting come on top, plus a new date for the handover inspection.
How do you record decisions in Merlin Project?
To use the curve, you need to see later what was planned at the moment of a decision. Merlin Project stores the entire project history in every document and works with a dynamic baseline. You do not need to save a baseline manually.
- Put a milestone at the end of every phase with Insert › Milestone (Alt+Cmd+M), for example "Design approved".
- After a change, open File › Project Settings (Cmd+;) and enter the approval date in the Reference Date field.
- All Planned fields now show the values of that day. In the Gantt chart they appear as gray reference bars next to the current bars.
- The views Plan/Actual Comparison (Time) and Plan/Actual Comparison (Cost) list the deviations as a table.
This shows you what a late change has shifted in schedule and cost. The dynamic baseline and the plan/actual views are part of Merlin Project only, not Merlin Project Express.
