I've watched a fair number of transformation programmes now, from the inside and from close enough alongside to see how they ended, and I've noticed something that took me an embarrassingly long time to accept.
Almost none of them failed for the reason everyone said they failed.
When a big insurance programme goes sideways, there's a story that gets told afterwards, and it's nearly always a technology story. The platform couldn't scale. The integration was harder than the vendor promised. The data migration threw up problems nobody anticipated. The architecture didn't fit. These explanations are comfortable, because they're specific, they're blameable, and they point at something you can fix next time by choosing a different tool.
They're also, in my experience, mostly wrong. Or rather, they're the visible wreckage, not the thing that caused the crash.
The programmes I've seen fail didn't fail because someone picked the wrong platform. They failed because of something much quieter and much harder to point at, something that doesn't show up in a status report until it's far too late to do anything about it. They failed on ownership. Specifically, on a set of decisions that nobody, at any point, was clearly responsible for making.
The failure doesn't look like a failure for a long time
Here's what makes this so difficult to catch. A programme dying of unclear ownership looks, for months, exactly like a programme that's going well.
The kickoff is energetic. The vendor is engaged. The steering committee meets. There are workstreams, and the workstreams have leads, and the leads produce slides, and the slides are green. Everybody is busy, genuinely busy, and the busyness feels like progress because most of the time busyness and progress are the same thing.
But underneath the activity, a specific kind of question keeps not getting answered. Not the big obvious questions, which everybody knows to escalate. The small, awkward, boundary-sitting questions that don't clearly belong to anyone.
Whose definition of "active policy" are we building to, underwriting's or finance's, given that they've never actually agreed and each has good reasons for their version? When the treaty terms conflict with what the downstream accounting system can represent, who decides which one bends? Is the migration supposed to preserve the historical mess exactly as it is, or clean it up, and if we clean it up, who signs off that the cleaned version is still correct? These questions sound small in isolation. They are not small. Each one is a fork in the road, and taking the wrong branch quietly commits the programme to months of rework that won't surface until integration testing.
And the thing about these questions is that they don't get escalated, because escalation requires somebody to first notice that the question is unresolved and important, and the whole problem is that no single person can see the full shape of it. The business assumes the BA has it. The BA assumes it was decided in a workshop they weren't in. The vendor assumes the client will tell them if it matters. Everybody is reasonably assuming somebody else is holding it, which is exactly how a thing ends up held by nobody.
Why insurance is unusually good at hiding this
Every industry has this problem to some degree. Insurance has it worse than most, and the reason is structural.
Insurance runs on definitions that look settled and aren't. A policy, a claim, an exposure, a premium, a reserve — these feel like fixed, universally understood objects, and they are nothing of the kind. The definition of any one of them shifts depending on whether you're asking underwriting, actuarial, finance, claims, or compliance, and each function has built years of process and mental habit on top of its own version. Nobody is wrong, exactly. They're locally correct in ways that quietly contradict each other.
For most of the organisation's history this doesn't matter, because the functions operate at arm's length and translate between themselves through habit, email, and the occasional argument at quarter-end. The contradictions are absorbed by people. Experienced people carry the reconciliation around in their heads, and it works, in a slow and expensive way, precisely because it never has to be written down in one place.
A transformation programme is the moment all of that has to be written down in one place. That's what a platform is, underneath the technology — it's a single, explicit, unforgiving statement of how the business actually defines things. And the instant you try to make those definitions explicit and shared, every contradiction that people have been quietly absorbing for years surfaces at once and demands a ruling.
This is roughly what I meant in an earlier piece when I described reinsurance as the most under-digitised corner of insurance, still running on spreadsheets, email, and individual memory. The under-digitisation isn't only a tooling gap. It's years of unreconciled definitions held together by people, and a transformation programme is the bill for all of it arriving at once.
The clarity that matters isn't the clarity people mean
When people say a programme needs "clear requirements," they usually picture a thick document. A well-structured, exhaustively detailed specification, signed off, version-controlled, comprehensive.
I've come to think that's almost beside the point, and occasionally it's worse than beside the point, because a thick signed-off document can create a powerful illusion that the hard decisions have been made when all that's actually happened is they've been written down in language vague enough for everyone to agree to. Two functions can both sign off on "the system will maintain an accurate view of policy status" while privately meaning two incompatible things by it. The document is complete. The conflict is completely intact. It's just been laminated.
The clarity that actually determines whether a programme survives isn't documentary. It's decisional. It's whether, for each of the genuinely contested questions, there is a named person with the authority and the context to make the call, and whether that call actually got made and communicated rather than deferred into a document.
Those are very different kinds of clarity, and organisations are much better at producing the first than the second, partly because the first is comfortable and the second involves telling a senior person in one function that the definition they've used for fifteen years is not the one the platform is going to use. That conversation is unpleasant. It's also the entire job. And when it doesn't happen, the decision doesn't go away. It just gets made by default, later, badly, usually by a developer who had to build something and picked whatever interpretation let them keep moving.
The quietest and most expensive failure of all
There's a particular version of this that I find almost tragic, because it's invisible right up until it's catastrophic.
A contested definition never gets resolved. Nobody owns it, so nobody forces the decision. The programme needs to keep moving, so an interpretation gets chosen implicitly, buried in a design somewhere, without anyone with the authority to own that choice ever actually seeing it. Development proceeds. The demos look fine, because the demos use clean, cooperative data that never exercises the contested edge. Everyone relaxes.
Then the programme reaches the real data, or the quarter-end close, or the regulatory report, and the buried interpretation meets the reality it was quietly wrong about. And now it isn't a decision anymore, it's a defect, embedded deep in a system that's been built on top of it, and unwinding it means unwinding everything that assumed it. This is the same lesson I keep running into from platform work, that the dangerous number is never the one that's obviously wrong but the right-looking one nobody can trace, and it applies just as brutally to a definition as to a figure. A decision nobody consciously made is far more expensive than a decision made badly, because at least the bad decision had an owner who could be asked to revisit it.
So where does this leave us
If I'm right that these programmes fail on ownership rather than technology, then a lot of the energy we pour into choosing platforms and grading vendors is energy spent on the part of the problem least likely to actually kill us. The platform matters, of course it matters. But it sits downstream of a set of decisions most programmes never hand to anyone, and a brilliant platform built on unowned definitions is just a faster, more expensive way to arrive at the same wall.
So here's what I've had to sit with, and it isn't comfortable.
Every programme I watched fail had a budget for the platform. It had a budget for the integrator, the migration, the testing, the change management. It had a name attached to every one of those things. And not one of them had a single person whose actual job was to stand in the gap between the functions and force the contested definitions to a decision before they turned into concrete. The most expensive role on the programme was the one nobody had hired, because it didn't look like a role. It looked like something that would just sort of happen.
It never just sort of happens.
And the part that genuinely keeps me up is this. That gap isn't unfilled because it's hard to fill. It's unfilled because almost every programme hands it, by default and without thinking, to exactly the wrong person — someone without the authority to make the call, or without the context to see the conflict, or without the standing to tell a fifteen-year veteran that their definition isn't the one that's shipping. We put the one decision that decides everything in the hands of whoever happens to be nearest to it, and then we act surprised when it doesn't get made.
There is a role built precisely for this. Most organisations already have the person. They've just pointed them at the wrong work, handed them the wrong remit, and quietly trained them to produce documents instead of decisions.
In Part 2, I'm going to name that role, make the case for why it's the right one, and lay out exactly how you turn it from the person who writes down what everyone agreed into the person who makes sure there's actually something to agree on. If you've ever watched a programme drift green-status all the way into a wall, you already know why this is the part that matters.
Part 2 is where the fix lives. I'll see you there.