DMAIC Process: 5 Phases Explained with Example

July 11, 2026 · QualityManager Team

DMAIC is a five-phase, data-driven method used in Six Sigma to improve an existing process. The phases — Define, Measure, Analyze, Improve, Control — move a team from a vague problem to a verified, sustained fix, replacing guesswork with measurement and root cause analysis at every step.

What is the DMAIC methodology?

DMAIC (pronounced “duh-may-ick”) is the core problem-solving roadmap of Six Sigma. Each letter is a phase, and the phases run in order because each one produces the input the next one needs: you cannot analyze data you have not measured, and you cannot control a fix you have not made.

The DMAIC process is built for a specific kind of problem — one where a process already exists, the output is measurable, and the root cause is not yet known. If you already know the fix, DMAIC is overkill. Its value is the discipline it forces: prove the problem with data, find the real cause before touching the process, and lock the gain in place so it does not erode.

Throughout this guide we follow one running example — an injection-molding line rejecting too many parts for scrap — so you can see each phase produce something concrete rather than just a description.

The five DMAIC phases at a glance

Here is the whole DMAIC process in one table before we walk through each phase in detail.

Define: frame the problem

Goal of the phase. Turn a fuzzy complaint (“scrap is too high”) into a specific, measurable problem statement with a numeric goal and an agreed scope.

Entry criteria. A business pain or customer issue worth a multi-week project, plus a sponsor willing to fund the team’s time.

Key activities. Write a project charter (problem statement, goal, scope, team, timeline). Map the process at a high level with a SIPOC diagram (Suppliers, Inputs, Process, Outputs, Customers). Capture the voice of the customer so the goal reflects what actually matters downstream.

In the example. The team writes: “Scrap on molding line 4 averaged 8.2% over the last quarter against a 3.0% target, costing roughly $18,000/month in wasted resin and machine time. Reduce line-4 scrap to 3.0% or below within four months.” Scope is limited to line 4 only, so the project stays finishable.

Exit criteria / deliverables. A charter signed by the sponsor, a defined metric (scrap %), and a goal everyone agrees on. If the team cannot state the problem in a number, Define is not finished.

Measure: quantify the baseline

Goal of the phase. Establish a trustworthy baseline for the metric and localize where the problem concentrates — you cannot improve what you have not honestly measured.

Entry criteria. An approved charter and a metric definition from Define.

Key activities. Build a data collection plan (what, how, who, how often) and confirm the measurement itself is reliable. Map the detailed process steps. Break the baseline down by category — machine, shift, defect type, material lot — to see where the numbers cluster. A Pareto chart is the workhorse tool here: it ranks defect categories so the team attacks the vital few instead of spreading effort across the trivial many.

In the example. Over three weeks the team logs every rejected part by defect type. The Pareto chart shows that 71% of scrap is “short shots” (incomplete fills), with flash and burn marks making up most of the rest. Two problems, not twenty — and one dominates.

Exit criteria / deliverables. A validated baseline (8.2% confirmed with clean data) and a clear statement of where the problem lives (short shots on line 4). The team now knows exactly what to explain in Analyze.

Analyze: find the root cause

Goal of the phase. Identify and verify the true root cause(s) of the problem, rather than the first plausible-sounding explanation.

Entry criteria. A validated baseline and a localized problem (short shots) from Measure.

Key activities. Brainstorm potential causes, then narrow to verified ones. A fishbone diagram organizes candidate causes across categories (Machine, Method, Material, Measurement, People, Environment) so the team explores the whole problem space instead of fixating early. From there, 5 Whys drills each promising branch down to a root cause you can act on. Where data allows, confirm causes with a hypothesis test rather than opinion. For a fuller menu of what to reach for here, see our guide to root cause analysis tools.

The Analyze-phase tools — 5 Whys, Fishbone, and Pareto — are available as free AI-guided tools in QualityManager.AI, which prompts you through each cause branch so you do not stall on a blank template. (A dedicated DMAIC project module is on our roadmap, not yet live.)

In the example. The fishbone surfaces melt temperature, injection pressure, and material moisture as suspects. A 5 Whys on short shots runs: parts don’t fill → melt is too cool at the gate → barrel set-point was lowered → an operator dropped it to reduce flash on a different part → no work instruction defined the correct temperature per mold. Root cause: a missing, standardized temperature setting per mold, not a broken machine.

Exit criteria / deliverables. One or a few root causes, verified with data, not a list of everything that might be wrong. The team can now say: “If we fix X, scrap drops.”

Improve: fix the root cause

Goal of the phase. Design, pilot, and confirm a solution that addresses the verified root cause and measurably moves the metric.

Entry criteria. A verified root cause from Analyze.

Key activities. Generate solution options, then test the leading one on a small scale before full rollout. Use a pilot run or a designed experiment (DOE) to confirm the fix works and does not create a new problem. Where possible, build in a poka-yoke (mistake-proofing) so the failure cannot recur, rather than relying on people to remember.

In the example. The team defines a validated melt-temperature set-point for each mold and pilots it for a week. Short-shot scrap on the piloted molds drops sharply; overall line-4 scrap falls from 8.2% to 2.6%, beating the 3.0% goal. To mistake-proof it, the correct set-point is added to each mold’s setup sheet and locked behind a supervisor code so it cannot be casually changed.

Exit criteria / deliverables. A piloted solution with proven, quantified improvement and no significant side effects. A fix that works in a pilot but has not been measured is not a finished Improve phase.

Control: make the gain stick

Goal of the phase. Sustain the improvement so the process does not quietly revert once attention moves elsewhere — the phase where most projects succeed or fail.

Entry criteria. A proven solution from Improve.

Key activities. Write a control plan naming what gets monitored, by whom, how often, and what to do when it drifts. Update SOPs and setup sheets to reflect the new standard. Put the key metric on a control chart (SPC) so a slide back toward the old baseline triggers action before it becomes scrap again. Formally hand the process back to its owner.

In the example. Line-4 scrap goes on a weekly control chart with a 3.0% upper action limit. The molding SOP is revised to reference the per-mold temperature table, and the shift lead owns the daily check. The project closes with scrap holding at 2.6% and a documented plan for what happens if it climbs.

Exit criteria / deliverables. A signed control plan, updated documentation, monitoring in place, and a process owner who has accepted the handoff. Only now is the DMAIC project genuinely done.

DMAIC vs PDCA vs 8D: which framework fits?

DMAIC is not the only structured improvement method, and using the heaviest tool for a light problem wastes weeks. Here is how the three most common frameworks compare.

When DMAIC fits. You have a chronic, measurable process problem, the cause is genuinely unclear, and the fix is worth a multi-month, data-backed investigation. This is the core Six Sigma use case.

When PDCA fits. The change is small, low-risk, or continuous — a shop-floor kaizen tweak you want to try, measure, and iterate quickly. The DMAIC vs PDCA choice usually comes down to scale and uncertainty: reach for PDCA when the loop is meant to spin fast and often, and for DMAIC when you need to prove a root cause before committing.

When 8D fits. A customer just rejected a shipment and you need containment today plus a permanent corrective action. 8D’s early emphasis on interim containment is something DMAIC lacks, because DMAIC assumes you have months, not hours.

The frameworks also overlap by design. DMAIC’s Define-Measure-Analyze block is a more rigorous version of PDCA’s “Plan,” and its Improve-Control block maps onto “Do-Check-Act.” Learning DMAIC well makes the lighter frameworks easier, not redundant.

Getting started with DMAIC

You do not need a belt certification or a statistics degree to run your first DMAIC project — you need a real problem with a measurable output and the discipline to work the phases in order. Start small: pick one line, one metric, one clearly bounded scope, exactly as the molding example did. The most common failure mode is not weak analysis; it is skipping Define (starting with no measurable goal) or skipping Control (walking away once the number looks good).

If you want to practice the Analyze-phase tools before committing to a full project, the free AI-guided 5 Whys, Fishbone, and Pareto tools are the fastest way to build the habit on a problem you already have.