Lean Six Sigma: What DMAIC Does, What Lean Does, and Which You Need
Lean Six Sigma is a process improvement approach combining Lean, which targets waste and delay, with Six Sigma, which targets variation and defects, usually run through the DMAIC cycle.
Before you start
Is this your framework?
This page covers two things that are often treated as one: DMAIC, the five-phase cycle Six Sigma runs projects through, and the question of whether your problem is a Lean problem or a Six Sigma one.
It is heavy machinery. A full DMAIC project takes months and needs data you may not have. If the fix is known and the problem is getting anyone to do it, this is the wrong tool and the table below says what is not.
| If your real problem is… | You probably want |
|---|---|
| The process is slow and full of waiting, but the output is fine | Value Stream Mapping — find where the work waits, which is a Lean question and needs no DMAIC Compare Lean Six Sigma and Value Stream Mapping |
| We want small continuous improvements, not one big project | Kaizen — short repeated cycles run by the people doing the work Compare Lean Six Sigma and Kaizen |
| We need a fix in days and everyone already knows roughly what it is | Kaizen Blitz — a focused event, where DMAIC's evidence requirements would be dead weight |
| The workplace itself is disorganized and that is the bottleneck | 5S Methodology — the groundwork, usually done before any measurement is worth trusting |
| We need to know what defect rates and sigma levels actually mean | Six Sigma Metrics — DPMO, sigma levels and yield, which DMAIC's Measure phase depends on |
| One step is limiting the whole system and we need to find it | Theory of Constraints — the bottleneck, which neither Lean nor Six Sigma will name for you |
| The process is both unreliable and slow, and we need evidence before changing it | Lean Six Sigma — you are in the right place |
What Is It?
Two separate traditions, joined late. Lean came out of the Toyota Production System and goes after waste and delay: the question it asks is why the work is waiting. Six Sigma came out of Motorola in the 1980s and goes after variation and defects: the question it asks is why the output is inconsistent.
They were combined because most real processes have both faults, and because fixing one alone can make the other worse. Speed up a process with high variation and you produce defects faster. Reduce variation in a process clogged with waiting and you get a reliably slow process.
The joining is more recent than most people assume, and less tidy. Practitioners were mixing the toolkits through the 1990s. The name was popularized by Michael George in 2002. What survived the merger is mostly Six Sigma's project structure with Lean's tools inside it.
That structure is DMAIC. It is the Six Sigma half, not a neutral container, and its character shows: it insists on measuring before changing and on proving the cause before proposing the cure. Lean's own improvement cycle is PDCA, which is shorter and expects you to learn by trying.
The cost of the rigor is time. A DMAIC project is normally months, not weeks, and much of that goes into establishing that the measurements can be trusted at all. That is the right investment for a persistent, expensive, poorly understood problem. It is dead weight for anything else, and the commonest failure of Lean Six Sigma programs is running full DMAIC on problems that never warranted it.
Quick Reference
The cycle
DMAIC, phase by phase
Each phase ends in a review before the next begins, and a phase that cannot answer its own question has not finished. What follows is what each one has to produce.
| Phase | What it has to produce | Where it goes wrong |
|---|---|---|
| Define what problem? | A problem statement in terms of the effect, not the suspected cause. Scope, a charter, and the customer requirement the problem violates. | Naming a solution as the problem. "We need a new scheduling system" is not a problem statement. This phase was added last and is still the one most often skipped. |
| Measure how bad? | A baseline you can defend, and evidence that the measurement system itself is reliable. | Trusting the existing data. If two people measuring the same thing disagree, nothing downstream is worth having, and this is common. |
| Analyze why? | A root cause with evidence, not a plausible story. Most of the statistical work lives here. | Stopping at the first cause that fits. The phase is meant to rule things out, and teams under time pressure use it to confirm what they suspected in week one. |
| Improve what change? | A change, tried, with before-and-after evidence that it moved the measure. | Changing several things at once, which leaves you unable to say which one worked or whether any did. |
| Control will it hold? | Monitoring, updated documentation, and a named owner after the project team disperses. | Treating it as paperwork. This is where gains are lost, usually six to twelve months later when nobody remembers why the procedure says what it says. |
Where the letters came from, and why it matters
The original at Motorola was MAIC — Measure, Analyze, Improve, Control — built by Mikel Harry and Bill Smith on the Shewhart cycle that Deming popularized as PDCA. Define was bolted on later, during General Electric's implementation, because projects kept failing for a reason measurement could not fix: nobody had agreed what the problem was.
That history is worth knowing because the failure it was added to prevent is still the most common one. A project that reaches Measure without a defensible problem statement will produce excellent data about the wrong thing, and the rigor of the later phases makes the wrong answer more convincing rather than less.
Choosing
Which half your problem needs
Most teams reach for the whole apparatus when they need half of it. The symptom tells you which half, and the two halves ask genuinely different questions.
| What you are seeing | Which half | What that means in practice |
|---|---|---|
| Work sits in queues. Lead time is long but the output is fine when it arrives. | Lean | Map where the work waits. The fix is usually about flow, batch size and handoffs, and needs no statistics. |
| Output quality is unpredictable. Some days are fine, some are not, and nobody knows why. | Six Sigma | Measure the variation and find its cause. This is what DMAIC is built for, and it is slow on purpose. |
| Both. Slow and unreliable, and fixing one seems to worsen the other. | Both | Remove the waste first. Waiting hides variation; taking out the queues makes the remaining inconsistency visible and measurable. |
| Everyone already knows the cause and nothing gets done about it. | Neither | This is an ownership or incentive problem. A DMAIC project will produce a report confirming what everybody knew. |
The confusion is historical, not conceptual
DMAIC belongs to Six Sigma. When a combined program runs, DMAIC is usually the outer structure and Lean tools get used inside it, mostly during Analyze and Improve. That is why people reasonably ask whether DMAIC is Lean or Six Sigma and get contradictory answers: it originated in one and is routinely used to house the other.
The practical consequence is that adopting DMAIC does not make a program Lean. If nobody is asking where the work waits, you have a Six Sigma program with Lean in the title, which is the usual outcome and worth noticing before it costs a year.
Core Features
- Evidence before change: measure and prove the cause before proposing a fix
- Phase reviews: each phase ends in a decision to proceed, not a handover
- A validated measurement system: checked before the baseline is trusted
- Two fault types addressed: waste and delay from Lean, variation and defects from Six Sigma
- Trained roles: belt levels, which give capability and also create overhead
- An explicit control phase: the gain is held after the project team leaves
Worked example
Six weeks fixing the ruler before measuring anything
An illustrative composite. A contract manufacturer of automotive wiring harnesses near Monterrey, Mexico, with roughly 900 staff. Customer returns were running high and lead times were slipping. The team's instinct was a full DMAIC project on the defect rate.
| Stage | What it showed |
|---|---|
| Define, done properly the second time | The first charter said "reduce defects on line 4". That names a solution area, not a problem. Rewritten in terms of effect: customer returns at 2.3% against a contractual ceiling of 0.8%, concentrated in one connector family. |
| Measure found the measurement was broken | Two inspectors examining the same harnesses agreed on only 71% of pass-fail calls. Six weeks went into the inspection standard before any baseline was trusted. Skipping this would have invalidated everything downstream. |
| The Lean half, run first | Work in progress between crimping and testing averaged eleven hours. Cutting batch sizes brought it to under two. Returns did not move, but the variation became visible, because defects were no longer being discovered days after the cause. |
| Analyze, with data worth analyzing | Failures clustered by crimp tooling age rather than by shift, operator or supplier, all of which had been blamed. Replacement intervals were based on a calendar rather than on cycles run. |
| Improve and Control | Tooling changed to cycle-count replacement, about MXN 1.4 million a year in additional tooling. Returns fell to 0.6%. Control put the cycle counter on the shift report with a named owner. |
The six weeks that felt like a delay were the project
At 71% agreement between inspectors, the existing defect data was close to noise. Every prior improvement attempt had been aimed at whatever that noise happened to suggest, which is why three of them had produced apparent gains that did not last. The Measure phase did not slow the project down; it was the first point at which the project became possible.
Note the sequencing too. Cutting work in progress changed no defect number by itself, and a program judged on quarterly results would have called it a failure. What it did was shorten the distance between cause and discovery, which is what made the tooling pattern visible at all. The Lean work did not fix the problem. It made the Six Sigma work findable.
When to Use
- A persistent, expensive problem that previous attempts have failed to fix
- The cause is genuinely unknown and competing explanations exist
- Output varies and nobody can say what drives the variation
- There is enough volume for statistical work to mean anything
- The organization can sustain a months-long project without abandoning it
- Gains from previous fixes keep eroding after a few months
When NOT to Use
- The cause is known and the obstacle is getting anyone to act
- Low volume or one-off work, where there is nothing to measure repeatedly
- A fix is needed in days rather than months
- The problem is a bottleneck rather than variation or waste
- Creative or exploratory work, where variation is the point rather than the fault
- No appetite for the training and role overhead a belt structure brings
In practice
How Lean Six Sigma goes wrong
The recurring pattern is applying the full apparatus to problems that did not need it, then blaming the method when the cost outruns the benefit.
| Failure mode | What it looks like | What to do instead |
|---|---|---|
| DMAIC on everything | Four-month projects on problems a two-day event would have closed | Screen for cause uncertainty. If the cause is known, run a focused event instead. |
| Solution disguised as problem | A charter naming the fix, so Analyze becomes a search for supporting evidence | Write Define in terms of the effect on the customer. If it names a system or a team, rewrite it. |
| Measurement never validated | A baseline built on data two inspectors would disagree about | Check agreement before the baseline. If it is poor, fixing that is the project's first deliverable. |
| Lean in the title only | A belt structure, DMAIC projects, and nobody asking where the work waits | Run a flow analysis before the statistics. Waste is usually cheaper to remove than variation. |
| Control treated as paperwork | Gains that reverse six to twelve months after the team disbands | Name an owner and put the measure somewhere already looked at daily, not in a project archive. |
| Belts without problems | Training volume becomes the metric, and certified staff go looking for projects | Count problems solved and gains held, never people trained. |
| Savings claimed, not banked | Project benefits that never appear in any budget | Have finance sign off the benefit, and check it a year later. |
Sourced
Evidence, and how to cite it
"Lean" was coined by John Krafcik, not by Womack and Jones.
The term first appeared in Krafcik's article "Triumph of the Lean Production System" in the Fall 1988 Sloan Management Review, drawn from his master's thesis at MIT under the International Motor Vehicle Program. He had been a quality engineer at NUMMI, the Toyota and General Motors joint venture in California. Earlier IMVP work had classified plants as fragile or robust; Krafcik chose "lean" as the better word. Womack, Jones and Roos popularized it two years later in The Machine That Changed the World, which is why the attribution usually lands on them.
Krafcik, J.F. (1988) ‘Triumph of the Lean Production System’, Sloan Management Review, 30(1), pp. 41–52.
DMAIC began as MAIC. The Define phase came later.
The ancestor is Walter Shewhart's cycle from the 1920s, popularized by Deming as PDCA. At Motorola in the 1980s, Mikel Harry and Bill Smith built a four-phase version for Six Sigma projects: Measure, Analyze, Improve, Control. Define was added during General Electric's implementation in the 1990s, and the reason is instructive: projects were failing because the problem had never been agreed, which no amount of measurement fixes. Most published accounts present the five letters as though they arrived together.
Accounts of the Motorola and GE Six Sigma programs; Shewhart (1939) and Deming on the plan-do-check-act cycle.
Six Sigma has a specific origin and date.
Bill Smith, a reliability engineer at Motorola, set out the argument in a memo in the mid-1980s connecting product field life to rework during manufacturing. Chief executive Bob Galvin backed it against a majority of his senior team. Motorola launched the program formally on 15 January 1987 with the goal of fewer than 3.4 defects per million opportunities, and won the first Malcolm Baldrige National Quality Award in 1988. The name was trademarked by Motorola.
Contemporaneous accounts of the Motorola Six Sigma program; Smith, W.B. (1929–1993), Motorola.
The financial case rests on self-reported figures from adopters.
The large savings numbers attached to Six Sigma programs come almost entirely from the companies running them, calculated using their own benefit rules, and published when the programs were going well. There is no controlled body of evidence comparing organizations that adopted the method against comparable ones that did not, and the celebrated cases are selected on their outcomes. Separately, the method's own logic cuts against it in some settings: work where variation is the source of value does not benefit from having variation removed.
Assessment of the management literature as of 2026; no controlled outcome studies of Lean Six Sigma adoption are available.
How to cite it.
Harvard: George, M.L. (2002) Lean Six Sigma: Combining Six Sigma Quality with Lean Speed. New York: McGraw-Hill.
APA: George, M. L. (2002). Lean Six Sigma: Combining Six Sigma quality with Lean speed. McGraw-Hill.
For the term Lean, cite Krafcik (1988), not Womack and Jones. For DMAIC, note that Motorola's version was MAIC and that Define was added later.
Key Strengths
- Refuses to change things before the cause is proven: rare, and the main reason it works
- Control is built in: the only common method that budgets for holding the gain
- Covers two fault types: waste and variation, which usually appear together
- Findings are defensible: the evidence trail survives a change of sponsor
- Exposes bad measurement: often the most valuable thing a first project produces
Key Weaknesses
- Slow and expensive: months per project, which rules out most problems
- Needs volume and data: low-volume work gives the statistics nothing to work with
- Overhead becomes the program: belt counts drift into being the measure of success
- Hostile to useful variation: a poor fit for creative or exploratory work
- Savings are self-reported: claimed benefits often never reach a budget line
Sequencing
What to run before and after
DMAIC is expensive enough that what happens either side of it determines whether it was worth running.
Before
Take out the waste, and check the problem is worth this much effort
Waiting hides variation. Removing queues shortens the distance between cause and effect, which makes the later analysis possible and sometimes makes it unnecessary.
During
Get the measurement right before the baseline
A baseline built on a measurement system people disagree about invalidates everything after it. Know what a defect is, how it is counted, and whether two observers would agree.
After
Hold the gain, and move to smaller cycles
Control is where improvements are lost. Once the big problem is closed, continuous small cycles run by the people doing the work cost far less than another full project.
Common questions
DMAIC and Lean Six Sigma: quick answers
What is DMAIC?
A five-phase problem-solving cycle: Define, Measure, Analyze, Improve, Control. Define states the problem and its scope. Measure establishes what is happening now. Analyze finds the cause. Improve changes something and tests whether it worked. Control makes the change hold after the project team leaves. Each phase ends in a review before the next begins.
Is DMAIC Lean or Six Sigma?
Six Sigma. DMAIC came out of Motorola in the 1980s and is the Six Sigma improvement cycle. Lean has its own cycle, PDCA, inherited from Deming by way of Toyota. In a combined Lean Six Sigma program DMAIC is usually the outer structure and Lean tools get used inside it, particularly in the Analyze and Improve phases, which is why the two get conflated.
What is the difference between Lean and Six Sigma?
They attack different faults. Lean goes after waste and delay, so the question is why the work waits. Six Sigma goes after variation and defects, so the question is why the output is inconsistent. A process that is slow but reliable is a Lean problem. One that is fast but unpredictable is a Six Sigma problem. Many real processes are both, which is why the disciplines were combined.
Who created DMAIC?
It has a lineage rather than an inventor. Walter Shewhart's cycle of the 1920s, later popularized by Deming as PDCA, is the ancestor. At Motorola in the 1980s Mikel Harry and Bill Smith built a four-phase version, MAIC: Measure, Analyze, Improve, Control. The Define phase was added later, during General Electric's implementation in the 1990s, producing the DMAIC in use today.
What are the five DMAIC phases and what does each produce?
Define produces a problem statement, scope and a charter. Measure produces a validated baseline and a measurement system you can trust. Analyze produces an identified and evidenced root cause. Improve produces a tested change with results. Control produces the monitoring and documentation that keep the gain after the team disbands.
How is DMAIC different from PDCA?
PDCA is shorter, faster and built for repeated small cycles; DMAIC is longer, more evidence-heavy and built for one substantial problem at a time. The practical difference is the Measure and Analyze phases, which demand data and a validated measurement system before anyone is allowed to change anything. That rigor is DMAIC's advantage and the reason it is too slow for small fixes.
When do you need both Lean and Six Sigma?
When the process is both slow and unreliable, and when fixing one would make the other worse. Speeding up a process with high variation produces defects faster. Reducing variation in a process clogged with waiting produces a reliably slow process. If either description fits, you need both, and the usual sequence is to remove the waste first because it makes the variation easier to see.
How do you cite Lean Six Sigma sources?
For Lean, cite Krafcik, J.F. (1988) 'Triumph of the Lean Production System', Sloan Management Review 30(1), which coined the term, rather than Womack and Jones, who popularized it in 1990. For Six Sigma, cite Motorola's program under Bill Smith and Bob Galvin, launched in January 1987. For the combined term, cite George, M.L. (2002) Lean Six Sigma.
Deep Resources
Frameworks related to Lean Six Sigma
- Six Sigma MetricsDPMO, sigma levels and yield — the measurement the Measure phase depends on…
- Value Stream MappingThe Lean half on its own: where the work waits, without the statistical apparatus…
- KaizenShort repeated cycles for problems that do not warrant a months-long project…