DMAIC, Explained: The Five Phases of Every Six Sigma Project

Every Six Sigma project, whatever the industry, runs on the same five-phase engine: Define, Measure, Analyze, Improve, Control. DMAIC is not paperwork for its own sake. It is a sequence of questions, asked in an order that stops smart people from doing the natural thing — jumping straight to solutions.

To keep this concrete, we will follow one process through all five phases: invoice approval at a mid-sized company. Invoices arrive by email, get routed for approval, and are eventually paid. Suppliers complain about late payments. Accounts payable is drowning in corrections. Everyone has a theory about whose fault it is. The company is fictional, but if you have worked in an office, it will feel familiar.

Define: what problem are we solving, and for whom?

Define answers the question every failed project skipped: what exactly is wrong, for whom, and how will we know when it is fixed? The team writes a problem statement in observable terms, names the customers of the process, sets a goal, and draws the boundaries — which steps are inside the project and which are not. All of it lands in a charter, and a sponsor signs it.

For the invoice process, the team resists the temptation to write “approvals are too slow.” Instead: invoices routinely take weeks from arrival to payment, some suppliers are paid late, and a meaningful share of invoices bounce back for correction. The customers are the suppliers who want to be paid on time and the finance team that wants clean books. The scope runs from “invoice received” to “payment released” — supplier onboarding and the payment system itself are out of bounds.

1. 01A problem statement written in observable, measurable terms
2. 02A goal statement that defines success without prescribing a solution
3. 03Scope boundaries — the first and last process step the project may touch
4. 04The team, the sponsor, and a rough timeline by phase

Measure: how does the process perform today?

Measure answers: what is actually happening, in numbers? Not what the procedure manual says. Not what the department head remembers. The team defines its metrics precisely, decides how to collect them, checks that the measurement itself can be trusted, and establishes a baseline.

The invoice team settles on two metrics: cycle time, the calendar days from invoice arrival to payment release, and first-pass yield, the share of invoices approved without being sent back for correction. They pull a sample of recent invoices and walk each one’s history through the system. Along the way comes the first surprise: the figures everyone quoted in meetings started the clock when an invoice was entered into the accounting system — not when it arrived in the shared inbox, where invoices can sit unlogged for days. Measure exists to catch exactly this. The baseline that emerges is worse than anyone claimed, and, for the first time, everyone trusts it.

Analyze: why is it happening?

Analyze answers: which causes, out of all the plausible ones, actually drive the problem? The team lists suspects — brainstorming, fishbone diagrams, the 5 Whys — and then does what casual problem-solving never does: tests them against data.

The invoice team’s suspect list is long: unclear approval limits, approvers on vacation with no delegate, missing purchase-order numbers, a clunky forwarding step. The data separates signal from noise. Invoices missing a purchase-order number take far longer, because clerks must email the requester and wait. And a large share of the total delay concentrates in one step: invoices sitting in the queues of a handful of approvers who receive far more than everyone else. Vacation coverage, the loudest theory in the room, turns out to matter much less than assumed. This is Analyze doing its job — retiring confident theories and confirming unglamorous ones.

Improve: what change will remove the cause?

Improve answers: what specifically do we change, and how do we know it worked? Solutions are aimed at verified causes only. Candidates are generated, screened for cost and risk, and piloted before any full rollout.

The team makes the purchase-order number a required field at intake, so an incomplete invoice cannot enter the queue at all — mistake-proofing rather than reminding. They rebalance the approval routing so no single approver becomes a bottleneck, and add a standing delegate rule. Both changes run as a pilot with two departments for a few weeks, and the pilot’s cycle time and first-pass yield are compared against the baseline. Only after the pilot shows a real, measured gain do the changes roll out to everyone. No banners, no launch party — just a process that now runs the way the data said it could.

Control: how do we keep the gain?

Control answers the question that separates Six Sigma from ordinary fix-it efforts: how do we make sure the problem stays solved after the project team walks away? Improvements decay. People revert, workarounds creep in, staff turn over. Control builds the guardrails.

The invoice team writes the new routing rules into standard work, sets up a simple monthly chart of cycle time and first-pass yield that the accounts-payable lead reviews, and defines a response plan: if either metric drifts past an agreed limit, specific actions trigger and a named owner takes them. Then the team hands the process back to its owner and closes the project. Months later, nobody remembers the project — and the invoices still go out on time. That is what success looks like.

A solved problem that quietly returns was never solved — it was postponed.

Learning to run the engine yourself

Reading about DMAIC and leading it are different skills, and the second is the one employers pay for. Our Green Belt program is built exactly this way — 35 hours of material organized phase by phase around a full simulated project, ending in a 100-question exam with one free retake and lifetime access. If you want the whole roadmap before committing, White Belt covers the foundations in about six hours. Either way, the next slow, error-prone process you meet will look less like a frustration and more like a project.