A kaizen event is a short, full-time improvement effort — typically three to five consecutive days — in which a cross-functional team takes one process, maps how it actually runs, changes it during the week, and standardises the result before leaving. This page covers the five-day structure, who has to be in the room, and the two points where events quietly fail. The agenda and role card are free to download.
Download the agenda and role card
Two sheets: a day-by-day agenda with the output you need before moving on, and a role table with what each person owns and what breaks when they are missing. No signup, no email.
Kaizen Event Agenda — Excel (.xlsx)
Two tabs: five-day agenda and the role card. Editable columns for owners and times.
Download .xlsxKaizen Event Agenda — Word (.docx)
Landscape, for the pack you send the sponsor and the team a week before.
Download .docxKaizen Event Agenda — PDF (print)
Print it A3 and put it on the wall of the room. That is where an agenda actually works.
Download .pdfA kaizen event is not a long workshop
The distinction matters because it changes what you have to negotiate before you start. A workshop borrows people for a few hours and produces an analysis. A kaizen event takes them out of their normal duties for several days and is expected to leave a physically changed, standardised process behind.
| RCA workshop | Kaizen event | |
|---|---|---|
| Duration | 1–8 hours | 3–5 consecutive days, full time |
| Output | Verified cause and an action list | A changed process, standard work, and a 30-day list |
| Team | Attends between other duties | Released from normal duties, in writing |
| Sponsor | Usually informed afterwards | Opens the event and accepts the result in person |
| Fails when | The cause is not verified | Nothing is running differently on the last day |
If your problem is one failure with a short causal chain, you want a root cause workshop, not an event. Use an event when the target is a whole process with several interacting problems and the fix requires physically rearranging how work happens.
The five days
The agenda above is the version that survives contact with a real week. What matters is not the exact hour split — it is the output you must have before moving on, which is the second thing every day.
| Day | What happens | Gate before you continue |
|---|---|---|
| Day 1 | Train the team on the few tools they will actually use, then walk the process and map current state on the floor | A current-state map with real cycle times that the operators recognise |
| Day 2 | Measure the gaps, then analyse causes for the biggest one | Verified causes, not the first plausible ones |
| Day 3 | Design the future state, generate options, then physically try the chosen one | Something is running differently by the end of the day |
| Day 4 | Measure the trial against the baseline; adjust or revert. Then write standard work | Standard work the operators helped write |
| Day 5 | The 30-day list for what did not fit, then report out to the sponsor | Owner and date on every open item, sponsor commitment on record |
Day 3 is the one that gets compressed, and it is the one that must not be. A week that maps, analyses and plans but never changes anything physically produces a report. The team then goes back to normal work and the plan competes with everything else — which it loses.
The pre-work decides the week
Two weeks before the event, three things need to exist. Every one of them is boring, and skipping any one of them is the usual reason a week goes sideways.
- A charter with boundaries in writing. One process, one metric, and an explicit statement of what is out of scope. Without it, Day 2 becomes a negotiation about what the team is allowed to touch, and Day 3 becomes a request for permission.
- A baseline nobody will dispute later. Measured the same way you will measure on Day 4 and at Day 30. If the baseline arrives during the event, someone will question it during the report-out, and the argument will be about the number instead of the change.
- The team released in writing. “Mostly available” means the two people who understand the process will be pulled out on Day 2. Sponsors can grant this; facilitators cannot.
Who is in the room
The role card in the download has the full table. Three roles are worth calling out because their absence has a specific, predictable consequence:
| Role | What they own | What happens when they are missing |
|---|---|---|
| Operators | How the work is really done today | The map describes the procedure rather than reality, and the improvement targets a process that does not exist |
| Process owner | Living with the result after everyone leaves | Standard work written by visitors, quietly abandoned within weeks |
| Finance / controlling | Agreeing before the week how the saving will be counted | The team claims a gain, the sponsor does not recognise it, and the next event is harder to fund |
The facilitator owns the method and the pace — not the outcome. That separation is what lets them push back on Day 3 when the room wants to skip the trial, and it is the difference between facilitating and quietly running the project yourself.
Where root cause analysis fits
Day 2, after the process is measured — not before. Analysing causes before you have the map is the most common way an event improves something that was never the constraint.
| Step on Day 2 | Tool |
|---|---|
| Which gap is worth attacking? | Pareto analysis — rank by frequency or cost |
| What could be causing that gap? | Fishbone — spread candidates across categories |
| Why does the most likely branch happen? | 5 Whys — drill the branch the data supports |
| Which one is it, when the symptom is selective? | Is / Is Not — the boundary is the evidence |
| What could go wrong with the new design? | FMEA — before you standardise it on Day 4 |
The Day 30 check
The event ends on Friday. Whether it was an improvement is decided about a month later, when someone re-measures the same metric the same way. Three questions at that review:
- Did the metric hold? Not “does the team feel it is better” — the number, measured as at baseline.
- Is the standard work being followed? If not, it is usually wrong rather than ignored. Ask the operators which step does not work.
- What happened to the 30-day list? Items without an owner and a date are the ones that expired — the pattern is the same as for any other corrective action, covered in corrective action tracking.
An event with no verification date is not finished; it is just over. That is the single cheapest thing to add to a kaizen programme that already runs.
FAQ
What is a kaizen event?
A short, full-time improvement effort — typically three to five consecutive days — in which a cross-functional team takes one process, maps how it actually runs, changes it physically during the week, and standardises the result before leaving. The team is released from normal duties, and a change is running by the end rather than added to a list.
How long should a kaizen event be?
Three to five consecutive days, plus about two weeks of preparation and a verification roughly thirty days later. Under three days rarely leaves time to try a change and measure it; over five and normal work starts pulling people out of the room.
What is the difference between a kaizen event and a workshop?
Scope and commitment. A workshop runs one to eight hours and produces an analysis and an action list. An event takes the team out of normal duties for several days and is expected to leave a physically changed, standardised process behind. If nothing is running differently on the last day, it was a workshop with a longer agenda.
Who should be in a kaizen event team?
The people who do the work, the leader who owns the process afterwards, a facilitator who owns the method rather than the outcome, the support functions the change touches, a sponsor for the opening and report-out, and someone from finance to agree in advance how the saving is counted. That last role is the one most often missing.
What preparation does a kaizen event need?
A written charter naming one process, one metric and explicit boundaries; a baseline nobody will dispute later; the team released from normal duties in writing; and the room booked for every day. Preparation in the week before is the biggest single predictor of whether the week produces a change or a discussion.
Where does root cause analysis fit in a kaizen event?
On Day 2, after current state is mapped and measured. Pareto ranks which gap to attack, a fishbone spreads candidate causes, 5 Whys drills the branch the data supports. Doing this before measuring is how events end up improving something that was not the constraint.
Why do kaizen event gains disappear after a few weeks?
Usually because standard work was written by the visiting team rather than the operators, because the last-day open items had no owner or date, or because nobody re-measured. A check about thirty days later, same metric and same method as the baseline, is what separates an improvement from a week that felt productive.
Related
- How to facilitate an RCA workshop — the 1h / 4h / 8h formats, when an event is overkill
- PDCA cycle — the loop a kaizen event is one turn of
- A3 template — the one-page report an event report-out fits on
- Corrective action tracking — keeping the 30-day list alive
- Where the 5 Whys came from — the Toyota context behind kaizen
- RCA method selector — four questions, one method