Most kaizen guides stop at Day 5. They teach you how to structure the week. They say almost nothing about what happens between Day 5 and the 90-day mark—which is where most of the gains disappear.
That gap—between a well-run event and a lasting result—is where most kaizen programs fail. And it almost always traces back to the same root cause: the prerequisites weren't in place before the event began.
My First Kaizen Was a Failure
My first Kaizen was a failure. The whole week was spent coming up with great ideas and a mile-long list of tasks. I was the only one who could complete them.
The event itself looked like a success. The team was energized. The ideas were sharp. The whiteboard was full. We generated 47 improvement ideas over five days, prioritized the top 20, and walked out of that room genuinely proud of what we'd built.
Three months later, three had been implemented.
The event didn't fail. The prerequisites weren't in place.
This is the category error most guides make: they teach you how to run a kaizen event as if the five days are the product. They're not. The five days are a forcing function. The product is a process that actually runs differently 90 days later—not a list of ideas that got implemented once and then reverted. And that outcome is almost entirely determined by what you put in place before Day 1.
What Most Articles Skip: The Three Prerequisites
Search "how to run a kaizen event" and you'll find dozens of articles covering the same five-day structure. Day 1: define the problem. Day 2: root cause. Day 3–4: design and pilot. Day 5: standardize and present. The structure is solid. It's not the problem.
The problem is everything before Day 1 that those articles don't mention.
Prerequisite 1: Current-State Data Collected Before the Event
If your team spends Day 1 measuring the current state, you've already lost a third of your highest-energy day to data collection that should have happened the week before.
Current-state data—cycle times, error rates, handoff counts, processing volumes—needs to be gathered, validated, and presented to participants before the event begins. This serves two purposes: it anchors the problem in evidence (not opinion), and it frees Day 1 for problem definition rather than debate about what the numbers even are.
In banking operations, this typically means pulling loan processing times, document turnaround cycles, or exception-handling rates from your core system. A Kuwait-based bank running a process transformation program reduced loan processing time from 139 days to 57 days—a 59% reduction—partly because the team arrived at the event with a complete picture of where delays were actually occurring, not where they assumed they were.
That baseline data changes the entire character of the conversation. Instead of "I think the problem is in underwriting," you get "here's where the 82-day gap actually lives." The event becomes specific from minute one.
Prerequisite 2: Action Items Owned by People Who Can Execute Without Engineering Sign-Off
This is the prerequisite that kills the most kaizen events, and it's almost never discussed.
At the end of a well-run event, you'll have a prioritized action list. The question that determines whether that list gets completed is: can the person assigned to each item execute it without waiting for someone outside the room to approve it?
If your action items require engineering tickets, IT infrastructure changes, or budget approvals from people who weren't in the event, your gains are already at risk. The items will sit in queues. Momentum will stall. The team that was energized on Day 5 will be demoralized by Week 6.
The discipline here is ruthless scoping before the event. When you define the process scope and invite participants, ask explicitly: "Can the people in this room make and sustain the changes we're likely to identify?" If the answer is no—if the real blockers are system constraints that require a six-month IT roadmap—then either expand the participant list to include decision-makers with execution authority, or narrow the scope to the parts of the process your team actually controls.
Smaller scope, complete execution beats broader scope, 15% follow-through.
Prerequisite 3: The 30/90-Day Follow-Up System Scheduled at the Event
This is the one that feels administrative until you realize it's actually structural.
On Day 5, before anyone leaves the room, you need three things locked in: a 30-day review date on everyone's calendar, a 90-day review date on everyone's calendar, and a defined owner for tracking action item completion between now and then.
Not "we'll follow up in a month." An actual calendar event, with the same participants, with a pre-distributed template for reporting what's been completed and what's stalled.
The reason this has to happen before people leave the room is simple: once they're back at their desks, the kaizen event is one of a dozen things competing for their attention. The calendar invite you send two weeks later lands in a different context—a busy inbox, a full week, no memory of the energy in that room. A calendar invite set in the room on Day 5 is a commitment made in front of peers.
This is also where the change management process improvement work becomes load-bearing. Sustained gains aren't a kaizen methodology problem—they're a change management problem. The event surfaces the improvement. The system holds it.
The Five-Day Structure (When the Prerequisites Are In Place)
With current-state data collected, execution authority confirmed, and follow-up dates scheduled, the five-day structure performs as designed.
Day 1: Problem Definition The team reviews pre-collected baseline data and agrees on the specific problem being solved—not the general area, the specific measurable gap. By end of Day 1, the team should be able to state: "We are solving [specific process], measured by [metric], currently at [baseline], targeting [improvement] by [date]."
Day 2: Root Cause Analysis Using 5-Why, fishbone diagrams, or process mapping, the team identifies the actual causes of the gap—not the symptoms. The emphasis here is on causes the team has authority to address. If root causes sit outside the team's control, that's a scoping problem to flag, not to paper over with action items that will stall.
Day 3: Improvement Design The team generates and prioritizes improvement ideas against two filters: impact and executability. High-impact, high-executability ideas go to the top of the action list. High-impact, low-executability ideas go to a separate escalation list for leadership review. Low-impact ideas get parked.
The 47-ideas-3-implemented failure mode usually originates here. Teams don't filter ruthlessly enough. They leave the room with a list that feels comprehensive but is actually a delegation of optimism to people who are already overextended.
Day 4: Pilot and Test If the scope allows, Day 4 runs a live pilot of the top improvement ideas against a subset of real work. The goal isn't perfection—it's proof of concept and identification of implementation friction before the SOP is written.
Day 5: SOP, Handoff, and Scheduling Standard operating procedures are written, owners are confirmed, and—this is non-negotiable—the 30-day and 90-day review dates are calendared before the room empties.
The Post-Event System That Most Teams Don't Build
The five-day event is a starting pistol, not a finish line. What happens in the 12 months after Day 5 determines whether the gains hold.
30-Day Review The 30-day review is a progress check, not a performance review. The question is: "What's been completed, what's stalled, and what needs to be unblocked?" For items that are stalled, the conversation is about removing the obstacle—not reassigning blame.
At this stage, you should expect 40–60% of action items to be complete or in progress. Items that haven't moved in 30 days need either a new owner, a smaller scope, or an escalation decision.
90-Day Review The 90-day review is the real accountability gate. By this point, you should be measuring the baseline metric you defined on Day 1. Did cycle time drop? Did error rates improve? Did processing volume increase?
If the numbers haven't moved, the question is why—and the answer is almost always one of three things: the root cause was misidentified, the action items required resources that weren't secured, or the change wasn't embedded in daily workflow (people reverted to the old process because the new one wasn't the path of least resistance).
365-Day Review At twelve months, the question shifts from "did this work?" to "what has this taught us about where to go next?" The best kaizen programs use annual reviews to identify which improvement hypotheses were confirmed, which were wrong, and which new gaps have emerged as the process evolved.
This is also where continuous monitoring changes the math. If you're only checking at 30 and 90 days, a regression that starts at Week 4 runs for eight weeks before anyone notices. E-S-S-A-M tracks process metrics against the event baseline continuously—so when a metric starts drifting, the signal surfaces in days, not at the next formal review.
The Mandate Problem
There's one more failure mode worth naming directly: the mandated kaizen event.
Leadership schedules a kaizen event. Attendance is required. Nobody says it out loud, but everyone in the room knows the real goal is to have held the event, not to fix the process.
That's a compliance event. And compliance events don't produce improvement—they produce documentation.
The difference between a compliance event and a genuine improvement event is almost always visible by Day 2. In a compliance event, the root cause discussion is polite and avoids naming real problems. The improvement ideas cluster around things that are easy to implement and safe to suggest. The action items go to people with no authority to complete them.
In a genuine improvement event, the root cause discussion is uncomfortable. People name the actual blockers—including the ones that implicate leadership decisions. The improvement ideas are prioritized by impact, not by safety. The action items go to people who are already responsible for the process.
The prerequisite for a genuine event isn't a methodology. It's psychological safety and executive sponsorship that creates space for honest diagnosis. Without those, the five-day structure produces a polished presentation and a list of action items that never close.
How ESSAM Supports the Full Kaizen Cycle
ESSAM is designed around the 90 days after the event closes—the part of the kaizen cycle where gains are most likely to erode without a tracking system.
Before the event begins, ESSAM pulls baseline data directly from your banking core system—cycle times, exception rates, handoff volumes—so the team arrives on Day 1 with the numbers already in front of them. No data-collection day. No debate about what the current state actually is. After the event, ESSAM assigns and tracks action items with owner accountability built in, surfacing stalled items before they fall through the cracks.
For ongoing monitoring, ESSAM tracks process metrics continuously against the event baseline. When a metric starts drifting, the signal surfaces in days—not at the next formal review. And it identifies which specific step, team, or exception type is driving the regression, not just that the headline metric has moved.
The result is a 90-day review that shows the number moved—and a 365-day review that doesn't start from zero. Not because the event was better, but because the gains were tracked and defended between reviews. That's what continuous process improvement looks like in practice.
Frequently Asked Questions
How long should a kaizen event be? Most kaizen events run five days, though some organizations use three-day or even one-day formats for tightly scoped problems. The length is less important than having the three prerequisites in place: current-state data collected before the event, action items owned by people with execution authority, and 30/90-day follow-up dates calendared on Day 5. A five-day event without those prerequisites will underperform a three-day event that has them.
Who should be in the room for a kaizen event? The core team should include people who work the process daily, a process owner with authority to approve changes, and a facilitator with kaizen methodology experience. The most common scoping error is inviting people who understand the problem but can't execute the solution—or excluding people who could execute but aren't seen as "process experts." If someone's sign-off is required to implement a change, they need to be in the room or available for same-day decisions.
What's the difference between a kaizen event and a kaizen workshop? The terms are often used interchangeably, but in practice a kaizen event refers to the structured multi-day format described in this post—with a specific scope, a defined team, and a formal follow-up system. A kaizen workshop is often shorter, more educational, and may not produce action items. If your goal is measurable process improvement, you want an event, not a workshop.
How do you measure the success of a kaizen event? Success is measured against the baseline metric defined on Day 1. If the event targeted a reduction in loan processing cycle time, the 90-day review measures whether cycle time actually dropped—and by how much. Secondary measures include percentage of action items completed by 30 days and gain retention at 90 days. An event that generated 20 action items and completed 18 of them with measurable impact on the target metric is a success. An event that generated 47 ideas and implemented 3 is not, regardless of how energized the team felt on Day 5.
Can kaizen events work in highly regulated banking environments? Yes, and they're often more valuable in regulated environments than in less constrained ones—because regulatory requirements create the kind of documented, standardized processes that kaizen analysis can target precisely. The key adaptation for banking is ensuring that any process changes go through the appropriate compliance review before being standardized. In practice, this means the Day 5 SOP step includes a compliance sign-off checkpoint, and action item timelines account for review cycles. The methodology adapts; the prerequisites don't change.
The Real Question
Everyone asks how to run a kaizen event. The real question is what needs to be in place before the event starts for the gains to hold 90 days later.
Current-state data. Execution authority. A follow-up system scheduled in the room on Day 5.
Without those three things, the best-facilitated event in the world produces a list. That list goes into a shared drive. It gets reviewed at next year's planning meeting, if at all.
With them, five days of structured work actually moves the number you set out to move.
If you're preparing for a kaizen event and want to see how ESSAM pulls baseline data before Day 1, tracks action items to completion, and flags metric drift before the 90-day review, talk to the ESSAM team.