Leadership Framework
How I Run a DMAIC Cycle
DMAIC is the engine of Six Sigma process improvement: Define, Measure, Analyze, Improve, Control. It is also the most over-invoked framework in business, applied to problems that needed a checklist and skipped on problems that needed exactly this. This page gives you the five phases as I actually run them, the gates between them, where the After-Action Review feeds in and where it does not, and a one-page charter you can open this week.
Definition
What DMAIC actually is.
DMAIC is a five-phase cycle for improving an existing process that produces a measurable defect. It came out of Motorola’s Six Sigma program in the 1980s and was scaled across industry by General Electric in the 1990s; the phase names — Define, Measure, Analyze, Improve, Control — have been stable for three decades because the sequence works. Each phase ends at a gate. You do not pass the gate until the phase’s exit question has a written answer.
What DMAIC is not: a project-management framework for building something new, a brainstorming format, a slide template, or a synonym for “we improved the process.” It exists for one situation — a process you already run, a defect you can count, and a defect rate worth the overhead of a disciplined cycle. If you cannot name the defect and count it, you are not ready for DMAIC. If one obvious fix would close the problem, you do not need it.
The Core Loop
The five phases, gate by gate.
Every phase below ends with an exit gate — one question that must have a written answer before the next phase opens. The running example is real: the DMAIC cycle I ran on this site’s own publishing pipeline after a string of failed deploys, documented end-to-end in the publishing workflow case study.
The five-phase cycle. Control is not the end — it is the standing watch that decides whether the cycle stays closed.
Phase 01 · Define
Name the defect, the scope, and the customer of the fix.
Purpose: one written problem statement everyone can repeat.
Define ends with a charter, not a feeling. The problem statement names the process, the defect, the period observed, and the cost of doing nothing — in numbers, not adjectives. Scope is written as in/out pairs: which process steps are inside the cycle, which adjacent problems are explicitly not. The most useful sentence in any Define phase is the one that begins “This cycle will not address…”
Exit gate: can a person outside the team read the charter and state the defect, the baseline period, and the goal without asking a question?
Publishing pipeline: the defect was defined as “a deploy requiring a corrective follow-up deploy.” Not “deploys feel risky” — a countable event with a yes/no test. Scope excluded content quality entirely; this cycle was about the pipe, not the water.
Phase 02 · Measure
Establish the baseline before touching anything.
Purpose: a defect rate you would defend to a skeptic.
Measure is where discipline is won or lost. Every term in the defect definition gets an operational definition — the test a stranger could apply and reach your count. Then you collect the baseline: how often, over what period, from what records. The temptation is to start fixing while you measure. Resist it. A fix applied mid-baseline destroys the baseline, and you will never again know whether you improved anything.
Exit gate: is the baseline written down, with its source records named, before any change ships?
Publishing pipeline: the baseline came from the deploy process log — every deploy, its date, its outcome, its rework. The log lives in a tracker workbook with live-formula KPIs, which meant the baseline was a query, not a memory.
Phase 03 · Analyze
Find the vital few causes, not the plausible many.
Purpose: causes proven against the data, ranked by contribution.
Analyze is a narrowing exercise. List every candidate cause, then make the data vote: a Pareto pass over the defect log shows which causes account for most of the failures, and 5 Whys pushes each top cause past its symptoms to something structural. The phase ends when you can say “these two or three causes account for most of the defect rate, and here is the evidence” — not when the whiteboard is full.
Exit gate: is each named root cause backed by counts from the defect log, not by the room’s confidence?
Publishing pipeline: the Pareto pass showed two causes dominating — file permissions silently reset by the host’s zip extraction, and verification done in a cached browser that showed the old page as the new one. Neither was the cause anyone proposed in the first meeting.
Phase 04 · Improve
Counter the proven causes. Pilot before you commit.
Purpose: the smallest set of changes that closes the gap.
Improve is not a brainstorm — the causes were chosen in Analyze, and the improvements answer them one for one. Each countermeasure gets a pilot: run it on real work, measure the defect rate under the new method, compare against baseline. Improvements that survive the pilot get written into the standard process. Improvements that merely sound smart do not ship.
Exit gate: does the piloted defect rate beat the baseline on the same operational definition?
Publishing pipeline: a permissions-walker script answered the first cause; a verification checklist with hard gates — byte-count check, string-presence check, private-window visual pass — answered the second. Both were piloted on live deploys before becoming the standard.
Phase 05 · Control
Make the gain hold after you stop watching.
Purpose: a control plan that survives attention moving on.
Most improvement dies here, quietly, about six weeks after the celebration. Control means the new method is the documented standard, the KPI stays on a chart someone owns, and there is a written response plan: if the defect rate crosses the line, this person re-opens the cycle. A DMAIC effort without a control plan is an expensive way to be good at something for one quarter.
Exit gate: is there a named owner, a monitored KPI, and a written trigger for re-opening the cycle?
Publishing pipeline: the checklist became the standing SOP, the KPI workbook tracks every deploy against six metrics, and the re-open trigger is explicit — a corrective deploy within 48 hours of any release sends the cycle back to Define with the new failure as evidence.
Series Connection
Where the AAR feeds in — and where it does not.
Series 03 closed with a promise: run After-Action Reviews consistently for a quarter and you will have the baseline data the Measure phase needs. Here is the mechanism. An AAR produces a written record of one event — what was planned, what happened, why they diverged. A stack of AARs over the same process is a defect log that wrote itself. When the publishing-pipeline cycle reached Measure, the baseline did not have to be reconstructed from memory; it was sitting in the after-action record, dated and signed.
But the two tools are different scales, and confusing them wastes both. The AAR is event-scale: one mission, one launch, one deploy, reviewed in thirty minutes. DMAIC is process-scale: a defect rate across many events, addressed over weeks. The AAR asks why did plan and reality diverge this time? DMAIC asks why does this process produce defects at this rate? If a single AAR finding fully explains the problem and one change closes it — make the change and skip the ceremony. DMAIC earns its overhead only when the defect recurs after the obvious fixes, which is precisely the signal that the cause is structural rather than situational.
The handoff also runs the other direction. The Control phase’s re-open trigger is, in practice, an AAR: the defect recurs, the team reviews the event, and the AAR’s findings become the opening evidence of the next Define. The two frameworks are one loop at two scales.
Adjacent Practices
DMAIC, PDCA, Kaizen event — not the same thing.
Three improvement cycles, routinely used as synonyms. They share ancestry — all descend from the same statistical quality tradition — but they carry different overhead and earn it in different situations.
| Dimension | DMAIC | PDCA | Kaizen Event |
|---|---|---|---|
| Lineage | Six Sigma — Motorola, scaled by GE | Shewhart–Deming cycle, quality movement | Toyota-lineage lean practice |
| Trigger | A recurring, countable defect worth a chartered cycle | Any change worth testing — the everyday loop | A known process area needing focused attack |
| Time scale | Weeks to months, gate by gate | Days to weeks, repeating continuously | Three to five days, full-time team |
| Data demand | High — baseline and proof at every gate | Light — enough to check the act | Moderate — measured before/after the week |
| Typical output | Verified defect-rate reduction + control plan | An adopted or rejected change | A redesigned process step, implemented same week |
| When I reach for it | The defect survived the obvious fixes | Routine course corrections | The team can stop the line and swarm |
The honest tell: PDCA is the default loop a healthy team already runs without naming it. DMAIC is what you escalate to when PDCA keeps “fixing” the same problem — the recurrence is the evidence that nobody has actually found the cause yet.
Failure Modes
Where DMAIC cycles go wrong.
Each of these shows up as a visible symptom mid-cycle. Catch the symptom at the gate and the cycle recovers; let it through and the final report will be fiction with charts.
- The team starts at Improve. The solution was chosen before the cycle began, and Define through Analyze are theater to justify it. Fix: the charter names the defect, not the solution. If a solution appears in the problem statement, strike it and ask what defect it was supposed to cure.
- Measure has no operational definition. Two people count the defects and get different numbers, so the baseline moves depending on who is asked. Fix: write the yes/no test for one defect first. If a stranger applying the test would reach your count, the definition is operational. If not, the baseline is an opinion.
- Analyze stops at the first plausible cause. The room agrees quickly, which feels like progress and is usually anchoring. Fix: make the data vote before the room does — Pareto the defect log, then 5 Whys the top contributors. The publishing-pipeline cycle’s real causes were proposed by nobody in the first meeting.
- Improvements ship without a pilot. The change goes straight to standard because it obviously helps. Six weeks later nobody can say whether the defect rate moved. Fix: every countermeasure runs on real work against the baseline definition before it is adopted. No pilot, no adoption.
- Control is a paragraph, not a plan. The report ends with “the team will monitor the process going forward.” Nobody is named; nothing is charted; the gain decays silently. Fix: Control means a named owner, a charted KPI, and a written re-open trigger. If those three are missing, the cycle is not closed — it is abandoned at altitude.
- DMAIC is applied to everything. Every hiccup gets a charter, and the framework drowns in its own overhead until the team resents it. Fix: hold the entry bar — a countable defect, a recurring pattern, survival past the obvious fixes. Everything else gets a checklist, an AAR, or a plain decision.
One-Page Template
Copy this and open a cycle Monday.
This is the charter page I actually open with. One page, five gates. If the problem will not fit on it, you have two problems — charter them separately.
DMAIC CYCLE CHARTER Process: ____________________________________________ Cycle owner: ____________________________ Opened: ________ Sponsor: ____________________________________________ DEFINE Defect (countable event): ____________________________________ (A yes/no test a stranger could apply. No adjectives.) Cost of doing nothing: ____________________________________ In scope: __________________________________________________ NOT in scope: ________________________________________________ Gate 1 passed: ____ (date) Charter readable by an outsider? MEASURE Baseline period: ______________ Source records: ____________ Baseline rate: ______ defects / ______ opportunities Gate 2 passed: ____ (date) Baseline written before any change? ANALYZE Root cause 1: _________________________ Evidence: ___________ Root cause 2: _________________________ Evidence: ___________ Root cause 3: _________________________ Evidence: ___________ Gate 3 passed: ____ (date) Each cause backed by counts? IMPROVE Countermeasure 1: ____________________ Pilot result: ________ Countermeasure 2: ____________________ Pilot result: ________ Gate 4 passed: ____ (date) Piloted rate beats baseline? CONTROL New standard documented at: __________________________________ KPI + chart owner: ___________________________________________ Re-open trigger: ___________________________________________ Gate 5 passed: ____ (date) Owner, KPI, trigger all named? CLOSE-OUT Final rate: ______ vs baseline ______ Verified by: ________ Cycle owner: ________________________ Date: ________________
The gates are the framework. A team that fills the boxes but skips the gate questions is doing paperwork, not improvement.
Worked Example
See the framework run on a real workflow.
The publishing-pipeline cycle referenced throughout this page is documented in full on this site — the 5 Whys passes, the Pareto analysis, the reusable checklist with verification gates, and the KPI framework that became the control plan. The artifacts below are the cycle’s paper trail, plus the series pages this framework builds on.
- AAR + DMAIC: the GoDaddy cPanel publishing workflow (the worked example, end to end)
- Publishing Process KPI Tracker — the live control-plan workbook (Excel)
- Workforce Stability — charter, risk register, and program-scale discipline
- Series 01: How I Write a Project Charter (the Define phase’s parent document)
- Series 02: How I Run a Risk Register (where a cycle’s risks live between gates)
- Series 03: How I Run an After-Action Review (the Measure phase’s data source)
Series Complete
Four frameworks, one operating discipline.
This closes the Leadership Frameworks series. The charter states the plan, the risk register guards it, the AAR converts each event into evidence, and the DMAIC cycle turns recurring evidence into a process that stops failing. Together they are one discipline: write it down, measure it honestly, and make the fix hold.