Ask Art
"Why does kaizen fail?"
Why Does Kaizen Fail?
Short answer: Kaizen programs most commonly fail because organizations never make the transition from running improvement events to building an operating and management system that sustains results daily. The events produce real changes, but without standardized work as a baseline, a management system to hold the gains, and technical depth on the genba, those changes do not last.
Kaizen (改善) means change for the better in Japanese or continuous improvement in English. Toyota’s TPS glossary (用語集) defines it as a series of activities to find muda — which exists everywhere — in people, materials, equipment, and production systems, and to swiftly eliminate it one by one, using wisdom and with minimal cost. The glossary adds two conditions: in manual work, work-method improvement takes priority over equipment improvement; and kaizen is not the job of specific people but something all employees can and should do, each from their own position.
Why don’t kaizen improvements stick?
A kaizen event — also called a kaizen blitz, kaizen workshop, or rapid improvement event — is a focused, time-boxed activity. A team comes together for three to five days, works intensively on a defined area, and presents results at the end of the week. The format was popularized in the Western lean movement in the 1990s and became the dominant vehicle for improvement. The problem is not the event itself. A concentrated effort on a specific area can produce real results. The problem is what happens after.
Kaizen events were the primary lens through which many companies first learned TPS principles in the 1980s and 1990s. Companies like Wiremold and Danaher successfully used events as a starting point and made the transition to effective operating systems. But as many or more companies tried this approach and found the results did not stick. They never made the transition from discrete improvement activities to a consistent operating and management system. Art Byrne of Wiremold has many excellent articles on this topic over the years.
Jim Womack called these failed efforts “kamikaze kaizen” — intense bursts of activity with no lasting effect other than a fiery death. As a countermeasure, LEI authored Learning to See, using value stream mapping to connect individual events in a flow from order to delivery and raw materials to finished goods. The workbook is based loosely on Toyota’s approach to drawing material and information flow diagrams for connecting processes visually and defining pull systems. Both approaches complement each other when done correctly. Both eventually need to lead to a management system that holds the gains and develops the people.
A one-week event cannot change permanent conditions on its own. At most it is a vehicle for local change and learning. Permanent conditions change when the gains get built into standards and held by an operating system that runs daily — routines, accountability, and the people development that sustains both. The event is a tool. The management system is what makes the tool’s results stick.
Toyota does not rely on kaizen events as its primary improvement mechanism. Improvement is built into daily work: standardized work defines the current best method, abnormalities are surfaced through jidoka and visual management, and team leaders and group leaders solve problems as they appear. Periodic focused activities exist — jishuken study groups led by OMCD are one example — but these involve people with deep technical skill, and the results are embedded in new standards. The event is not the system. The daily discipline is the system.
Why does improvement stall even when the tools are in place?
The specific answer always depends on the organization. There is not a single root cause. However, there is a general pattern. A company launches a lean initiative. Early workshops produce visible changes — rearranged layouts, new flow lines, posted boards. Results look promising. Leaders order more workshops or delegate improvement to others in the organization. Then progress slows. The workshops continue, but measured performance stops improving. Leaders conclude that “lean does not work.”
The failure is usually not the tools. It is the gap between methodology, technical depth, and leadership. The lean movement has made real progress on principles, frameworks, and thinking models. It has made less progress on the domain-specific technical knowledge needed to actually solve problems on the floor. There is usually a disconnect from leadership and from daily activities where results are made.
This is what I have generically called lean wallpaper — artifacts posted on walls with little to show in actual results. Standardized work charts that no one follows. Value stream maps that sit in binders. A3 reports drafted and not reviewed or completed. The documents exist but did not produce improvement because the people creating them lacked the domain depth to solve the actual problems or make the required changes.
The genba disconnect runs deeper than physical presence. A problem is a gap from standard. If no standard is clear, the problem is not visible. Companies that cannot define a specific problem generate action items with no bearing on cause and effect. Resources are spent, time passes, and employees grow disenchanted. The 80/20 rule applies here: teams spend effort on activities that do not address the vital few problems that actually drive performance.
The companies that sustain improvement over years share a common trait: a critical mass of people with both the right thinking and the right technical knowledge, developed through practice on the floor — not through workshops alone. They go to the genba. They define problems precisely. And they use standardized work as the mechanism connecting daily management to daily improvement — not as a document in a binder. Management and organizational capabilities have to adapt and expand as well.
See also: What Is Standardized Work?, What Is the Difference Between TPS and Lean?, What Does Gemba Mean?, What Is the Difference Between Muda, Mura, and Muri?.