Kaizen Blitz: Running a Rapid Improvement Event, and Making It Stick
Kaizen Blitz is a short improvement event, usually five days, in which a cross-functional team scopes, measures, tests and implements a change to one process before the event ends.
Before you start
Is this your framework?
A blitz answers one question: can we change this specific process, this week, with the people who run it. Its defining feature is that the change is made before the event ends, not recommended.
That constraint is also its limit. A week is not long enough to find an unknown cause or to settle a disagreement between departments. The table below says what handles those.
| If your real problem is… | You probably want |
|---|---|
| Improvement only happens when we run an event, and stops in between | Kaizen — the daily practice this event is named after, which is what holds gains Compare Kaizen Blitz and Kaizen |
| The cause is genuinely unknown and competing explanations exist | Lean Six Sigma — DMAIC, which spends months establishing cause before changing anything Compare Kaizen Blitz and Lean Six Sigma |
| We do not yet know which process is worth attacking | Value Stream Mapping — find where the work waits, then point the event at it |
| One step limits the whole system regardless of what we improve elsewhere | Theory of Constraints — a fast win away from the bottleneck changes nothing |
| The workplace itself is the obstacle before any process change | 5S Methodology — often the right content for a first event, and simpler |
| The change will fail on resistance rather than on design | Kotter's 8-Step Process — adoption across an organization, which a week cannot deliver |
| One bounded process is visibly bad and we want it changed this week | Kaizen Blitz — you are in the right place |
What Is It?
Take five to twelve people who touch one process, remove them from their normal work for a week, and require that the process is different by Friday. That is the whole format. The insistence on implementing rather than recommending is what separates it from a workshop.
It works because of what the constraint removes. There is no time to escalate, so someone with authority has to be in the room. There is no time to schedule a follow-up meeting, so disagreements get settled the same day. And there is no time to build a business case, so changes have to be small enough to try. A week of enforced proximity solves coordination problems that would otherwise take a quarter.
The format's origin explains its shape. Japanese consultants supporting United States manufacturers in the late 1980s could not fly over often enough to support improvement continuously, so they compressed it into a visit. The week is the length of a consulting trip, not a finding about how long improvement takes. That is worth knowing before treating five days as though it were a principle.
What the format cannot do is hold anything. The team disperses on Friday, the process goes to people who were not in the room, and the reasons behind the new standard leave with the people who worked them out. Erosion within two or three months is the normal outcome, not the unlucky one.
So the honest description is a starter and a demonstration. It shows an organization that change is possible and produces something visible quickly, which buys patience for slower work. Judged as a way of making permanent improvements on its own, it mostly fails, and the failure is structural rather than a matter of running the week better.
Quick Reference
The event
The week, day by day
Five days is the common shape. What matters is less the exact schedule than the order: nothing gets implemented before it has been measured and tried at small scale.
| Day | What it has to produce | Where it goes wrong |
|---|---|---|
| 1. Scope | A boundary, a current-state map made by walking the process, and agreement on what success would look like. | Scope too wide. Nearly every failed event can be traced to a day-one boundary nobody was willing to narrow. |
| 2. Measure | Actual numbers from the process as it runs: times, distances, counts, defects. Collected, not recalled. | Accepting what people believe happens. The gap between the remembered process and the observed one is usually where the event's value sits. |
| 3. Test | Changes tried at small scale, with before-and-after numbers. Several ideas, cheaply. | Skipping to implementation because the answer seems obvious, which loses the evidence that would have defended it later. |
| 4. Implement | The change made for real, physically if the process is physical. Layout moved, forms changed, system configured. | Producing a plan instead. An event that ends with a proposal has become a workshop. |
| 5. Handover | The new standard written down, training done, and a named owner who has agreed to inherit it. | Treating it as a presentation. A closing session for management is not a handover, and it is where the erosion starts. |
Day one determines the week
Scope is the single decision that most affects whether a blitz produces anything. Too wide and the team is still mapping on Wednesday. The useful test is whether one team could plausibly change it without asking anyone outside the room. If the answer needs another department's agreement, the scope is wrong, and no amount of energy later in the week recovers it.
Two conditions are worth insisting on before day one. Someone who can approve changes has to be present all week rather than reachable, because the whole advantage of the format is that decisions do not wait. And the people who actually do the work have to be on the team, not represented by their manager, since the point is to use knowledge that does not otherwise travel upward.
Afterward
Why gains fade, and what holds them
The week is the part that gets planned. What happens afterward is the part that decides whether any of it mattered, and it is usually nobody's job.
| Why it fades | What it looks like | What holds it |
|---|---|---|
| The team leaves | The people who understood why the change was made go back to their own jobs within days | A named owner who was in the room and stays with the process, agreed before the event, not after. |
| The reasons are undocumented | The new standard exists; the reasoning behind it does not, so it looks arbitrary to whoever inherits it | Write down what was tried and rejected, not only what was adopted. |
| Nobody checks | No date, no owner, and no measurement after the closing presentation | A scheduled check about thirty days out, with the same measures taken on day two, by someone who was there. |
| The old conditions return | Volumes rise, staff change, and the change quietly stops fitting | Treat drift as information rather than as failure. A standard that no longer fits needs revising, not enforcing. |
| There is no habit to fall back on | The next problem waits for the next event, twelve months away | Daily improvement between events. This is the structural answer, and the only one that generalizes. |
Two dates decide more than the whole agenda
Before the event: the date on which the process owner agreed to inherit the result. After it: the date of the thirty-day check, in a calendar, with a name against it. Both are administrative and both are skipped more often than any step in the week itself, which is why so many organizations have a folder of successful events and a set of processes that look much as they did.
It is worth being plain about the limit. An event is a good way to start improving and a poor way to keep improving, and no refinement of the week fixes that. The organizations that get lasting value from blitzes are the ones running daily improvement in between, using events to open up problems too big for a suggestion. Used alone, the format gives you five improved days a year.
Core Features
- Implementation inside the event: the change is made, not proposed
- A bounded scope: one process, changeable without outside agreement
- Cross-functional team: the people who do the work, not their representatives
- Decision authority present: in the room all week, not reachable
- Measurement before change: observed on day two, repeated at the end
- A named owner and a check date: agreed before the event begins
Worked example
214 minutes, and the two dates that had been skipped
An illustrative composite. A generic pharmaceuticals manufacturer near Hyderabad, India, running packaging lines for export markets. Changeover between products was taking most of a shift, and two previous events on the same line had produced gains that did not last.
| Stage | What it showed |
|---|---|
| Why the earlier events failed | Both had ended with a closing presentation and no owner. Neither had a check date. The documented standard from the second event was found in a shared folder, never printed, never trained, and contradicted by what operators were actually doing. |
| Day one, narrowed | The proposed scope was "reduce changeover time". Narrowed to one line and one product family, on the test that the team could change it without another department's approval. That excluded the quality release step, which needed a separate conversation. |
| Day two, measured | Observed changeover averaged 214 minutes against a believed 150. Of that, 96 minutes was waiting: for tooling, for a supervisor signature, for cleaning materials fetched from a store two floors away. |
| Days three and four | Tooling and materials moved to a shadow board at the line. Signature authority delegated to the shift leader. Preparation steps moved to before the line stopped. Changeover fell to 121 minutes by Thursday afternoon. |
| Day five, and day thirty | Standard written with photographs, both shifts trained, and the shift leader named as owner in front of the team. At the thirty-day check, changeover was 118 minutes. Two elements of the standard had already been revised by operators. |
Nearly half the changeover was waiting, and no equipment was bought
214 minutes to 118, and nothing on the line was replaced. The gains came from moving tooling closer, delegating a signature, and doing preparation while the line still ran. All three were visible to the operators before the event and none had ever reached anyone who could authorize them — which is the case for having the people who do the work in the room rather than represented.
The difference from the two failed attempts was not the week. It was the owner named in front of the team and the check date in a calendar. Both are administrative, both take ten minutes, and both had been skipped twice. The detail worth noticing is the last one: at thirty days the operators had already revised two elements of the standard themselves, which is the point at which an event stops being an event and starts becoming a habit.
When to Use
- One bounded process is visibly bad and the causes are broadly understood
- A quick, visible result is needed to build confidence for slower work
- The problem sits across a few functions who rarely coordinate
- People can genuinely be released for the full week
- Someone with authority to approve changes can be present throughout
- A process owner has agreed in advance to inherit the result
When NOT to Use
- The cause is unknown and needs statistical investigation
- The scope spans departments with genuinely competing objectives
- Nobody can be released, so the event runs part-time around day jobs
- Previous events were run and every one of them was allowed to lapse
- The change will fail on resistance rather than on design
- It would be the organization's only improvement activity this year
Afterward
How events go wrong
The first two happen during the week. The rest happen after it, which is why they are less often noticed and more often fatal.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| Scope too wide | Still mapping on Wednesday, implementing nothing by Friday | Narrow until one team could change it without outside approval. Do this on day one or not at all. |
| It becomes a workshop | The week ends with recommendations and a plan rather than a changed process | Require something physically different by Thursday. If that is impossible, the scope was wrong. |
| No owner | A closing presentation to management, and nobody who has agreed to inherit the process | Name the owner before the event starts, and again in front of the team on day five. |
| No check date | Nobody re-measures, so erosion is invisible until the next event finds the old numbers | Put a thirty-day check in the calendar during the week, with the day-two measures repeated. |
| Managers represent the workers | The team describes the process as it is documented rather than as it runs | Put the people who do the job on the team. The gap between the two versions is the opportunity. |
| Authority on call | Decisions wait for someone to become available, and the week's advantage is lost | Have the approver in the room, or reduce the scope until none is needed. |
| Events as the whole program | Four events a year, nothing in between, and each one rediscovering the last one's ground | Run daily improvement between events. Judge the year on the other 250 days. |
Sourced
Evidence, and how to cite it
The week-long format exists because of a travel constraint.
Japanese consultants, among them Yoshiki Iwata and Chihiro Nakao, were supporting United States manufacturers in the late 1980s and could not be present often enough to sustain continuous improvement across that distance. They compressed the work into a concentrated visit. The most widely cited early instance is 1988 at Jacobs Vehicle Equipment, at the request of its president George Koenigsaecker, and the format was originally called Five Days and One Night. Boeing later adopted it as Accelerated Improvement Workshops. The length is the length of a consulting trip rather than a finding about improvement.
Accounts of the origin of the kaizen event format in Lean practice; Laraia, A.C., Moody, P.E. and Hall, R.W. (1999) The Kaizen Blitz. New York: Wiley.
By Toyota's own vocabulary, this is closer to kaikaku than to kaizen.
Kaizen describes small incremental change made continuously by everyone. A concentrated step change made by a selected team in one week is what Japanese practice calls kaikaku, radical change. The naming is not pedantry: it sets expectations. An organization told it is doing kaizen expects a culture, and receives a series of projects. Both are useful, and the confusion is the reason so many report doing continuous improvement while improving on five days a year.
Standard Lean vocabulary distinguishing kaizen from kaikaku; see the Kaizen page for the daily practice.
The format is documented, and its own literature is candid about sustainment.
Laraia, Moody and Hall set out the event format in 1999 through case material from manufacturers who had adopted it, published in association with the Association for Manufacturing Excellence. The book is a practitioner account rather than a study, and it is explicit that rapid results and lasting results are different problems. That distinction has largely dropped out of the shorter summaries that circulate since, which describe the week and stop.
Laraia, A.C., Moody, P.E. and Hall, R.W. (1999) The Kaizen Blitz: Accelerating Breakthroughs in Productivity and Performance. New York: Wiley.
There is no controlled evidence on how long the gains last.
Erosion after events is reported consistently by practitioners and is the reason sustainment appears in every serious treatment of the format. But it has not been measured across organizations in a way that would let anyone say what proportion of gains survive, or for how long, or which of the recommended countermeasures actually work. The published cases are supplied by the organizations that ran them and are selected on having gone well. Treat the sustainment advice on this page as accumulated practitioner judgment, which is what it is.
Assessment of the Lean and operations literature as of 2026; no controlled follow-up studies of kaizen event outcomes are available.
How to cite it.
Harvard: Laraia, A.C., Moody, P.E. and Hall, R.W. (1999) The Kaizen Blitz: Accelerating Breakthroughs in Productivity and Performance. New York: Wiley.
APA: Laraia, A. C., Moody, P. E., & Hall, R. W. (1999). The kaizen blitz: Accelerating breakthroughs in productivity and performance. Wiley.
For the philosophy the event is named after, cite Imai (1986), and note that the event is a later Western adaptation.
Key Strengths
- Something changes this week: the constraint that makes the format work
- Solves coordination cheaply: a week of proximity beats a quarter of meetings
- Surfaces what operators know: knowledge that rarely travels upward
- Builds belief: a visible result buys patience for slower improvement work
- Cheap: the cost is a week of people's time, rarely capital
Key Weaknesses
- Cannot hold the gain: structural, not a matter of running the week better
- Needs a narrow scope: which excludes most interesting problems
- Expensive in attention: a dozen people off their jobs for a week
- Rewards speed over evidence: five days is not long enough to establish a cause
- Crowds out the habit: events can become the only improvement anyone does
Sequencing
What to run before and after
A blitz is a burst. What it needs on either side is a reason to point it somewhere and something to hold what it produces.
Before
Work out which process is worth a week
Events are expensive in attention and narrow in scope, so pointing one at the wrong process wastes both. Find where the work waits, and check the target is not simply downstream of a bottleneck.
During
Measure before changing, and keep the numbers
Day two's measures are what the thirty-day check compares against. Without them there is no way to tell erosion from normal variation, and no evidence to defend the change when someone questions it.
After
Build the habit that holds it
This is the step that decides whether events compound or repeat. Daily improvement between events keeps standards alive and stops the next event rediscovering the last one's ground.
Common questions
Kaizen Blitz: quick answers
What is a kaizen blitz?
A short, intensive improvement workshop, usually a week, in which a cross-functional team is taken off its normal work to analyze one process and change it before the week ends. It is also called a kaizen event, a rapid improvement event or a rapid process improvement workshop. Implementing within the week, rather than producing recommendations, is the defining feature.
What happens on each day?
A common five-day shape: day one fixes scope and maps the current process, day two measures what is actually happening, day three tests changes on a small scale, day four implements what worked, and day five documents the new standard and hands it to whoever owns the process. Events run shorter than three days rarely get past mapping.
Where did the kaizen blitz come from?
Japanese consultants working with United States manufacturers in the late 1980s could not visit often enough to support daily improvement, so they compressed it into a concentrated week. The first widely cited example was in 1988 at Jacobs Vehicle Equipment. It was originally called Five Days and One Night. Boeing later adopted the format as Accelerated Improvement Workshops.
Is a kaizen blitz the same as kaizen?
No, though the name suggests it. Kaizen is continuous improvement made in small increments by everyone as part of daily work. A blitz is a concentrated event run by a selected team. By Toyota's own vocabulary a step change is closer to kaikaku, radical change. The two are complements: events start things and demonstrate what is possible, daily practice is what holds them.
Why do the gains disappear after the event?
Because the team that made the change goes back to its normal job, and the process is handed to people who were not in the room. What was obvious during the week stops being obvious, the documented standard drifts, and within a couple of months the old way returns. The fix is structural: a named owner, a documented standard, and a scheduled check roughly a month later.
What has to be true before running one?
The problem must be bounded enough to change in a week. Data has to exist or be collectible on day two. Someone with authority to approve changes must be available all week, not on call. The people who do the work must be on the team rather than represented. And the process owner has to have agreed to inherit the result.
When is a blitz the wrong tool?
When the cause is genuinely unknown and needs statistical investigation, which is a DMAIC project. When the problem spans several departments with competing objectives, because a week is not long enough to settle that. When nobody can be released for five days, since a part-time blitz is just a slow meeting. And when the organization has run events before and let every one of them lapse.
How do you cite kaizen event sources?
For the format and its rationale, cite Laraia, A.C., Moody, P.E. and Hall, R.W. (1999) The Kaizen Blitz: Accelerating Breakthroughs in Productivity and Performance, Wiley. For the underlying philosophy the event is named after, cite Imai, M. (1986) Kaizen: The Key to Japan's Competitive Success, and note that the event format is a later Western adaptation.
Deep Resources
Frameworks related to Kaizen Blitz
- KaizenThe daily practice the event is named after, and the thing that holds what a week produces…
- Value Stream MappingHow to decide which process deserves a week of a dozen people's attention…
- Lean Six SigmaDMAIC, for problems where the cause is unknown and a week would not be enough…