The improvement is not the point
The kaizen event has become the signature ritual of Lean manufacturing.
Five days. A cross-functional team. A defined scope. Structured analysis. Rapid implementation. A presentation on Friday afternoon with before-and-after metrics, a benefits calculation, and a list of follow-up actions that everyone in the room commits to and approximately half complete.
Done well, the event produces genuine improvement. Cycle times reduce. Changeover times fall. A quality issue is addressed. A workspace is reorganised. A workflow is simplified. The people who participated learn something real about the process and about problem-solving.
Done poorly, it is an expensive week that produces a presentation and a laminated action plan that nobody revisits.
But here is the thing most organisations miss.
Whether it goes well or badly, the kaizen event is not the most valuable thing that happens that week.
The most valuable thing that happens is what the event reveals about the management system that allowed the problem to exist, unaddressed and unresolved, for as long as it did.
That revelation is almost always ignored.
This post is about why it matters, what it tells you, and what to do with it.
1. The Problem with the Problem
Every kaizen event starts with a problem.
Sometimes the problem is well-defined before the week starts. A specific cycle time target. A documented quality issue. A changeover duration that is limiting capacity. A workstation layout that is creating ergonomic risk.
Sometimes the problem is vague — an area of the business that leadership knows is not performing well, that has been underperforming for a while, and that a kaizen event has been identified as the mechanism for addressing.
In either case, the problem has been present for some time before the event begins.
That is the first question worth asking: how long?
Not as a criticism of the team running the event, or the area being improved. As a diagnostic question about the management system. If a problem significant enough to justify a week of cross-functional resource has been present for six months — or eighteen months, or three years — what does that tell you?
It tells you that the normal management system — the daily reviews, the weekly meetings, the improvement cadences, the leadership observation routines — did not surface this problem and create the conditions for it to be resolved in the normal course of operations.
The kaizen event is a workaround.
It is a mechanism for addressing things that the management system failed to address through its standard processes.
That is not a reason not to run kaizen events. It is a reason to ask what the management system needs to do differently.
2. What the Preparation Reveals
The pre-work for a kaizen event is itself diagnostic.
When the team begins gathering baseline data — current cycle times, defect rates, floor layouts, process documentation — they almost always encounter one or more of the following.
The data doesn’t exist. Nobody has measured the process recently enough to have a reliable baseline. The cycle times on the standard work document were last verified two years ago. The defect rate for this specific failure mode has never been disaggregated from the category it sits within.
The data exists in multiple places and doesn’t agree. The ERP system says one thing. The manual log says another. The team leader’s memory says a third. The reconciliation of these versions takes a day that wasn’t planned for.
The documentation doesn’t reflect reality. The standard work that was written for this process describes something that nobody has actually done in recent memory. The process has evolved — informally, locally, without documentation — and the gap between the standard and the actual is significant.
None of these are surprises to people who spend time on the shop floor.
All of them are diagnostic signals about the management system. About whether daily observation is happening. About whether standard work is living or laminated. About whether data systems are trusted or worked around. About whether the information infrastructure of the business reflects reality or approximates it.
The kaizen preparation is a management system audit. Most businesses treat it as an administrative step.
3. What the Event Reveals
During the event itself, a different set of signals emerges.
The why chain stops early.
The 5 Whys is a standard kaizen tool. In theory, asking why five times takes you from the symptom to the root cause. In practice, many kaizen events stop at two or three — not because the root cause has been found but because the third or fourth why leads somewhere that is outside the scope of the event, or involves a function that isn’t in the room, or implicates a decision that was made above the pay grade of the team.
When the why chain stops early, note where it stopped and what question it was heading toward. That is where the real problem lives.
The same problems appear in multiple places.
An experienced kaizen facilitator recognises a specific moment during the analysis phase of a well-run event: the moment when the team realises that the problem they are working on is not unique to this area. The same root cause is producing the same symptom in three other value streams. The same planning failure is creating the same inventory problem across multiple product families. The same engineering change process is generating the same quality issues in different cells.
When that recognition arrives, it tells you something important: the problem is systemic, not local. The kaizen event will solve it locally. The management system needs to solve it systemically. Whether that distinction gets acted upon depends entirely on what happens after the event closes.
People know things they haven’t said.
In a well-facilitated kaizen event, a specific dynamic occurs. People who have been in the building for years — operators, team leaders, technicians — begin to say things that have never been said formally. Things they have known, and observed, and compensated for, but that have never surfaced through the normal management process.
Not because they were hiding it. Because nobody asked. Because the normal management interaction wasn’t designed to elicit that quality of information. Because the daily review is about numbers, not narratives. Because the relationship between floor-level knowledge and management decision-making doesn’t have a reliable channel.
The kaizen event creates a temporary channel. The knowledge surfaces for a week. What happens to it after Friday afternoon is the question.
4. What the Presentation Reveals
The Friday presentation is the most visible output of the kaizen event and the least diagnostically useful part of it.
But even the presentation contains signals.
The benefits calculation.
Every kaizen event produces a benefits number. Often a significant one. Annualised savings from cycle time reduction. Labour cost equivalent of changeover time saved. Scrap cost eliminated.
The sum of kaizen event benefits across a business over a three-year period is almost always significantly larger than the actual improvement in financial performance over the same period. The gap between the claimed benefits and the observed results is a measurement of two things: the degree to which benefits are double-counted or optimistically calculated, and the degree to which improvements are not sustained.
Both are management system problems. The first is about the discipline and rigour of benefit measurement. The second is about the infrastructure for sustaining change once the event team has dispersed.
The action list.
The follow-up actions at the end of a kaizen event tell you something about the scope of what was attempted and the honesty of what was achieved.
A list of twenty-five actions, mostly assigned to individuals who weren’t in the room during the event, many of them dependent on functions or systems outside the team’s control — that is a list that will not be completed. Not because people don’t try, but because the system for following up is not robust and the ownership is diffuse.
The quality of the action list — and the governance attached to it — is a direct measure of the organisation’s improvement maturity. The best kaizen events end with five significant actions, clearly owned, with defined completion dates and a specific review mechanism. The rest end with a longer list and good intentions.
5. What Happens After Friday
This is where most improvement programmes lose their return on investment.
The event closes. The team disperses. Monday morning arrives and the operational machine restarts. The urgency and focus of the event week dissolves back into the daily management rhythm. The actions get entered into a tracker. The tracker gets reviewed — with diminishing frequency — in the weeks that follow. By week six, most of the actions are complete, overdue, or quietly parked.
The metrics improve briefly. Then they drift.
Not always dramatically. Often subtly — a small reversion each week, sustained over months, until the metric is back within touching distance of where it started.
When this happens, the standard diagnosis is: the change wasn’t sustained because the culture wasn’t ready. Or: the team didn’t have enough ownership. Or: the change was too big for the current capability.
Those diagnoses are sometimes right.
More often, they are wrong. The change wasn’t sustained because the management system wasn’t redesigned to sustain it.
The visual management board that was created during the event isn’t reviewed in the daily management meeting with the same attention as the production output. The standard work that was updated isn’t audited with a frequency that identifies drift before it becomes habit. The root cause that was addressed hasn’t been verified as resolved — only the symptom has been checked.
The event improved the process.
The management system reverted it.
6. Using the Event as a Diagnostic
The reframe this post is building toward is straightforward.
Stop evaluating kaizen events primarily on the improvement they produce.
Start evaluating them on what they reveal about the management system — and whether those revelations result in management system change.
That means building a formal after-action review into every event. Not the Friday presentation, which is the improvement summary. A separate, leadership-attended conversation that asks different questions.
What did we learn during this event that the daily management process should have surfaced but didn’t? What data gap did we encounter that the measurement system should be designed to close? Where did the why chain stop, and what does that tell us about where the next event should look? What systemic issue did we find that this event addressed locally but that requires a broader response?
Those questions produce a different kind of output. Not a list of improvement actions in this area, but a list of management system development actions across the business. A programme of work that addresses the conditions that created the problem, rather than just the problem itself.
That is improvement at the system level. It is slower and less visible than the kaizen event scorecard. It is also the only improvement that doesn’t require another kaizen event in the same area three years later.
7. The Maturity Curve
There is a recognisable maturity curve in how organisations use kaizen events.
At the beginning, the events are focused on obvious, physical improvements. Workspace organisation. Waste walks. Layout changes. These are high visibility, relatively easy to sustain, and produce early wins that build confidence and momentum. They are the right place to start.
As the organisation develops, the events get harder. The easy problems have been addressed. The remaining issues require deeper root cause work, more cross-functional involvement, and more uncomfortable conversations about systemic design. The events start to surface management system problems rather than just operational ones. This is the point at which many improvement programmes stall — because the organisation is not equipped to act on what the events are revealing.
The organisations that continue to develop use kaizen events as a diagnostic tool as much as an improvement tool. They track what the events reveal as carefully as what they improve. They maintain a view of the management system development agenda that runs parallel to the improvement project list. They measure their improvement maturity — not just their improvement output.
At that level of maturity, a kaizen event that produces modest operational improvement but surfaces a significant systemic insight is considered more valuable than one that produces dramatic local results and reveals nothing new.
Because the systemic insight is the scarce resource.
Final Thought
The kaizen event is a torch.
It illuminates the process it is pointed at. It reveals the waste, the variation, the gap between standard and actual, the knowledge that has never been documented, the root causes that have never been traced to their source.
Most organisations look at what the torch illuminates and consider that the point.
The more important question is what the need for the torch reveals about the management system that operates in its absence.
Why was this problem here long enough to require a week of cross-functional resource to address? What would have caught it earlier? What would have prevented it? What in the daily management system, the measurement infrastructure, the leadership observation routine, the standard work discipline — what in the system that runs this business every day — allowed this to accumulate to the point that a kaizen event was the solution?
Those questions are uncomfortable. They are also the ones that build genuinely better businesses.
Three questions.
When did you last review a kaizen event not for what it improved but for what it revealed about the management system?
What is the sum of benefits claimed from kaizen events in your business over the past three years — and how does that compare to actual measured financial improvement over the same period?
And if the gap is significant — where did the improvement go?
Leave a Reply