DMAIC

DMAIC (pronounced "duh-may-ick") is the acronym of the five phases of a Six Sigma project: Define, Measure, Analyze, Improve, Control. It is the backbone of the method: a Six Sigma project without DMAIC is not a Six Sigma project, it is an action plan.

What sets it apart is less the tools than the order. Each phase ends with a gate review — a milestone, often called a toll-gate — where it is decided to go on, loop back or stop. That discipline is what distinguishes DMAIC from common sense: it forbids proposing a solution before having measured, and generalising before having proved.

Define — frame the problem in measurable terms, identify the customer and what matters to them, delimit the scope. Typical deliverables: project charter, SIPOC, voice of the customer translated into CTQs.

Measure — establish current performance with data, not with impressions. This is where the credibility of the project is decided: if the measurement system is not reliable, everything that follows is noise. Hence the gauge R&R study before any large-scale collection.

Analyze — find the root causes, and prove them. The tools range from the Ishikawa diagram to hypothesis tests. The requirement is the same: a suspected cause is retained only if the data supports it.

Improve — design, test and deploy the solutions. A design of experiments makes it possible to know which factors really weigh, rather than changing one parameter at a time for six months.

Control — lock in the gain. Monitoring plan, control charts, updated standard, handover to the process owner. Without this phase, the process returns to its initial state within a few months — and that is what happens most often.

DMAIC is expensive in time: a project run properly occupies a project leader for several months. That cost is justified only in one specific situation — a quantifiable, recurring problem whose cause nobody knows. It is that last condition that decides.

When the cause is known and the solution obvious, rolling out five phases to arrive where one stood on day one discredits the method with those who have to sit through it: a short workshop is enough. When the problem is not measurable — a climate, a strategic decision — DMAIC has nothing to bite on; it needs data.

The right clue lies in one question put to the sponsor: "if you were handed the solution tomorrow morning, which one would it be?" A confident answer signals that an action plan is needed, not a project. Three contradictory answers in the same room signal the opposite.

Invoicing department, 12,400 invoices issued per month. The customer rejects 6.2 % of them, i.e. 769 invoices to redo, with a rework timed at 22 minutes. That makes 282 hours per month, nearly two full-time people busy redoing what has already been done once.

Define. The problem is written with these figures and no other way: "bring the customer rejection rate from 6.2 % to under 2 % on the invoices issued by the site, within six months". A scope, a measure, a target, a deadline. Without those four elements, the Improve phase will have no criterion to decide between two solutions.

Measure. First reflex, check the measurement system before the data: three clerks classified the same thirty rejections and agreed on the cause in only 71 % of cases. Nearly one rejection in three was therefore filed in a category that depended on who was looking. The categories had to be redefined before anything could be used — that is the time everyone wanted to skip.

Analyze. Once the categories were reliable, the Pareto of causes gives: wrong delivery address 41 %, missing item reference 27 %, inappropriate VAT rate 14 %, miscellaneous 18 %. Two causes carry 68 % of the rejections, and both arise at order entry — not at invoicing, which was nonetheless taking all the blame.

Improve. A blocking check at entry, which refuses a delivery address unknown to the customer and requires an existing item reference. The rejection rate drops from 6.2 % to 1.9 %, i.e. 236 invoices instead of 769.

Control. Weekly tracking on a control chart, with a reaction defined in advance if the rate goes back above 3 %. Six months after closure, it stands at 2.1 % — slightly up, still under target, and watched by someone whose job it now is.

The net gain is written without argument: 195 hours of rework avoided every month. But the most instructive figure of the project remains the one from the Measure phase: without those 71 %, the team would have built its Pareto on misassigned categories and treated the wrong cause with a great deal of method.