DMAIC: the 5 phases of a Six Sigma project

In one line

DMAIC (Define, Measure, Analyze, Improve, Control) is the 5-phase sequence a Six Sigma project uses to attack a process problem, relying on data and statistical control at every step.

What it is

According to the cited source, Six Sigma is three things at once: a strategy for improving quality by reducing defects and variation, a data-driven approach that uses statistical process control, and a structured implementation approach that relies precisely on the DMAIC cycle and on certified specialists (the well-known "belts"). DMAIC is the backbone of that third leg: the fixed path that any Six Sigma project follows, whether it is about a machine or an administrative process.

The 5 phases, as the source summarizes them:

• Define: identify who the process customers are and what their requirements are, and which process characteristics are key to satisfying them.
• Measure: catalog the key inputs and product characteristics, verify that the measurement system is reliable, collect data and set a baseline performance (where the process stands today).
• Analyze: turn that raw data into information that explains how the process really behaves. This is where cause analysis tools come in.
• Improve: develop solutions that improve the process capability and compare the results obtained against the baseline set in the Measure phase.
• Control: monitor the process over time to make sure the improvement holds and no unexpected changes appear.

DMAIC shares the same underlying logic as PDCA: in both cases you understand the problem before acting, you test a change, and you verify the result before calling it good. The difference is in size and rigor: PDCA is lightweight and meant for iterating quickly in short cycles, while DMAIC is longer and more formal, typical of a Six Sigma project with statistical measurements, a numerical baseline and an explicit Control phase backed by control charts. It is not unusual for a full DMAIC project to take weeks or months, versus the days of one PDCA turn.

What it is for

It is for not improvising a process improvement project: instead of jumping straight to "the solution" that someone came up with, it forces you to define the problem from the customer's point of view, measure the real situation with data (not with the impression that "something is off"), understand the cause before acting, and confirm with numbers that the change actually worked, while also leaving a control mechanism in place so the improvement is not lost over time. It is the framework Six Sigma projects use, but the 5-phase sequence is useful for any process problem that can be measured.

How it is applied

Each phase has typical tools used to move through it:

• Define: you identify the process, the customer (internal or external) and their requirements, and you limit the scope of the project.
• Measure: you set up a reliable measurement system and collect enough data to know the current performance, typically with statistical process control charts, which show the central tendency and the variation of the process over time.
• Analyze: this is where you usually turn to Pareto (if the problem has several possible causes or categories, to prioritize which ones explain most of the defect) and to root cause tools such as Ishikawa or FMEA (to anticipate and prioritize failure modes before they occur). This site has articles dedicated to each of them within this same pillar, each with its own interactive tool.
• Improve: you design and implement the corrective actions, and you measure again against the baseline set in the previous phase. Pareto and FMEA also come back here to decide which improvement to tackle first according to its impact.
• Control: you leave a control chart running on the critical variables, so that any deviation is detected as soon as it appears. If the process goes out of control, that is when you go back to a cause-and-effect diagram to investigate why.

Real example

The source includes a real case of a hospital that used control charts, the central tool of the Measure and Control phases of DMAIC, to reduce patient falls in a unit (a case documented by Health Quality Ontario). The source does not lay it out as a DMAIC exercise labeled phase by phase, but it follows exactly that logic: measure with real data, act, and verify that the result holds over time.

The control chart tracked the number of falls per week over a whole year. At the start, the process averaged 5.28 falls per week. The team introduced improvements in stages and measured the effect of each one with the same control chart:

1. They changed the post-fall report form (to capture better information about each incident).
2. They added a multidisciplinary post-fall meeting. With these two changes, the average dropped to 3.10 falls per week.
3. They added a post-fall intervention assessment at 72 hours and an audit tool for the post-fall process.
4. They added a 24-hour shift report and put it on the leadership agenda. With the full set of interventions, the average ended at 1.94 falls per week, a reduction of more than 60% from the starting point.

This is exactly what DMAIC asks for: no single big solution was applied all at once, but a series of changes measured one by one against a numerical baseline, until the control chart confirmed that the improvement was real and held week after week.

How to build one

A table with the 5 phases and their guiding questions is enough to get a DMAIC project started:

Phase	Guiding questions
Define	Who is the customer of this process and what do they need? What is the specific problem and what is the scope of the project?
Measure	What data will be used to measure the process? Is the measurement system reliable? What is the current performance (baseline)?
Analyze	What does the data show about how the process behaves? What are the most likely causes (Pareto, Ishikawa, FMEA)?
Improve	What concrete action will be implemented? How does the result compare against the baseline?
Control	What control chart or indicator will watch the process from here on? What is done if the process goes out of control again?

Benefits

• It forces you to define the problem from the real need of the customer, not from an internal assumption
• It sets a numerical baseline before acting, so you can later demonstrate with data whether the improvement worked
• It integrates the cause analysis tools (Pareto, Ishikawa, FMEA) into a single path, at the right moment of the project
• It leaves an active control mechanism in place, instead of ending the project and trusting that the improvement will maintain itself

Limitations to keep in mind

• It is heavier than a PDCA cycle: defining the scope well, building a reliable measurement system and sustaining a control chart take more time and discipline than a quick improvement turn
• It needs data: if the process cannot be measured reliably, the Measure phase becomes weak and all the analysis that follows loses solidity
• The Control step is, just as in RCA, the one most often abandoned in practice; without an active control chart, there is no way to detect in time whether the process drifts again
• It does not replace technical knowledge of the process: it organizes how to use the data and the analysis tools, but it does not tell you on its own what the root cause is

In summary

DMAIC is the extended, data-driven version of the same idea behind PDCA: understand before acting, measure the result, and keep it under control. Its 5 phases (Define, Measure, Analyze, Improve, Control) give a Six Sigma project the exact place to use Pareto, Ishikawa or FMEA, and a final Control phase that keeps the improvement from being lost as soon as the project ends.