Six Sigma — Fundamentals
DMAIC — the five phases
DMAIC structures a Six Sigma improvement project into five sequential phases: Define (clearly define the problem, project goals, and customer requirements — establishing what "success" actually means before any analysis begins), Measure (establish current process performance through actual data collection, not assumption — creating a baseline against which improvement is later measured), Analyze (identify the root causes of the problem or defects, using the Measure phase's data rather than guesswork), Improve (develop, test, and implement solutions addressing the identified root causes), and Control (ensure the improvement is sustained over time, through monitoring and process controls, rather than reverting to the prior state once initial attention fades). This phase order matters structurally — skipping ahead (say, jumping to Improve without genuinely completing Measure and Analyze) is a common and costly mistake, since solutions developed without solid root-cause analysis often address symptoms rather than the actual underlying problem.
Why "Measure before Analyze" is a hard rule, not just good practice
A frequently tested conceptual point: Six Sigma insists on establishing measured, data-based process performance (Measure) before attempting root-cause analysis (Analyze), because analysis based on assumption or anecdote rather than actual data risks misidentifying the real cause of variation — teams that skip rigorous measurement often converge on an intuitively appealing but factually incorrect root cause, then implement an "Improve" solution that doesn't actually address the real problem. This is the concrete, practical reason DMAIC's phases are sequenced and not simply a checklist that can be reordered for convenience.
Process variation — common cause vs. special cause
A foundational statistical distinction Six Sigma relies on throughout: common cause variation is the natural, inherent variation present in any process, arising from the many small factors always at play (material variation, minor environmental fluctuations) — a stable process still varies to some degree due to common causes, and this variation is generally addressed by fundamentally redesigning the process, not by reacting to individual instances. Special cause variation is variation from an identifiable, specific, and often intermittent source (a machine malfunction, an unusual input batch) — special cause variation is generally addressed by identifying and eliminating that specific source. Confusing the two is a classic Six Sigma error: treating normal common-cause variation as if each instance has a specific findable cause wastes effort chasing phantom causes, while treating a genuine special-cause problem as unavoidable common-cause variation misses addressable, fixable issues.
Voice of the Customer — grounding "Define" in real requirements
The Define phase (above) relies heavily on Voice of the Customer (VOC) — systematically gathering and translating actual customer requirements and expectations into specific, measurable process/product requirements, rather than assuming what matters to the customer based on internal assumption. This matters because a Six Sigma project can technically reduce process variation and defects while still missing the point if it's optimizing against the wrong requirement — VOC exists specifically to ground the entire DMAIC effort in what customers (internal or external) actually need, from the very first phase onward.