The Pattern Doesn't Lie: Why Operating Model Failure Looks the Same in Every Sector

Foreword

Over 25 years of designing operating models, I have worked across sectors that have almost nothing in common. Banking and financial services. Manufacturing. Nuclear new build. Healthcare. Each one has its own language, its own regulatory environment, its own tolerance for risk. And yet, when an operating model fails — and they fail regularly — it fails in the same way.

Most people inside these programmes never see it. They are too close to the sector-specific detail — the regulatory constraint, the technology platform, the stakeholder politics — to notice that the structural failure happening around them is the same one that has happened in industries they have never worked in, in organisations they have never heard of, for reasons that have nothing to do with the sector at all.

The gap appears between what was built and what actually works. A structure is announced. A programme delivers. A go-live is celebrated. And then, quietly, the organisation continues operating the way it always did. The governance doesn't connect to decisions. The capability isn't in place before it's needed. The transition gets treated as a communications exercise rather than a design problem.

This article sets out that pattern in full. Not in the abstract, but in the specific, recurring forms it takes every time, in every industry. If you are responsible for operating model transformation — designing it, commissioning it, or trying to recover one that has gone wrong — what follows is the diagnostic lens that changes how you see every programme you touch.

The Failure Pattern

Operating model failures are rarely spectacular at the moment they happen. They are not the result of a single bad decision or one catastrophic project. They accumulate. They compound. And they follow a sequence that is almost identical every time.

I have identified five failure modes that appear with such consistency across sectors that I now treat them as a diagnostic checklist. When I am brought into a programme, I look for these first. They are almost always present — rarely all five simultaneously, but usually three or four.

Once you have seen the pattern, you cannot unsee it. In my experience, the cost of not addressing these failure modes before go-live is typically two to three times the cost of addressing them during design. Most organisations discover that ratio in the post-implementation review.

Failure Mode 1: The Operating Model Is Treated as an Output, Not a Constraint

This is the most common failure mode, and the most consequential. The programme is structured around a technology implementation, a merger, a regulatory response, or a cost reduction target. The operating model, if it is considered at all, is what the programme produces at the end. A diagram. A structure chart. A RACI.

This gets the logic completely backwards. The operating model is not the output of the transformation. It is the framework within which transformation has to occur. It defines what the organisation needs to be capable of, how authority flows, how work moves through the system, and how value is delivered to the people who depend on it. If those questions are not resolved before the programme designs its solution, the programme will build a solution for a destination the organisation cannot reach.

I have seen this in retail banking, where a digital transformation programme redesigned the customer journey without first resolving how the branch network would operate alongside it. I have seen it in nuclear new build, where a supply chain operating model was designed for a level of organisational capability that did not yet exist and had no plan to. The sectors could not be more different. The failure mode is identical.

Failure Mode 2: Governance Is Designed for Accountability, Not for Decisions

Almost every operating model produced in a major programme contains a governance section. It specifies who sits on which board, what cadence the steering group meets at, and which stakeholders need to sign off on which decisions. What it rarely specifies is how decisions are actually made — what information is required, who has the authority to act on it, and what happens when that authority is contested.

The result is governance that functions as a reporting mechanism and an escalation path, not as a decision-making system. Issues surface in the governance forum. They are discussed. Actions are assigned. And then, in the next meeting, the same issues surface again, with slightly updated status reports. The organisation mistakes motion for progress.

I have seen this in healthcare commissioning, where integrated care systems with genuinely complex governance architectures consistently failed to make timely decisions because the governance was designed around representation rather than authority. I have seen it in professional services firms where partnership models created governance structures that everyone attended and no one owned. The setting is different. The dysfunction is the same.

Failure Mode 3: Capability Is Treated as a Training Problem

When a new operating model requires people to work differently, the standard response is to commission a training programme. This is understandable. It is also, in most cases, insufficient. Training addresses knowledge deficits. It does not address structural gaps.

Capability is a design question before it is a development question. It must be assessed, planned for, and where it cannot be built in time, factored into the sequencing of implementation. The operating model should not go live in a state that assumes capabilities the organisation does not yet have.

Failure Mode 4: The Transition Is Managed as a Communications Exercise

This is the most consistently underestimated failure mode. Organisations invest heavily in designing the future state. They invest far less in designing the route from the current state to it.

Transition is treated as a change management problem: tell people what is changing, why it is changing, and what is expected of them. Create a communications plan. Run engagement sessions. Produce a readiness assessment. And then, on go-live day, declare success.

What this misses is that transition is a design problem. The organisation cannot move from A to B in a single step. There will be a period — often an extended period — during which the old model and the new model are operating simultaneously. During that period, the organisation needs to know which model applies to which decisions, how exceptions are handled, which legacy processes have been formally suspended, and who is accountable for managing the boundary between the two states. None of that is answered by a communications plan.

Failure Mode 5: The Operating Model Is Declared Complete at Go-Live

An operating model is a living system. It is not a document that is produced, validated, and filed. But in practice, the moment a programme passes its go-live milestone, attention moves on. The programme team disperses. The budget closes. The steering group stops meeting. And the operating model — which is now encountering the real conditions of the organisation for the first time — is left to fend for itself.

This is how organisations end up, five years after a major transformation, operating in a way that bears little resemblance to the target model. Not because the design failed. Because no one was responsible for maintaining it.

The Five Failure Modes: Summary

#	Failure Mode	What It Costs You
1	Operating model treated as an output, not a constraint	Programme builds for a destination it has not defined
2	Governance designed for accountability, not decisions	Reports are produced; decisions are deferred
3	Capability treated as a training problem	Structural gaps survive the go-live
4	Transition managed as a communications exercise	The boundary between old and new is never owned
5	Operating model declared complete at go-live	The model reverts within 18 months

Why a Standard Works

These five failure modes do not respect sector boundaries. They appear in regulated industries and in competitive markets, in public sector organisations with long planning horizons and in private sector businesses under quarterly pressure, in organisations with sophisticated transformation functions and in organisations where operating model design is an unfamiliar discipline.

This presents a challenge for practitioners who have built their expertise within a single sector. Sector knowledge is genuinely valuable. But sector knowledge does not, on its own, address these failure modes, because the failure modes are not caused by sector-specific factors. They are caused by the absence of a disciplined approach to operating model design and delivery.

What Changes When the Standard Is Applied

When OMDDMS® is applied, operating model design becomes a constraint on transformation design from the outset, not an output at the end. Governance is structured around decision rights, not reporting lines — which means decisions get made rather than deferred. Capability gaps are assessed before implementation sequencing is finalised. Transition is planned as a distinct design phase with explicit accountability for managing the boundary between current and future states. And operating model governance is an ongoing function, not a programme deliverable that closes with the project.

The result is not a perfect programme — no standard eliminates all risk. But it is a programme that has addressed the failure modes in advance rather than discovering them in the post-implementation review. The organisation arrives at its future state and stays there, rather than quietly reverting to the past.

Oliver Swift works directly with transformation programmes to apply OMDDMS® at the point of design, not just through training, but as a delivery partner.

The Universal Application

Oliver Swift is one of two globally accredited training organisations for OMDDMS®. We deliver training and apply the standard across sectors because the discipline it defines is genuinely transferable. A practitioner who understands how to design governance for decision-making in a financial services context can apply the same discipline in a healthcare setting. The governance content will differ — the regulatory levers, the accountable bodies, the decision types — but the design discipline is the same.

This matters for organisations commissioning operating model transformation. It means that a practitioner trained to the standard brings a level of rigour that is not dependent solely on their sector experience. It also means that sector-experienced practitioners who are trained in the standard can apply a structured discipline to problems they have previously been solving intuitively — often well, but inconsistently, and without a shared language for what good looks like.

The discipline transfers. The results follow.

Twenty-Five Years, One Pattern

I did not set out to build a sector-agnostic practice. I built a career in operating model design across diverse sectors and, over time, noticed what I have described in this article: that the failure pattern is consistent, that the discipline required to address it is transferable, and that the absence of that discipline costs organisations far more than they usually recognise until it is too late. That observation was the starting point for OMDDMS®.

The standard was not designed in the abstract. It was built from practice, from the recurring patterns visible across Lloyds Banking Group and HSBC, across NHS Digital and Hinkley Point C, across organisations whose operating contexts could not be more different but whose transformation challenges, at the level of discipline, were the same.

I have shared the diagnostic framework in this article freely because I think it is genuinely useful, and because the problem it describes is one that good people inside well-resourced programmes are currently running into right now, in every sector, without always having the language to name it. Naming it is the first step to fixing it.

The sectors I work across are not a coincidence of client development. They are evidence of the premise: that if the discipline is sound, it works wherever operating models are being built. Nuclear new build and retail banking do not share a regulatory framework, a workforce profile, or a technology landscape. They share the same five failure modes. And they benefit from the same structured approach to avoiding them.

If you are responsible for operating model transformation — designing it, commissioning it, or reviewing one that has not delivered — the question worth asking is not only "does our transformation partner know our sector?" It is "do they know these failure modes, and do they have a disciplined approach to addressing them?"

The practitioners who ask the second question are the ones whose programmes land. In my experience, they are also the ones who do not need a post-implementation review to tell them what went wrong.