The Improve Phase: How to Test a Change Without Betting the Process on It
By the time a Lean Six Sigma project reaches the Improve phase of DMAIC, the team has earned the right to change something. Define framed the problem, Measure established a baseline, and Analyze pinned down the vital few causes driving the defect or delay. Improve is where you act — but acting carelessly here can undo all that work. The discipline of Improve is not bravery; it is testing a change so that if it is wrong, the process survives and you learn cheaply.
This mattered acutely in the recovery period after 2020, when many processes were already stressed by supply disruption and thin staffing. A failed full-scale rollout in that environment was not a tidy lesson — it was a real outage. Piloting first was less a best practice than a survival tactic.
Generate solutions that target the proven cause
Improve begins with options, not a single answer. Because Analyze identified the root causes with data, your candidate solutions should each map back to one of them. Resist solutions that merely feel productive but do not attack a verified cause. A short, honest list usually beats a long wish list:
List several distinct ways to address each vital cause, not one favourite.
Screen them against effort, cost, and risk to the rest of the process.
Favour changes that are reversible — if it fails, you can step back cleanly.
Test before you commit
The heart of a safe Improve phase is the pilot. You run the change on a deliberately limited slice — one line, one shift, one region — long enough to gather real data, and you compare it against the baseline you captured in Measure. The point is to let the numbers, not enthusiasm, decide.
Define success before you start. State the target metric and the threshold that counts as an improvement. Decide this in advance so you cannot rationalize a weak result after the fact.
Pilot on a contained scope. Limit the blast radius. A pilot lets you observe the change against the same conditions Measure recorded, without exposing the whole operation to an unproven idea.
Use a design of experiments where it fits. When several factors interact, a structured experiment tells you which ones actually move the outcome — far more reliably than changing one thing at a time and guessing.
Confirm the gain is real. Compare pilot results to the baseline with the same measurement system. A difference that could be ordinary variation is not yet a win; look for a change that holds up.
Plan the failure path. Before scaling, write down how you would roll back and what early signal would trigger it. Knowing the exit makes the experiment safe to run.
Only once the pilot proves the gain do you widen the change. Even then, scale in steps and keep watching the metric. A solution that worked on one shift can behave differently across the whole operation, and catching that early is far cheaper than discovering it after full rollout.
Hand a stable change to Control
Improve is not finished when the numbers look good once. Before the project moves to Control, document the new way of working, update the standard, and define what people should monitor to know the gain is holding. A change that improves the process but cannot be sustained is a problem deferred, not solved. The goal of Improve is a proven, repeatable change that the next phase can lock in.
If your organization is ready to improve a critical process without gambling on an untested fix, XNM's strategic advisory can help you pilot and prove changes with confidence.