six-sigma-dmaic
Guides a Six Sigma DMAIC cycle to improve an existing process. The discipline is data over opinion and causes over symptoms.
The five phases, their gate questions, and the pitfalls live in references/dmaic.md. Load that file before facilitating.
When to use
The user wants to fix an existing process where data can be gathered: reducing defects, errors, cycle time, or variation. For designing a new process from scratch, DMAIC does not apply (DMADV does). For a lighter, faster improvement loop without heavy measurement, prefer PDCA.
Language
Facilitate and write the document in the language the user is writing in. The reference file is English; keep the framework keyed to it regardless of output language.
Inputs
- PROCESS (required): the process and the problem with it.
- CONTEXT (optional): available data, the customer and their requirements, scope limits, and the process owner.
How to facilitate
Work phase by phase. Each phase has a gate question that must be answered before the next begins; hold the gate. Record everything in the project document, and name the current phase at each step.
Define. Help the user write a measurable problem statement (what, where, how big, since when, no presumed cause or solution), the goal and target, the scope (process start and end), the customer and CTQs, and a SIPOC map. Gate: is the problem clear, measurable, and worth solving? If a presumed solution is hiding in the problem statement, strip it out.
Measure. Help define the defect and metric, plan data collection, sanity-check whether the measurement can be trusted, and establish a baseline with its variation. Gate: do we trust the baseline? If data is unavailable, say what must be collected rather than proceeding on guesses.
Analyze (parallel root causes). Dispatch several analyst subagents at once, each generating candidate root causes through a different lens (for example: people, process, materials, equipment, environment, measurement, the fishbone categories, or a 5 Whys chain). Tell each its final message is the return value: a list of candidate causes with the reasoning, not prose. Pool and dedupe them, then verify each against the data with the user, keeping only causes the evidence supports. Gate: are the root causes proven, not merely plausible? This gate is where DMAIC most often fails; do not pass it on assertion.
Improve. Help generate solutions that target the proven root causes, select against impact and feasibility, and design a small-scale pilot with a measure of success. Gate: does the pilot move the metric? Confirm with data before recommending full rollout.
Control. Help build a control plan: standardized procedure, ongoing monitoring (control charts or equivalent) with response rules when the metric drifts, and handover to the process owner. Gate: will the gain hold without the project team?
Project document
Maintain a markdown document, saved to six-sigma-dmaic-<process-slug>-<YYYY-MM-DD>.md (today's date) in the working directory unless the user names another location:
- Header. The process, the date, and the project owner.
- Define. Problem statement, goal and target, scope, customer and CTQs, SIPOC.
- Measure. Defect and metric definition, data-collection plan, measurement trust, baseline and variation.
- Analyze. Candidate causes, the data tests applied, and the proven root causes (the vital few).
- Improve. Solutions, the selection, the pilot design, and the pilot result against the metric.
- Control. Control plan, monitoring and response rules, and owner handover.
- Phase gates. A short record that each gate question was answered before advancing.
- Caveats. Conclusions are only as good as the data and the measurement system behind them; verified root causes reduce, not eliminate, the chance of a wrong fix; and a gain holds only if Control is real.
Principles
- Hold the gates. Do not advance a phase that has not answered its question. Define clear, baseline trusted, causes proven, pilot working, control real.
- Data over opinion. Causes and effects are tested against data. The method exists to defeat the plausible-but-wrong fix.
- Causes, not symptoms. Improve targets the root causes proven in Analyze. A symptom fix returns.
- Pilot before rollout. Prove the change on a small scale with data first.
1---2name: six-sigma-dmaic3description: Use when the user wants to improve an existing process by reducing defects or variation using Six Sigma DMAIC (Define, Measure, Analyze, Improve, Control). Guides the five phases with gate checks, uses parallel root-cause hypotheses in Analyze, insists on verifying causes against data, and maintains a DMAIC project document. Triggers include "Six Sigma", "DMAIC", "reduce defects", "process improvement", "root cause analysis", "reduce variation".4---56# six-sigma-dmaic78Guides a Six Sigma DMAIC cycle to improve an existing process. The discipline is data over opinion and causes over symptoms.910The five phases, their gate questions, and the pitfalls live in [references/dmaic.md](references/dmaic.md). Load that file before facilitating.1112## When to use1314The user wants to fix an existing process where data can be gathered: reducing defects, errors, cycle time, or variation. For designing a new process from scratch, DMAIC does not apply (DMADV does). For a lighter, faster improvement loop without heavy measurement, prefer PDCA.1516## Language1718Facilitate and write the document in the language the user is writing in. The reference file is English; keep the framework keyed to it regardless of output language.1920## Inputs2122- **PROCESS** (required): the process and the problem with it.23- **CONTEXT** (optional): available data, the customer and their requirements, scope limits, and the process owner.2425## How to facilitate2627Work phase by phase. Each phase has a gate question that must be answered before the next begins; hold the gate. Record everything in the project document, and name the current phase at each step.28291. **Define.** Help the user write a measurable problem statement (what, where, how big, since when, no presumed cause or solution), the goal and target, the scope (process start and end), the customer and CTQs, and a SIPOC map. Gate: is the problem clear, measurable, and worth solving? If a presumed solution is hiding in the problem statement, strip it out.30312. **Measure.** Help define the defect and metric, plan data collection, sanity-check whether the measurement can be trusted, and establish a baseline with its variation. Gate: do we trust the baseline? If data is unavailable, say what must be collected rather than proceeding on guesses.32333. **Analyze (parallel root causes).** Dispatch several analyst subagents at once, each generating candidate root causes through a different lens (for example: people, process, materials, equipment, environment, measurement, the fishbone categories, or a 5 Whys chain). Tell each its final message is the return value: a list of candidate causes with the reasoning, not prose. Pool and dedupe them, then verify each against the data with the user, keeping only causes the evidence supports. Gate: are the root causes proven, not merely plausible? This gate is where DMAIC most often fails; do not pass it on assertion.34354. **Improve.** Help generate solutions that target the proven root causes, select against impact and feasibility, and design a small-scale pilot with a measure of success. Gate: does the pilot move the metric? Confirm with data before recommending full rollout.36375. **Control.** Help build a control plan: standardized procedure, ongoing monitoring (control charts or equivalent) with response rules when the metric drifts, and handover to the process owner. Gate: will the gain hold without the project team?3839## Project document4041Maintain a markdown document, saved to `six-sigma-dmaic-<process-slug>-<YYYY-MM-DD>.md` (today's date) in the working directory unless the user names another location:42431. **Header.** The process, the date, and the project owner.442. **Define.** Problem statement, goal and target, scope, customer and CTQs, SIPOC.453. **Measure.** Defect and metric definition, data-collection plan, measurement trust, baseline and variation.464. **Analyze.** Candidate causes, the data tests applied, and the proven root causes (the vital few).475. **Improve.** Solutions, the selection, the pilot design, and the pilot result against the metric.486. **Control.** Control plan, monitoring and response rules, and owner handover.497. **Phase gates.** A short record that each gate question was answered before advancing.508. **Caveats.** Conclusions are only as good as the data and the measurement system behind them; verified root causes reduce, not eliminate, the chance of a wrong fix; and a gain holds only if Control is real.5152## Principles5354- **Hold the gates.** Do not advance a phase that has not answered its question. Define clear, baseline trusted, causes proven, pilot working, control real.55- **Data over opinion.** Causes and effects are tested against data. The method exists to defeat the plausible-but-wrong fix.56- **Causes, not symptoms.** Improve targets the root causes proven in Analyze. A symptom fix returns.57- **Pilot before rollout.** Prove the change on a small scale with data first.
l4ci