What a continuous improvement framework can't fix alone

Most teams that come to us convinced their continuous improvement framework has failed are using a perfectly good one, whether that be DMAIC, PDCA, A3, Kaizen, 8D. These are proven, and the people running them usually chose them for sound reasons. However, when a programme built on a solid framework still stalls, the instinct to go looking for a better methodology is understandable. We'd argue however, it’s also the wrong place to look.

The framework is almost never the thing that breaks.

We have found the problem lies with the system around it: the visibility that tells you which projects are moving, the coordination that keeps work aligned across teams, the evidence that proves any of it worked, and the engagement that keeps people contributing. A framework describes how to run an improvement project, but it says nothing about how to run two hundred of them at once, across sites, over years, without the whole thing quietly coming apart. That is an infrastructure question, and it is the one most CI content skips.

The framework is rarely why a programme stalls

A continuous improvement methodology is a method for solving a problem well. Used properly, it does exactly that. The trouble starts when an organisation treats adopting the framework as the finish line, rather than the first requirement.

We've watched capable teams run textbook A3s and clean DMAIC cycles and still lose momentum by the second year. The methodology was correct every time, yet what was missing was everything the methodology takes for granted: someone with visibility of the full portfolio, a shared way to surface blockers, a record of what each project actually returned. The framework kept producing good improvements however, nothing kept those improvements connected, visible or provable, so they never added up to a programme.

Rigour done properly needs more than training

The reader who cares about methodology already knows this instinctively, because they've seen rigour get hollowed out. Rob Regan, who has led CI programmes across manufacturing and financial services for over two decades, has watched it happen since the 1990s. In our conversation on scaling continuous improvement he was candid about where it goes wrong:

"It's often been dumbed down. Often for good reason, but sometimes it gets dumbed down too much. There's such a desire to go at pace and to do mass that you lose quality. We've seen examples of a thousand yellow belts trained up across frontline people, and the quality just isn't there."

His point is not that the tools are wrong, but that training on a framework, without the coaching, follow-up and measurement around it, doesn't hold. He puts it memorably:

"It's like bending a piece of card. You bend the card, you let it go, and it springs back. It's quite easy, if they're not getting support, to go back to the old ways, because the old ways are comfortable."

A framework is the card and the system around it is what stops the spring-back. Skip the second part and you get a well-documented methodology that slowly stops being used.

Frameworks assume an infrastructure most organisations never build

Every CI framework carries a set of silent assumptions:

It assumes someone can see the whole picture.
It assumes work stays coordinated as it scales.
It assumes the value gets captured in a form the business will believe.
It assumes the people doing the work stay engaged enough to keep feeding it.

At one site with one committed lead, those assumptions quietly hold. Push past that and they stop holding, one by one, usually in that order.

This is why changing frameworks so rarely fixes a struggling programme. Swapping DMAIC for a different process improvement methodology does nothing about visibility, coordination, evidence or engagement, because none of those live in the framework. They live in the operating layer around it, and if that layer was never built, the new framework will fail in precisely the same way as the old one.

Five methodologies, one operating layer

The way we think about it at OpX is that the framework and the system around it are separate jobs, and the second one is the job almost nobody resources. A good operating layer doesn't replace your methodology or force everyone onto one house style. It gives each canonical approach, A3, DMAIC, Kaizen, 8D and PDCA, its own structured space with proper phase gates, so rigour is built into how work moves rather than left to individual discipline. Underneath all five sits the same shared infrastructure: one view of the portfolio, one place blockers surface, one consistent record of impact.

That is the difference between a methodology and a programme that lasts. The methodology gets a single problem solved and the operating layer is what lets you solve two hundred and still prove, a year later, that they mattered.

Stop changing frameworks. Fix the system around them.

If your programme is stalling and you're weighing up a new framework, it's worth checking the diagnosis first. Ask what your current methodology is actually missing. If the honest answer is visibility, coordination, evidence or engagement, a different framework won't touch any of it, because the problem was never the framework.

This is the thinking OpX is built around, and it's the thread running through everything we explored with Rob on scaling improvement, from keeping the frontline engaged to proving impact when it counts. The methodologies that came out of the lean tradition are as good as they ever were. What most organisations are missing sits around them, not inside them.

See how OpX gives your framework a system that scales