The illusion of costs incurred by having to change something late is a very real part of every day life in the IT industry. We have been schooled to think that late change is bad and should be avoided at all cost. Yet, we can and do accommodate, embrace even, late change every day. The question is how to make the change less expensive.

Generally speaking, I would name two contributors to the cost of late change: excessive bureaucracy and bad quality.

We have traditionally tackled late change by introducing change control boards and change request management, which has increased the cost of making changes significantly. According to my experience with a number of "enterprise projects", we have not actually succeeded in managing change using these processes. We have prevented change from happening but at what cost? The process of pushing a change through the organization in place is generally slow and requires non-trivial effort. At the same time, we're decreasing our throughput—the very thing that defines our productivity.

Often, the need for the change in question is real. Why should we purposefully prevent that need from getting fulfilled? Wouldn't it make more sense to serve our customer's needs as effectively as we can?

Bad quality is another very real problem with many software projects today; just like it has been for as long as I've been in this industry. Preventing change is a good way to avoid getting rid of that problem among others.