Chasing the Wrong Cause: A Lesson from the Analyze Phase
In DMAIC — Define, Measure, Analyze, Improve, Control — the Analyze phase is where improvement projects either earn their keep or quietly go astray. Its job is narrow and important: confirm the real driver of the problem before anyone spends money fixing it. Teams that skip the rigour here often improve something, just not the thing that mattered. Here is an anonymized example from a regional fulfilment operation, working through the supply pressures still gripping early 2021, that nearly fixed the wrong cause.
The obvious answer
The problem was clear in the Measure data: roughly a third of orders were shipping late, and late shipments had been climbing for months. The operations team had a confident explanation. The warehouse was short-staffed — pandemic absences, a tight labour market, people picking orders slower than before. Everyone agreed. The proposed fix was to hire temporary pickers and add an evening shift, a real expense the team was ready to approve.
The Green Belt running the project asked for one thing before the budget moved: prove it. Not because staffing felt wrong, but because the Analyze phase exists precisely to test the cause everyone already believes.
What the analysis actually showed
The team stratified the late orders rather than treating them as one undifferentiated pile. They broke lateness down by product category, by supplier, by order size, and by where in the process the delay occurred. Three findings reshaped the project:
Picking time per order had barely changed year over year — the staffing theory predicted a clear rise that the data did not show.
Late orders clustered hard around a single product family sourced from two suppliers whose inbound deliveries had become erratic.
The delay was concentrated upstream, at receiving and putaway, not at picking and packing where the staffing fix was aimed.
A scatterplot of staffing levels against daily lateness showed almost no relationship. A Pareto chart of delay by cause put inbound supply variability far out in front. The obvious culprit — slow picking — was a comfortable story that the evidence simply did not support. The real driver was sitting one step upstream, in unreliable replenishment of a specific product family.
Why the Analyze phase earns its place
Had the team acted on intuition, they would have spent real money adding picking capacity and watched lateness barely improve, because picking was never the bottleneck. Instead, the Improve phase targeted the genuine cause: safety stock on the affected product family, a second source for the worst-performing supplier, and tighter inbound scheduling. Lateness fell within two cycles, at a fraction of the cost of the staffing plan.
Separate symptom from cause. Late orders were the symptom. Slow picking was a plausible cause but not the verified one. Analyze exists to close that gap with data, not assumption.
Stratify before you conclude. A single average hides the pattern. Breaking the defect down by category, supplier, and process step is what exposed where the problem truly lived.
Let the data overrule the loudest opinion. The staffing theory was unanimous and wrong. A scatterplot and a Pareto chart settled it more honestly than any meeting could have.
The discipline of Analyze is not academic. It is the difference between spending your improvement budget on the cause that feels right and spending it on the cause that is right. Confirm the driver first; the fix is easy once you are aiming at the correct target.
When the obvious cause is costing you and the real one is hiding upstream, XNM's strategic advisory can help you find the driver before you spend on the fix.