Everyone knows the canonical cost of change curve (first image), where the cost of a change rises exponentially throughout the project. Let's pretend it's a law of nature, as many many project planners before us have done.

Now suppose someone notices they need to change a requirement in the middle of the project. The cost of change curve says that the change would be far too expensive. So it's not made.

Fine. But we know that almost every product that's actually used gets re-released with new features added. Most usually, the next project starts as soon as the previous one finishes. According to the cost of change curve, that's exactly at the point where the costs are highest (second image).

The decision to postpone changes can only make sense if the cost of change resets to something much closer to the far left of the curve (third image). What's supposed to make that happen? And why doesn't that operate in the middle of the first project's curve?

These are serious questions, even though I suspect I'm being stupid. I'm writing a book chapter that explains conventional and agile software development to an audience of sociologists, and this occurred to me. Mail me, and I'll summarize.