Target operating model

Every organisation already has an operating model for data and AI. Most of them have never written it down, which means it was arrived at by accident and is defended by whoever benefits from it.

This is the least visible work I do and, on the evidence of my own engagements, the highest returning. Taking thirty per cent of low value work out of a $17M portfolio was an operating model change, not a technology one. Nothing was bought to achieve it.

The operating model work was worth more than any single product we shipped. Deciding what not to build is where most of the money was.

What usually breaks

Nobody can refuse anything. Every request becomes a commitment because there is no agreed way to say no, so the portfolio grows until the team is the constraint and everything is late.

Decision rights are unwritten. Four people believe they own the roadmap. In practice it is owned by whoever escalated most recently.

Funding is annual and work is not. Money arrives once, in a lump, against a scope agreed before anybody knew anything. The team then spends the year defending an estimate rather than pursuing a result.

Central and federated fight. A central team that cannot keep up and business teams building in the shadows, each convinced the other is the problem. Usually neither is: the split of responsibility was never defined.

The function depends on individuals. It works because three people care. There is no succession, so the maturity is real but not durable.

The path a request actually takes. Not an org chart. An org chart tells you who reports to whom, which is the least useful thing to know about an operating model. This is the only diagram here with a visible reject route, because refusing work is the part almost nobody designs.

What this covers

• Decision rights. Who decides what gets built, who decides what gets stopped, and who can overrule either. Written down, in one page, agreed by the people named on it.
• Demand governance. How work enters, how it is scored, and the agreed basis on which it is declined. This is the piece that requires saying no in public, which is why it usually needs somebody from outside.
• Funding shape. Moving from annual project approvals to a standing allocation reviewed against value delivered. The argument for that is here, and it is the single change that most reliably outlives me.
• Delivery shape. Central, federated or hub and spoke, decided from your actual demand pattern rather than from a diagram in a vendor deck. Pod structure, spoke leads, and where the line sits between platform and product.
• Roles and skills. What you need on payroll, what you can rent, and what you should stop doing entirely. Including the honest version of which roles you are unlikely to hire in your market.
• Value realisation. Baselines, named budget holders and a review cadence, so the function can prove what it returned rather than assert it.

How I approach it

Start from the demand, not the org chart. What actually arrives, from whom, how often, and what happens to it. A week of that tells you more about the right shape than any target state workshop.

Then change the smallest number of things that alter behaviour. Decision rights and demand governance almost always come first, because they are cheap, they are visible, and they immediately stop the bleeding. Structure comes last, because reorganising before the rules are agreed just relocates the argument.

Where I am careful

I am wary of reorganisations presented as operating model work. Moving people between boxes is the most disruptive intervention available and the least likely to change an outcome on its own. If the rules do not change, the new structure produces the old behaviour within two quarters.

I am equally wary of governance that only adds friction. A demand process that slows good work down without stopping bad work is worse than none, because people route around it and you lose visibility as well as time.

What you are left with

• A one page decision rights map, agreed by the people named on it rather than circulated to them.
• A demand governance process with a scoring basis, including the agreed grounds for declining work.
• A funding recommendation that moves the highest value work off annual approval.
• A target delivery shape with the transition sequenced, not just the destination drawn.
• A role and skills plan separating what to hire, what to rent and what to retire.
• A value realisation cadence with baselines and named budget holders, so year two is defensible.

Where this has worked

I have built the function from zero twice and rebuilt one that already had defenders, which is the harder of the two. A 50+ person cross functional organisation across India, the US and Europe on a pod model with spoke leads. A drug development analytics function inside a corporate centre of excellence, including the succession pipeline. And demand governance that removed a third of the portfolio while maturity went from 46 to 88 per cent in a year. The case studies are here.

How this connects

Operating model is not a layer in the chain. It is how every layer gets run, which is why a weak one shows up as a low score at several gates at once rather than at one of them.

If the free gate check comes back with three or four gates low and no obvious pattern, this is usually the answer rather than any of the individual fixes.