Dmaic

DMAIC (Six Sigma Problem Solving)

When to use

Use DMAIC when:

• A problem has recurred multiple times despite previous corrective actions
• The process needs measurable, data-driven capability improvement (Cpk improvement target)
• The root cause is unknown and requires statistical analysis to identify
• A customer requires a Six Sigma approach or asks for a DMAIC report
• The improvement opportunity involves eliminating chronic waste (rework, scrap, test failures)

Use 8D instead when: The problem is a single customer complaint, an escape to the field, or requires immediate containment. 8D is reactive and fast. DMAIC is proactive and thorough — it takes weeks to months.

Use PDCA instead when: The improvement is incremental and the root cause is already known or assumed.

Prerequisites

• A defined problem with measurable impact (reject rate, Cpk, scrap cost, defect count)
• Baseline data available or collectable
• Process owner and cross-functional team assigned
• Management support and a time budget (minimum 4–12 weeks depending on project scope)

Workflow

Phase 1 — DEFINE

Objective: Define the problem, the scope, the team, and the goal in measurable terms.

Key tools and deliverables:

Project Charter — The DMAIC starts and ends here. Contains:

• Problem statement: what is happening, where, since when, how much (measured impact)
• Goal statement: specific, measurable target (e.g., "Reduce connector reject rate from 3.2% to 0.5% by Q3")
• Scope: what is IN and OUT of scope (use Is/Is-Not to define boundaries)
• Business case: financial or customer impact ($, PPM, warranty cost)
• Team: Champion, Black Belt/Green Belt, process owner, operators, engineering

SIPOC diagram:

• Suppliers → Inputs → Process → Outputs → Customers
• Defines the process at a high level before diving into detail
• Identifies all inputs that could affect the output (Y)

Voice of the Customer (VOC) → CTQ:

• What does the customer care about? (VOC)
• Translate to a measurable Critical to Quality (CTQ) characteristic
• The CTQ becomes the Y (output) the project will improve

Gate criteria to exit Define:

• Problem is specific and measurable
• Goal is agreed with the Champion
• Scope is bounded
• Team is assigned and available

---

Phase 2 — MEASURE

Objective: Establish the current baseline and validate the measurement system.

Key tools and deliverables:

Process map (detailed):

• Map every step of the process as it IS (not as it should be)
• Identify where defects are created or detected
• Mark each step: Value-Added (VA), Non-Value-Added (NVA), or Required Non-Value-Added

Data collection plan:

• What will be measured? (the Y and key process inputs Xs)
• How will it be measured? (gauge, method)
• How many samples? (for capability: minimum 100 pieces)
• Who will collect data? When? Where?

MSA (Gauge R&R):

• Validate the measurement system for the CTQ before collecting data
• %GRR < 30% required; <10% preferred
• If measurement system is inadequate: fix it before proceeding

Baseline capability:

• Calculate current Cpk/Ppk for the CTQ
• Establish current defect rate (PPM or %)
• This baseline is the MEASURE gate deliverable — do not proceed without it

Gate criteria to exit Measure:

• Baseline Cpk/PPM established with statistical confidence
• MSA complete and measurement system adequate
• Data collection plan executed with sufficient data

---

Phase 3 — ANALYZE

Objective: Identify and confirm the root cause(s) of the problem using data.

Key tools and deliverables:

Fishbone / Cause & Effect diagram:

• Brainstorm potential causes using 6M (Man, Machine, Method, Material, Measurement, Mother Nature)
• All potential causes are hypotheses at this stage — none are confirmed

Is/Is-Not analysis:

• Scope the problem precisely — what IS affected vs. what IS NOT
• Narrows the hypothesis list before investing in analysis

Multi-Vari study:

• Understand whether variation is: positional (within-part), cyclical (part-to-part), or temporal (time-based)
• Identifies the dominant family of variation — directs the investigation

Hypothesis testing: Confirm or reject hypotheses statistically. Selection guide:

Use p < 0.05 as the significance threshold unless a different risk level is warranted. Always check the test's assumptions (normality for t-test/ANOVA; independence for chi-square).

Root cause confirmation:

• A root cause is NOT confirmed until data proves it
• Reject "human error" as a root cause — it is a symptom; ask why the error was possible
• Confirmed root causes: demonstrate that when the Xs change, the Y changes predictably

Gate criteria to exit Analyze:

• Root cause(s) confirmed with data (not assumed)
• Cause-and-effect quantified (Y = f(X) relationship established)
• Team agrees on which Xs to improve

---

Phase 4 — IMPROVE

Objective: Develop, test, and implement solutions that address the confirmed root causes.

Key tools and deliverables:

Solution generation:

• Brainstorm solutions for each confirmed root cause
• Evaluate solutions: impact vs. effort vs. risk
• Do NOT select solutions based on opinion — test them

Pilot / Design of Experiment (DOE):

• Test the proposed solution on a small scale before full implementation
• DOE: systematically vary multiple factors to find the optimal process settings
• Simple experiments: OFAT (One Factor At A Time) for straightforward improvements

Solution validation:

• Run a production pilot with the solution in place
• Collect data: does the Y improve as predicted?
• Calculate new Cpk/PPM — compare to baseline and goal

Implementation plan:

• Who does what, by when, to implement the solution at full scale
• Change management: update Process Flow, PFMEA, Control Plan, Work Instructions, training

Gate criteria to exit Improve:

• Solution tested and statistically validated (not just "it seems better")
• Cpk/PPM improvement demonstrated in pilot data
• Implementation plan complete and approved

---