The £100 Million Mistake: Why FTSE 250 Transformations Fail Without Operating Model Design

How FTSE 250 companies double their transformation costs by skipping one critical step.

Austin Merrett
Co-Creator of OMDDMS® | Founder, Oliver Swift

Your board approved £50 million for digital transformation. Strategy was designed. Technology was built. Change was managed.

Eighteen months later, initial results looked good. Presentations to the board, green RAG statuses, go-live celebrations.

Twenty-four months later, teams have reverted to old ways. The new CRM system is a glorified spreadsheet repository. Your "agile" organisation runs waterfall with stand-ups.

You didn't fail because of bad strategy, poor technology, or weak change management.

You failed because no one designed how your organisation would actually operate after the transformation.

The Pattern Nobody Talks About

Transformation follows a predictable pattern in FTSE 250 organisations:

1

Strategy

Analysis is conducted, workshops are run, PowerPoint decks with target operating models are produced. They look impressive but lack operational detail.

2

Technology

Platforms are implemented. Salesforce, ServiceNow, Workday, SAP — best-in-class tools that promise to revolutionise operations.

3

Change Management

Training sessions, communication campaigns, change champions embedded in the business. Everyone attends workshops. Everyone nods in agreement.

4

Go-Live

Celebrations. Press releases. Board presentations showing green RAG statuses.

5

The Slow Collapse

Six months later, workarounds emerge. Teams revert to old processes "just for now." Excel spreadsheets multiply. The new system becomes a data graveyard. Eighteen months later, leadership quietly commissions another transformation to "fix" the problems.

What Went Wrong?

Between the strategy deck and the technology implementation, operating model design got lost.

No one designed how the organisation would actually operate. No one defined decision rights, information flows, governance structures, or capability allocation. No one documented what had to be true for the transformation to work.

Everyone assumed it would "sort itself out" after go-live.

It never does.

What Happens When Operating Model Design is Skipped?

A FTSE 100 organisation's board approved a £60 million IT transformation to consolidate regional systems across 27 countries into a single technology platform. The business case promised operational efficiency, cost reduction, and 24/7 follow-the-sun support.

Leadership treated it as a technology programme. The focus was on implementing the platform, migrating data, and achieving go-live. Standard playbook.

Two years later, it still hadn't gone live.

After two years, £24 million had been spent on programme costs alone — £1 million per month. The technology platform had been upgraded twice. Leadership had become disenfranchised. And the transformation was stalled — not because of technical failure, but because no one had designed how the organisation would actually operate once the technology was implemented.

FTSE 100 Transformation Timeline

Month 0
£60M Approved
Month 12
£12M Spent
Month 24
£24M Spent
Status
Still Stalled

What "no operating model" actually looked like:

There was no blueprint. Different countries ran different processes, but no one had documented the current state. HR systems were fragmented — when programme teams asked "how many people work in IT support across EMEA?", three different systems gave three different answers.

The target operating model was "indicative." Leaders agreed on the vision (one platform, standardised processes, global service desk) but couldn't agree on the operational details:

  • Which country owned which service?
  • Who had decision rights for cross-border incidents?
  • How would career paths work when roles were consolidated globally?
  • What governance structures would resolve conflicts between regions?

No one had documented the pre-conditions for success or the post-implementation dependencies. Teams were building technology without knowing what organisational changes had to happen first, or what needed to exist afterward.

Monthly steering committees turned into arguments about operating model questions that should have been answered before the programme started. Decisions were deferred, then revisited, then deferred again.

After two years and £24 million spent, the programme was still trying to answer fundamental questions about how the organisation would operate.

The known costs:

  • £24M+ in programme costs (£1M/month for 24+ months)
  • Significant technology investment
  • 2+ years of organisational paralysis
  • Zero operational benefit delivered
  • Leadership disenfranchised
  • Programme still stalled

The transformation didn't fail because of bad technology or poor project management.

It failed because leadership assumed operating model design would "happen naturally" during implementation.

It didn't.

Why Operating Models Matter More Than Technology

An operating model defines how work actually flows through your organisation. It's not an org chart. It's not a process map. It's not technology architecture.

An operating model is the systematic definition of:

  • Decision rights: Who has authority to approve what, at what threshold, with what escalation paths
  • Information flows: How data moves between teams, what triggers handoffs, where the single source of truth resides
  • Governance: How performance is monitored, how conflicts are resolved, how exceptions are handled
  • Capability allocation: Which teams do what work, where expertise resides, how skills are deployed
  • Process integration: How workflows connect across functions, how handoffs are managed, where accountability sits

Technology enables operating models. It doesn't create them.

You can implement Salesforce* perfectly and still fail if you haven't designed:

  • Which teams own which customer data
  • Who has authority to update records
  • How sales and service teams coordinate handoffs
  • What happens when data conflicts arise
  • How performance is measured across the customer journey

The CRM works. But your operating model doesn't, because no one designed it.

* Other SaaS solutions are available

The Hidden Costs

FTSE 250 boards approve transformation investments based on business cases that assume technology will deliver operational benefit.

The True Cost of Transformation Without Operating Model Design

£50M Direct Investment
+
£35M Wasted
(30% utilisation)
+
£15M Remediation
Costs
£100M True Cost of Transformation Failure

And that's if you fix it on the first attempt.

Direct costs: £50M transformation investment — 30% utilisation of new capabilities (because the operating model wasn't designed to use them) — £35M effectively wasted.

Remediation costs: £15M spent to "fix" the transformation — additional internal resources diverted to workarounds — delayed benefits realisation (18–24 months of zero ROI).

Opportunity costs: Competitors move faster whilst you're stuck re-transforming — market share lost during organisational paralysis — strategic initiatives deferred because "we're still fixing the last transformation."

Organisational costs: Team fatigue and cynicism about "the next big initiative" — loss of credibility for transformation leadership — talent attrition (your best people leave when they see the dysfunction).

What Operating Model Design Actually Means

Operating model design is not:

  • An organisation chart redesign (that's structure, not operating model)
  • Process mapping (that's workflow, not operating model)
  • Technology architecture (that's enablement, not operating model)

Operating model design is:

  • Systematic definition of how the organisation will operate post-transformation
  • Integration of strategy, processes, technology, people, and governance into a coherent operating system
  • Design of decision rights, information flows, capability allocation, and performance management
  • Documentation of pre-conditions and post-implementation dependencies
  • Blueprint that answers: "How will we actually work once the transformation is complete?"

Effective operating model design requires a structured methodology.

Organisations need a robust method and scalable frameworks that connect strategic intent to operational reality — ensuring transformation investments actually change how work gets done, not just how it looks on paper.

Without systematic operating model design, transformation becomes expensive hope.

How To Fix This

Before the transformation starts…
1

Conduct operating model design before procuring technology

Design how the organisation will operate, then select technology that enables that operating model. Not the other way around.

2

Include operating model design in procurement requirements

When commissioning transformation work, specify operating model design as a distinct deliverable. Make it clear that "strategy" and "implementation" are necessary but insufficient.

3

Demand a blueprint

Before approving the business case, require a documented operating model blueprint. Not indicative. Not high-level. Detailed enough that someone could actually operate the organisation using it.

During the transformation…
1

Separate 'implementation' from 'operating model design'

Technology implementation and operating model design are different disciplines. Make operating model design an explicit workstream with dedicated accountability.

2

Design decision rights, governance, and information flows explicitly

Don't assume they'll "emerge naturally." They won't. Document them, test them with pilot teams, refine them based on real operational friction.

3

Test the operating model before full rollout

Run pilots that stress-test decision rights and governance structures. Find the gaps before you've committed £50M to scaling broken processes.

After go-live…
1

Monitor operating model effectiveness, not just technology adoption

Track: Are decisions being made at the right level? Are handoffs working? Are conflicts being resolved through designed governance, or through escalation and workarounds?

2

Adjust governance and decision rights based on real operational friction

Operating models aren't static. They need active management and refinement as the organisation learns what actually works.

3

Build an internal operating model design and delivery capability

Develop internal expertise in operating model design, or you'll repeat this cycle every 3–5 years.

Ask These to Reveal Missing Operating Models

If you're commissioning transformation work, ask three questions:

1. "Who will design our target operating model?"

If the answer is vague — "we'll develop that collaboratively during implementation" — you're not buying operating model design. You're buying facilitated workshops that produce PowerPoint, not operational capability.

2. "How will you ensure decision rights are clear post-transformation?"

If there's no articulated methodology for defining, documenting, and testing decision rights, you're buying strategy or technology, not operating model design.

3. "What happens after go-live — who maintains the operating model?"

If the answer is "you'll have the documentation," that's not enough. Operating models require active management. If internal capability isn't being built to manage the operating model, you're creating dependency.

Three Red Flags That Operating Model Design is Missing

!   "Show me your operating model blueprint"

If the transformation team can't produce a documented operating model — not an org chart, not a process map, but an actual blueprint showing decision rights, governance, information flows, and capability allocation — you don't have an operating model. You have hope.

!   "How do these project outcomes support our strategic objectives?"

If programme teams can't draw a clear line from their deliverables to business strategy, the transformation is activity-driven, not outcome-driven. You're implementing technology without designing what it's supposed to achieve operationally.

!   "What are the second-order implications of this decision?"

If leaders are making decisions (consolidate this team, centralise that function, implement this technology) without articulating what happens next — how governance changes, how performance is measured, how conflicts are resolved — you're designing in silos, not designing an operating model.

The Bottom Line

Transformation without operating model design is expensive hope.

Technology is necessary but insufficient. Strategy is important but incomplete. Change management matters but doesn't create operational capability.

"Operating model design is where transformation ROI actually lives."

It's the difference between:

  • Technology that gets used vs. technology that becomes shelfware
  • Transformation that sustains vs. transformation that regresses
  • £50M investment that delivers value vs. £50M investment that gets written off

FTSE 250 organisations spend millions on strategy and technology implementation. They invest in change management and training.

But they rarely invest systematically in designing how the organisation will actually operate post-transformation.

That's the hidden cost.

Not the money wasted on failed transformation. The opportunity cost of not transforming effectively in the first place.

Build the Capability That Prevents the £100M Mistake

Operating model design isn't taught in project management courses. It's not covered in change management certification — yet it is the critical skill that determines whether the transformation succeeds or fails.

OMDDMS® Foundation and Practitioner Courses for transformation leaders, programme managers, business analysts, and all change professionals.

Foundation and Practitioner Courses | Virtual and Classroom | Public | Private | In-house | London | Edinburgh

Foundation Course Practitioner Course Connect on LinkedIn

Don't commission £50 million transformation work without specifying operating model design as a deliverable.

The hidden cost of skipping this step isn't the transformation budget you approved. It's the transformation budget you'll approve again in three years to fix what you're about to break.

About the Author

Austin Merrett is Co-Creator of OMDDMS® (Operating Model Design, Delivery, Management Standard) and Founder of Oliver Swift, one of only two globally accredited OMDDMS® training organisations.

With over two decades of experience designing operating models for complex transformations at major organisations, including Lloyds Banking Group, HSBC, NHS Digital, and Hinkley Point C nuclear facility, Austin specialises in helping FTSE 250 companies navigate high-stakes change.

Oliver Swift is one of only two OMDDMS® Accredited Training Organisations globally, headquartered in The City of London and serving the UK, Europe, Africa, and the United States.

Download PDF Version