The Changing Cost of Change
I’ve written previously about how process needs to change depending on the stage of your project.
Doing so will mean you can remain responsive to changing information and constantly optimise your project.
The last blog I wrote outlined how agile approaches — Scrum and Kanban — can be adapted and used to better deliver projects. Each is applied at a different point because they deal with change differently.
Let’s take a quick look at where the cost of change is in a project.
Why is this relevant?
A traditional project management approach tends to head quickly toward a point in time that fixes intentions. Thereafter, we see the familiar concept of the change order, or change request, invariably loading on additional fees to accommodate re-work. While this is quite predictable when cost is the major driver in selecting a contractor, the relationship isn’t direct, and costly change orders can arise even with more experienced and expensive contractors — it’s the paradigm.
Interestingly, it’s predicated on a myth. It’s a case of circular reasoning that has likely cost industry trillions: the cost of change after design is high because we make the cost of change high after design.
Depending on your geography and industry, this problem (amongst other similar issues) isn’t as terrible as the above lays out — companies have learned to go with a trusted partner rather than the lowest cost bidder for the sake of the lowest cost. But it’s not gone.
And where I’ve painted a picture with change orders to cajole you to roll your eyes in sympathy, the issue is systemic — believing that something can’t be changed beyond a certain point is bad.
If that’s a bad myth, what’s the reality?
Change changes.
The cost of change is relatively low until you start to deal with more than paperwork and people. Sure, your team will grow a bit as you get more serious in your intentions, but their ability to change something is, in the technology powered 21st century, a factor of how many times Ctrl + Z can be mashed, rather than the complicated print-and-mail logistics of the pre-internet age. It’s cheap.
For conventional projects, that’s much longer than you’ve been led to believe — it straddles the whole detail phase between agreeing your designs and building them.
And even once you’ve started building, construction, manufacturing and so on, cost of change isn’t high immediately. It just gets high much faster compared to the people-and-paperwork phases previously.
As soon as you order parts and materials, you add costs you didn’t have earlier in the project.
Relatively speaking, your cost of change is now higher. You’re getting together an inventory of components that are specific to your project, meaning you can’t offload them easily if circumstances change — they’re less liquid.
Therefore, the inverse is true: before you order these things, the cost of change is relatively low, your project remains quite liquid.
That means you should welcome change well into the detail phase of your project, and with suitable analysis even beyond that. People change their mind, budgets shift, contexts switch, contractors change.
All these things are normal in standard project delivery. If nothing else, better late than never.
