The second site is where CI falls apart

There is a pattern that shows up in almost every organisation that has tried to scale continuous improvement past its first site. The programme works, results come in, leadership notices and someone gets asked to roll it out. Then, somewhere between site one and site three, it stops working. In our experience, this is usually because the system they built was never designed to scale.

Understanding why this happens matters more than any individual improvement methodology. You can read about scaling continuous improvement and recognise the failure modes in the abstract, but the multi-site version of this problem has its own distinct shape, and it’s worth naming precisely.

A consistent finding in continuous improvement research is that gains from early pilot sites fail to replicate at scale because the infrastructure supporting it was personal rather than systemic.

The impact of proximity on scaling CI successfully

At a single site, continuous improvement runs on proximity. The CI lead knows which teams are moving, which are stuck, and where the blockers are. They walk the floor, catch problems before they escalate, and know intuitively which projects need more attention this week.

The reporting might live in a spreadsheet and the coordination might happen over a coffee, and none of that matters because it works. It works because one person is holding it together through presence and knowledge, and at one site that is enough.

This isn’t a criticism of how early-stage programmes tend to operate by any means. In fact, it’s an accurate description of how successful ones look.

The person leading it is skilled, committed, and close to the work, and that closeness is doing a great deal of structural work that nobody has had cause to notice yet. The problem surfaces when that closeness can no longer cover the distance.

A real scenario of when proximity meets its a limit

We saw this exact challenge play out at a UK general insurer. For nine months, the continuous improvement programme at their Leeds claims centre worked beautifully. Average claim handling time dropped by a third, customer satisfaction scores were rising and the team genuinely owned the change. Most of that was down to the site's CI lead, Ian.

Ian ran the programme out of his head, a shared spreadsheet and a Sharepoint site containing some tools and templates. He sat among the claims handlers, so he knew which improvement projects were stalling and which team leader was quietly avoiding their actions, usually before the next review. Coordination happened in passing - a word at someone's desk or a quick steer during a morning huddle. None of it was written down because none of it needed to be. It worked.

Then the organisation asked him to roll the programme out across two more claims centres in Bristol and Ipswich.

The spreadsheet survived a month, then stopped reflecting reality. The templates in the Sharepoint site started to be changed and control loosened. Ian could read the room in Leeds, but he couldn't read three rooms he wasn't in. He started learning about stalled projects weeks late, through status updates that had been gently optimised by people who didn't want to flag their own delays.

What had looked like a well-run programme turned out to be one person's judgement applied at close range. The structure had been Ian’s presence and presence doesn't replicate across multiple sites. The fix wasn't more travel or a better CI lead. They had to build explicitly the things proximity had been providing invisibly: a shared way to surface blockers without someone walking past them, visibility of impact without reliance on Ian, and a cadence that caught drift without relying on one person's intuition.

OpX was built for the moment proximity stops being enough. It gives multi-site teams a shared operating layer for tracking improvement work, so visibility doesn't depend on one person walking the floor.

Explore how OpX can keep your CI programme on track

OpX connects with the tools your team already uses

Implementing an operating system for improvement doesn’t mean starting from scratch. OpX is designed to sit across the tools teams already rely on, including Jira, Microsoft Teams, Miro and Excel, connecting the work that's already happening rather than asking teams to change how they operate.

For a CI lead managing a single site through familiar tools, this matters because the operating layer doesn't compete for attention. It pulls visibility from where the work already lives, so the shift to a more systemic approach doesn't feel like a new system to learn.

What changes when a second site joins your CI programme?

When a second site is added, the proximity that made site one work becomes a constraint. The CI lead is now divided, and the informal coordination that held everything together, including the floor walk, the instinct about which team is struggling, and the conversation that caught a problem before it became a report, has to be replaced with something more deliberate. Most programmes have not built that something yet.

The coordination challenge at scale is essentially a standards problem: how do you maintain quality, consistency and momentum across sites that can't all be walked in the same week? As Rob Regan, a CI leader with 25 years in manufacturing and financial services, puts it:

"If you've got 300 clubs across Wales, how do you maintain coaching standards in all 300 clubs? What's the connective tissue that means everybody broadly does the same thing?"

It’s the right question, and the connective tissue is precisely what breaks first. This is the first gap OpX is built to close.

Why lean manufacturing process improvement breaks down across sites

In manufacturing contexts specifically, where lean manufacturing process improvement principles often originate, the physical separation of sites makes this harder still. You can run a hybrid check-in with a dispersed contact centre team, but you can’t walk a factory floor in a different region.

What actually breaks at the second site tends to follow a recognisable sequence. Visibility goes first:

• The CI lead no longer knows what is happening across both sites without asking, and asking takes time they do not have.

• Coordination becomes the next casualty, as what was instinctive becomes administrative and the CI lead finds themselves spending more time on status updates than on improvement work itself.

• Then quality starts to drift. Standards that were maintained through proximity begin to diverge, and teams at the newer site start operating differently. It’s not deliberate, we should clarify, but there’s no clear mechanism keeping them aligned.

In a recent podcast with Chris Dando, founder of OPX, and Rob Regan, Rob describes the endpoint of this pattern plainly, "The ones we've seen fail go very broad very quickly, and then you also just completely lose track of measurement and value. All of a sudden you've got a thousand things going on across an organisation”.

For manufacturing teams managing CI across multiple locations, OPX provides a single, consistent way to track standards, progress and outcomes, whatever is happening on each individual floor.

Learn more about OpX

The CI infrastructure gap that derails multi-site scaling

The conventional response to the scale problem is to hire. Add a CI lead at the second site, replicate the model and keep going. The structural flaw in this approach is that it makes the programme's capacity entirely dependent on headcount, which is expensive to build, slow to find and fragile to retain. When the person holding site two together moves on, the programme regresses.

The deeper issue is that what worked at site one was never documented, systematised or made transferable. It lived in a person, and continuous improvement at scale requires that knowledge to be held in the operating system rather than in any individual's head or calendar.

The infrastructure gap is not usually visible until it is too late to address it cheaply, and by the time a second or third site is struggling, the investment required to rebuild the operating layer is significantly larger than it would have been to configure it properly at the start.

From our experience working with CI programmes at scale, there are certain ingredients a sustainable programme actually needs:

1. Tracking activity against cost-benefit analysis, so the impact of what is happening is visible rather than assumed.

2. A mechanism for measuring value without creating a reporting burden that consumes the time it was meant to free up.

3. Sustainable communication and engagement - a way of keeping teams visible and supported that does not depend on any one person being in the room

Each of these is an infrastructure requirement rather than a people requirement, which matters when the goal is to scale without proportionally scaling the team.

A question for operations leaders scaling process improvement

If you are an operations leader running a multi-site improvement programme, or a CI lead who has been asked to roll out something that is working well at site one, the question worth sitting with is this:

What is currently holding the programme together, and would it survive if that person were unavailable for a month?

If the honest answer involves a specific individual, including their knowledge, their relationships, their ability to hold the threads, then the infrastructure gap is real, even if the programme looks healthy from the outside.

It might look like a project that drifts without follow-up, a team that starts skipping the process, a set of metrics that no one is looking at any more, a leader at site two who feels unsupported but does not say so. By the time the pattern becomes visible at leadership level, the programme has already lost significant ground.

OPX is built for organisations at exactly this point. Multi-site or multi-team programmes where the infrastructure that worked at one site needs to be systematised rather than replicated through more people. The configuration-first approach means the operating layer is documented, visible and transferable from the moment a second site comes online.

What successful multi-site CI programmes do differently

Organisations that scale continuous improvement successfully tend to share one structural characteristic: they treat the operating layer as a first-class investment rather than an afterthought, and they build it before they need it.

For example:

• They document standards before expanding

• They build tracking that gives leadership visibility across sites without requiring someone to compile it manually

• They create the connective tissue described above before the absence of it becomes a problem

For lean manufacturing process improvement in particular, this means capturing not just the methodology but the cadence: how often project reviews happen, who is accountable for escalating blockers, and how outcomes are measured consistently across sites.

These are not the glamorous questions of a CI programme, but they are the ones that determine whether something that worked at one site can genuinely work at five.

After working with companies scaling CI for more than two decades, we can safely say that process improvement doesn’t get harder at the second site, but it’s where you’ll feel the negative impact of not having a proper infrastructure in place.

Get in touch with the team today to book a demo of OPX, the operating system designed to keep CI on track, no matter how many sites you have.

Contact the team