16.2 Six Sigma DMAIC for Auditors

16.2 Six Sigma DMAIC for Auditors (CQA BoK V.B.1 — Apply)

/practice/cqaPractice questions with detailed explanations

Six Sigma is a structured methodology for reducing process variation and defects, historically targeting extremely low defect rates when fully deployed. For quality auditors, the practical skill is DMAIC literacy: knowing what good project evidence looks like in each phase, where shortcuts appear, and how DMAIC artifacts support objective evidence of problem solving and control.

You will see DMAIC in:

• CAPA and major nonconformity investigations
• Customer complaint reduction and cost-of-quality projects
• Supplier development and process qualification stories
• Management review inputs claiming “Six Sigma results”
• Case-study exam items with phase-labeled exhibits

DMAIC at a glance

Related structure: DMADV / DFSS (Define–Measure–Analyze–Design–Verify) for designing new processes/products. Auditors should not confuse improve existing process (DMAIC) with design something new (DMADV).

Define — set the problem correctly

Define prevents solving the wrong problem. Strong Define work is specific, customer-linked, scoped, and measurable.

Elements to recognize:

• Problem statement: what is wrong, where, when, magnitude (not a disguised solution).
• Goal statement: targeted improvement with metric and date (e.g., reduce late shipments from 8% to <2% by Q3).
• Business case: why it matters (cost, risk, customer, compliance).
• Scope: in/out boundaries; process start/stop.
• SIPOC: Suppliers, Inputs, Process, Outputs, Customers—high-level context.
• VOC → CTQ: Voice of Customer translated to Critical to Quality measures.
• Team and sponsor: authority to change the process.

Audit / exam application:

• Charter that already names the solution (“buy new software”) without baseline data → Define failure.
• Goal of “improve quality” with no metric → not auditable.
• Scope so wide it cannot finish → project theater risk.
• When evaluating CAPA, weak problem definition is the same disease in different clothing.

Scenario — Define in a complaint project. Customers report “damaged packaging.” Define phase discovers three different codes mixed: transit damage, warehouse crush, and shipping wrong dunnage. Splitting the Y metric avoids a single vague project. An auditor reviewing the program asks whether complaint taxonomy supports meaningful Define work.

Measure — make the Y trustworthy

Measure establishes a credible baseline. Without measurement system integrity, Analyze and Improve are fiction.

Core practices:

Sigma level literacy (conceptual): Higher sigma implies fewer defects relative to specifications/requirements, under stated assumptions. Exam items may reference defect metrics without requiring deep calculation. Focus on whether the metric matches the problem and whether data are reliable.

Scenario — Measure failure. A team claims 4.5σ performance using only weekly manager estimates of “good days.” No operational definition, no sampling plan, no MSA. Auditor treating this as objective evidence of capability would be wrong; the Measure phase is incomplete.

Link to audit fieldwork: Auditors apply Measure thinking when designing sampling plans, defining “nonconformity,” and ensuring checklists collect comparable data across team members.

Analyze — find validated causes

Analyze separates vital few root causes from noise using process analysis and data.

Common tools in Analyze (overlap with V.A and later statistics topics):

• Process maps, value-stream analysis, waste walks
• Pareto, histograms, box plots, scatter, multi-vari
• Cause-and-effect, 5 Whys, fault trees
• Hypothesis tests / regression (recognize purpose; deep calc is not the CQA focus)
• Stratification by machine, shift, supplier, material lot

Apply-level auditor stance:

1. Do stated causes explain the baseline problem and its stratification patterns?
2. Were causes tested against data (not only brainstormed)?
3. Is the team still open to disconfirming evidence?
4. Are human-error causes drilled to system design?

Scenario. Analyze shows defect spikes only on Line 2 after changeover, not Line 1. Root focus becomes changeover standard work and first-article verification—not plant-wide “quality awareness.” An auditor assessing CAPA would expect actions aligned with that stratification, not generic posters.

Improve — change the process deliberately

Improve selects and implements solutions that address validated causes, preferably with pilots before full rollout.

Hallmarks of solid Improve:

• Solution criteria linked to causes and CTQs (impact, cost, risk, speed)
• Error-proofing preferred over detection where feasible
• Risk analysis of the change (and update of FMEA/control plan as applicable)
• Pilot plan with success metrics and exit criteria
• Implementation: docs, training, equipment, IT, suppliers
• Resistance/change management considered

Auditor red flags:

• Jumping to Improve before Measure/Analyze (“we already knew”)
• Solutions that only add inspection without removing cause
• No pilot on high-risk changes
• “Training only” for systemic process design flaws
• Unauthorized process changes outside change control

Scenario — Improve with audit impact. A validated cause is wrong-component picks from look-alike bins. Improve implements poka-yoke (asymmetric connectors + barcode interlock) and revises pick face layout. Detection sampling decreases after proof of effectiveness. Audit trail: change control, validation of the interlock, updated WI, training records.

Control — sustain the gains

Control is where many projects die. Without Control, performance regresses and “Six Sigma success” is temporary.

Control phase elements:

Scenario — missing Control. A DMAIC project cut scrap 40% during the pilot quarter. Six months later scrap returned; temporary engineers left; temporary check sheet abandoned; no control plan in the QMS. Management still cites the project as success in reviews. An auditor applies DMAIC knowledge by sampling whether Control deliverables exist and whether metrics remain at goal—effectiveness, not trophy slides.

How auditors apply DMAIC without being Black Belts

You do not need to: calculate complex DOE models, run Minitab, or hold a belt. You do need to: map evidence to phases, spot skipped phases, and judge whether conclusions are supported.

DMAIC vs PDCA vs CAPA (exam clarity)

Exam trap: treating DMAIC as mandatory for every tiny correction. Apply proportionality: depth scales with risk and complexity. Another trap: equating a belt certificate on the wall with effective Control in the process.

Tollgates and governance (what “Apply” looks like)

Mature deployments use tollgates between phases: sponsor reviews charter (Define), data quality (Measure), cause validation (Analyze), pilot results (Improve), and control plan ownership (Control). Auditors may sample tollgate records as evidence that improvement is managed—not ad hoc.

Scenario — governance audit. Quality manual claims a Six Sigma program. Sampling 5 closed projects finds 4 without control plans and 3 without MSA on critical gages. Finding is not “belts are bad”; it is that the stated methodology is not implemented as claimed—system nonconformity against the organization’s own requirements.

Integration with audit case studies

Case-study packets may include a partial charter, a Pareto, a fishbone, and a control chart. Work the packet like a mini-DMAIC review:

1. Is the problem in Define measurable and scoped?
2. Do Measure exhibits match the Y in the charter?
3. Does Analyze connect data patterns to stated root causes?
4. Do Improve actions attack those causes?
5. Does Control show how gains are held and who owns them?

That sequence is pure BoK V.B.1 Apply skill—and it transfers directly to field audits of improvement systems.

Practical auditor questions by phase

Define: What CTQ or requirement is harmed? What is in scope? Who sponsors?
Measure: How is the metric defined? Is the baseline current? Is the measurement system adequate?
Analyze: What evidence validates the vital few causes? What was ruled out?
Improve: Why this solution? What was piloted? What risks were assessed?
Control: What will detect regression? What is the reaction plan? Where is it documented?

Memorize the five phase names in order, the question each answers, and at least two artifacts per phase. That package answers most CQA DMAIC items without belt-level statistics.