The post-mortem pattern
We've sat in on a lot of post-mortems for transformation programmes that didn't land. The story is almost always the same shape. The technology was delivered. The dashboards lit up green for a quarter. Then usage drifted, the operational metric didn't move, and the budget got reallocated. The headline conclusion: 'the technology didn't fit.' The actual conclusion, six layers down: nobody changed how decisions got made when the new system existed. The decision rights still flowed through the old org chart, the old approval cycles, the old incentives. The system was a thin layer of evidence on top of an operating model that hadn't moved.
Why operating-model change is harder than tech change
Tech change has a clear definition of done: the system is in production, the test suite passes, the SLA is met. Operating-model change has no equivalent. It involves rewriting decision rights, RACI matrices, incentive systems, and the unwritten rules of who gets to override whom. None of those have a unit test. The work is political, not technical — which is why technical teams systematically under-invest in it.
What we ship alongside the technology
Concretely: a written decision-rights document that names the person who approves each class of change. A working agreement with the operating team for how exceptions are routed during the first 90 days. A retrospective cadence with a fixed audience that meets even when there's nothing dramatic to report. A 'sunset clause' for at least one piece of the old workflow — committed to in writing — so the new system isn't running in parallel forever. None of this is software, and all of it is load-bearing.
Two failure modes to avoid
Failure mode one: ship the technology, declare success, move on. Six months later the old workflow has reasserted itself and the new system is a shadow estate. Failure mode two: try to redesign the operating model from scratch before shipping anything. The redesign takes 18 months, nothing ships, and the budget moves to whoever's promising delivery this quarter. The right move is co-design: the operating-model change ships inside the same engagement as the technology, scoped to the specific decisions the new system touches. Not the whole org. Not 'after we've delivered.' Together, in the same engagement.
Closing
If you're scoping a transformation, treat the operating-model questions with the same engineering rigor you treat the data architecture. They're harder. They're more important. And they're the variable that decides whether the technology investment compounds or evaporates.