How many times can your platform rollout afford to be wrong?
I sat in a steering meeting a few years ago that I’ve never quite stopped thinking about, because it taught me that the expensive thing in a rollout isn’t getting something wrong. It’s what it costs to fix it afterwards.
Eight months into a deployment, visibly behind, and the sponsor wanted to know what had happened. What came out eventually was that an approval step in the design routed to a role that no longer existed. The person had moved functions in month three. Nobody in delivery knew, and nobody in the business knew the design depended on him.
Small thing. Fixing it meant reopening a workflow that four other things had been built on top of, which meant a change request, which meant a gate, which meant six weeks.
Nobody in that room had done anything wrong
That’s the part that stayed with me. The platform was right, the design was right the day it was written, the discovery had been thorough and the governance worked exactly as designed. The organization had just moved, the way organizations do, and the plan hadn’t.
What I think now is that every rollout carries an unwritten budget for being wrong. Not a risk register, which is about things that might happen. I mean how many times you can discover that something agreed in month one is no longer true, fix it, and get the fixed version back in front of the people who have to live with it.
For most rollouts that number is one. Maybe two if the sponsor is patient.
Once you see that, a lot of odd behaviour starts making sense. Why teams defend a design they privately know has drifted. Why new information shows up as a change request rather than as information. Why the cheapest thing an organization can do with something it just learned is nothing at all.
We froze the wrong thing
Funding is approved against a defined scope and reopening scope reopens the business case. Integration teams need interfaces that stop moving or nothing gets tested. In a regulated environment an auditor will ask what was approved and when, and “we kept adjusting” is not a survivable answer.
There’s a human cost too that never appears in a plan. Every reopened decision asks someone to make the same call twice, and do that enough and you lose the thing a rollout needs most, which is people willing to commit to an answer.
So the problem isn’t that we freeze things. It’s what we freeze. A funding envelope should be genuinely hard to change. An approval chain built on last spring’s org chart should not get the same protection, and it does only because we built one governance process and pointed it at everything.
Which is roughly what Contextual Delivery is reaching at. If the build comes out of the environment as it currently runs rather than a document signed in March, the next version doesn’t mean redoing the analysis that produced the first one. Being wrong gets cheaper, and once it does, the first answer no longer has to survive nine months.
None of which speeds up the human part. People still have to agree, and learn, and decide they trust it.
But I’d ask a rollout something different now than I used to. Not whether the design is right.
How much would it cost you to find out it isn’t?
