Part 2 of 2

I finished the first part of this with a claim I owe you an answer on. Every insurance transformation programme I've watched come apart had a budget and a named owner for the platform, the migration, the testing, the change management, and not one of them had a person whose actual job was to force the contested definitions to a decision before they set into code. The most expensive role was the one nobody hired, because it never looked like a role. It looked like something that would just sort of happen on its own.

So I should probably name it, even though naming it is going to be a bit of an anticlimax.

The role is the business analyst. And if reading that produced a small sigh in you, a sense that I've taken a genuinely serious problem and handed it off to the person who writes the requirements document, then you've landed on precisely the thing that's gone wrong. Because the BA as most programmes actually use the role really is the wrong person to hold this. It's the BA as the role could be used who's the right one, and the whole argument here lives in the distance between those two versions of the same job.

Why it keeps landing on the wrong version of the role

The trap is an honest one, and reasonable people walk straight into it.

A contested definition surfaces. Underwriting and finance turn out to mean different things by "active policy," and the programme does the thing that feels sensible, which is to ask the analyst to capture the requirement. Go and talk to both sides, understand where they stand, write it up clearly, bring it back so everyone can see it laid out.

And the analyst, being conscientious, does exactly that. They document underwriting's view and finance's view, faithfully, in a clean table with the differences highlighted, and they bring it to a meeting. Everyone studies it, agrees it's a very good summary of the disagreement, and then the meeting runs long, somebody has a hard stop, and it moves on. The document goes into the folder. The disagreement is now beautifully articulated and exactly as unresolved as it was an hour ago.

This is the failure I keep circling back to in almost everything I write about this work. The output was a document, and the document got quietly mistaken for the decision. Capturing a conflict with real clarity feels like progress, and it hands you something tangible to point at, but it moves the actual decision precisely nowhere. The analyst did the job as it was framed for them. The framing was the problem.

What the role has to become

The change I'm arguing for is easy to say and genuinely hard to do. On a transformation programme, the analyst's job is not to document the decisions. It's to make sure the decisions actually get made.

Those two things sound close and they're miles apart in practice. Documenting a decision is a recording job. You sit downstream of the choice and write down what was chosen. Making sure the decision gets made is closer to the opposite. You sit upstream, you spot the fork in the road before anyone else has noticed it's a fork, and you refuse to let the programme wander past it while it's still unresolved. The first version waits for clarity to show up and then captures it neatly. The second goes and manufactures clarity that, left alone, would never have formed at all.

What makes me keep landing on this role rather than dreaming up some new one is that the analyst is already standing in the only spot on the whole programme where this is even possible. They're the single person who talks to underwriting and finance and claims and the vendor and the developers. They're the one who sees that what underwriting quietly assumes and what the accounting system can actually represent don't line up, because they've been in both rooms in the same week. The architect sees the technical shape of things. The project manager sees the schedule and the dependencies. It's only the analyst who sees the semantic collisions, the places where two functions are using one word to mean two different things and calmly building on top of it. That's a rare vantage point, and it's almost entirely wasted if the only thing it ever produces is a tidy description of the collision.

I've made a version of this case before in a different setting, that the analyst whose whole value is the document is building a career on the one thing that just became free, and that the version of the role worth keeping is the one that builds and owns rather than describes. This is that same argument in different clothes. On a transformation programme, owning doesn't mean writing sharper specifications. It means taking it personally that a contested definition either gets ruled on or gets escalated to someone who can rule on it, and never once gets buried in a design because the programme needed to keep the wheels turning.

But the BA doesn't have the authority

Here's the objection, and it's a fair one, so I'd rather meet it than tiptoe around it.

An analyst usually can't simply declare that finance's definition of "active policy" beats underwriting's. They don't have the seniority for it, and honestly they often shouldn't, because a call like that can carry regulatory or financial weight that sits well above their level. So how can I hand ownership of a decision to someone who can't actually make the decision?

The answer is that owning a decision and making a decision are not the same act, and letting them blur together is exactly what lets everyone quietly off the hook. The analyst's ownership is procedural rather than substantive. Their job isn't to be the one who chooses. It's to be the one who guarantees a choice gets made, by the right person, in time, and then travels everywhere it needs to travel. In practice that means surfacing the conflict early, while it's still cheap to touch. It means framing it sharply enough that a decision-maker can genuinely decide, instead of having two pages of context dumped on them with a vague hope that they'll sort it out. It means working out who actually holds the authority for this specific call, getting it in front of them, and staying on it until it's closed rather than letting it slip because the last demo happened to go fine. And it means treating an unresolved contested definition as a live defect in the programme, not a tidy open item near the bottom of a list.

The cleanest way I can put it is that there's a difference between the person who makes every decision and the person who makes sure no decision goes missing. On the programmes I watched fail, nobody was doing that second job. Everyone assumed it would take care of itself, folded invisibly into somebody else's remit, and it turns out to be exactly the kind of thing that never takes care of itself.

What this looks like on a Tuesday

Let me get concrete, because it's easy to write lofty paragraphs about ownership and the whole thing actually lives or dies in the ordinary practice.

It looks like a decision log, though not the passive sort that just records what got agreed. It's a running register of the contested definitions and the open semantic conflicts, and each one carries a named owner who actually has the authority to resolve it, a date it has to be resolved by because something downstream is waiting on it, and a visible, slightly uncomfortable status once it goes overdue. The discomfort is deliberate. The entire failure in Part 1 was that these questions stayed invisible until integration testing turned them into catastrophes, so the fix has to be a mechanism that keeps them impossible to ignore while they're still cheap to fix.

It looks like walking into the room with a forced choice instead of an open question. Not "here are underwriting's and finance's views on active policy, what does everyone think," which only ever buys you another round of admiring the problem together, but something closer to "these two definitions conflict, here's what breaks downstream under each one, here's who I think needs to own this call, and I need it made by Thursday because we can't build the data model until it is." One of those framings actually moves a decision. The other just books another meeting.

And it looks like being willing to be a little bit annoying. Being the person who keeps raising the definitional question everyone would rather leave for later, who won't quietly accept "we'll figure that out down the line" on something where down the line is where it gets ruinously expensive. That's not a comfortable way to be, and it's a good part of why the role gets quietly declined even by people who technically hold the title, because it is so much more pleasant to hand over a clean document and let the awkward conversation be somebody else's problem. But the clean document was never the thing the programme was dying for the want of.

Why this matters more now, not less

There's a version of this argument that was already true a decade ago, and it was. But something has shifted underneath it that sharpens the whole thing to a point.

The documentation half of the analyst's job, the capturing and the writing-up and the neat tables of who-said-what, is precisely the half that machines have become genuinely good at. If the centre of gravity of the role stays parked there, it isn't only worth less than it should be. It's directly exposed. The parts that survive are the parts that were never really about the document in the first place, the judgement to see which of the definitional conflicts is actually load-bearing, the standing to push it to a decision, the context to know whose call it even is. None of that automates, because none of it is a translation task. It's a run of judgements made in rooms full of people who disagree with each other, and then the nerve to act on what you've concluded.

So the shift I'm describing isn't only how you keep a transformation programme alive. It's how the role itself stays worth having at all. The analyst who owns decisions is doing the single part of the job that both rescues the programme and can't be handed to a model. The analyst who owns documents is doing the part a programme increasingly doesn't need a person for.

The one thing I'd leave you with

If nothing else survives from these two pieces, I'd want it to be this. On a transformation programme the platform sits downstream of the decisions, the decisions sit downstream of somebody choosing to own them, and that somebody is very often already on your team, mislabelled, underused, and quietly turning out documents instead of forcing the choices that would actually save the thing.

You probably don't need to go and hire the most expensive role on your programme. You need to find the person you've already got, and let them stop writing the problem down long enough to go and solve it.