Opens in a new tab
←
All terms
Problem SolvingUpdated 8 October 2026

DMAIC

The five-phase improvement cycle — Define, Measure, Analyse, Improve, Control — that structures a Six Sigma project from framing the problem to holding the gain.

DMAIC is the improvement cycle at the centre of Six Sigma. It runs a project through five phases in order (Define, Measure, Analyse, Improve, Control), each with an exit condition that has to be met before the next begins. It is the method taught and practised in Green Belt and Black Belt certification.

It suits problems where the cause is genuinely unknown and the process already exists. Where the cause is known and the fix obvious, DMAIC is overhead. Where the process does not exist yet, DMADV applies instead.

Define: agree on the problem before looking for causes

Define establishes what problem is being solved, for whom, and what better would look like in measurable terms. The output is a scoped problem statement, not a hypothesis about the cause. A project that starts with “we need to implement X” has skipped Define.

Typical tools: project charter, SIPOC to bound the process, voice of the customer to turn complaints into measurable requirements (CTQs).

Exit condition: a one-page charter with the problem, the metric, the baseline if known, the scope, the team and a target that the sponsor has signed.

Measure: establish the current state with data

Measure establishes the current state with data rather than opinion. That includes checking the measurement system itself: a project built on an unreliable gauge fails regardless of how good the later analysis is. If two people measuring the same thing get different answers, the first improvement project is the measurement.

Typical tools: data collection plan, operational definitions, Gage R&R, process map of the current state, process capability (Cp, Cpk, sigma level).

Exit condition: a validated baseline for the metric in the charter, with its variation, over a period long enough to be representative.

Analyse: find what actually drives the problem

Analyse identifies what is actually driving the problem. Most failed projects fail here, by assuming a cause early and spending the remaining phases confirming it. The discipline is to list candidate causes widely, then test them against data, and keep only those the data supports.

Typical tools: Ishikawa diagram and 5 Whys to generate candidates, Pareto chart to rank them, stratification, scatter plots and hypothesis tests to confirm which inputs move the output. Black Belt projects add regression and designed experiments.

Exit condition: a short list of root causes, each with evidence, and an estimate of how much of the problem each explains.

Improve: design, test, then deploy

Improve designs and tests changes against those causes. Testing before full deployment is what separates this from ordinary problem solving: a pilot on one line, one team or one week shows whether the change moves the metric before the organisation commits to it.

Typical tools: solution selection matrix, FMEA on the proposed change, pilot plan, poka-yoke, and the Lean tools that often provide the fix itself: 5S, standard work, SMED, kanban.

Exit condition: pilot results showing the metric at or near the target, and a deployment plan.

Control: make the change the new normal

Control makes the change stick through standards, monitoring and a defined response to drift. Skipping Control is why so many organisations can point at improvements that no longer hold. The phase ends when the process owner, not the project team, is running the monitoring.

Typical tools: control plan, control charts, standard operating procedures, visual management, a reaction plan that says who does what when the chart signals.

Exit condition: a signed control plan, the metric held at target for a defined period, and a closed project with lessons recorded.

A worked example

A logistics company loses customers over late deliveries. Define: the problem is stated as “18% of deliveries in region X arrive after the promised window; target 5% within four months”. Measure: delivery timestamps are checked against the promise for three months; the baseline is 18.4%, with Mondays at 31%. Analyse: candidate causes include route planning, vehicle availability, order cut-off times and warehouse picking. Stratified data shows Monday lateness comes from weekend orders released in one batch at 06:00; picking capacity is the bottleneck, not the routes. Improve: a pilot releases weekend orders in two waves on Sunday evening and Monday morning; Monday lateness drops to 9% in the first month. Control: the two-wave release becomes the standard, a weekly control chart tracks lateness by day, and the warehouse supervisor owns the reaction plan.

The cause the team expected at the start (route planning) turned out to be wrong. That is the typical outcome of a DMAIC project done properly, and the reason Analyse exists.

DMAIC and Lean

Lean Six Sigma uses DMAIC as the project structure and Lean as much of the content. Measure and Analyse borrow value stream mapping and the seven wastes to see where time is lost; Improve draws on flow, pull and standard work. The statistics are what Six Sigma adds when the cause is in variation rather than in waste.

When DMAIC is the wrong tool

DMAIC is slow by design: a Green Belt project runs three to six months. It is the wrong choice when the cause is already known and the fix is cheap (just fix it, and use A3 or a kaizen event if you want structure), when the process does not exist yet (use DMADV), or when the problem is a one-off incident rather than a recurring pattern.

Frequently asked questions

How long does a DMAIC project take? Three to six months for a Green Belt project, longer for Black Belt projects with several causes or sites. Shorter projects usually mean Measure or Control was cut.

Who leads a DMAIC project? A Green Belt or Black Belt, with a sponsor who owns the process and team members from the people who do the work. Yellow Belts contribute to data collection and improvement ideas.

What is the difference between DMAIC and PDCA? PDCA is a general improvement loop with no required analysis depth. DMAIC prescribes what each phase must produce and insists on data before causes and tests before deployment. PDCA suits daily improvement; DMAIC suits problems that have resisted it.

What is the difference between DMAIC and DMADV? DMAIC improves an existing process. DMADV designs a new one, or redesigns one whose structure prevents it from ever meeting the requirement.

Where is DMAIC taught? It is the backbone of Green Belt certification, where participants run a real DMAIC project, and is deepened with advanced statistics in Black Belt. The Yellow Belt covers the cycle at team-member level.

At a glance
Taught atYellow Belt
Updated8 October 2026
No results