You know the problem. A process that has been broken for months. A team that talks about fixing it in every stand-up. A backlog of improvement ideas that never quite make it off the whiteboard.
A Rapid Improvement Event changes that. It takes a bounded problem, a cross-functional team, and three to five uninterrupted days, and produces a measurable result before the week is over. No waiting for the next project cycle. No month-long approval chain. Changes happen at the Gemba, in real time, by the people who actually do the work.
What this guide covers:
- What a Rapid Improvement Event is and when to use one
- How to select the right process and build the right team
- How to prepare in the two weeks before the event
- A day-by-day breakdown of the five-day format
- How to lock in the gains and prevent them from slipping
This is not a theoretical overview. It is a practical guide you can follow from first scoping conversation to 90-day follow-up review.
What Is a Rapid Improvement Event?
A Rapid Improvement Event (RIE) is a structured, short-duration workshop focused on improving a single process or work area. You may also hear it called a Kaizen Blitz, Kaizen Event, or simply a Kaizen workshop. The names are used interchangeably across industries.
The word "Kaizen" comes from the Japanese for "change for the better." According to the Lean Enterprise Institute, a Kaizen event concentrates the improvement cycle into a compressed timeframe, typically three to five days, so that analysis, design, and implementation all happen within the same week.
Key distinction: A Rapid Improvement Event is not a planning meeting or a steering group. It is an implementation event. The team does not leave with a list of recommendations. They leave with a changed process.
This is what separates an RIE from most other improvement approaches. In a standard project, analysis happens in month one, design in month two, and implementation, if it ever happens, somewhere in month four. An RIE collapses that timeline entirely. The current state is analysed on Day 1. The future state is designed and implemented by Day 4. Standard work is written and presented on Day 5.
RIE vs. DMAIC: When to Use Which
Both are legitimate improvement methodologies. The choice depends on the problem in front of you.
| Rapid Improvement Event | DMAIC Project | |
|---|---|---|
| Timeframe | 3 to 5 days | 3 to 6 months |
| Problem type | Known, bounded, visible | Complex, data-heavy, multi-variable |
| Root cause | Largely understood | Needs statistical investigation |
| Scope | One process or work area | Cross-functional or systemic |
| Output | Implemented changes | Validated solution with control plan |
| Best for | Waste elimination, flow, 5S, setup reduction | Defect reduction, variation, capability |
If you can see the waste with your own eyes during a Gemba walk, an RIE is usually the right tool. If the problem requires hypothesis testing or regression analysis to understand, a DMAIC project is more appropriate.
When to Run a Rapid Improvement Event
Not every problem is suited to an RIE. Running one on the wrong type of problem is a waste of five days and a fast way to erode trust in the method.
An RIE works best when all of the following conditions are true:
- The problem is visible. You can observe the waste, the delay, or the defect directly at the Gemba. It does not require months of data collection to confirm it exists.
- The scope is contained. The problem sits within one process, one department, or one work area. It is not a systemic issue that spans the entire value stream.
- The root cause is largely known. You may not have pinpointed every contributing factor, but the team has a working hypothesis. An RIE is not the right vehicle for open-ended root cause investigation.
- Management can release the team. Six to ten people need to be fully dedicated for the entire event. No emails, no covering their day jobs. If this is not possible, the event will fail.
- The team has authority to implement. Changes cannot require a six-week sign-off process. Leadership must grant implementation authority before the event begins.
Common Scenarios Where an RIE Delivers Results
RIEs are used across manufacturing, healthcare, financial services, and the public sector. Typical applications include:
- Reducing changeover or setup time (SMED)
- Eliminating waste in a specific work cell or service process
- Applying 5S to a work area
- Improving patient flow through a clinical department
- Reducing handoff delays between teams
- Streamlining a back-office process such as purchase order approval or new starter onboarding
The rule of thumb: if you could describe the improvement target in one sentence and measure whether you hit it with one metric, the scope is probably right for an RIE.
Step 1: Select the Process and Write the Charter
The most important decision happens before the event begins. Selecting the wrong process, or scoping it too broadly, is the single most common reason an RIE fails to deliver.
Selecting the Right Process
Use one or more of these inputs to identify where an RIE will have the most impact:
- Value stream map. Which step has the longest wait time or highest defect rate?
- KPI data. Where is performance consistently below target?
- Gemba walk observations. What waste is visible when you stand in the process and watch it?
- Team feedback. What do frontline operators say is the biggest frustration?
Prioritise processes where the pain is felt daily and the improvement would have a direct impact on output, quality, or cost. Do not pick a process because it is politically convenient. Pick it because fixing it matters.
Writing the Event Charter
Every RIE needs a one-page charter signed off by a sponsor before preparation begins. The charter prevents scope creep and ensures the team arrives with a shared understanding of the mission.
A complete charter includes:
| Charter Element | What to Include |
|---|---|
| Problem statement | What is wrong, where, and what is the impact? |
| Target metric | Specific, measurable goal (e.g. reduce lead time from 8 days to 3 days) |
| Scope boundaries | What is in scope and what is explicitly out of scope |
| Team members | Names and roles of all participants |
| Event dates | Start and end dates, including daily start and finish times |
| Sponsor | Named leader with authority to approve changes |
| Resources required | IT access, maintenance support, materials, room booking |
Critical rule: the target metric must be specific. "Improve the process" is not a target. "Reduce average handling time from 14 minutes to 8 minutes" is a target. Vague goals produce vague results.
You can use the free Kaizen Event Planner Template to structure your charter and event preparation in one place.
Step 2: Build the Right Team
The team composition determines more about the outcome than the methodology. Get this wrong and the event produces recommendations that cannot be implemented. Get it right and the changes stick because the people who own the process designed them.
Aim for six to ten participants. The ideal mix looks like this:
- 2 to 3 frontline operators from the target area. These are the people who actually do the work. Their knowledge of how the process really operates is irreplaceable.
- 1 supervisor or process owner from the area. They ensure proposed changes are practical and have the authority to sustain them after the event.
- 1 facilitator trained in Lean tools. Their job is to guide the methodology and keep the team on track, not to generate the ideas.
- 1 to 2 outside members from other departments. Fresh eyes ask "why?" without assumptions. They often spot waste that the regular team has stopped noticing.
- 1 specialist where relevant: a maintenance technician for physical changes, a quality engineer for defect-related problems, or an IT contact for system changes.
Who Should Not Be on the Team
This is equally important. Loading the team with managers who do not touch the process creates two problems. First, it signals to frontline staff that their input is secondary. Second, senior presence in the room changes the dynamic. People self-censor. Ideas get filtered before they are spoken.
Keep senior leaders informed through daily end-of-day briefings. Keep them out of the working sessions.
The American Society for Quality recommends that the majority of any Kaizen team be made up of those closest to the process, with management playing a supporting role rather than a directing one. The team that implements the change is the team that sustains it.
Step 3: Complete the Pre-Work
Poor preparation is the number one reason Kaizen events stall on Day 2. The team arrives, realises the baseline data does not exist, and spends two days collecting information that should have been gathered weeks earlier.
Start preparation two to three weeks before the event. Complete every item before the event begins.
Pre-Work Checklist
Data and documentation:
- Collect baseline metrics: cycle time, lead time, defect rate, throughput, or whatever measure your target is based on
- Document the current process in whatever level of detail is available (even a rough process map is useful)
- Gather any complaints, near-miss reports, or customer feedback related to the process
- Identify the 8 Wastes present in the process based on initial observation
Logistics:
- Book a dedicated room with wall space for the entire week. The team needs somewhere to put up maps, data, and tracking boards without having to clear them down each evening.
- Arrange cover for all team members. They cannot be pulled back to their regular work during the event.
- Confirm IT access, system permissions, and any maintenance support needed for physical changes.
- Gather supplies: sticky notes, markers, flipchart paper, stopwatches, tape, a camera for before-and-after photos.
Team preparation:
- Brief all participants on the event objectives, their role, and the daily schedule.
- Confirm that the process owner has authority to approve changes within the agreed scope.
- Walk the Gemba with the facilitator at least once before Day 1. Understand the physical layout.
The better the pre-work, the faster Day 2 moves. Teams that arrive with solid baseline data and a documented current state can move to root cause analysis by mid-morning on Day 1. Teams that arrive without it spend the first two days catching up.
Step 4: Run the Five-Day Event
The five-day format is the standard for a full-scope RIE. Smaller, well-scoped problems can be tackled in three days. The structure below applies to the full format; for a three-day event, compress Days 1 and 2 into Day 1, and Days 4 and 5 into Day 3.
Day 1: Observe and Understand
The first day is about alignment and observation. The team should leave Day 1 with a shared, data-backed picture of how the process actually works today.
Morning:
- Team kickoff: review the charter, confirm the target metric, agree on ground rules
- Brief training on relevant Lean tools: the seven or eight wastes, standard work concepts, time study methods
- Review all pre-work data as a group
Afternoon:
- Go to the Gemba. Observe the process in person. Time every step with a stopwatch. Count work in progress at each station. Draw a spaghetti diagram if operator movement is relevant.
- Document the current state with photos and video. What you see today is your baseline.
- End of day: the team reviews observations, confirms baseline measurements, and begins generating improvement ideas.
Day 2: Analyse and Design
Root cause analysis happens on Day 2. The team moves from "here is what we see" to "here is why it happens" and then to "here is what we will change."
Morning:
- Share overnight ideas. Run a 5 Whys analysis on the top defects or delays identified on Day 1.
- Use a Fishbone Diagram to map contributing causes for the biggest problem.
Afternoon:
- Draw the future state: what should this process look like once the waste is removed?
- Separate quick wins (implementable on Day 3) from longer-term changes that need more time or resources.
- Create an action log with a named owner, specific action, and deadline for every improvement item.
Day 3: Implement
This is where most improvement initiatives stall. An RIE does not let that happen.
The team spends the full day on the floor or in the process, implementing the quick wins identified on Day 2:
- Rearrange workstations or equipment for better flow
- Update standard work instructions to reflect the new method
- Fix tooling issues, label storage locations, create visual controls
- Prototype any new process flows at reduced speed before running them at full pace
- Test and time the new process. Is it faster? Are there fewer defects?
- Document every change with before-and-after photos
Do not try to roll out changes to the entire area on Day 3. The goal is proof of concept. Confirm that the change works before standardising it.
Day 4: Test and Refine
Run the new process under normal conditions. Measure it against the baseline.
- Time actual cycle times. Count errors. Track any downtime.
- Fix problems found during Day 3 testing. Adjust what is not working.
- Update standard operating procedures (SOPs) to reflect what actually happened, not just what was planned.
- Train all operators on the new standard, not just the team members who were in the room.
- Begin preparing the results presentation for Day 5.
The test on Day 4 is not optional. A change that works during a controlled pilot may behave differently under full production conditions. Day 4 is where you find out.
Day 5: Standardise and Present
The final day locks the gains in and hands the process back to the team that owns it.
Morning:
- Take final measurements and calculate improvement against the baseline metric.
- Write or update the standard operating procedure for the new process.
- Complete the 30-60-90 day action plan for any items that could not be finished during the event.
- Assign a named owner to every open action. No orphaned tasks.
Afternoon:
- Present results to leadership and the broader team. The presentation should cover:
- What the team found (current state data and waste identified)
- What they changed (before-and-after photos, process descriptions)
- What they achieved (metric improvements with data)
- What still needs to be done (open action items with owners and dates)
- What they learned (insights for future events)
Acknowledge the team publicly. An RIE is intensive work. Recognition matters.
Step 5: Sustain the Gains
This is where most Rapid Improvement Events either succeed or quietly fail. The week ends. The team disperses. The process owner returns to their regular workload. Six weeks later, the old habits have crept back in and the metric has drifted back towards baseline.
Sustaining the gains is not an afterthought. It is a phase of the event, and it requires the same discipline as the implementation itself.
The 30-60-90 Day Review Cadence
Assign a named improvement champion, typically the area supervisor or process owner, to own the follow-up and report progress. Schedule three structured reviews before the event ends:
| Review | Key Questions |
|---|---|
| 30 days | Is the new standard being followed? Are the metric improvements holding? Are all action items on track? |
| 60 days | Have open action items been completed? Are operators comfortable with the new process? Are refinements needed? |
| 90 days | Final validation that improvements are sustained. Update the value stream map to reflect the new current state. Identify the next RIE target. |
Industry benchmarks suggest targeting 80% or more of improvements sustained at 90 days as a key Lean KPI. If you are consistently below that, the issue is usually one of three things: the standard work was not written clearly enough, operators were not trained properly, or management stopped reinforcing the new method.
What Standard Work Actually Means
Writing a standard operating procedure is necessary. It is not sufficient. Standard work only holds if:
- It is posted at the point of use, not filed in a folder on a shared drive
- It is written in plain language, ideally with visual aids
- New starters are trained to it, not to the old method
- Supervisors audit adherence regularly and address deviations immediately
The A3 Problem Solving Template is a useful tool for structuring the follow-up phase. It keeps the problem statement, countermeasures, and results visible on a single page, making it easy to review at each check-in.
The gains from an RIE do not maintain themselves. They are maintained by the people who own the process, supported by leaders who check in, and reinforced by standard work that is actually used.
Common Mistakes and How to Avoid Them
Most RIE failures are predictable. They follow the same patterns. Knowing them in advance is the fastest way to avoid them.
Scope Too Wide
The team tries to fix the entire value stream in a week. By Day 3, they are overwhelmed, decisions are being deferred, and nothing has been implemented. The fix: write the scope boundary into the charter before the event begins, and hold it. If a new problem surfaces during the event, log it for a future RIE. Do not chase it now.
No Real Baseline Data
The team spends Day 1 and half of Day 2 collecting data that should have been gathered in pre-work. The event effectively becomes a two-day event. The fix: make baseline data collection a hard pre-work requirement, not an optional preparation step.
Team Members Pulled Away
The finance manager is needed for a budget call. The operator has to cover a colleague's absence. By Day 3, the team is half the size it started. Decisions stall. Momentum collapses. The fix: arrange backfill cover before the event begins and get commitment from line managers in writing. This is a non-negotiable.
No Authority to Implement
The team designs a brilliant future state and then discovers on Day 3 that every change requires a committee sign-off. The event ends with a presentation of recommendations rather than implemented improvements. The fix: confirm implementation authority with the sponsor before the charter is signed.
Gains Not Locked In
The team implements changes, writes the SOP, and presents results. Three months later, the process has drifted back. The fix: treat the 30-60-90 day review cadence as part of the event, not an optional follow-up. Assign a named owner before Day 5 ends.
For a broader look at why continuous improvement programmes lose momentum over time, the guide on why continuous improvement initiatives fail covers the systemic patterns behind the common pitfalls.
Key Tools Used in a Rapid Improvement Event
An RIE draws on a focused set of Lean tools. You do not need all of them for every event. Select the ones that fit the problem type.
| Tool | Purpose | When to Use |
|---|---|---|
| Value Stream Map | Visualise the end-to-end process and identify where waste concentrates | Day 1 current state, Day 2 future state design |
| 5 Whys | Drill down to root cause by asking "why?" five times | Day 2 root cause analysis |
| Fishbone Diagram | Map all potential contributing causes across categories | Day 2, for complex or multi-factor problems |
| Spaghetti Diagram | Track physical movement of operators or materials to identify motion waste | Day 1 Gemba observation |
| 8 Wastes Assessment | Systematically identify all waste types present in the process | Day 1, before or during Gemba walk |
| Impact vs Effort Matrix | Prioritise improvement ideas by likely impact and implementation effort | Day 2 when the team has more ideas than time |
| A3 Problem Solving | Structure the entire event on a single page: problem, analysis, countermeasures, results | Throughout, especially for follow-up |
| Standard Work Sheet | Document the new method step by step so it can be taught and audited | Day 5 standardisation |
You do not need specialist software to run any of these. A wall, some sticky notes, and a marker will do the job for most of them. The tools are a means to an end. The end is a changed process.
Running Your First Rapid Improvement Event
A Rapid Improvement Event is one of the most powerful tools in the Lean practitioner's toolkit. Not because of the methodology itself, but because it forces a decision that most organisations avoid: to stop talking about the problem and start fixing it.
The five-day format is a constraint, and that constraint is the point. It creates urgency. It forces prioritisation. It puts the people who know the process in the same room as the authority to change it, and it does not let them leave until something is different.
Start small. Your first event does not need to be a five-day blitz on your most complex process. Pick a contained, visible problem. Run a three-day event. Build confidence and competence in the method before scaling it up.
Use the templates. The Kaizen Event Planner Template covers the charter, pre-work checklist, daily agenda, and 30-60-90 day follow-up tracker in one place. The free template library has everything else you need: 5 Whys, Fishbone, A3, 8 Wastes, and more.
Build the habit. A single RIE is a project. A cadence of RIEs is a culture. The organisations that see lasting results from this method do not run one event and declare victory. They run one, learn from it, and use that learning to run the next one better. That is what Kaizen and continuous improvement actually means in practice.