Measuring What Matters: A Plant's Lesson in Not Drowning in Data
A mid-sized fabrication shop kicked off a Six Sigma project in early 2022 to cut the time a customer order spent waiting before it reached the floor. Like a lot of teams that winter, they were already stretched: two machinists short, steel prices climbing, and half the office still rotating between home and the plant. The project champion wanted hard numbers, so the team did what eager teams do in the Measure phase — they tried to measure everything.
Within three weeks they had eleven spreadsheets, a time-stamp log nobody trusted, and a stalled project. This is the most common way the Measure phase goes wrong: confusing more data with better data. Here is what the team learned by starting over.
Measure the problem, not the universe
DMAIC puts Measure second for a reason. Define gave them a problem statement: orders wait too long between entry and release to the floor. That single sentence tells you exactly what to measure — the elapsed time from order entry to floor release, and the things that plausibly drive it. It does not tell you to log machine temperatures, overtime hours, or supplier lead times, however interesting those are. The team had been collecting data that belonged to three different projects at once.
When they rewrote their data-collection plan around the one output they cared about, the eleven spreadsheets collapsed to two: a timestamp at order entry and a timestamp at floor release. Everything else was a candidate cause to test later in Analyze, not something to drown in now.
A data-collection plan beats a data dump
A good Measure phase is built on a short, explicit plan agreed before anyone touches a stopwatch. The team's second attempt answered five questions on a single page:
What is being measured? The exact metric — here, elapsed hours from order entry to floor release — with an operational definition so two people clock the same order the same way.
How is it measured? Pulled from the ERP timestamps, not hand-written, to remove the transcription errors that had poisoned the first log.
How much do we need? Enough to see the real variation, not a census. They sampled four weeks of orders rather than trying to capture every job forever.
Who collects it and when? One named person, on a fixed daily pull, so collection did not depend on whoever remembered.
Is the measurement trustworthy? A quick check that the ERP clock and the floor's clock agreed — a basic guard against measuring noise instead of signal.
That last point matters more than teams expect. Before you trust a number, you have to trust the gauge that produced it. In Lean Six Sigma this is measurement-system analysis, and skipping it is why the team's first time-stamp log was useless: two people reading two different clocks were never going to agree.
Let the data describe before it decides
With clean data in hand, the team resisted the urge to jump to root causes. The Measure phase is for establishing a baseline and understanding current variation — not for fixing anything yet. They plotted the elapsed times over the four weeks and found something the spreadsheets had hidden: the average wait was tolerable, but a fifth of orders sat for days because they stalled at a single credit-check step that nobody had flagged. That insight came from looking at the spread, not just the mean.
The lesson for any 2022 team working short-staffed and under cost pressure is the same: data collection is expensive, in hours you do not have. Spend that effort narrowly. Measure the one output your problem statement names, prove the gauge is trustworthy, take enough data to see real variation, and stop. A focused half-page plan will tell you more than eleven spreadsheets ever will, and it leaves you the energy to actually fix the problem in the phases that follow.
If your improvement projects keep stalling in measurement, XNM's strategic advisory can help you scope what to measure and turn the numbers into decisions.