Piloting the Improve Phase Without Breaking the Process
By the time a DMAIC project reaches Improve, the team has done the hard analytical work. They have defined the problem, measured the baseline, and analyzed the data well enough to know which inputs actually move the output. The temptation now is to roll out the obvious fix everywhere, claim the win, and move on. That is exactly where well-run projects fall apart.
Improve is not about deploying a solution. It is about confirming that a proposed change produces the result you expect, at scale, without creating a new problem somewhere else. In 2022, with materials lead times stretched, crews short-staffed, and every dollar under inflationary pressure, the cost of a rushed change is higher than it used to be. A fix that looks clean on a whiteboard can quietly add rework, scrap, or overtime that nobody budgeted for.
Where Improve projects go wrong
Skipping the pilot. The single most common mistake is moving straight from idea to full rollout. A pilot on one line, one shift, or one site is what separates a verified improvement from an expensive guess. Without it you have no clean before-and-after to point to.
Changing several things at once. When a team adjusts the setting, swaps the supplier, and retrains the operator in the same week, any improvement is unattributable. If results get worse, you cannot tell which change to reverse. Isolate variables so the data can actually teach you something.
Ignoring the new failure modes. Every change has side effects. Faster cycle time can raise defect rates; a cheaper input can shift the problem downstream. A quick FMEA on the proposed change surfaces these before they reach a customer.
No real measurement during the trial. Teams run a pilot but keep using gut feel to judge it. Decide the success metric, the sample size, and the decision rule before you start, so the result is not a debate about impressions.
Forgetting the people doing the work. A change that the front line did not help design will be quietly worked around the moment supervision looks away. Bring operators into the pilot; they will find the practical flaws an engineer cannot see from a desk.
How to test a change safely
Treat the pilot as a controlled experiment, not a soft launch. Pick a representative slice of the process, hold everything else steady, and run long enough to capture normal variation rather than one good day. Where you can, use a simple A/B comparison so you have a parallel control. Capture the baseline and the trial data the same way, with the same measurement system you validated back in the Measure phase.
Define the success criterion and the minimum sample before the pilot, not after.
Run a focused FMEA on the change itself to anticipate new risks.
Keep a rollback plan ready so a failed trial costs hours, not weeks.
Compare against a control, not against memory of how things used to be.
Document what you changed precisely enough that someone else could repeat it.
When the pilot confirms the gain, you carry a small, proven, low-risk change into Control with evidence behind it. When it does not, you have learned something cheaply and you adjust. Either outcome beats a confident full-scale rollout built on hope. The discipline of Improve is patience under pressure, and the pressure in 2022 made that discipline more valuable, not less.
If you are weighing a process change and want a second set of eyes on the pilot design before you commit, XNM's strategic advisory can help you test it safely and read the results honestly.