- Home
- Lean Corner
- You Have Five Sites Engaged in a Lean Programme and They Are All Doing It Differently
You Have Five Sites Engaged in a Lean Programme and They Are All Doing It Differently
A continuous improvement director I worked with oversaw five sites. Each had been engaged in a lean programme for two years. Each had its own rituals, boards, KPIs, and escalation logic. When he tried to compare performance across sites, he realised he could not: the indicators were not defined the same way, the Tier 2 meetings did not cover the same topics, and the notion of an ‘open problem’ meant something different depending on the site.
The rollout had succeeded. The standardisation had failed.
How It Happens: the Copy-and-Adapt Problem
The rollout starts with a shared template. Site 2 copies it and shifts the meeting time by fifteen minutes to accommodate the shift change. Site 3 adjusts the KPI set because the production manager does not find two of the proposed metrics relevant. Site 4 adds a local safety metric and removes one nobody was filling in. Site 5 is run by a CI manager who had their own approach before the rollout. They adapt more than the others, but his results are good, so nobody steps in.
This pattern is familiar in fast-scaling organizations: documents and templates multiply, versions proliferate, and the version on the floor stops matching the version on the shared drive. Two years later, five sites are running five different programmes. Nobody did anything wrong. Each adaptation was locally justified. The problem is not in the individual decisions; — it is in their accumulation. You can no longer benchmark sites against each other, identify best practices to propagate, or detect which sites are genuinely drifting.
Fix 1: Audit What Actually Exists Before Trying to Re-Standardise
Before you can re-standardise, you need to know precisely what each site is doing. Audit all five on the non-negotiable elements: tier structure and meeting cadence, escalation logic, KPI category definitions, problem-solving methodology.
This audit happens on the floor, not in a meeting room. What gets said on a call and what actually happens in a real Tier 1 meeting always diverge, and direct observation is the only thing that reveals the gap.
Document the current state at each site without judgement. This is not a blame exercise. It is the prerequisite for a re-standardisation plan that sites will accept. Knowing what exists also allows you to recover the local adaptations that deserve to become the new shared standard.
Fix 2: Re-Standardise the Non-Negotiables Only, and Do It Through the Sites
Standardizing everything is tempting, and it fails for a predictable reason. An identical standard imposed on genuinely different contexts gets rejected informally: sites keep the paperwork and change the practice, and the drift restarts underneath a compliant surface. Standardizing nothing leaves you where you are.
So the workshop has one job: agree which elements must be identical for cross-site comparison to be possible, and say out loud that everything else can vary. Bring the CI managers from all five sites, present the audit findings, and let them draw the line themselves. A standard built by the people who have to follow it holds better than one designed centrally and distributed afterward.
The framing that makes this land: a lean standard is not a rule to obey, it is a reference point for self-assessment. Where the line falls between shared and local is a decision in its own right.
Fix 3: Build the Governance Mechanism Before You Finish the Workshop
Before the workshop closes, three points to formalise. First, the visibility mechanism: who sees adherence data, how often, and in what form. Second, the drift detection threshold: what level of deviation triggers a follow-up, and who is responsible. Third, the process for future local adaptation requests: sites need a legitimate channel to propose a change, and a named owner who answers within a defined window. A channel with no response time is the same as no channel: people stop using it and adapt informally again.
A re-standardisation without governance is the same rollout you already did. What separates a deployment that holds from one that drifts is decided before you leave the room.
See how iObeya makes lean standard adherence visible across a multi-site network.
