Your Operating Model is not a Monument

A scene repeats itself across large transformations. I have sat in versions of it more times than I care to count. The chief operating officer turns to the programme director at steering committee and asks the most disarming question in the room. “Remind me why we’re building this?” The programme is eighteen months in, several million pounds deep, and halfway through its second major milestone. Everyone around the table knows the answer in theory. The delivery plan traces back cleanly to a target operating model signed off nearly two years earlier. Every workstream has a thread of lineage back to that founding artefact.

What nobody wants to say out loud is that the artefact no longer describes the organisation paying for it. The market has moved. A new regulatory regime is on the horizon. Two executive members who sponsored the original design have left. A technology decision made in year one is already looking like the wrong one. And yet the programme is pressing on, dutifully shipping capabilities against a blueprint the business has quietly outgrown.

That scene is not unusual. It is the rule, not the exception.

The target we keep missing

The target operating model is one of the most widely used artefacts in the business architect’s toolkit. It describes where the organisation intends to be in three to five years: which capabilities it will run, how it will organise itself to run them, what technology will underpin them, what data will flow through them. It is the scaffolding around which transformation programmes are shaped, investment cases are approved, and operating model design authorities govern change.

It is also, increasingly, an artefact the world no longer respects.

Consider the last five years. A pandemic rewrote customer behaviour and workforce expectations in six months. An AI wave made every capability map drafted in 2022 look a generation old. Interest rate shifts and tariff regimes gutted long-dated business cases and reset the economics of cross-border sourcing. None of these respected a five-year horizon. Most did not respect a one-year horizon. And yet organisations have continued, with surprising consistency, to commission target operating models on the assumption that the destination will hold still while the journey is walked.

The orthodoxy is failing. What is not clear is what should take its place.

Two failure modes, one root cause

When I look at the transformations I have been close to over the last two decades, two patterns recur.

The first is the TOM that ages faster than the programme delivering it. The document is produced, signed off, and locked down. The programme is chartered against it. Somewhere between year one and year two, the organisation’s priorities move. A new CEO is appointed. A competitor makes an unexpected move. A regulator issues new guidance. The TOM, sitting in a SharePoint folder, does not move with them. By year three, the programme is delivering capabilities that no longer match what the business now needs. In the best cases, the team notices, raises a change request, and absorbs a painful replan. In the worst cases, they keep delivering to the original blueprint because the governance is built around it, and nobody has the appetite to reopen the business case.

The second is the TOM that never gets delivered at all. The document is well crafted. The ambition is clear. The programme charter is written. But the organisation never musters the continuity of leadership, funding, or attention to see it through. Fragments get delivered. The rest sediment into the backlog of things the organisation meant to do. A new TOM is commissioned two or three years later. The cycle begins again.

Both failure modes share a common root. The target operating model is treated as a destination. The delivery of it is treated as a journey. And like every journey planned in detail against a fixed destination, the first serious weather event breaks the plan.

Not dead. Just wrongly used.

I want to be careful here, because it would be easy to write off the TOM entirely, and I do not think the artefact is the problem.

A target operating model forces useful conversations. It forces an executive team to decide which capabilities matter most, where the seams of the organisation should sit, what they will stop doing, what they will invest in, and how the pieces hang together. These are conversations most organisations, left to themselves, will not have. The TOM is a forcing function for strategic clarity, and strategic clarity does not come for free.

The problem is not the artefact. The problem is the cadence and the delivery model we have wrapped around it.

We have treated the TOM as a once-every-five-years event, produced at considerable expense, blessed by the board, and then left to ossify. We have treated the delivery of it as a mega-programme, chartered on day one, governed against the original design, and driven to completion regardless of whether the original design still makes sense.

Neither habit fits a world that has stopped behaving predictably.

A rolling target

If the five-year TOM is broken, what replaces it?

My working answer is a rolling target operating model. Not a destination refreshed every five years, but a directional artefact refreshed continuously against a shorter horizon. Three disciplines do most of the work.

The first is pace-layered design. Stewart Brand captured the idea in his 1999 book How Buildings Learn, and Gartner later adapted it for enterprise architecture. The principle is that different parts of any complex system move at different speeds. In an operating model, some elements should move slowly: the organisation’s purpose, its core capabilities, its fundamental customer proposition. Others should move quickly: channels, partnerships, product configurations, the technology stack. Separating the slow layer from the fast layer stops the whole artefact from being thrown out every time the world moves. It also clarifies where governance effort should sit. You can refresh the fast layers every quarter without relitigating the slow ones.

The second is a rolling horizon with an explicit assumption register. Rather than describing where the organisation will be in five years, the rolling TOM describes where it intends to be in the next twelve to eighteen months, refreshed every six. Alongside the model sits a register of the assumptions it depends on: market conditions, regulatory direction, technology availability, customer behaviour, cost of capital. Those assumptions are tested on a regular cadence against external signals. When one breaks, the affected part of the TOM is revisited immediately, not at the next five-year review. Financial services firms already do this for capital adequacy under ICAAP and for operational resilience under the post-2022 UK regime. It is overdue in operating model design.

The third is optionality in capability investment. Instead of committing to the full stack of changes needed to reach a single end state, the rolling TOM prioritises moves that create options. Capabilities useful in multiple scenarios. Technology choices that preserve exit routes. Organisational changes that increase flexibility rather than lock in a single path. Defence planners have used scenario-based capability planning for decades, and corporate strategy has been catching up slowly. Business architecture has been slower still.

The rolling TOM has its own failure modes, and it is worth naming them. Perpetual recalibration can become its own pathology. An organisation that never settles long enough to deliver anything substantial ends up with decision fatigue and an eroded sense of shared direction. The discipline is to know which parts of the model hold still and which flex, and to resist the temptation to reopen the slow layers every time the fast ones shift. Pace-layering is the guardrail against that.

The mega-programme problem

The rolling TOM only works if the delivery model changes with it. This is where the argument becomes uncomfortable, because the mega-programme is one of the most culturally embedded features of transformation.

The pattern is familiar. A large design effort produces a TOM. A programme is chartered to deliver it. The programme is sized in hundreds of millions and years. A full governance superstructure is built around it: steering committees, design authorities, benefits realisation frameworks, reporting cadences. The programme becomes, in effect, a second organisation running alongside the business, with its own targets, its own metrics, its own momentum.

By the time the programme reaches its second or third year, three things have usually happened. The original TOM has drifted out of alignment with what the business now needs. The programme has built up enough sunk cost and political weight that nobody wants to be the person who suggests stopping it. And the architects who set the direction have either moved on or become curators of an obsolete blueprint.

I have watched programmes deliver perfectly against scope and still fail to move the business. I have watched others cancel at year three with a portfolio of half-finished capabilities and a book of lessons learned that rarely gets opened again. Both outcomes share the same root cause. The delivery model assumed the target would hold still, and it did not.

A fair objection lands here. Some changes genuinely cannot be compressed into shorter arcs. Core banking replacements, insurance policy administration migrations, regulated entity consolidations, large ERP overhauls. These carry dependency chains, data migration sequencing, and regulatory approval timelines that resist a twelve to eighteen month cut. Anyone who has delivered one knows the compression argument breaks down quickly in the face of real engineering and regulatory constraint.

The answer is not that every programme should be chopped into small pieces. The answer is that the design cadence should be separated from the delivery duration. A five-year platform migration can still sit inside a rolling operating model refreshed every six months. The difference is in how the programme is governed. Recalibration gates are built into its lifecycle. The governance is designed to absorb direction changes rather than resist them. The architects stay close to the model, not just to the plan, so that when the underlying assumptions shift, the programme adapts rather than ploughing on.

Put differently: the critique is not of long programmes. It is of long programmes running on short-term assumptions that were never tested again after sign-off.

Where the shape of the work permits, break the change into shorter arcs that hold value on their own. Build in explicit recalibration gates between them, at which the rolling TOM is refreshed and the next arc’s priorities are set against current conditions. Measure the arcs on outcomes, not on output against the original design. Where the shape of the work does not permit shorter arcs, build the same recalibration discipline inside the long programme, and hold the governance to it.

Architects should be navigators across these arcs, not guardians of a fixed target. Their value sits in helping the organisation see where the capability gaps are now, where the next arc should concentrate investment, and where the last arc’s assumptions are beginning to crack.

What this changes for the practitioner

For business architects, the implications are significant.

The craft shifts from producing a definitive TOM to maintaining a living one. The artefact matters less than the cadence around it. The conversation matters more than the document. The architect’s authority comes from being the person who knows what is changing and why, not from being the person who once wrote the blueprint.

For delivery leaders, the shift is from managing a programme to managing a rolling portfolio of shorter arcs, or, where the programme is unavoidably long, building recalibration into its lifecycle. The governance superstructure either simplifies or gets re-pointed at direction changes rather than scope defence. The accountability sharpens, because each arc, or each recalibration gate, has to justify itself on outcomes.

For executives commissioning transformation, the ask is harder. It is easier to approve a single large business case than to commit to a rolling series of smaller ones. It is easier to point at a finished TOM and say “this is what we paid for” than to explain that the TOM is now a continuously refreshed artefact. But the easier path is also the one that keeps producing programmes that miss.

The target was never the point

The uncomfortable truth, for anyone who has spent a career producing target operating models, is that the target was never really the point. The value was never in arriving somewhere specific. The value was always in the conversation the artefact forced, the decisions it made explicit, and the discipline it imposed on investment.

The target operating model is not dead. But the habit of producing one every five years, handing it to a mega-programme, and waiting for delivery belongs to a world that no longer exists.

If your TOM has not changed in eighteen months, it is not a target. It is a monument. The most useful thing you can do with it is pick it up, treat the assumptions as hypotheses, and ask which of them still hold.

That, not the document, is where the work is.