You remember the rollout. The CEO came back from a conference in
Scottsdale where somebody told him that General Electric had saved
twelve billion dollars with Six Sigma, and by Monday morning your
company was going to be a Six Sigma organization too. The consulting
firm arrived with binders. The binders arrived with certifications. The
certifications arrived with colored belts — yellow, green, black, master
black — as if your quality department had secretly been a martial arts
dojo this entire time and nobody had thought to mention it.
Training sessions were scheduled. People were pulled off lines and
put into classrooms where they learned the DMAIC framework: Define,
Measure, Analyze, Improve, Control. They learned about normal
distributions and standard deviations. They learned that “six sigma”
meant 3.4 defects per million opportunities, a number that sounded so
impressively precise that nobody thought to ask whether it was actually
relevant to anything your company made. They did Minitab exercises. They
ran Monte Carlo simulations on laptop computers that took seven minutes
to boot. They were given project charters and told to find savings.
And for a while — maybe six months, maybe a year — it worked. People
were excited. Projects were launched. Savings were reported. The VP of
Quality stood up at the annual meeting and showed a slide that said
“$4.2 million in certified savings” and the board applauded and the
consulting firm sent a fruit basket.
Then the slides went into the drawer. The Minitab licenses expired.
The black belts got promoted into other roles or left for other
companies. The project tracker stopped being updated. The control plans
that were supposed to sustain the improvements were filed in a
SharePoint site that nobody could navigate. And the variation you had
supposedly reduced? It came back. Not all at once — not dramatically —
but slowly, the way a river finds its old bed after you stop maintaining
the levee.
This is the story of Six Sigma DMAIC in most organizations. Not the
success story they tell at conferences, but the real one — the one where
a powerful statistical methodology was transformed into a credentialing
program, a reporting exercise, and eventually a punchline.
The Framework That Wasn’t
Wrong
Let’s be clear about something before we go further: DMAIC is not the
problem. Define, Measure, Analyze, Improve, Control is a perfectly
rational sequence of steps for solving a process problem. It’s older
than Six Sigma itself — it’s essentially the scientific method applied
to manufacturing, and it traces its lineage back through Deming’s PDCA
cycle and Shewhart’s work at Western Electric. The logic is sound. You
define what matters. You measure how you’re doing. You analyze what’s
driving the variation. You improve the process. You control it so the
gains stick.
The framework is right. The execution is where everything falls
apart.
Define:
Where the Project Charter Becomes a Creative Writing Exercise
The Define phase is supposed to answer a simple question: what
problem are we solving, and why does it matter to the business? A good
project charter names the defect, quantifies the financial impact,
identifies the process boundaries, and defines the customer. It takes
maybe half a day to write a good one if you actually understand the
problem.
But in most Six Sigma deployments, the project charter becomes a
sales document. The financial impact gets inflated because the black
belt needs to hit a savings target to maintain their certification. The
problem statement gets worded to fit within the boundaries of what the
team thinks it can actually solve, rather than the boundaries of the
actual problem. The scope gets narrowed to exclude the messy political
parts of the process — the supplier who is the CEO’s golf buddy, the
equipment that the plant manager just bought against the quality team’s
advice, the product design that everyone knows is the real source of the
defects but nobody is allowed to criticize.
So the charter gets written. It gets approved. And the project begins
solving a problem that is adjacent to — but not actually — the problem
that matters.
This is the first failure mode of DMAIC: the Define phase becomes an
exercise in defining a problem that is solvable within the
organizational politics rather than a problem that is worth solving. The
team is set up to succeed against a target that was designed to be
hit.
Measure: Where the Gage
R&R Gets Buried
The Measure phase is where things get technical — and where things
get quiet. Because the Measure phase requires you to confront an
uncomfortable truth: you don’t actually know what your measurement
system is telling you.
A proper Measure phase starts with a Measurement System Analysis. You
need to know that the data you’re about to analyze is trustworthy. You
need to know that your gage R&R — the repeatability and
reproducibility of your measurement — is acceptable. You need to know
that your operators measure the same part the same way. You need to know
that your instruments have enough resolution to detect the variation
you’re trying to reduce.
But here’s what actually happens: the team runs a gage R&R study,
finds that the measurement system contributes 40% of the total variation
— which is catastrophically bad — and then has a choice. They can stop
the project and fix the measurement system first (which could take
months and involves buying new equipment, retraining operators, and
re-validating procedures), or they can note the inadequacy in the
project file, add a footnote to the final report, and continue with the
analysis using the flawed data because the project deadline is in six
weeks.
Almost nobody stops. Almost nobody fixes the measurement system.
Almost every Six Sigma project in the history of corporate deployments
has been built on measurement data that the team knew — or should have
known — was not trustworthy. The analysis that follows is therefore a
statistical exercise performed on unreliable numbers, which produces
conclusions that carry the weight of mathematical rigor without the
foundation of empirical truth.
This is not a minor point. This is the entire ballgame. If your
measurement system is broken, every subsequent phase of DMAIC is built
on sand. Your control charts show special-cause signals that are really
just gage noise. Your hypothesis tests find differences that don’t
exist. Your regression models identify factors that aren’t real. And
your improvement — whatever it is — can’t be verified because you can’t
measure well enough to confirm it worked.
Analyze: Where the
Statistics Become Theater
The Analyze phase is the showpiece of Six Sigma. This is where the
black belts earn their belts — running hypothesis tests, ANOVA tables,
regression analyses, and DOE (Design of Experiments) to identify the
root causes of variation. This is the phase that gets presented to
leadership, complete with Pareto charts and fishbone diagrams and
scatter plots with trend lines and R-squared values.
The problem is that the analysis is only as good as the data (which
we’ve already established is suspect) and only as honest as the team
running it (which is under pressure to produce actionable findings
regardless of whether the data supports them).
In practice, the Analyze phase becomes a confirmation bias exercise.
The team enters the project with a hypothesis — they usually know what’s
wrong before they start, because the people on the line have been
telling them for months. The statistical analysis is then conducted in a
way that confirms the hypothesis. If the p-value is below 0.05, it’s
presented as proof. If the p-value is above 0.05, the team re-specifies
the model, transforms the data, removes outliers, or switches to a
different test until the p-value cooperates.
This is not malice. It’s human nature under deadline pressure. But it
means that the Analyze phase — which is supposed to be the intellectual
core of DMAIC, the part where data replaces opinion and science replaces
gut feel — becomes another form of opinion wearing a statistical
costume. The conclusions were determined before the first data point was
collected. The analysis just provided the footnotes.
And the real root causes — the ones that live in the gaps between
departments, in the supplier’s process, in the equipment design, in the
fundamental physics of the manufacturing process — go unexamined because
they’re hard to model in Minitab and impossible to present on a single
PowerPoint slide.
Improve:
Where the Solution Becomes Whatever Was Already Planned
The Improve phase is where the team implements changes to the process
based on the analysis. In theory, this is where the breakthroughs happen
— where the team pilots a new approach, validates it with a structured
experiment, and rolls it out with documented evidence that it works.
In practice, the Improve phase usually produces the solution that was
obvious before the project started. The team installs a fixture that the
maintenance department had requested two years ago. They update a work
instruction that had been wrong since the process was launched. They add
an inspection step that catches the defect before it reaches the
customer. They change a supplier that everyone knew was substandard.
They adjust a machine parameter that the operator had been flagging for
months.
None of these are bad changes. Most of them are genuinely helpful.
But none of them required a six-month Six Sigma project with a black
belt, a green belt, three team members, weekly meetings, a project
charter, a Minitab license, and a 47-slide final report to identify.
They were known issues that had been sitting in the suggestion box, the
maintenance log, and the operator’s verbal complaints since the process
began.
The Six Sigma project didn’t discover these solutions. It provided
the organizational mechanism — the budget, the cross-functional
authority, the management attention — to actually implement changes that
the existing system should have been capable of making on its own. The
DMAIC framework was a workaround for a broken improvement culture, not a
source of new insight.
And the savings? The reported financial impact of the improvement is
almost always overstated. The baseline gets set high. The
post-improvement performance gets measured during a honeymoon period
when everyone is paying attention. And the savings calculation includes
soft costs — avoided rework, theoretical capacity gains, projected
defect reductions — that would impress an accountant but wouldn’t
survive a cash flow audit.
Control: Where the
Sustainability Dies
The Control phase is supposed to ensure that the improvements stick.
You update the control plan. You revise the FMEA. You implement
statistical process control with control charts. You establish a
monitoring system. You hand off to the process owner. The gains are
locked in.
Except they’re not. Because the Control phase is the last thing
everyone wants to do after six months of project work. The team is
tired. The black belt has two more projects queued up. The process owner
has been operating without the improvement for years and doesn’t see why
they need to change their routine now. And the control chart that was
supposed to be reviewed daily gets pinned to the bulletin board next to
the safety training schedule and the holiday potluck sign-up sheet,
where it yellows in the fluorescent light until someone takes it down to
make room for the next quarter’s safety poster.
Within three to six months, the process drifts back to its
pre-project state. Not all at once. Not dramatically. But the operator
who was trained on the new procedure quits and the replacement gets a
five-minute explanation from a supervisor who wasn’t involved in the
project. The new fixture gets damaged and maintenance “temporarily”
removes it. The supplier that was supposed to be qualified still hasn’t
submitted their PPAP. The control chart stops being updated when the
quality engineer goes on vacation and nobody picks it up.
And the variation — the variation that was the entire point of the
project — returns to its previous level. The defects come back. The
customer complaints resume. And the next time someone proposes a Six
Sigma project to solve the same problem, the organizational memory has
been conveniently wiped clean by turnover and time.
The Credentialing Trap
The deepest problem with Six Sigma DMAIC in most organizations is not
that the methodology is flawed — it’s that the methodology has been
captured by a credentialing industry that profits from certifications
rather than results.
The belt system — yellow, green, black, master black — creates a
hierarchy of expertise that is measured by training hours and exam
scores rather than by actual process improvement. The certification
bodies require projects as part of the portfolio, which means that
projects are initiated not because they matter but because someone needs
a project to get promoted. The consulting firms that run the training
have a vested interest in making the methodology seem complex enough to
require their ongoing services, which means the training emphasizes
statistical techniques over practical problem-solving.
The result is an organization full of certified belts who can run a
hypothesis test in Minitab but can’t walk onto a shop floor and identify
why a press is producing out-of-round parts. They know the formula for
Cpk but they don’t know that the operator has been compensating for a
worn die by adding a shim that nobody documented. They can build a
Pareto chart but they can’t facilitate a conversation between
engineering and production about why a tolerance was specified at a
level the process can’t achieve.
The credential becomes a substitute for competence. And the
organization collects belts the way a neglected child collects trophies
— for display, not for use.
What Actually Works
DMAIC can work. It has worked, in specific contexts, at specific
companies, for specific problems. The conditions under which it works
are not secret, but they are frequently ignored because they require
discipline that most organizations aren’t willing to sustain:
The measurement system must be validated first. Not
as a checkbox — as a genuine, honest assessment. If your gage R&R is
bad, you fix it before you do anything else. Period. No exceptions, no
footnotes, no “we’ll address it in the next phase.”
The project must address a real problem. Not a
convenient problem, not a politically safe problem, not a problem that
fits neatly within a single department’s control. The problem that
actually costs the company money and customer trust.
The analysis must be honest. If the data doesn’t
support your hypothesis, you change your hypothesis — not your data
transformation. If the root cause is uncomfortable, you report it
anyway. If the improvement doesn’t work, you say so.
The control plan must be owned by someone with
authority. Not the quality engineer, not the black belt who has
moved on to the next project. The process owner — the person who runs
the process every day — must be responsible for sustaining the
improvement, and they must have the tools, training, and authority to do
it.
The certification must be secondary to the result.
If your organization values belt colors more than defect reduction, your
Six Sigma program is a training program, not an improvement program.
The Question You Need to Ask
If your organization has invested in Six Sigma — the training, the
belts, the software, the consulting — and your defect rates haven’t
meaningfully improved, your customer complaints haven’t decreased, and
your process capability indices haven’t moved, you need to ask yourself
a hard question:
Did you implement a problem-solving methodology, or did you buy a
credentialing system?
Because DMAIC — the real DMAIC, the one that involves honest
measurement, rigorous analysis, uncomfortable truths, and sustained
control — is genuinely powerful. It’s one of the best structured
problem-solving frameworks ever developed for manufacturing
environments. But the version that most organizations actually implement
— the version with the binders and the belts and the project charters
and the savings reports and the control plans that nobody follows — that
version is a bureaucratic exercise in appearing to improve while
actually standing still.
The difference between the two is not the framework. It’s the
honesty, the discipline, and the leadership commitment to use the
methodology as a tool rather than a performance.
Six Sigma DMAIC doesn’t fail because the statistics are wrong. It
fails because the organization was more interested in looking like it
was solving problems than in actually solving them. And no belt color —
yellow, green, black, or master — can compensate for that.
About the Author: Peter Stasko is a Quality
Architect with over 25 years of experience in manufacturing quality
management, process improvement, and production system design. He has
implemented and evaluated quality systems across automotive,
electronics, and industrial manufacturing environments throughout his
career.
