Implementation Guide
Kaizen Events.
A kaizen event is a focused workshop, usually three to five days, in which a cross-functional team measures a process, tests changes physically at the process, and standardizes what works within the same week. The event is won in the two weeks of preparation and kept in the 30-day follow-up list: a great week with no owner for the leftovers is a team-building exercise with production losses.
What a kaizen event is
A kaizen event, also called a kaizen blitz or rapid improvement event, is three to five consecutive days in which a dedicated team improves one process at the process. The team measures the current state on day one and changes the physical reality of the work by day three: moving equipment, mocking up fixtures, relocating material, rewriting the standard. Nothing is scheduled for later implementation. If a change can be tried this week, it is tried this week.
That compression is both the point and the risk. The point: an event concentrates attention, authority and hands so that changes a committee would debate for three months happen in an afternoon. The risk: a week is long enough to change a process and far too short to change a habit. Which is why the two weeks before the event and the 30 days after it decide more than the five days in the middle.
Scope note: this page covers the workshop format, how to prepare an event, run it, and follow it up. The everyday improvement system that events belong to, capturing ideas, triaging them and implementing small improvements daily, has its own guide: kaizen. If you are choosing between building that system and scheduling events, build the system first. Events are one lane of it, not a substitute for it.
Where events sit in the roadmap
On the TeamGuru deployment roadmap, kaizen events belong to the Improve stage, inside the kaizen practice: one of three improvement lanes next to daily kaizen and larger projects. Events pay off once daily management can hold the gains they produce, and their topics should come from evidence: kaizen bursts on the value stream map, loss Paretos, and repeat problems from the daily boards. An event whose topic was chosen by walking past something ugly is already half wasted.
When an event is the wrong tool
An event is a hammer for a specific nail: a bounded problem in one area, with causes visible at the process, and fixes that can be physically tried within a week. Outside that shape, the format works against you:
- The cause is unknown and needs weeks of data. That is a structured problem-solving case, not an event; trystorming a problem you do not understand produces confident noise.
- The fix is a pure engineering project: new equipment, tooling design, software. Scope that as a project with a plan; use an event, if at all, for the workplace around it.
- The problem only needs a decision. If one manager could fix it with a signature, book a meeting, not a week of eight people.
- The real goal is morale or team-building. An event run as energy theater produces exactly that: energy, which drains the moment people watch the changes revert.
For problems that need deeper cause analysis first, start with root cause and corrective action and bring the verified cause into an event later. And match the method to the topic: a changeover event should run the SMED method inside the event format, a workplace organization event should follow 5S, not generic brainstorming.
Two weeks of preparation
Most failed events failed before Monday morning: the scope was a wish, the baseline did not exist, half the team got pulled back to cover production, and maintenance heard about the layout change when the team asked for a forklift. Preparation is not administration around the event. It is the event. This checklist is two calendar weeks of it:
| When | What must be done | Output that proves it |
|---|---|---|
| Two weeks before | Scope one measurable problem and write a one-page charter: problem statement with numbers, one primary metric, physical boundaries (which stations, which shifts), and what is explicitly out of scope. | A charter the sponsor signed |
| Two weeks before | Collect baseline data at the process, not from reports: cycle times, walking distances, defect counts, whatever the primary metric needs, measured over normal production. | A baseline the team can defend |
| Two weeks before | Name the team of 6 to 8: a majority from the area including operators from the affected shifts, plus two or three outsiders from maintenance, engineering or another area, and one leader who can approve changes on the spot. | A confirmed roster |
| One week before | Arrange backfill for every team member and agree trial windows with planning, including any buffer stock needed so trials do not starve the customer. | A coverage plan production accepted |
| One week before | Put support on call: maintenance for physical moves, a cart of supplies (cardboard, tape, markers, tags, hardware), and a small pre-approved budget so nothing waits for a signature. | Support and materials committed |
| One week before | Book the day 5 leadership report-out in the sponsors' calendars. A report-out booked in advance is a promise the week has to keep. | Report-out accepted by leadership |
| Day before | Walk the area with the supervisor and brief every shift on what will happen, why, and how they will be involved and trained during the week. | No one is surprised on Monday |
Two of these rows carry most of the weight. The charter, because a scope that fits on one page with one primary metric is what stops the week from drifting. And the baseline, because a result can only be as honest as the number it is compared against. If baseline data cannot be collected in the two weeks before the event, the topic is not ready, and moving the event beats running it blind.
The five-day agenda
The sequence below is the standard shape of a five-day event: understand, analyze, change, standardize, prove. Compress it to three days for a narrow scope, but keep the order, and never cut day 4. A week that ends with changes but no trained standard has rented its improvement, not bought it.
| Day | What happens | Deliverable by end of day |
|---|---|---|
| Day 1 | Short training on the method and the charter, then measure the current state at the process: confirm the baseline, time the work, map the walking, count the piles. | A measured current state the team believes, and a first waste list |
| Day 2 | Waste walk and cause analysis: observe full cycles, ask the operators what gets in their way, and verify causes at the process instead of voting on them in the meeting room. | A prioritized list of causes verified by observation |
| Day 3 | Trystorm changes at the process: mock up new layouts and fixtures in cardboard and tape, move material to point of use, trial each change during the agreed windows, keep what works, kill what does not. | Changes physically trialed, with keep or kill decisions made on evidence |
| Day 4 | Standardize what worked: update the standard work chart and visual aids to the new method, then train every shift on it, at the process, before the day ends. | An updated standard, and all shifts trained on it |
| Day 5 | Measure the result with the same method as the baseline, prepare the report-out, and assign the leftover list: every open item gets one owner and a date inside 30 days. | Before and after measured the same way, and a 30-day list with owners |
Trystorm, do not brainstorm
A brainstorm produces a flipchart of ideas to evaluate later. A trystorm produces a pile of experiments already run. Cardboard, tape and an hour of trial at the process beat slideware for three reasons. Reality votes immediately: the gravity chute that jams as a cardboard mockup never gets welded in steel. Operators judge a physical change they can touch, instead of being asked to approve a drawing. And cheap mockups keep every decision reversible until the evidence arrives. A useful rule: if a proposed change cannot be mocked up and tried before day 4, it does not belong in the week. It goes on the leftover list as a project candidate.
What a week like this looks like
An illustrative event at the 450-person components manufacturer used across these guides (456 units per day, takt 118 seconds): the daily boards showed station 3 of the assembly cell repeatedly missing takt, and the baseline measured in the week before confirmed it at 131 seconds per cycle, with the operator walking 18 meters per cycle to fetch parts and tools. By day 3 the team had trialed point-of-use racks, a cardboard gravity chute and a relocated tool rail. By day 4 the new standard work chart showed a 109-second cycle and 4 meters of walking, and both shifts had been trained at the station. The day 5 report-out compared 109 to 131 using the same stopwatch method, and handed leadership a nine-item leftover list. The steel version of the chute, the updated layout drawing and the day 30 re-measurement were on it, each with an owner and a date.
Measuring honestly, and the 30-day list
One rule governs event results: same metric, same measurement method, same conditions. If the baseline was measured over full shifts of normal production, the after number cannot be one golden hour with the whole team watching and the material pre-staged. Day 5 numbers are provisional by definition: the team is present, the area is freshly organized, everyone performs. They belong in the report-out, clearly labeled as day 5 results.
The result that counts is the day 30 re-measurement, under normal conditions, with nobody watching. Book it before the event ends, give it an owner, and treat a gap between day 5 and day 30 as information, not failure: it points at training, at the standard, or at a change that only worked while the team was there to nurse it.
Everything the week could not finish lands on the 30-day follow-up list, and this list is where events are kept or lost. The format is deliberately minimal:
| Item | Owner | Due | Verified |
|---|---|---|---|
| Replace the cardboard parts chute at station 3 with the fabricated steel version | Maintenance planner | Day 12 | Done, day 14 |
| Update the layout drawing and station 3 standard work chart to the new arrangement | Area engineer | Day 7 | Done, day 9 |
| Train the weekend relief crew on the new station 3 standard | Shift supervisor | Day 5 | Done, day 6 |
| Order and install the second kitting cart for station 4 | Area engineer | Day 21 | Open |
| Re-measure station 3 cycle time over both shifts, same method as the baseline | Event leader | Day 30 | Scheduled |
Example rows are illustrative, from the station 3 event above. The rules that make the list work:
- Every item has exactly one owner and a date inside 30 days. An item without an owner is a suggestion.
- The area leader reviews the list weekly until it is empty, in the existing meeting rhythm, not a new meeting.
- The last item on every list is the day 30 re-measurement itself, owned by the event leader.
- Items that grow into real projects leave the list explicitly and enter the improvement portfolio; they do not quietly age on it.
Common mistakes
What bad looks like
- The scope grows mid-week until the team is trying to save the whole plant in five days
- No baseline was measured, so the report-out compares estimates to enthusiasm
- The night shift reverts every change because nobody trained them before day 5
- The leftover list is emailed once after the event and never reviewed again
- Events run back to back as a calendar ritual, with no daily improvement between them
What good looks like
- One measurable problem, one area, a baseline the team measured itself before the week
- Changes trialed physically during the week, at the process, with operators deciding
- Every shift trained on the new standard before the report-out
- A 30-day list with owners and dates, reviewed weekly until it is empty
- The metric re-measured at day 30 under normal conditions, same method as the baseline
After the event: keeping what you won
An event that worked changed a standard, or it did not happen. The day 4 standard work chart is the carrier of the gain, which is why it deserves the same discipline as any other piece of standardized work: owned, audited, and revised when someone finds a better way. A result worth having in one area is usually worth spreading, and yokoten is how it spreads without copy-paste: the receiving area sees the practice run, adapts the method, and keeps the verification.
Events also need a system between them. A plant that improves only during event weeks gets a sawtooth: gains in the week, decay in the quarter. The kaizen system is what fills the space between events with daily improvements, and it is where event leftovers that became project candidates get triaged and resourced.
The follow-up list is also where digital support earns its place. In TeamGuru, event leftovers live as owned, dated actions in project and action management, and the improvement itself runs through the kaizen pipeline from capture to verified benefit, so the day 30 check is a scheduled task with an owner instead of a memory. Either way, on paper or in software, the discipline is the same: the event ends when the list is empty and the day 30 number holds, not when the team photo is taken.
