codexkit-dmaic-improvement-charter
Define a Lean Six Sigma improvement project using DMAIC, problem framing, baseline measures, root-cause hypotheses, CTQs, and control planning. Use when an existing process is underperforming and the
SKILL.mdskills/codexkit-dmaic-improvement-charter/SKILL.md
GitHubDMAIC Improvement Charter
Purpose
Move a process problem from vague frustration into a structured improvement project.
When to use
- An existing process is failing on cost, quality, speed, or customer outcomes.
- A team needs a DMAIC project charter before running improvement work.
- Root causes are unclear and a baseline must be established.
When not to use
- The process does not exist yet and needs greenfield design.
- The request is only for a symptom list with no process boundary.
Inputs
- problem statement and business impact
- process boundary, stakeholders, and customers
- current metrics, CTQs, defects, or delays
- known hypotheses and constraints
Procedure
- Define the problem, scope, and business case precisely.
- Build a SIPOC view and identify CTQs.
- Establish the baseline and what data must be collected.
- Separate observations from root-cause hypotheses.
- Propose improvement experiments and a control concept.
- State project risks, assumptions, and sponsor needs.
Output
- DMAIC charter
- SIPOC summary
- baseline measure plan
- CTQs and likely root-cause hypotheses
- improvement path and control considerations
Definition of done
- The process boundary is explicit.
- The baseline and CTQs are clear enough to measure progress.
- The team can start DMAIC without guessing the problem statement.
Examples
- "Define a DMAIC project for our slow order-to-cash process."
- "Turn these recurring service failures into a Lean Six Sigma charter."
Quality Criteria
- All placeholder sections are filled with domain-specific content
- Structure follows the relevant industry standard or framework
- Language matches target audience (technical / executive / legal)
- Output is ready for review — not a rough draft requiring major rework
Verification (4C)
| Check | Question |
|---|---|
| Correctness | Does the draft structure follow the stated framework or industry standard? |
| Completeness | Are all required sections present with substantive (not placeholder) content? |
| Context-fit | Does tone, detail level, and terminology match the intended audience? |
| Consequence | If sent to the intended recipient without further editing, what would fail? |
Edge Cases
- No existing template for this type — Use the closest available template and document all customizations made.
- Stakeholder requirements conflict — Flag conflicts explicitly in the draft. Do not silently choose one requirement over another.
- Output required in multiple formats — Produce the canonical format first, then derive others. Note any formatting limitations.
Changelog
- v1.0.0 — Initial release