The Five-Day Miracle That
Wasn’t
A kaizen event — sometimes called kaikaku, sometimes a “rapid
improvement event,” sometimes a “blitz” — is supposed to be the shock
troops of your lean transformation. You pull together a cross-functional
team for three to five days, give them a process to destroy and rebuild,
and by Friday afternoon you have a redesigned cell, a eliminated waste,
a takt time achieved, and a team that went from skeptical to
evangelical. That’s the promise. That’s the poster. That’s the story
your lean office tells at conferences.
Here’s what actually happens in most organizations.
Monday is wasted on introductions, icebreakers, charter reading, and
a gemba walk where everyone nods politely at things they already knew.
Tuesday is value stream mapping of a process someone already mapped six
months ago. Wednesday is “brainstorming” — sticky notes on a wall,
affinity diagrams, dot voting — that produces the same list of
improvements the team wrote down at the last event. Thursday is frantic
implementation where the team rushes to move equipment, build new
fixtures, and create new standard work documents before the Friday
report-out. And Friday is a presentation to leadership where the team
shows before-and-after photos, declares victory, and eats cake.
Then Monday comes. The operators who weren’t on the team look at the
new setup, don’t understand it, weren’t trained on it, and within two
weeks everything reverts. The standard work document is pinned to a
board nobody reads. The new fixture breaks and nobody fixes it. The 5S
shadows are ignored within a month. Six months later, someone walks the
floor and finds the process exactly as it was before the event —
sometimes worse, because the half-implemented changes created confusion
that was never resolved.
The kaizen event didn’t fail. The kaizen event was never the point.
The point was the management system that should have sustained the
changes. And that system doesn’t exist.
The Event as Substitute
for the System
Organizations fall in love with kaizen events because they are
visible, measurable, and produce immediate, photographable results. A
vice president can walk through a cell on Thursday and see that it looks
different from how it looked on Monday. That’s powerful. That’s
seductive. That’s also the problem.
A kaizen event is a tool — one tool — within a continuous improvement
system. It is not the system itself. When organizations use events as
their primary — or only — improvement mechanism, several predictable
pathologies emerge.
Event theater. The event becomes a performance. The
team knows leadership will visit on Friday, so they optimize for the
presentation, not for the process. Improvements are chosen for their
visual impact rather than their systemic value. A messy shelving unit
gets reorganized because it photographs well. A deeply broken changeover
process is left alone because fixing it would take six weeks, not four
days.
The improvement debt. Each event generates action
items that can’t be completed during the event week. These go on a
“30-day list” — tasks assigned to people who weren’t at the event, who
don’t understand the context, and who already have full-time jobs. The
30-day list becomes a 60-day list becomes a never-done list. The next
event starts before the last event’s actions are closed. Over a year,
you accumulate hundreds of incomplete action items. Nobody tracks them.
Nobody closes them. The debt grows until someone declares the lean
program a failure and replaces it with a new initiative.
The sustainability cliff. Even when an event
produces genuine improvements, there is no mechanism to hold the gains.
Standard work is written but not followed. Visual controls are installed
but not maintained. Audits are promised but not conducted. The process
drifts back because the management system — the daily checks, the hourly
tracking, the escalation rules, the coaching — was never built. The
event is a sprint. Sustainability is a marathon. Organizations that only
sprint never finish the race.
Selection Bias and the
Wrong Targets
Here’s a question your lean office doesn’t want to answer honestly:
how do you choose which processes get a kaizen event?
In most organizations, the answer is some combination of: wherever
the loudest executive wants one, wherever is most convenient for the
team to gather, wherever looks the most impressive in a report-out, and
wherever has the most visible mess (regardless of whether that mess is
the actual bottleneck).
This is selection bias, and it destroys the value of the event
program before it starts.
The correct way to select a kaizen event target is to start with the
constraint — the bottleneck resource that limits your entire system’s
throughput. Goldratt taught this forty years ago. If you improve a
non-bottleneck process, you don’t increase output. You increase local
efficiency at the cost of global performance. You build more inventory
in front of the bottleneck. You add cost without adding throughput.
But kaizen event selection rarely starts with constraint analysis. It
starts with politics, visibility, and convenience. The result is a
portfolio of events that collectively produce no measurable improvement
in the metrics that actually matter: on-time delivery, cost per unit,
quality at the customer.
Worse, organizations often choose targets where improvement is easy
rather than where improvement is valuable. A cell that’s already running
at 85% OEE gets the event because the team can push it to 92% and claim
a win. A cell running at 40% OEE — the real bottleneck — is left alone
because pushing it to 50% would be harder, messier, and wouldn’t look as
good in the Friday presentation.
The Team That Wasn’t There
A kaizen event team typically includes five to eight people: a
facilitator, a few process experts, maybe an engineer, maybe a quality
person, and — if you’re lucky — one or two operators from the line being
improved.
The operators who actually run the process every day are
underrepresented. Sometimes deliberately — management worries they’ll
“resist change.” Sometimes structurally — you can’t pull key operators
off a running line for a week without crashing production. Either way,
the people who know the process best are the people least likely to be
in the room.
This creates a predictable disaster. The team designs a new process
on a whiteboard, validates it with cardboard and tape, and declares it
ready. The operators who return on Monday find their workstation
redesigned, their tools moved, their sequence changed, and their
standard work rewritten — all without their input. They were never asked
what problems they actually experience. They were never consulted on
whether the new flow makes sense. They were never trained on the new
procedure.
So they do what any competent professional does when someone
reorganizes their workspace without asking: they ignore it. Not out of
malice. Out of self-preservation. The new process might look good on
paper, but the operators know — because they weren’t asked — that step
three doesn’t work when the humidity changes, or that the new fixture
can’t hold tolerance on the thicker material, or that the new sequence
puts a quality check after the point where the defect is already
buried.
The event team blames the operators for “resisting change.” The
operators blame the event team for “never asking.” And the process
reverts.
The Facilitator Trap
Every kaizen event needs a facilitator. The facilitator is supposed
to be process-neutral — someone who guides the team through structured
problem-solving without dictating solutions. In mature lean
organizations, this role is filled by an experienced lean practitioner,
often someone from a different area who brings fresh eyes and deep
improvement methodology.
In most organizations, the facilitator is the lean office. And the
lean office — let’s be honest — is often one person who took a six-week
certification course and was handed a binder of templates. That person
is now responsible for facilitating twenty events a year across a
factory they barely understand, designing improvements for processes
they’ve never run, and coaching teams whose collective experience dwarfs
their own.
This isn’t a critique of lean coordinators. Many are talented,
hardworking, and deeply committed. The critique is structural: you
cannot facilitate improvement in a process you don’t understand. A good
facilitator can guide methodology, but without deep process knowledge —
either their own or properly represented on the team — the event
produces superficial changes. The tools get applied (5S, standard work,
visual management) but the root causes go untouched because nobody in
the room has the authority or knowledge to address them.
The facilitator trap has a second dimension: dependency. When the
lean office runs every event, improvement becomes something that happens
TO a department, not something that happens IN a department. Managers
abdicate responsibility for improvement. “That’s a lean office thing,”
they say. “We’ll put in a request for an event.” The idea that
improvement is part of every manager’s daily job — not a special event
run by a specialist — never takes root.
The Metrics That Lie
Every kaizen event ends with a report-out. The report-out includes
metrics: cycle time reduced by 35%, floor space freed up by 200 square
feet, walking distance reduced by 60%, WIP reduced by 40%.
These numbers are almost always real — in the moment. On Friday
afternoon, with the team standing there, the redesigned cell running
with the best operator, the brand-new fixture working perfectly, and no
variability in the incoming material — yes, the numbers are real.
Monday is different. The second operator calls in sick. The fixture
designed Thursday afternoon cracks under repeated use. The new material
lot is slightly thicker and the new standard work doesn’t account for
it. The cycle time creeps back. The WIP rebuilds. The walking distance
increases because people found shortcuts around the new layout.
The Friday metrics are a snapshot under ideal conditions. The Monday
reality is a video under normal variation. Organizations report the
snapshot and ignore the video. Over twelve months of events, they
accumulate a spreadsheet of “improvements” that collectively suggest
300% productivity gains — gains that are invisible in the P&L.
This is not lying. It’s worse. It’s self-deception. The team
genuinely believes they achieved the Friday numbers. The executive
genuinely believes the spreadsheet. The factory genuinely produces the
same output it did a year ago. Nobody connects the gap because nobody
goes back to verify sustained results at 30, 60, and 90 days.
Verification would expose the reversion, and exposure would threaten the
program, and the program is the only improvement mechanism anyone has.
So the deception continues.
What Real Kaizen Looks Like
Real kaizen — the kind that actually transforms organizations —
doesn’t look like a five-day event. It looks like a thousand small
improvements made every day by the people who do the work.
An operator notices that a tool is always missing. She builds a
shadow board. Five minutes saved per shift. A maintenance technician
notices a bearing running hot. He changes the PM schedule. A defect
avoided. A team leader notices a step in the standard work that confuses
every new hire. He rewrites it. Training time drops by a day.
None of these improvements are dramatic enough for a Friday
report-out. None of them photograph well. None of them produce a 35%
cycle time reduction. But collectively, over a year, they transform the
operation. And — critically — they stick, because the people who made
the changes are the people who do the work, and the changes solve real
problems that real people experience every day.
This kind of kaizen requires a management system that enables it:
leaders who coach rather than direct, standard work that is owned by the
operators not imposed by engineers, a suggestion process that actually
responds, visual controls that are maintained daily, and a culture where
finding a problem is celebrated rather than hidden.
Kaizen events have their place. For a problem that is well-defined,
has a clear scope, requires cross-functional expertise, and can be
meaningfully addressed in a focused week — an event can be exactly the
right tool. But the event must be preceded by proper problem definition
(not “let’s improve the cell” but “we are losing 12% of throughput to
changeover time on machine 4, and the root cause appears to be fixture
design”), must include the people who actually run the process, and must
be followed by a sustained management system that holds the gains.
The Diagnostic Question
If you run kaizen events, ask yourself this question: of all the
improvements made in events over the past two years, what percentage are
still in place and still delivering results today?
If the answer is less than 80%, you don’t have a kaizen event
problem. You have a management system problem. The events are exposing
it. The reversion is proving it.
Stop running more events. Start building the system that would
sustain the ones you’ve already done. That’s harder. That’s slower. That
doesn’t photograph as well. But in three years, you’ll have an
organization that improves itself — with or without events.
And that — not the Friday report-out, not the before-and-after
photos, not the spreadsheet of claimed savings — is what transformation
actually looks like.
About the Author: Peter Stasko is a Quality
Architect with over 25 years of experience in manufacturing quality,
lean transformation, and continuous improvement. He has led quality
organizations across automotive, electronics, and industrial sectors,
and writes about the gap between what quality tools promise and what
they actually deliver on the shop floor.
