Quick Answer

What: The DMAIC phases of a Lean Six Sigma project are five questions asked in a fixed order: what matters, what is true today, why, what change closes the gap, and what keeps it closed. The formal names are Define, Measure, Analyze, Improve and Control.

Why it matters: Most improvement projects do not fail on tools or effort. They fail on sequence: a question answered out of order, or skipped, and everything built on top of it.

How to apply: Run one question at a time, and do not let a project move forward while the question behind it is still open. In every review, ask which question the project is on.

The payoff: Results that survive scrutiny, gains that are still there in a year, and a team that has seen the whole method hold together once, which is how practitioners are actually formed.

The map underneath the tools

Ten Field Notes into this series, a fair question has earned an answer: is there a map, or is it one tool after another until the series runs out?

There is a map, and it has been underneath the whole time.

Every improvement effort that finishes, in any industry, answers five questions, and it answers them in order. What matters, and what would better look like? What is actually happening today? Why is it happening? What change closes the gap? And how will the gain still be there when everyone has moved on to something else?

The method most people know as DMAIC is those five questions wearing formal names. The DMAIC phases are not a bureaucracy invented to slow projects down, and they are not a menu to pick from. They are the order in which an honest answer becomes possible at all. A cause cannot be tested before normal behavior is known. A fix cannot be chosen before a cause is confirmed. A result cannot be trusted before it is compared with what the process does on its own. Each phase exists to make the next one honest.

Take the tools out of that arc and they are party tricks. Inside it, each one does one job, in one place. That is the real subject of this article: not any single tool, but the arc that gives every tool its job.

What each phase actually asks

Define: what matters, and what would better look like?

Define turns a complaint into a piece of work. "The backlog is out of control" becomes a stated problem, a number that says what better means, a boundary around what is in and out, and named people carrying it. Two earlier notes live here: choosing the few projects worth full attention rather than half-funding everything, and mapping the people a change will actually land on, because agreement is not alignment. A project that skips this question argues about success at the end instead of the beginning, and that argument has no referee.

Measure: what is true today?

Measure establishes the honest starting point. A data collection plan decides what counts before anyone counts it. A measurement system check confirms the ruler can be trusted before any number from it is believed. And the baseline records not just today's average but how far the process swings on its own, which is the yardstick every later claim will be held against. This is also where the cost of poor quality puts a price on the gap, so the project knows what solving it is worth. Measure produces no fixes, which is why impatient programs cut it, and why their results cannot be defended later.

Analyze: why?

Analyze exists to earn the word "because." The cause list is cast wide before it is narrowed, because a cause that never makes the list is never investigated. The narrowing digs past symptoms to the cause that actually drives the behavior. And the survivors are put to the test, because a visible difference is a claim until it is tested against the process's own variation. An untested cause is still an opinion. Opinions with budgets are how improvement money disappears.

Improve: what change closes the gap?

Improve is the phase everyone wants to start in, and the one that becomes almost calm when it is reached in order. A tested cause usually names its own fix. The work here is designing the change, piloting it, and proving the result is larger than the noise before anyone celebrates. Run out of order, Improve is expensive guessing with a project name attached.

Control: what keeps it closed?

Control is the question almost nobody budgets for. A gain needs an owner, a signal that drift has started, and an agreed response for when it does. Without those, the process slides quietly back toward the old level, and within a few quarters the only trace of the project is its slide deck. Nothing is finished at Improve. It is finished when the gain no longer depends on anyone remembering the project.

Where projects break sequence

Nearly every failed project tells the same story in a different costume, and the diagnosis is rarely a missing tool. In the projects I have been called into after the fact, it is almost always a skipped question.

A project that cannot say what better means in a number skipped Define, and every later argument about success is that argument, postponed. A result announced with no baseline skipped Measure, and the first ordinary month takes the credit back. A fix aimed at an untested cause skipped Analyze, and the symptom returns under a new name. A gain with no owner skipped Control, and evaporates on schedule.

The DMAIC phases are unforgiving about this in a way that feels slow early and proves fast late. Define and Measure look like delay because they produce no fixes; they are where the project quietly becomes winnable. By the time visible activity peaks in Improve, the outcome has mostly been decided by the questions that came before it.

There is one more failure mode worth naming: the project that answers every question correctly and still fades, because the people who ran it were never formed by it. Finishing one whole arc, even on something small, changes practitioners in a way no course does, which is why what happens after the training decides whether a program compounds or resets.

The road from here

This series has walked the first half of the arc: the defining questions, the measuring questions, and the first analyzing ones. The notes ahead go deeper into why, and then into the two questions almost nobody budgets for: making the change, and keeping it. For readers who want the arc at a finer grain, the same five questions break into the specific, phase-by-phase questions of the 16 Questions DMAIC framework, which has guided my own project work since 1999.

Field notes from this arc arrive weekly. If a colleague runs projects and has never seen the map drawn this way, the notes are free and short: join the newsletter here.

Frequently asked questions

What does DMAIC stand for?

Define, Measure, Analyze, Improve, Control: the five phases of a Lean Six Sigma improvement project. In plain words: decide what matters, establish what is true, find out why, change it, and keep it changed.

Do the DMAIC phases have to run in order?

Yes, and the order is the point. Each phase exists to make the next one honest: a cause cannot be tested without a baseline, and a fix cannot be chosen from an untested cause. Teams often loop back as they learn; what fails is skipping forward.

How long does a DMAIC project take?

It depends on scope, but a well-chosen first project is measured in weeks and months, not days. Speed comes from sequence, not shortcuts: the slower early phases are what make the later ones fast, and finishing one whole arc matters more than finishing quickly.

Why do DMAIC projects fail?

Rarely because of tools. The common diagnosis is a skipped question: no numeric definition of better, no baseline, an untested cause, or no control plan. The failure appears phases later than the skip, which is why it gets blamed on the wrong thing.