Design a Kaizen event for this improvement opportunity: [PROBLEM AND TARGET]. The process begins and ends at [PROCESS BOUNDARY]. Current performance and evidence are [CURRENT STATE DATA]. The event participants and decision makers are [TEAM AND ROLES]. Available event time, implementation limits, and safety or compliance constraints are [CONSTRAINTS AND TIMELINE]. Create a plan for an actual working session, not a generic Lean overview. Do not assume savings, capacity, customer impact, or root causes that the data does not support. Preserve safety, quality, labor, privacy, and regulatory controls; do not frame removing a required control as waste. Produce: 1. A one-page event charter: problem, measurable target, scope, out-of-scope items, sponsor, team, and decision rights. 2. A day-by-day agenda with time blocks for observing work, mapping the current state, identifying waste, testing countermeasures, and reporting out. 3. A current-state data collection plan with baseline metrics, observation method, sample size or period, and evidence owner. 4. A root-cause and prioritization method using direct observation, 5 Whys where appropriate, and impact-effort-risk scoring. 5. A future-state design with standard work changes, needed materials or system changes, and a pilot plan. 6. An action register listing task, owner, due date, dependency, approval needed, and proof of completion. 7. A 30-60-90 day sustainment plan with process measures, outcome measures, audit cadence, escalation trigger, and named review owner. Before answering, check that every action has an owner and verification method and that the target is measurable within the process boundary. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROBLEM AND TARGET] | Describe the problem and the measurable improvement target, including the deadline if known. | Reduce new-hire laptop readiness failures from 18% to under 5% within 60 days. |
| [PROCESS BOUNDARY] | State where the process starts and ends and which related processes are excluded. | From signed offer entering HRIS through laptop delivery on the employee's first day; excludes recruiting and long-term IT support. |
| [CURRENT STATE DATA] | Provide baseline metrics, observations, process steps, and known sources of variation. | Last 40 hires: 7 lacked a ready laptop. Handoffs occur among HR, IT procurement, identity management, and shipping; request timing varies from 3 to 14 days. |
| [TEAM AND ROLES] | List participants, sponsor, frontline roles, process owner, and decision makers. | Sponsor: People Operations director. Participants: HR coordinator, IT service desk lead, procurement analyst, identity admin, and office manager. IT director approves system changes. |
| [CONSTRAINTS AND TIMELINE] | Enter available days, budget, implementation restrictions, and safety, quality, or compliance requirements. | Two-day event next month, no new software purchase, SOC 2 access controls must remain, pilot can cover 10 hires. |
How to use
- Bring a current process map and baseline data, even if both are incomplete.
- Paste the prompt and confirm that the event scope excludes work the team cannot change.
- Assign action-register owners during the event rather than after the report-out.
- Follow up with: "Create a facilitator script and printable observation sheet for Day 1."
Variations
Kaizen charter
Use this when leadership needs to approve the event before detailed planning.
Draft a Kaizen event charter for [PROBLEM]. The target is [MEASURABLE TARGET], the boundary is [SCOPE], and the sponsor and participants are [TEAM]. Available time and restrictions are [CONSTRAINTS]. Produce a one-page charter with business reason, baseline, target, in-scope and out-of-scope work, required data, risks, decision rights, and expected deliverables. Do not estimate financial benefits without data. Check that the target has a metric, deadline, and accountable process owner.
Daily management
Use this after a Kaizen event to keep improvements from fading.
Create a daily-management plan for this improved process: [PROCESS]. The new standard work is [STANDARD WORK], target measures are [MEASURES], and the owner roles are [OWNERS]. Provide a visual board layout, daily huddle agenda, threshold rules, escalation path, weekly audit checklist, and 30-day review. Distinguish leading process measures from outcome measures. Do not add metrics nobody can collect during normal work. Check that every threshold has a named responder and a defined first action.
Rapid improvement
Use this for a one-day event focused on a low-risk, local process change.
Plan a one-day rapid improvement event for [LOCAL PROBLEM] in [WORK AREA]. Current evidence is [BASELINE], participants are [PARTICIPANTS], and constraints are [CONSTRAINTS]. Create an hour-by-hour agenda, observation checklist, simple cause-ranking method, two pilotable countermeasures, implementation checklist, and seven-day follow-up. Keep changes within the team's authority and preserve required controls. Check that each proposed pilot can be reversed safely and measured against a baseline.
Tips
- Choose a process that has one accountable owner and a measurable local target; broad culture problems are not good event scopes.
- Observe actual work across normal variation, such as busy periods and different shifts, before redesigning the process.
- Treat a future-state map as a testable hypothesis until a pilot shows it improves the target without harming quality or safety.
- Schedule the 30-day review before the event ends, with the metric owner present.
FAQ
How long should a Kaizen event last?
Many events run three to five days, but a tightly scoped improvement can be planned in one or two days. The follow-up period matters more than the workshop length.
What should the team measure?
Use one primary outcome metric, such as turnaround time or defect rate, plus process measures that show whether the new work is actually being followed.
Can a Kaizen event remove approval steps?
Only after confirming the step is not required for safety, quality, legal, financial, or control reasons. Simplifying an unnecessary handoff is different from removing a required safeguard.