Six Sigma improves processes by measuring variation and removing its causes, not its symptoms — the paper on pubmed.ncbi.nlm.nih.gov (Reviews on Environmental Health) treats its DMAIC sequence as a project frame. The tools work in order: diagrams organise causes, FMEA ranks failure modes, a control chart decides what counts as a signal.
Quick Overview
What you’ll learn:
- Why DMAIC has that order and what shortening it breaks
- What a Pareto diagram settles, and what an Ishikawa diagram settles instead
- When FMEA applies, and why a consistent scoring scale decides its worth
- What a control chart will not tell you, although it looks as if it does
Who this article is for:
- Operations managers running a process improvement programme
- Team leads expected to justify a change with data rather than impression
- Anyone preparing for a role inside an improvement project
Reading time: 7 minutes
DMAIC: Why the Order Matters
DMAIC is a sequence of improvement stages: define the problem, measure the current state, analyse the causes, improve, and control the result. The paper on pubmed.ncbi.nlm.nih.gov (Reviews on Environmental Health) describes the DMAIC approach combined with the theory of constraints as a way of running a quality project end to end — a frame for the work, not a menu of techniques.
The most common error is jumping from define straight to improve. The team knows the answer before it has measured the problem, so the measure stage degenerates into gathering evidence for a conclusion already reached. That costs twice over: a change goes in with an unknown effect, and there is no baseline left to compare the result against.
The second common omission is the control stage. Without it an improvement lasts exactly as long as the team’s attention, and the process drifts back to its old behaviour with no visible event marking the return. Control is not documentation — it is a named owner and a measurement that continues after the project closes.
Pareto and Ishikawa: Different Decisions, Different Stages
A Pareto diagram ranks causes by frequency or cost and answers a single question: what to work on first. Its value depends entirely on whether the categories are mutually exclusive. A chart in which “operator error” and “no work instruction” sit side by side as separate entries counts the same cause twice and points at a priority that does not exist.
An Ishikawa diagram — the cause-and-effect or fishbone diagram — answers a different question: which causes could produce this effect. It is a divergent instrument, meant to widen the list of candidates by grouping them into areas: people, method, machine, material, measurement, environment. Using it to declare a root cause is a misunderstanding; what follows an Ishikawa session is verification against data.
The order between them follows from the stage. In analysis you first widen the list of causes, then narrow it with measurement, and Pareto ranks whatever survives. Reversed, you get priorities set on a list that was never complete.
FMEA: Risk Assessed Before the Failure
Failure mode and effects analysis is an anticipatory technique: it identifies the ways a process or product can fail and ranks them by severity of effect, likelihood of occurrence and detectability. The technique is described by the IEC 60812 standard, covering both FMEA and FMECA — worth reading before an organisation starts building its own scoring sheet.
The systematic review on pubmed.ncbi.nlm.nih.gov (Journal of Evaluation in Clinical Practice) surveys the literature on FMEA in healthcare and describes it as a reliability management tool that identifies potential failures before they occur. The practical lesson is narrow and useful: the technique’s output is only as comparable as the scoring definitions behind it, so the definitions belong in writing before the first workshop rather than after it.
One note on detectability: it is the column most often filled in optimistically. A team records that a failure “would certainly be noticed” without naming the mechanism that would notice it. Detectability with no named mechanism is an assumption, not an assessment.
Control Charts: What They Actually Say
A control chart plots measurements over time with limits derived from the process’s own variation. The paper on pubmed.ncbi.nlm.nih.gov (Quality & Safety in Health Care) describes statistical process control as a tool for distinguishing natural variation from variation attributable to a specific cause — and that distinction is the whole value of the technique.
The managerial consequence is uncomfortable: reacting to every individual deviation inside the limits of natural variation does not improve a process, it destabilises it. A control chart exists to separate the moment that warrants a response from the noise that should be left alone.
The diagnostic-laboratory review on pubmed.ncbi.nlm.nih.gov describes the method as problem solving and continuous improvement combined with quantitative statistical process control, built on the DMAIC sequence — which is where control charts do their work. The statistical thresholds behind the method’s name describe process capability: the relation between the spread of results and the limits set by requirements, measured on one process and one sample. Outside that context such a number says nothing about another process.
The Black Belt’s Role, and the Rest of the Team
Black Belt is a role rather than a certificate on a wall: it runs the improvement project, owns correctness of method, and makes sure conclusions follow from the data. A Green Belt works inside the project, joining method to knowledge of the process. The sponsor allocates people’s time and accepts the result — without one, an improvement project competes with day-to-day work for attention and loses.
The function most often left out is the process owner, who keeps the change in place once the project ends and watches the control chart. Without it, a project finishes with a report rather than a changed process.
Read Also
- Lean Six Sigma: principles, tools and implementation — how the two improvement traditions combine; the DMAIC frame used here is the one on
pubmed.ncbi.nlm.nih.gov - Benefits of using Lean Six Sigma tools — where the toolkit pays off and where it does not; the control-chart evidence cited above sits on
pubmed.ncbi.nlm.nih.gov - Value stream mapping in practice — finding the place where a process stalls, before analysing causes
Build Your Skills
This topic is developed in the IT operations analytics - process optimization and APQP & PPAP – product and process quality planning courses. The first works on measuring and analysing operational data; the second on planning process quality, where FMEA is a mandatory instrument. Contact us to match the scope to the process you are improving.
Frequently Asked Questions (FAQ)
How does DMAIC-based improvement differ from lean management?
Six Sigma addresses variation and its causes — the DMAIC paper on pubmed.ncbi.nlm.nih.gov (Reviews on Environmental Health) frames the approach as reducing waste, variation and work imbalance — while lean management addresses flow and waste. In practice they are combined, because they answer different questions: lean shows where a process stalls, while variation analysis explains why the result scatters between repetitions. A programme built on only one of them stops at the first problem of the other kind.
Which certification level makes sense: White Belt, Green Belt or Black Belt?
It depends on the role in a project. The introductory level supplies the vocabulary and an understanding of the DMAIC sequence for people who take part in projects. A Green Belt works inside the project and runs the analyses. A Black Belt leads the project and owns the method. Choose by what the person will actually do afterwards, rather than by the order of the belts.
When do you use FMEA, and when is a post-incident analysis enough?
FMEA applies before a process starts or before it changes, to assess the ways it could fail. A post-incident analysis concerns a failure that has already happened and looks for its cause. The first lowers the likelihood, the second closes a specific case, and neither substitutes for the other.
Do Pareto charts and control charts need templates or statistical software?
Templates speed the work up but settle nothing: a Pareto diagram and a control chart are both built in a spreadsheet. Statistical software earns its keep for capability analysis and designed experiments. Start with a properly defined measurement — no template repairs data collected inconsistently.