LeanInsight Library

Running Lean Improvement Projects: From Scope to Verified Results

lean-tools-and-methods

Lean Tools and Methods

Master the specific tools and techniques that make lean manufacturing work in practice, from visual management and poka-yoke to kanban, SMED, and the full RCA toolkit, with implementation guidance for every tool on the shop floor.

Author

Vibhav Jaswal

Vibhav Jaswal

Content Architect

Vibhav Jaswal is a content architect who turns complex technical subjects into clear, well-organized knowledge systems. With a background in graphic design and project management, he focuses on breaking down intricate concepts and connecting them in ways that make sense to the reader, from first principles all the way through to practical application. His work spans educational content, visual resources, and product documentation. At LeanSuite, he applies this to lean manufacturing, building structured content that helps production teams understand and implement the tools and methods that drive operational improvement.

Articles by Vibhav Jaswal

Published

Updated

Reading Time

19 mins

Running a lean improvement project means managing the full lifecycle from problem definition and scope agreement through team assembly, execution, and verified results, with documented accountability at every stage so the improvement holds after the project closes and the team disperses. The lean improvement project lifecycle is not a variation of general project management. It is a discipline specific to manufacturing improvement work, shaped by the constraints of production schedules, cross-functional team availability, gemba-based verification, and the requirement that every result be confirmed with data rather than assumed from activity.

The Project Management Institute identifies clarity of scope and documented role assignments as the two most critical factors in project success. Lean manufacturing teams routinely skip these in the urgency to start executing. The consequence is predictable: projects that begin without defined scope absorb adjacent problems and run out of time. Projects that begin without documented accountability produce results that nobody is accountable for sustaining.

This blog covers the lean improvement project lifecycle as a complete execution system, connecting each phase to the specific lean project management tools that govern it.

Phase 1: Initiation: Scope Definition and Project Charter

Every lean improvement project begins with a scope definition conversation, not with a team assembled and ready to work. Assembling the team before the scope is clear wastes cross-functional time and produces the most common failure mode in manufacturing improvement: the scope expansion that makes the original objective undeliverable.

Defining the Problem Statement

The project charter begins with a problem statement that describes the specific operational gap the project will close. A valid problem statement has three components: what is currently happening, what should be happening instead, and how large the gap is in measurable terms.

A problem statement that reads "defect rate at the final assembly station is running at 4.7 percent against a customer specification of 1.5 percent, generating an estimated $38,000 in monthly rework cost" is complete. It defines the current state, the target state, and the financial magnitude of the gap. A problem statement that reads "improve quality" is not a scope definition. It is a direction.

Setting the Project Target

The project target is the single measurable outcome that will confirm the project has been delivered. It connects directly to the problem statement and defines the verification criterion for project closure. The target should specify:

  • The metric being improved
  • The target value
  • The verification date and method

One metric. One target value. One verification date. Projects with multiple primary metrics have multiple unresolved scope decisions embedded in them.

Defining the Scope Boundary

The scope boundary specifies what the project will not address. Every improvement project generates adjacent improvement opportunities as the investigation proceeds. Without an explicit boundary, these adjacent opportunities pull the team away from the primary objective.

The scope boundary is written as a constraint: "This project will address the inspection sequence defect at Station 7 only. Material supplier quality, incoming inspection, and the adjacent deburring process are outside scope and will be captured for separate projects."

Key Insight: A scope boundary is as important as a scope definition. Without it, every new finding expands the project until it cannot be completed.

Phase 2: Planning: Team Assembly and RACI

With scope defined and the project target established, the next phase assembles the team and builds the accountability structure that will govern execution. The planning phase produces two documents: the team roster and the RACI matrix.

Assembling the Right Team

The improvement project team should include the people closest to the problem, the people with authority to approve changes, and the specialists whose expertise the improvement requires. The team composition rule is the same regardless of project type:

  • Operators or technicians who run the process being improved
  • An engineer or analyst with technical depth on the process
  • A quality representative where quality is the improvement target
  • A maintenance representative where equipment is involved
  • A project lead who owns the project accountability

Operators are not optional. An improvement project that excludes the people who run the process produces solutions that work in theory and fail on the shop floor.

Building the RACI Matrix

The [RACI Matrix in Lean Manufacturing: Roles, Accountability, and Clarity] is the planning phase's primary accountability tool. For every major project deliverable, the RACI assigns:

  • One Responsible party who does the work
  • One Accountable party who approves the result
  • The Consulted parties whose expertise is required before decisions are made
  • The Informed parties who receive updates at defined milestones

The RACI is built collaboratively with the team present. Disputes about accountability that surface during RACI construction are disputes the team resolves before execution begins. This is far less costly than resolving the same disputes during the project when schedule pressure makes every conflict more urgent.

Key Insight: RACI disputes surface in the planning phase or during execution. Planning phase resolution costs an hour. Execution phase resolution costs a week.

Phase 3: Execution: Investigation and Implementation

The execution phase covers everything from the first gemba observation to the final implemented change. For most lean improvement projects, execution has two distinct stages: investigation and implementation. The boundary between them is the root cause confirmation. Implementation does not begin until the team has confirmed what it is solving.

Investigation: Confirming the Problem at the Gemba

Investigation starts at the gemba with direct observation of the process generating the problem. The 5G Methodology (五現主義: Gemba, Gembutsu, Genjitsu, Genri, Gensoku) provides the physical investigation framework that ensures the team is working from confirmed evidence rather than reports and assumptions.

The investigation produces a confirmed root cause specific enough that countermeasures addressing it would prevent the problem from recurring, not reduce its frequency. An investigation that produces "operator error" as a root cause has not been completed. An investigation that produces "the go/no-go gauge at Station 7 is worn beyond tolerance, allowing parts outside specification to pass inspection" is complete.

The [A3 Report as a Project Management Tool: From Problem to Solution] documents the investigation, captures the root cause, and connects it to the countermeasures that will address it. The A3 is the investigation record that any stakeholder can read to understand the current state of the project without requiring a status meeting.

Implementation: Executing the Countermeasures

Implementation converts confirmed countermeasures into completed changes. Each countermeasure from the A3 becomes a task in the implementation plan with a named owner, a completion date, and a verification method. Implementation tasks that lack named owners are not implementation tasks. They are intentions.

Implementation velocity matters. The longer the time between root cause confirmation and countermeasure execution, the more organizational attention shifts to the next priority. Lean improvement projects that take months to implement confirmed countermeasures lose their momentum and frequently stall at 60 to 70 percent completion.

Key Insight: Implementation stops at confirmed countermeasures, not at activity. A change made without a verified connection to the root cause is a workaround.

Phase 4: Verification: Confirming the Result

Verification is the phase that most lean improvement projects skip or abbreviate. An improvement is implemented, the team moves to the next project, and no one confirms whether the improvement delivered what the project charter specified. The project is treated as closed. The result is assumed.

The 30-Day Verification Measurement

Verification uses the metric specified in the project target to confirm the result at a defined point after implementation, typically 30 days, long enough for normal production variation to confirm whether the improvement holds under real operating conditions.

The 30-day verification answers one question: has the metric reached the target specified in the project charter? If yes, the project result is confirmed. If no, the project re-enters the investigation stage to determine whether the root cause was correctly identified, the countermeasures were fully implemented, or a condition not visible during the initial investigation is generating the problem.

Standard Work Update as Verification Prerequisite

No lean improvement project is closed until the standard work for the affected process is updated to reflect the improved method. Standard work update is not an administrative closure task. It is the mechanism that makes the improvement permanent rather than temporary.

An improvement that is not captured in standard work will erode as operators return to previous habits, new operators are trained to the old method, and supervisors lose visibility into what the correct process looks like. The improvement's half-life without standard work update is typically measured in weeks. [Standard Work in Manufacturing: A Complete Guide] covers how standard work is written, validated, and maintained.

Key Insight: Standard work update is a verification prerequisite, not a closure formality. The improvement does not exist until it is in the standard.

Phase 5: Closure and Yokoten

Project closure formalizes two outcomes: the confirmed result and the organizational learning the project produced. Both have direct value to the manufacturing improvement program.

Closure Documentation

Closure documentation captures the project outcome in a format that future teams can reference. The A3 report, completed through the Follow-Up section, is the primary closure document for lean improvement projects. A completed A3 shows the problem, the investigation, the countermeasures, and the verified result on one page.

The closure document should also capture the 30-day action list status, confirming that all items on the list were completed by their assigned owners or explicitly deferred to a separate project with a named owner.

Lessons Learned and Yokoten Deployment

Every completed lean improvement project produces organizational learning: what the root cause was, what countermeasures worked, what the investigation revealed about the process. The Kanban Tool lean project management framework notes that traditional lessons learned events happen after the project closes and miss the opportunity to improve work already in progress. Lean improvement programs capture lessons during the project and apply them immediately.

Yokoten (横展) is the lean practice of horizontally deploying confirmed improvements from one process or facility to all other processes and facilities where the same condition exists. A completed improvement project is not done when the originating process is fixed. It is done when every process with the same root cause condition has been addressed or assessed.

[Standard Work in Manufacturing: A Complete Guide] covers the yokoten deployment mechanism. The [Lean Project Management: Applying Lean Principles to Improvement Projects] overview covers how yokoten connects to the lean principle of pursuing perfection: the recognition that an improvement at one location is an improvement opportunity at every location where the same waste exists.

Key Insight: Yokoten converts a single project result into a program-level result. An improvement that stays local is an improvement running at partial return.

Within the Lean System

Connection to Lean Principles

Running lean improvement projects operationalizes all five lean principles simultaneously. Value is defined in the problem statement. The value stream is mapped during the investigation phase. Flow is created by eliminating the waste the project targets. Pull is applied to project sequencing through the [Prioritization Matrix in Lean Manufacturing: Impact vs Effort] that determines which project enters execution based on capacity. Perfection is pursued through yokoten, which spreads the confirmed improvement to every location where the same waste exists. The [5 Core Principles of Lean Manufacturing] are not abstract philosophy in a functioning lean improvement program. They are the operating logic of every project executed within it.

Connection to Lean Tools

The lean improvement project lifecycle integrates the full lean project management toolkit. The [Prioritization Matrix in Lean Manufacturing: Impact vs Effort] selects the project. The [RACI Matrix in Lean Manufacturing: Roles, Accountability, and Clarity] governs accountability. The [Kaizen Event as a Project: Scoping, Executing, and Closing Improvement Events] or the [A3 Report as a Project Management Tool: From Problem to Solution] provides the execution structure. The [Yamazumi Chart: Workload Balancing for JIT Production Lines] is available where the improvement targets operator workload distribution. Standard work closes the loop between the improvement and the production system. Together these tools cover the full lifecycle without duplication or gap.

Connection to Continuous Improvement

The lean improvement project lifecycle is the operational expression of the [PDCA Cycle: The Foundation of Continuous Improvement]. The initiation and planning phases are the Plan. The execution phase is the Do. The verification phase is the Check. Closure and yokoten are the Act: standardizing the improvement and spreading it. Each completed lean improvement project is also the starting point for the next project: the lessons learned identify where improvement opportunities remain, the yokoten assessment identifies where the same problem exists in other processes, and the closure documentation provides the template that makes the next project start faster and execute more reliably than the last.

Frequently Asked Questions

What is a lean improvement project lifecycle? A lean improvement project lifecycle is the structured sequence of phases through which a manufacturing improvement initiative moves from problem identification to verified result. The five phases are initiation (scope definition and charter), planning (team assembly and RACI), execution (investigation and implementation), verification (30-day result confirmation and standard work update), and closure (documentation and yokoten deployment).

Why do lean improvement projects fail to sustain their results? Lean improvement projects most commonly fail to sustain results because standard work is not updated to reflect the improved process, the 30-day verification measurement is not conducted, implementation tasks are not assigned to named owners who are accountable for completion, or the root cause was not correctly identified and the countermeasure addressed a symptom rather than the cause.

What is the difference between project completion and project closure in lean? Project completion means the implementation tasks are finished. Project closure means the result is verified against the project target metric and standard work is updated to capture the improvement. A project can be completed without being closed. The change has been made but the result has not been confirmed and the improvement is not yet permanent.

How does yokoten apply to lean improvement project closure? Yokoten is the practice of horizontally deploying confirmed improvements to all other processes or facilities where the same root cause condition exists. After a lean improvement project closes with a verified result, the team assesses which other processes, lines, or sites have the same problem. Each identified location either adopts the confirmed countermeasure directly or conducts its own investigation to confirm applicability before deploying.

What documents should a lean improvement project produce? A lean improvement project produces a project charter (problem statement, target, scope boundary, team roster), a RACI matrix (accountability for every major deliverable), an A3 report (investigation record from problem definition through verified result), an updated standard work document reflecting the improved process, and a closure record confirming the 30-day verification measurement and yokoten assessment.

LeanSuite: A complete lean manufacturing software

Schedule Demo
Blog Banner