THE BRIEFING ROOM

Why transformation fails (and how to fix it)

Seventy percent of large-scale digital transformations fail. That's McKinsey's number, from 2024. Bain puts it even worse - 88% fail to achieve their original ambitions. BCG says two-thirds of large technology programmes miss their targets. Globally, that's an estimated $2.3 trillion in wasted spend.

You've read stats like these before. They probably landed differently the first time, back when transformation was something you were planning rather than something you'd already been through.

Because if you're a managing partner or operations leader at a mid-sized B2B service firm, there's a reasonable chance you're not reading this out of curiosity. You're reading it because you sponsored a programme - or sat on the steering committee for one - that didn't deliver what it was supposed to. And now you're sitting with the aftermath: a partnership that's sceptical, a technology team that's cautious, and your own credibility feeling a bit thinner than it was two years ago.

We've tried transformation. It didn't work. The organisation isn't ready for another big change programme, and I'm not sure the problem was fixable anyway.

I hear some version of that in about half the discovery conversations we have at Distinction. And honestly, I get it. But I'd push back on almost every part of it - gently, because I think the scar tissue you're carrying is actually more useful than you realise.

The scar tissue is real

Before we get into frameworks and fixes, let me name what you're actually dealing with. Transformation failure in a professional services firm doesn't look like a dramatic collapse. It looks like a slow fade.

It looks like the partnership meeting where someone says, "Last time we spent £300k and the website still doesn't do what we were promised," and the room goes quiet. Not hostile, just... tired. The will to fight for it again isn't there.

It looks like your technology lead - the one who was genuinely enthusiastic the first time around - now hedging every recommendation with caveats. They learned the hard way what happens when you champion something that doesn't land. They're not going to stick their neck out again without ironclad cover.

It looks like the middle managers who were asked to change how they work, attended the workshops, tried the new system for three weeks, and then quietly went back to the old way because nobody followed up. They didn't resist the change. They just learned that if they waited long enough, the initiative would lose momentum on its own. And they were right.

And it looks like you. The person who signed off the budget, made the case to the board, and now has to decide whether to go back and make that case again - knowing that "this time will be different" is the least convincing sentence in the English language.

I sat with a COO at a 400-person professional services firm last year who described it perfectly. She said, "The failure wasn't dramatic. Nothing broke. It just... didn't arrive." The platform was technically live. The CRM was connected. But adoption was patchy, the content hadn't been migrated properly, and the team had moved on emotionally long before the project was formally closed. The technology worked. The transformation didn't.

That gap - between the technology working and the transformation landing - is where most programmes die. And the reasons are remarkably consistent.

Five failure patterns (and you'll probably recognise at least three)

I've been involved in enough transformation programmes - ours and other people's - to see the same patterns repeat. Not identical situations, but the same structural problems wearing different outfits.

The vision without a metric. Someone at the top says, "We need to be more digital" or "We need a modern client experience." Everyone nods. A programme gets funded. But nobody defines what success looks like in terms you can actually measure. I was in a steering committee meeting once - not our project, mercifully - where someone asked, "How will we know this has worked?" and there was genuine silence. Not because nobody cared, but because the goal had always been expressed as a direction rather than a destination. "Improve the client experience" is a direction. "Reduce enquiry-to-onboarding time from 14 days to 5" is a destination. You can build towards the second one. The first one just generates activity.

The committee that owned nothing. Steering committees are where accountability goes to die. I know that sounds harsh, and I don't mean every steering committee is useless - some are genuinely effective governance bodies. But when a transformation programme is "owned" by a committee of eight people who meet monthly, nobody owns the outcome. Everyone has input. Nobody has authority. Decisions get deferred to the next meeting. And when something goes wrong, the committee discusses it rather than fixes it. BCG's research backs this up - 60% of transformation failures are attributed to the absence of a master plan, which is a polite way of saying nobody was in charge.

The big reveal that never came. Some programmes are designed to deliver all their value at the end. Everything builds towards a launch date. The problem is that by month nine of a twelve-month programme, the organisation has lost faith. People who were supposed to change their behaviour have been waiting for something tangible for three quarters of a year. And when the big reveal finally happens, it's anticlimactic - because the gap between expectation and reality has been growing unchecked the entire time. I've written about this separately in the context of digital strategy - why strategy fails when it starts with technology - but the principle applies to every transformation programme. If you can't show progress within the first 60 days, you've probably designed it wrong.

The people who weren't in the room. This one's subtle and it's the one that gets me most frustrated. The transformation gets designed by senior leaders and technology teams. The people whose daily behaviour actually needs to change - the fee earners, the client managers, the operations staff - find out about it when they're asked to attend training on a system they had no input into. By that point, they're not stakeholders. They're passengers. I was talking to a partner at a mid-market law firm last year who told me he'd learned about the new CRM system via an email from IT. He'd been at the firm for twenty-two years. His first instinct wasn't excitement - it was suspicion. "What's wrong with the way we do things now?" Nobody had answered that question for him because nobody had thought to ask it.

Technology before problem. A firm selects a platform, then works backwards to figure out what problem it solves. The technology becomes the anchor point, and everything else - goals, process changes, adoption - gets fitted around it. It's backwards. But it happens constantly because technology decisions feel concrete and measurable in a way that problem definition doesn't. Buying a platform is a decision. Defining the problem is a conversation. And busy leaders prefer decisions. I've written about this at length in a companion piece on why digital strategy fails when it starts with technology.

Now, I'll be honest - I've contributed to at least one of these failures myself. A few years back, we were brought into a programme mid-flight to help rescue it. We diagnosed the governance problem correctly. We recommended the phased approach. What we didn't do well enough was push back on the timeline the client had already committed to internally. We knew it was too tight. We said so once, got reassured, and moved on. The programme delivered late, the relationship survived, but I still think about that one. Sometimes the failure isn't the big structural thing. Sometimes it's the moment you didn't push hard enough on the thing you already knew.

The diagnosis nobody wants to hear

McKinsey's 2024 research found that cultural change is 5.3 times more likely to drive transformation success than technology selection. Five point three times. That's not a marginal difference. That's the difference between the thing you spent 80% of your budget on and the thing that actually determines whether it works.

Most digital transformation failures are leadership failures. Not because the leaders were incompetent or didn't care - usually the opposite. They cared deeply. They approved the budget. They attended the steering committee. They sent the all-staff email.

But they didn't restructure how decisions got made. They didn't change the incentives. They didn't make someone personally accountable for outcomes. They didn't create the conditions for the behaviour change that the new technology required.

The technology usually did what it was supposed to do. The CRM captured the data. The CMS published the content. The portal processed the applications. But the consultants didn't enter their client notes. The partners didn't use the content library. The brokers found the old process easier and went back to it.

I'm not saying this to assign blame. If you sponsored a programme that didn't land, you probably did everything you thought was right at the time. The problem is that the playbook most firms follow - select technology, implement technology, train people, go live - skips the hardest part entirely. It assumes that if you build it well enough, people will use it. They won't. Not without a reason that matters to them personally, communicated by someone they trust, with visible evidence that the change is actually happening.

That's a leadership task, not a technology task. And it's the task that most programmes under-resource by an order of magnitude.

What actually works

Right, enough diagnosis. Let me talk about what I've seen work - not in theory, but in programmes we've been involved in that actually delivered.

Start with a specific problem, not a platform. Not "improve the client experience" but "reduce the number of portal login failures by 40% within six weeks" or "increase qualified inbound enquiries from the website by 50% in six months." When you define the problem with that level of specificity, the technology selection becomes almost obvious. And more importantly, everyone involved can tell whether it's working. We helped a mid-sized consulting firm go from three inbound enquiries a month to thirteen by reframing the entire project around a specific, measurable goal. The technology mattered. But it was the clarity of the objective that made everything else fall into place.

Deliver something visible within 90 days. Not a PowerPoint deck. Not a wireframe. Something a partner can log into, a client can interact with, or an operations team can use on Monday morning. Each phase builds on the last, and each phase gives the organisation evidence that progress is real. I've seen this approach rescue programmes that were on life support. When a professional services firm we worked with delivered a working proposal generation tool inside 90 days - after an 18-month AI strategy exercise had produced nothing but a report - the CTO told me it was the first time in three years that the leadership team believed digital investment could actually produce results.

Name one person who owns the outcome. One person. Named. Accountable for outcomes, not activities. With the authority to make decisions without convening a committee. This is where professional services firms struggle most, because partnership structures diffuse authority by design. But the programmes that work always have a single point of accountability. Not someone who "oversees" - someone who owns.

Build in a quarterly reckoning. Not the kind of status report that says everything is green until it's suddenly red. A structured review every three months that asks: what did we set out to achieve this quarter? Did we achieve it? What's changed? What should we do differently? This is exactly what our WHNN framework - What, How, Now, Next - structures into a repeatable process. It organises decisions around four questions: what needs to change, how will it be delivered, what does the current state honestly look like, and what does the next phase require? I've written a detailed explainer on what WHNN looks like in practice if you want the full picture. The quarterly rhythm creates accountability. It makes it very difficult for a programme to drift quietly off course for nine months without anyone noticing.

None of this is revolutionary. It's almost obvious when you list it out. But obvious and easy are different things, and the gap between them is where most of the $2.3 trillion goes.

How to restart

So. You've been through a failure. You've got the scar tissue. You're at least open to the idea that the problem wasn't unfixable - it was just approached wrong.

Don't start with a vendor selection. Not with a budget request. Not even with a project plan. Start with an honest retrospective. Three questions.

What was the goal, and was it specific enough to be measurable? If the answer is "improve the client experience" or "modernise our technology," that's your first problem identified. A transformation without a measurable goal is just organised activity.

Who owned the outcome, and did they have the authority to deliver? If the answer is "the steering committee" or "the technology team," that's your second problem. Ownership without authority is a title, not a mandate.

What was the first visible milestone, and when was it supposed to happen? If the answer is "go-live in month twelve," that's your third problem. Twelve months of faith without evidence is too much to ask of any organisation, especially one that's already been burned.

These three questions will usually surface two or three things that need to be different this time. Not a complete reinvention - a targeted correction.

And here's the thing that gets lost in the post-failure malaise: you're actually in a stronger position now than you were before the first attempt. You have budget precedent. You have organisational awareness of the problem. You have first-hand knowledge of what the failure modes look like. The firms that turn a failed transformation into a successful one don't change vendor. They address the governance, ownership, and goal-setting failures that caused the first attempt to stall.

But the partnership won't support another big programme.

Good. Don't propose one. Propose a 90-day sprint with a specific, measurable outcome and a single named owner. Deliver something visible. Then use that evidence to make the case for the next phase. That's not spin - it's how every successful transformation I've seen actually builds momentum.

The managing partner who understands the leadership mindset that separates digital winners from digital laggards isn't the one with the biggest budget. It's the one who's honest about what went wrong and disciplined about what comes next.

I was at dinner with a managing partner a few months ago - someone who'd been through exactly the kind of failed transformation this piece describes. He said something that stuck with me: "The worst part wasn't the money. It was watching the organisation learn that nothing changes."

That's the real cost. Not the write-off. Not the wasted months. It's the learned helplessness that follows - the quiet assumption, across every level of the firm, that this stuff doesn't work for us.

It does work. Just not the way most firms try it the first time.

If this is landing and you're thinking about what the restart looks like - particularly under the budget and credibility constraints that follow a failed programme - the next piece has a framework for making that case. And if you want to understand what good governance looks like before you take a proposal to the board, there's a companion piece on what every board should know before approving a digital transformation budget worth reading first.