Beyond Amazing
The Strategy Toolkit

Operations & process

DMAIC

The Six Sigma improvement roadmap. Define the problem, Measure current performance, Analyse root causes, Improve the process, then Control the gains. A disciplined, data-driven cycle for fixing processes whose defects have causes that can be measured and verified.

Also known as Six Sigma improvement cycle, Define, Measure, Analyse, Improve, Control. First set out by Motorola; Six Sigma credited to Bill Smith, roadmap codified in Motorola and GE practice in 1986; the primary source is cited in full below.

Where this is contested

Six Sigma is credited to Bill Smith at Motorola (1986), but the DMAIC roadmap has no single documented author: it grew from Smith and Harry's four-phase MAIC and was formalised diffusely across Motorola and GE practice in the 1990s, with clear ancestry in Shewhart and Deming's plan-do-check-act cycle.

Format
Process / loop
Level
Business unit · Team
Best for
Plan execution · Prioritise
Decision stage
Diagnose · Execute · Review
Difficulty
Intermediate
Time to apply
Weeks to months per project; a typical Green Belt project runs three to six months.

Plate · The model

DefineMeasureAnalyseImproveControl
The 5 steps of DMAIC, worked in sequence.
I

The components

1

Define

Establish what problem is being solved, for whom, and what success looks like in numbers. Produces the charter, the high-level process map and the critical-to-quality requirements.

Signals of strength
A one-page charter with problem, goal, scope and team agreed by the sponsor · The defect traced to a requirement of a named customer · A first-pass estimate of the cost of poor quality · Explicit statement of what is out of scope

2

Measure

Quantify current performance and establish a trustworthy baseline. Includes validating the measurement system itself, mapping the as-is process and collecting data on the defect and its suspected drivers.

Signals of strength
A baseline defect rate or capability figure with a defined counting rule · A process map drawn from observation rather than the procedure manual · Evidence the measurement system is repeatable and reproducible · A data-collection plan the team has actually executed

3

Analyse

Identify and verify the root causes of the defect. Candidate causes are generated broadly, then narrowed using data until the vital few are confirmed.

Signals of strength
Candidate causes tested against data, beyond the brainstorm · A Pareto view showing which causes drive most of the defect · Root causes the process owners recognise as true · Rejected hypotheses documented rather than silently dropped

4

Improve

Design, pilot and implement changes that remove or reduce the verified causes. Solutions are tested at small scale and judged against the baseline before full rollout.

Signals of strength
Countermeasures mapped one-to-one against verified causes · A pilot with before-and-after comparison against the baseline · Risks of the change assessed before rollout · Improvement demonstrated in the data as well as the meeting

5

Control

Make the improvement permanent. Standardise the new method, monitor the metric, define the reaction plan for drift, and transfer ownership from the project team to the line.

Signals of strength
Updated standard work and training records · A control chart or equivalent ongoing monitor with response rules · A named process owner accountable for the metric · Benefits tracked for months after closure, beyond the final tollgate

II

When it earns its keep

  • An existing process is producing defects, delays or rework at a rate you can measure, and the causes are not obvious enough to fix by inspection.
  • Previous fixes have not stuck. DMAIC's Measure and Control phases exist precisely because intuitive fixes tend to treat symptoms and then decay.
  • The problem is worth a project. A properly run DMAIC cycle consumes weeks of effort, so the defect should carry real cost in money, time or customer harm.
  • You need the improvement to survive an audit or a handover. The tollgate structure leaves an evidence trail from baseline to verified result.

And when it doesn't

  • The cause and the fix are already known. If a valve is leaking, replace the valve; running a five-phase project around a known answer is ritual rather than rigour.
  • You are designing a new process or product rather than improving an existing one. Six Sigma practice uses DMADV or Design for Six Sigma for that.
  • The work is exploratory or creative and the value lies in variation itself. Applying DMAIC to research and innovation is the core of the 3M critique.
  • There is no capacity to gather data. DMAIC without measurement collapses into opinion with extra meetings; a Five Whys session may serve better.
III

How to run it

Before starting, gather the inputs the analysis depends on:

  • A measurable defect or performance gap, with an initial estimate of its cost to the business.
  • Access to process data, or the means to collect it: operational systems, quality records, or a data-collection plan the team can actually run.
  • A sponsor who owns the process and can authorise changes to it, plus a team that includes people who do the work daily.
  • An agreed operational definition of the defect, so that everyone counts the same thing the same way.
  • Time and permission to hold the gains: Control is a phase, and a budget line, rather than a sentence at the end of the report.
  1. 1

    Charter the project and Define the problem

    Write a one-page charter: the problem in numbers, the goal in numbers, the scope, the team and the customer harmed. Trace the defect to a critical-to-quality characteristic a named customer actually cares about. A Define phase that cannot say who suffers and by how much is not finished.

  2. 2

    Measure the current process

    Map the process as it actually runs, and establish the baseline: defect rate, cycle time, variation. Check that the measurement system itself is trustworthy before trusting what it tells you; a gauge study on a subjective quality score is rarely wasted.

  3. 3

    Analyse to confirm root causes

    Generate candidate causes with tools such as the fishbone diagram and Five Whys, then verify them against data using Pareto analysis, stratification, scatter plots or hypothesis tests. The discipline is in the verification. A cause the data does not support remains a suspicion, whatever the room believes.

  4. 4

    Improve: design, pilot and prove the fix

    Develop countermeasures aimed at the verified causes, pilot them on a limited scale, and compare results against the baseline. Resist the urge to bundle every good idea into the change; if the pilot improves, you need to know why.

  5. 5

    Control: lock in the gains and hand over

    Standardise the new method, set up ongoing monitoring such as control charts, define the response plan for when the metric drifts, and hand ownership back to the line. Most failed DMAIC projects fail here, quietly, months after the closing presentation.

  6. 6

    Review and select the next project

    Confirm the financial and customer benefit against the charter, capture what the team learned, and feed the next-worst problem into the pipeline. DMAIC is a loop at programme level even though each project runs left to right.

IV

Reading the result

A verified process improvement with an evidence trail: a chartered problem, a measured baseline, data-confirmed root causes, a piloted and proven fix, and a control plan that holds the gain after the project team disbands.

  • Judge the project by the Control phase, and only then by the Improve phase. An improvement without a monitoring and response plan is a temporary condition.
  • Compare the closing metric to the charter's goal and baseline. If the goal moved during the project, ask why.
  • Look for the causal chain: every countermeasure should point back to a cause that was verified with data in Analyse. Fixes without verified causes are guesses that happened to get implemented.
  • DMAIC descends from Shewhart and Deming's plan-do-check-act cycle; read it as PDCA with the study phases expanded and formalised for project work.
V

A worked example

An insurance contact centre attacks repeat calls on home claims

The claims contact centre of a UK home insurer handles 40,000 calls a month. First-contact resolution on new home claims sits at 61%, and 28% of claimants call back within a week to chase progress or correct details. Repeat calls cost roughly 90,000 pounds a month in handling time and drive most complaints. A Green Belt project is chartered to raise first-contact resolution to 75% within five months.

Define
Charter agreed with the head of claims: problem stated as a 28% seven-day call-back rate on new home claims against a 12% peer benchmark; goal of 75% first-contact resolution; scope limited to new claim notifications, excluding escape-of-water surge events. The critical-to-quality requirement is defined from the claimant's side: 'I know what happens next and when'.
Measure
Listening samples showed the QA form scored politeness heavily and completeness barely, so the measurement system was fixed first. Baseline confirmed at 61% first-contact resolution. Call-reason codes proved unreliable, so a two-week manual re-coding of 1,200 repeat calls built a dataset the team could trust.
Analyse
Pareto analysis of the re-coded calls: 64% of repeat calls trace to three causes, incomplete information captured at first notification, no follow-up date given to the claimant, and handlers unable to see supplier appointment systems. Stratification showed the gap widest on evening shifts, where handle-time pressure peaked. The popular theory that new starters drove the problem was tested and rejected; tenure made little difference.
Improve
Three countermeasures piloted on two teams for six weeks: a revised intake script with a mandatory next-step-and-date commitment, read-only access to the two largest repair suppliers' booking systems, and removal of average handle time from individual scorecards, retained at team level only. Pilot teams reached 76% first-contact resolution; calls lengthened by 40 seconds, comfortably repaid by fewer call-backs.
Control
Script and supplier access rolled out with updated training. Daily first-contact resolution and seven-day call-back rates plotted on control charts by team, with a written response plan: any team below the lower limit for three days triggers side-by-side coaching. Ownership handed to the operations manager; finance tracks the benefit monthly for two quarters.

The read. First-contact resolution stabilised at 74%, just short of charter, and call-backs fell to 15%, worth roughly 47,000 pounds a month net of longer calls. The honest reading: the largest single gain came from changing what handlers were scored on, which cost nothing and had been available all along. The control charts earned their keep in month four, when winter surge staffing pulled the metric down and the response plan caught it within a week.

VI

Pitfalls

  • Starting with a solution and running the phases backwards to justify it. If the countermeasure was decided before Analyse, the project is theatre.
  • Measuring what is easy rather than what matters, and skipping measurement-system checks entirely. A baseline built on an unreliable gauge poisons everything downstream.
  • Tollgate bureaucracy: treating phase reviews as document inspections rather than decision points, which slows projects until the organisation concludes the method itself is the problem.
  • Doing improvement to frontline staff rather than with them. The people who run the process daily hold most of the causal knowledge and all of the power to make a fix stick or die.
  • Declaring victory at Improve. Gains that are not standardised, monitored and owned decay, and the erosion is rarely announced.
VII

What the critics say

Applied indiscriminately, Six Sigma's variance-reduction logic can suppress the exploration innovation requires. Hindo's account of 3M under James McNerney documented a company whose invention pipeline weakened as Six Sigma discipline spread into the labs, and whose next chief executive pulled it back out of research to recover creativity.

Hindo, B. (2007) 'At 3M, A Struggle Between Efficiency and Creativity', BusinessWeek, 11 June 2007.

Headline failure-rate claims deserve scrutiny in both directions. Figures such as '60% of process-improvement initiatives fail' and QualPro's claim that 91% of large firms announcing Six Sigma programmes trailed the S&P 500 circulate widely, but rest on loose definitions of failure and weak causal designs, much as the movement's own savings claims often did. The honest position is that programme-level evidence is mixed.

Chakravorty, S. S. (2010) 'Where Process-Improvement Projects Go Wrong', The Wall Street Journal, 25 January 2010.

Academic reviewers note that Six Sigma, DMAIC included, codifies existing quality engineering and applied statistics rather than contributing new theory, and that its distinctive element is organisational, the parallel structure of belts and chartered projects. Its theoretical base remains thin relative to its commercial footprint.

Schroeder, R. G., Linderman, K., Liedtke, C. and Choo, A. S. (2008) 'Six Sigma: Definition and underlying theory', Journal of Operations Management, 26(4), pp. 536-554.
VIII

Sources and further reading

  • American Society for Quality, 'The Define Measure Analyze Improve Control (DMAIC) Process'. ↗
  • Pyzdek, T. and Keller, P. (2018) The Six Sigma Handbook, 5th edn. New York: McGraw-Hill.
  • Hindo, B. (2007) 'At 3M, A Struggle Between Efficiency and Creativity', BusinessWeek, 11 June 2007. ↗
  • Schroeder, R. G., Linderman, K., Liedtke, C. and Choo, A. S. (2008) 'Six Sigma: Definition and underlying theory', Journal of Operations Management, 26(4), pp. 536-554.

Pairs well with PDCA Cycle·Fishbone Diagram·Pareto Analysis·Five Whys·Theory of Constraints·SIPOC·compare side by side

Near neighbours (computed from shared tags)·AI Risk Management Framework (NIST AI RMF)·Customer Journey Mapping·Hoshin Kanri