Execution Method Triage

Definition

Not every improvement deserves the same execution machinery. The book classifies every countermeasure on a transformation plan into one of three tracks based on complexity and risk: "just-do-its" (JDI) — low-risk, same-day fixes needing no cross-functional coordination; "kaizen events" (KE) — two-to-five-day focused sprints for medium-complexity redesigns; and "projects" (PROJ) — traditional project management for anything capital-intensive, technically complex, or touching external customers and suppliers.

In the Book

Chapter 5 lays out the three categories with concrete examples: just-do-its cover things like hanging clarifying signage, moving equipment, or discontinuing an already-agreed-upon review step — simple experiments run through a mini-PDSA cycle where the team can just try it and see. Kaizen events suit process-flow redesign and standard-work development, and the book notes that closely related kaizen bursts on the future-state map are often grouped into a single event for efficiency. Projects are reserved for cases needing extensive data analysis, capital investment, technology changes, or external stakeholder impact, and the book adds a fourth intermediate tool — the "rapid planning event" (RPE) — as a kaizen-event-like first step to build a detailed execution plan before a large or complex project formally begins. The book is equally clear about what's deliberately excluded from this plan: "daily kaizen" (small continuous-improvement behavior, sometimes called "kata") is treated as an ongoing organizational habit, not a line item to schedule and track, so the transformation plan stays focused on the resource-intensive changes that actually need tight time-bound management.

Why It Matters

Running every improvement through the same heavyweight process wastes effort on the trivial ones and under-resources the complex ones; running everything as an informal "just try it" under-serves anything that's genuinely risky or cross-functional. Triaging by complexity and risk before choosing a method — rather than defaulting to whatever process the organization already knows — keeps small fixes fast and big fixes properly managed, a distinction useful anywhere a backlog mixes trivial and substantial changes under one label.