Help me build a Lean Six Sigma Black Belt-level DMAIC project plan for [PROCESS OR PROBLEM]. The sponsor is [PROJECT SPONSOR], the process boundary is [START AND END POINT], and the primary business or customer outcome is [PRIMARY CTQ AND BASELINE]. Known process facts, constraints, and stakeholders: [PROCESS FACTS AND CONSTRAINTS] Available data and target date: [DATA AND TIMELINE] Create an execution-ready plan, not a claim that root causes or financial benefits have been proven. Use DMAIC and produce: 1. Define: a one-paragraph problem statement with baseline, defect or delay definition, affected customers, and business impact; a goal statement with measurable target and date; in-scope/out-of-scope boundaries; stakeholder map; SIPOC; and a draft project charter. Separate assumed benefits from validated benefits. 2. Measure: a CTQ tree and operational definitions for each metric, including numerator, denominator, unit, timestamp, inclusion/exclusion rules, owner, source system, and data-collection frequency. Specify a measurement-system check appropriate to the data type, such as attribute agreement analysis or gauge R&R. 3. Analyze: a current-state value-stream or process-map outline; a stratification plan by product, channel, shift, team, supplier, and time; hypotheses to test; likely analytical methods; and rules for distinguishing correlation from causation. Include a root-cause validation plan using data and process observation, not a fishbone alone. 4. Improve: a prioritized solution matrix using impact, effort, risk, and controllability; pilot design with success criteria, countermeasures, training, and rollback trigger; plus a RACI naming accountable owners by role. 5. Control: a control plan with metric, target, control limits or escalation threshold where justified, owner, review cadence, reaction plan, documentation update, and handoff acceptance criteria. 6. A week-by-week timeline through [DATA AND TIMELINE], with stage gates and decisions required from the sponsor. Before answering, check that the project scope is narrow enough to measure end to end and flag any baseline, target, savings, or root cause that is not supported by the input. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROCESS OR PROBLEM] | Describe the process and the specific defect, delay, cost, or quality issue to improve. | Reduce late first responses for customer support tickets without lowering resolution quality. |
| [PROJECT SPONSOR] | Enter the executive or process owner sponsoring the project. | Director of Customer Operations, Priya Shah |
| [START AND END POINT] | Define where the process begins and ends for this project. | From ticket creation in Zendesk to the first human response sent to the customer. |
| [PRIMARY CTQ AND BASELINE] | State the critical-to-quality metric, its current baseline, and how it is currently measured. | Percent of priority-2 tickets receiving a first response within four business hours; baseline is 71% for April–June, measured from ticket creation and first-agent-reply timestamps. |
| [PROCESS FACTS AND CONSTRAINTS] | Paste known workflow steps, stakeholders, systems, compliance limits, capacity constraints, and prior attempts. | Three regional teams work different shifts. Bots send acknowledgments but do not count as a first response. Agents may reassign tickets. Staffing cannot increase this quarter, and enterprise customers have contractual service levels. |
| [DATA AND TIMELINE] | Describe available data sources and the target completion date or project duration. | Zendesk event data, staffing rosters, and ticket tags are available for the last 12 months. Complete the pilot decision by September 30. |
How to use
- Define the start and end points before pasting the prompt, because a broad process creates unusable metrics and too many causes.
- Replace estimated benefits with the actual baseline, data source, and operational definition used by the business.
- Confirm each named owner has authority to act before treating the RACI as a commitment.
- Follow up with: “Create a data-collection plan for the Measure phase with a sampling frame, data dictionary, and attribute-agreement study procedure.”
Variations
Project charter
Use this to qualify a potential Black Belt project before launching DMAIC.
Draft a Lean Six Sigma project charter for [PROBLEM]. The sponsor is [SPONSOR], the process runs from [START] to [END], and current evidence is [BASELINE EVIDENCE]. Include business case, problem statement, goal statement, scope, CTQs, stakeholders, estimated benefits labeled as validated or assumed, constraints, risks, milestones, and required team roles. List information still needed to approve the charter. Do not state root causes, savings, or targets as facts unless supported by the evidence. Check that the goal is measurable and within the team’s control before answering.
Root cause plan
Use this after Measure when the team needs to test causes rather than brainstorm them.
Create a root-cause validation plan for [PROBLEM] using this process map and baseline data description: [PROCESS AND DATA]. The outcome metric is [Y METRIC], and suspected factors are [SUSPECTED X FACTORS]. Produce a stratification table, operational definitions, a data-collection plan, testable hypotheses, suitable statistical or visual analyses, and observation steps. Explain what result would support, weaken, or leave each hypothesis unresolved. Do not call a suspected factor a root cause without evidence. Check for confounding, changing denominators, and non-independent observations before answering.
Control plan
Use this after a successful pilot to sustain the changed process.
Create a control plan for this improved process: [IMPROVED PROCESS]. The pilot results are [PILOT RESULTS], the CTQ is [CTQ], and the process owner is [OWNER]. Output a control-plan table with metric definition, source, sampling or reporting frequency, target, escalation trigger, owner, reaction plan, audit cadence, training/document updates, and handoff criteria. Separate pilot evidence from longer-term claims. Do not invent statistically valid control limits from incomplete data. Check that every trigger has a named response owner and that the owner can access the metric.
Tips
- Write the defect definition so two people can classify the same case the same way; vague labels such as “late” or “poor quality” cannot support analysis.
- A fishbone diagram is a hypothesis list, not root-cause evidence; validate suspected causes with stratified data, observation, or a controlled pilot.
- Do not combine waiting time, processing time, and total lead time in one metric without showing their separate timestamps and ownership.
- For a pilot, predefine the success metric, observation window, guardrail metric, and rollback trigger before changing the process.
FAQ
Can AI identify the root cause of a process problem?
It can help structure hypotheses and tests, but it cannot establish a root cause without reliable process data and direct validation.
What makes a project Black Belt level?
It usually crosses functions, uses meaningful data analysis, has a measurable business or customer outcome, and requires sustained control after improvement.
Should every DMAIC project use advanced statistics?
No. Use the simplest valid analysis for the data and decision. Sound definitions, stratification, and a disciplined pilot often matter more than complex models.