DMAIC Process Explained With Examples

What is the DMAIC process?

DMAIC is a five-phase method for improving a process that already exists and is not performing. Define establishes the problem, the customer, and the scope. Measure quantifies the current performance. Analyze identifies and verifies the root causes. Improve implements and tests a change. Control standardises the result so it holds.

The distinction that matters is between improving an existing process and designing a new one. DMAIC is for the first case. If the process does not exist yet, or the current design is so broken that patching it is wasted effort, the parallel method is DMADV — Define, Measure, Analyze, Design, Verify.

Each phase has a deliverable that the next phase depends on. Skipping the sequence is the most common way a DMAIC project becomes a rebranded action list.

Where does DMAIC come from?

Motorola developed the method in 1986, driven by engineer Bill Smith’s work on reducing defects in manufacturing and connecting quality directly to cost. The company set a target of 3.4 defects per million opportunities and won the Malcolm Baldrige National Quality Award in 1988.

General Electric adopted Six Sigma in 1995 under Jack Welch and turned it into a management system rather than a quality programme, reporting hundreds of millions of dollars in savings by the late 1990s. Mikel Harry’s work on the statistical structure of the method shaped DMAIC into the five-phase form used today, with the phases mapped onto the older MAIC cycle (Measure, Analyze, Improve, Control) by adding a Define stage up front.

What survived from that history is the discipline of counting: define a defect precisely, measure it per opportunity, and compare the process against a known sigma benchmark. What did not survive is the assumption that every problem needs a Black Belt and a regression model.

What happens in each of the five phases?

Each phase answers one question and produces one artefact. The table below is the working summary; the sections after it explain what each gate actually tests.

Define

Define converts a complaint into a scoped problem. The charter states the business case, the process boundaries, the customer requirement, the defect definition, and the target. A SIPOC map — suppliers, inputs, process, outputs, customers — is usually enough to expose whether the team has drawn the boundary in the wrong place.

The gate is scope discipline. If the charter cannot be written on one page, the project is too large. If the defect cannot be described in a sentence a customer would recognise, it is too vague.

Measure

Measure builds a baseline you can defend. That means an operational definition of a defect, a data collection plan, and a measurement system analysis to confirm that two people counting the same thing get the same answer. A baseline built on a measurement system that disagrees with itself will produce a conclusion that does not survive contact with the process.

This is also where the process is expressed in defects per million opportunities (DPMO), so performance can be compared with other processes and against sigma benchmarks. The gate is simple: is the baseline reproducible, and does the team agree on what counts as a defect?

Analyze

Analyze separates cause from coincidence. The team starts wide with a Pareto chart to find where the defects concentrate, then narrows with a fishbone diagram or 5 Whys, then confirms with data. Confirmation is the step that gets skipped. A plausible cause that the data does not support is a hypothesis, not a finding.

Good analysis produces a short list — usually three to five verified causes — with an estimate of how much of the defect rate each one explains. If the list has fifteen items, the team has not finished analysing.

Improve

Improve turns a verified cause into a tested change. The pilot matters more than the plan: run the change on a subset, measure the same metric with the same definition, and compare against the baseline. If the result does not move, the analysis was incomplete, and the honest move is to return to Analyze rather than to add another countermeasure on top.

Improve is also where the cost side gets settled. Every candidate solution should be compared on effect size against implementation cost, because the largest effect is often not the one with the best payback.

Control

Control is the phase that decides whether the project was real. It produces a control plan naming the metric, the owner, the sampling frequency, the control limits, and the action to take when a point falls outside them. Standard work and mistake-proofing reduce the chance of reversion; an audit or dashboard makes reversion visible.

Without this phase, the process drifts back within two or three quarters, usually without anyone noticing until the same complaint returns.

What does a DMAIC project look like with real numbers?

Consider an accounts payable process handling 12,400 invoices a month, with four opportunities for error per invoice — wrong vendor, wrong amount, wrong coding, duplicate payment. That is 49,600 opportunities per month.

Define. The defect is an invoice that requires rework before payment. The customer is the supplier waiting for settlement and the finance team absorbing the rework. The target is a 60% reduction in defective invoices within five months, with no increase in headcount.

Measure. Last quarter, 640 invoices required rework. DPMO is 640 ÷ 49,600 × 1,000,000 = 12,903. The defect rate per invoice is 5.16%, giving a yield of 94.8%. Cost of poor quality, at US$38 of rework per defective invoice, is US$24,320 a month — US$291,840 a year.

Analyze. A Pareto chart shows three causes account for 78% of defects: missing purchase order (243), wrong general-ledger coding (154), and duplicate entry (102). Together that is 499 of 640. The fishbone exercise adds two candidate causes that the data does not support — staff tenure and month-end volume — so they are dropped.

Improve. Three countermeasures are piloted for six weeks: a mandatory PO field that blocks submission, a coding drop-down limited to the vendor’s historical accounts, and a duplicate-invoice check at entry. Defective invoices fall to 190 a month. DPMO is 190 ÷ 49,600 × 1,000,000 = 3,831, and yield rises to 99.6%. Savings are (640 − 190) × US$38 = US$17,100 a month, or US$205,200 a year. Implementation cost — configuration, testing, and training — is US$46,000, which pays back in 46,000 ÷ 17,100 = 2.7 months. Invoice cycle time falls from 14.2 days to 9.6.

Control. The team monitors a weekly sample of 400 invoices on a p-chart. The baseline centre line was 5.16% with an upper control limit of 8.48%. After improvement the centre line sits at 1.53% with an upper limit of 3.38%. The response plan names the AP manager as owner and requires a cause check whenever a weekly point crosses the upper limit.

The same numbers, read as a sigma comparison: 12,903 DPMO corresponds to roughly 3.7 sigma, and 3,831 DPMO to roughly 4.2 sigma. The project moved the process about half a sigma, which is a realistic outcome for a five-month effort.

What do the sigma levels actually mean?

Sigma levels convert a defect rate into a common scale. The convention used across Six Sigma includes a 1.5-sigma shift to account for long-term drift between how a process performs in a short study and how it behaves over a year.

Two practical notes. A “six sigma process” is not a process with zero defects; it is one expected to produce 3.4 defects per million opportunities. And most service processes sit between two and three sigma, which sounds alarming until you remember that the scale counts opportunities, not transactions — a single invoice with four ways to fail is judged four times.

How long should a DMAIC project take?

A focused project on a single process typically runs three to six months; a cross-functional problem with several systems involved runs six to twelve. The invoices example above fits a 22-week plan: three weeks in Define, five in Measure, four in Analyze, seven in Improve, and three in Control.

The durations are not arbitrary. Measure is slow because data rarely exists in the form the team needs, and the measurement system has to be checked before the baseline is trusted. Improve is slow because a pilot needs enough time to show a stable result rather than a good week.

The failure signal is a project that has spent four months in Analyze. That usually means the team is searching for a sophisticated cause because the obvious one was politically inconvenient, or the data cannot answer the question and nobody wants to restart Measure.

What is the difference between DMAIC and DMADV?

DMAIC improves a process that exists and is underperforming. DMADV designs a new process or product to meet a requirement that current performance cannot reach, using Define, Measure, Analyze, Design, and Verify. The first half looks similar because both start by understanding the requirement; the second half diverges, because DMADV produces a design rather than a countermeasure.

Use DMAIC when the process is capable of meeting the requirement but is not doing so consistently. Use DMADV when the requirement is new, or when the existing design has a structural ceiling — a single approval queue that cannot handle the volume no matter how well it is operated.

There is also a hybrid pattern worth naming: a DMAIC project that concludes the process cannot reach the target without redesign. That is a legitimate finding, and it should end the project with a handover to DMADV rather than a series of increasingly desperate countermeasures.

What makes DMAIC projects fail?

The method is robust; the execution is where it breaks. Six patterns account for most failures.

Solution jumping. The team knows the answer in week one and spends four months writing documentation to justify it. The tell is an Analyze phase with no disproved hypotheses.

A baseline nobody trusts. If the measurement system was never validated, every later comparison is arguable, and the project ends in a debate about data instead of a decision about the process.

Scope inflation. A charter that covers three processes and two departments will deliver nothing in any of them. Narrow scope is not a lack of ambition; it is what makes the control phase possible.

Analysis by opinion. Fishbone diagrams are generative, not evidential. A cause that appears on the diagram and not in the data should be dropped, and dropping it is a skill.

No financial validation. Savings claimed by the project team and rejected by finance destroy credibility for the next project. Bring a finance representative into Define, not into the final presentation.

An abandoned Control phase. The project closes, the dashboard is retired, the champion moves roles, and the process drifts back. Control is the cheapest phase and the one most often cut when the timeline slips.

The trade-off is worth stating plainly. DMAIC costs time up front — often a month before anyone changes anything — and that delay is uncomfortable in organisations that reward visible action. The return is that the change addresses a verified cause rather than the loudest theory, and that the gain is documented well enough to survive a change of management. Teams that skip the front end usually pay for it in a second project on the same problem. If you want the broader view of how quality planning fits alongside scope and schedule, see our guide to project quality management.

Who should be on a DMAIC team?

Five roles matter, and the project fails if any of them is missing.

• Sponsor. Owns the business case, approves the charter, and removes cross-functional blockers. Without a sponsor, a team that needs data from another department stalls in Measure.
• Project lead. Runs the method, owns the gate reviews, and keeps the team honest about what the data supports. This is the Belt role in a formal Six Sigma programme.
• Process owner. Owns the process after the project closes, signs off the control plan, and is accountable for the metric in the dashboard. A project without a named process owner has no Control phase.
• Team members. Frontline operators, analysts, and system administrators who know how the work actually flows. Their value is in the exceptions nobody documented.
• Finance partner. Validates the cost of poor quality and the claimed savings using the organisation’s own accounting definitions.

A useful size is four to six people. Larger teams slow the gate reviews and add coordination cost without adding analytical capability. If the problem genuinely spans functions, run two linked projects with a shared sponsor rather than one project with twelve members.

How does Doitify support a DMAIC project?

DMAIC produces artefacts — a charter, a data plan, a cause list, a pilot schedule, a control plan — and the usual failure is that they live in five different places. The charter is a document, the data is in a spreadsheet, the pilot tasks are in a chat thread, and the control chart is in a slide that nobody opens after the close-out meeting.

Doitify holds the project structure in one workspace: tasks and sub-tasks for each phase, checklists for gate criteria, dependencies for the pilot sequence, milestones for the gate reviews, budgets for the implementation cost, and progress reports so the sponsor sees the same numbers as the team. Doitify Copilot and AI Coach can turn a stated goal into a phase plan with tasks and checklists, which shortens the setup work that often delays Define by a fortnight.

Doitify is our product, so read that as a disclosure. No tool runs DMAIC for you. The method depends on a team looking at a process honestly and following the data where it leads, and a workspace only helps by keeping the evidence together.

Conclusion

DMAIC is a disciplined answer to a common failure: teams that fix the loudest theory instead of the actual cause. Its value is not in the acronym but in the gates — a defined problem, a baseline that can be defended, a verified cause, a tested change, and a control plan that survives the project team’s departure.

The invoices example shows what that discipline buys. A 5.16% defect rate, measured properly, led to three verified causes covering 78% of the problem, a change that paid back in under three months, and a process that moved from roughly 3.7 to 4.2 sigma. None of that required advanced statistics. It required refusing to move to the next phase until the current one had earned it.

Start with one process, one metric, and one page of charter. The rest of the method is mostly the discipline of not skipping ahead.

If this post on DMAIC process was helpful, you might also enjoy How to Measure Team Productivity (2026) and Free Project Roadmap Template.