codexkit-dmaic-improvement-charter

name	codexkit-dmaic-improvement-charter
description	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 team needs a charter, SIPOC, baseline, and improvement path. Do not use for brand-new process design or vague complaints with no process boundary.
version	1.0.0
category	scaffolding

DMAIC 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

1. Define the problem, scope, and business case precisely.
2. Build a SIPOC view and identify CTQs.
3. Establish the baseline and what data must be collected.
4. Separate observations from root-cause hypotheses.
5. Propose improvement experiments and a control concept.
6. 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