DMAIC

Goal

DMAIC is a project approach that improves an existing process whose performance falls short of its customers' expectations or of the set standard. It orders the work into five fixed phases. Each phase asks one question and ends with a deliverable that a review approves.

The approach settles one question: which cause, verified by the data, produces the gap, and which change to the process removes it for good? It protects the project from a solution decided in advance. Nobody proposes a change before the Improve phase, the fourth of five.

The project delivers a changed process and a project file: the charter, the baseline, the verified causes, the pilot result and the control plan that the process owner takes over at closure.

DMAIC also gives each Lean and Six Sigma tool its phase: the Pareto chart in Measure, the Ishikawa diagram in Analyse, the control chart in Control.

Usage

When to use it

• Existing process below its expected level: a lead time, an error rate or a cost departs from the customer's expectation or the internal standard.
• Recurring problem of unknown cause: the team has fixed it several times and the gap keeps coming back.
• Complex or high-risk problem: several causes are possible and a misdirected fix is expensive.
• Service or administrative process: invoices, cases and requests go through the same approach as manufacturing.
• Data available or collectable: timestamps, volumes and error counts exist, or the Measure phase can collect them within a few weeks.
• Gain to hold over time: the Control phase hands the process owner an indicator and a reaction rule.
• Sponsor able to commit a part-time team: a team project lasts several months.
• Management ready to see its assumptions disproved: the Analyse phase sometimes rules out the cause that senior management took for granted.

When not to use it

• Failure that has hit a customer and needs urgent containment: a project of several months comes too late; use 8D problem solving.
• Product or process to design or redesign from scratch: there is nothing to measure yet; use DMADV.
• Known cause and cheap fix: five phases cost more than the gain; test the fix with one turn of the PDCA cycle.

Description

The ASQ, the American professional body for quality, states that each phase builds on the one before. The ISO 13053-1 standard describes good practice for each phase of a Six Sigma project, in manufacturing, service and transactional processes.

Define: state the problem without the solution

The team drafts the project charter. It holds the problem statement, the objective, the scope, the indicator tracked, the team and an outline schedule. The sponsor signs it.

The problem statement describes a gap with a figure, a date and a place: "36% of physiotherapy invoices are reimbursed after more than 15 working days, out of the 4'820 invoices of the first quarter". It names neither cause nor solution. "The department is understaffed" is an assumed cause, "automate data entry" a solution. Either one closes the analysis before it starts.

The team identifies the process's customers, internal and external, and what they expect. The voice of the customer translates those expectations into critical-to-quality characteristics, or CTQs: a lead time, an error rate, a compliance requirement. The project indicator, which Six Sigma writes as Y, measures one of them. A SIPOC sets the process boundaries, from its suppliers to its customers.

Measure: establish the baseline

The team maps the process as it actually runs, with its steps, inputs and outputs. The map records what people do, which often departs from the written procedure.

Next, the team checks the measurement system. A receipt date keyed in by hand, two departments that each count cases their own way, an extract that drops suspended cases: each of these defects produces a false baseline. A figure the team cannot defend in a review is no starting point.

Finally, the team establishes the baseline: the value of Y before any change, over a named period and population. Process capability compares this performance with the limit the customer tolerates. The Pareto chart shows where defects concentrate. The baseline is the reference for the Improve pilot and for monitoring in Control.

Analyse: verify the causes

The Analyse phase looks for the process inputs, written X, that make Y vary. The team first lists the possible causes, with an Ishikawa diagram, the five whys or an FMEA. It then tests each shortlisted cause against the data: a cause is verified when Y differs clearly depending on whether it is present or absent, beyond what chance explains. The Improve pilot proves the effect.

An Analyse review that presents a completed Ishikawa diagram without data presents a list of suspicions. The full root cause analysis approach applies in this phase.

The team drops a hypothesis that the data disprove, even when management took it for granted. Dropping it stops an investment that would have fixed nothing.

Improve: test the solution

The team generates solutions that act on the verified causes, through brainstorming or benchmarking. It assesses them against criteria set in advance: expected effect on Y, cost, lead time, risk. When several Xs interact, a design of experiments measures the effect of each factor and of their combinations in a limited number of runs. The team estimates the financial gain and the expected capability. It also names the critical Xs that the control plan will monitor.

The chosen solution goes through a pilot: a reduced scope, a fixed duration, the same definition of Y and the same type of invoices as the baseline. A control team, measured over the same weeks without the change, separates the effect of the solution from a seasonal effect.

A solution built into the workflow holds better than one left to people's memory. An application check that stops the case carries more weight than training, an email reminder or an internal memo.

Control: hold the gain

The Control phase gives the process owner what it takes to hold the gain without the project team. The word means control of the process in the sense of statistical process control. A reader who takes "control" to mean inspection misreads the phase.

The control plan sets, for Y and for each critical X, the measure, its frequency, the person who takes it, the limit and the planned reaction when the limit is crossed. A control chart separates a real shift from the process's ordinary variation. Standard procedures lock in the new way of working. A mistake-proofing device, or poka-yoke, makes the error impossible or visible on the spot.

The project closes when the process owner has taken over the plan and Y holds at the new level for the period set in the charter. A project closed the day after the pilot has not passed the Control phase.

The tools of each phase

Phase reviews

A phase review, called a tollgate in Six Sigma vocabulary, closes each phase. The sponsor, the project lead and the process owner examine the deliverable against a list of exit criteria. The review decides to move to the next phase, to complete the current one or to stop the project.

The order of the phases follows what each one consumes. Measure needs the Y defined in Define. Analyse tests the causes against the Measure baseline. Improve targets the causes verified in Analyse, and Control monitors the improved Y. A skipped phase leaves the next one with nothing to work on.

Stopping is a legitimate outcome. A Measure review may find a smaller gap than the problem statement claimed. An Analyse review may uncover a cause that can be fixed in a day. In both cases, stopping the project saves months of work.

ISO 13053-1 also describes the roles, expertise and training of the people involved in these projects. Six Sigma vocabulary names them by belts: the Black Belt leads projects full time, the Green Belt leads them alongside a regular job. The sponsor, often called the Champion, argues for the project with senior management.

Team project or kaizen event

In a team project, according to the ASQ, an improvement specialist leads a part-time team over several months.

The kaizen event, which the ASQ also describes, runs through the five phases in about a week. The specialist prepares Define and Measure before the week. The team, released from its usual duties for the event, carries out the other three phases and pilots the changes on site. Full deployment follows the event, with monitoring of its effects. This pace suits a narrow problem whose data already exist.

DMAIC and its neighbours

The Shewhart and Deming cycle is the approach's ancestor. In the 1920s Walter Shewhart laid the foundations of statistical process control, then in 1939 published the loop that Deming would later take up as PDSA. In the 1980s Bill Smith, an engineer at Motorola, applied these ideas to reducing variation, under the name Six Sigma. Mikel Harry and Richard Schroeder set out the method for an executive readership in 1999.

Lea Monday notes two differences from the PDSA cycle, which is Deming's version of the Shewhart cycle. DMAIC measures and analyses before proposing a change, at the fourth step of five, whereas the PDSA cycle tries a change at the second. It also makes process control the last step, which holds the gain even when nobody starts another cycle.

The 8D method responds to a failure that has hit a customer. It first protects the customer with containment actions, then looks for the cause and prevents it from recurring. DMAIC improves a process that may have no open incident, at the pace of a project. DMADV (Define, Measure, Analyse, Design, Verify) designs a new product or process, whereas DMAIC improves an existing one.

The QC Story, which comes from Japanese quality circles, runs an improvement project in fixed steps and presents it in a single document. The A3 problem-solving sheet plays the same role on a single page.

The mistakes that sink a DMAIC project

A solution written into the charter is a common mistake. A project titled "Introduce electronic document management" has decided before Define. Measure and Analyse then justify a decision already taken. The Define review rejects any statement that contains a cause or a solution.

The team can also get bogged down in Define and Measure. It rewrites the charter and hunts for a perfect baseline. The project never reaches Improve. The remedy lies in the schedule: the charter dates each review, and the baseline only needs to separate the gap from measurement noise. A phase can be shortened, never skipped: a team that starts from the data it already holds, without checking how they were collected, analyses data-entry errors instead of the process.

The cause voted for in a meeting replaces the verified cause. The team fills in an Ishikawa diagram, keeps the three causes with the most votes and moves on to Improve. The project then fixes what the team believed, and Y does not move.

A pilot without a control team proves nothing. In summer, delays can fall in every team, and the pilot takes credit for a drop that the season produced.

A Control phase reduced to a final report brings the process back to its original level within a few months. With no named owner, no limit and no planned reaction, nobody sees the drift before it has wiped out the gain.

Variation that is part of the work resists the approach. Monday points this out for healthcare: each patient presents a different case. Clinical guidelines vary in their strength of evidence and leave room for clinical judgement. DMAIC then applies to the part of the process that can be standardised, such as passing on a test result or administering a drug. The clinical decision stays with the clinician.

AI considerations

An assistant reviews the charter. It flags a problem statement that contains a cause or a solution, an objective with no figure or date, a scope that does not say what it excludes. This review takes a few minutes and keeps the solution out of the charter.

It writes the analysis code. A model produces the R or Python code for the Pareto chart, the control chart, the capability calculation or the test that compares the pilot with the baseline. The analyst checks that the code reads the right columns and that the chosen test suits the data. An unsuitable test produces a cause that is verified only on paper.

It suggests candidate causes for the Ishikawa diagram. The list widens the range of causes the team examines, but the model does not know the actual process: each cause stays a hypothesis until the data confirm it.

A model does not know the baseline. Asked about a process it has never seen, it returns plausible figures, and an invented baseline skews the pilot, then the control plan. Health invoices carry sensitive personal data within the meaning of art. 5 let. c FADP. They go to an external AI service only under a processing agreement that complies with art. 9 FADP, concluded by the health insurer.

Examples

Each review in a DMAIC passes a figure to the next. The register follows a project at a health insurer in French-speaking Switzerland on the reimbursement time for physiotherapy invoices.

The Analyse row carries the decision that paid off most. Management wanted to add staff to the review team. The analysis shows that headcount did not explain the delay: hiring more staff would have left the rate at 34%.

Visualisations

The roadmap is a diagram. Its information is a sequence in which a review guards each transition, and the figure shows at a glance that the first change comes in the fourth phase. The tools by phase, the cross-tabulation of delays against the prescription, the comparison with neighbouring approaches and the review register are made of rows and columns, so they are tables.

Cost

Tooling

A charter template and a list of exit criteria per review, in a shared document, are enough to hold the project's structure. A spreadsheet produces the Pareto chart and the descriptive statistics of the baseline.

Statistical software becomes necessary from measurement system analysis onward, for capability calculations, control charts and designs of experiments. Minitab and JMP are the standard tools of the profession. R and Python do the same work, with code the team reviews.

The process map is drawn on the whiteboard during the workshop, then in a process modelling tool when it has to last. A board displayed next to the process carries the Control phase indicator, in front of the people who move it.

Sources

• American Society for Quality, "DMAIC Process: Define, Measure, Analyze, Improve, Control": the definition of the approach, the content and tools of each phase, the boundary with DMADV and the two ways of running it, as a team project or as a kaizen event.
• ISO 13053-1:2011, Quantitative methods in process improvement, Six Sigma, Part 1: DMAIC methodology: good practice for each phase, project management, the roles and training of the people involved, application to service and transactional processes.
• Monday, Lea M. (2022), "Define, Measure, Analyze, Improve, Control (DMAIC) Methodology as a Roadmap in Quality Improvement", Global Journal on Quality and Safety in Healthcare, vol. 5, no. 2: the steps and their tools, the comparison with the PDSA cycle, the origin at Motorola and the limits of the approach in healthcare.
• Harry, Mikel and Schroeder, Richard (1999), Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations, Currency: the presentation of the Six Sigma method for an executive readership.