CTQ, QFD & Kano

CTQ, QFD & Kano (CSSGB BoK II.B.3 — Apply)

Quick Answer: Turn Voice of the Customer into measurable requirements using CTQ trees, Critical to X thinking, QFD (House of Quality), and the Kano model. Weight and prioritize CTQs so the project Y and Improve actions focus on what matters most—not every comment equally.

Hearing customers (II.B.2) is not enough. Green Belts must translate “faster,” “safer,” and “easier” into specs a process can hit and a control plan can monitor. BoK II.B.3 is Apply.

From VOC to Requirements

Critical to Quality (CTQ) characteristics are the measurable product or process features that determine whether the customer’s quality need is met. Broader Critical to X (CTX) language includes:

Exam stems may say Critical to Quality even when the measurable is delivery time; recognize the pattern: customer need → measurable characteristic → specification or target.

CTQ Tree — Structure and Worked Example

A CTQ tree (need hierarchy) breaks a broad need into drivers and then into measurable CTQs.

Levels (typical):

1. Need (customer voice, still broad)
2. Drivers (dimensions of the need)
3. CTQ requirements (measurable, with units and targets when known)

Worked example — online pharmacy delivery

VOC: “I want my prescriptions delivered reliably.”

Need: Reliable prescription delivery
├── Driver: On-time arrival
│     ├── CTQ: % of orders delivered by promised window ≥ 98%
│     └── CTQ: Promise-date accuracy (promised date − actual) median ≤ 0 days late
├── Driver: Order correctness
│     ├── CTQ: Wrong-item rate ≤ 500 DPPM
│     └── CTQ: Missing-cold-pack rate for refrigerated SKUs = 0
└── Driver: Communication
      ├── CTQ: Tracking update latency ≤ 30 minutes after scan events
      └── CTQ: Proactive delay notice sent before promise window ends (yes/no ≥ 95% of delay events)

How to use it on a project:

• Pick one or few primary CTQs as project Y(s) for the charter (e.g., on-time % and wrong-item rate).
• Ensure each CTQ has an operational definition and data source (Measure phase).
• Do not leave the tree as slogans—“reliable” without numbers is not yet a CTQ.

Specification tips: Prefer customer-relevant units; separate target from specification limits when both exist; note if the official limit is unknown and must be baselined.

QFD — Quality Function Deployment

Quality Function Deployment (QFD) is a structured method to deploy customer requirements into design and process characteristics. The classic first matrix is the House of Quality:

Green Belt application (practical, not full DFSS craft):

1. List prioritized customer CTQs (from trees + weighting).
2. List candidate process/product features or measures.
3. Mark which features drive which CTQs.
4. Spot conflicts on the roof (e.g., thicker packaging improves damage CTQ but hurts cost and sustainability CTC).
5. Set technical targets that flow into Improve and Control.

QFD prevents “we improved a metric nobody asked for.” It is common in DFSS but appears in CSSGB Define when translating VOC to features/measures.

Kano Model

The Kano model classifies how fulfillment of a need maps to customer satisfaction:

Implications for Green Belts:

• Fixing basics stops defections but may not raise NPS much—still mandatory.
• Performance CTQs are classic DMAIC Y’s (time, defects, cost).
• Delighters can differentiate but should not replace broken basics.
• Over time, delighters decay into basics (what delighted in 2018 is expected in 2026).

Kano surveys ask paired questions (“How do you feel if this feature is present?” / “if absent?”) to classify needs; on the exam, focus on category behavior, not survey form design minutiae.

Weighting and Prioritization Methods

When VOC produces many CTQs, weight them:

Worked mini-weighting: Three CTQs from interviews (n mentions) and severity 1–5:

Project charter Y → on-time and correctness; tracking polish is a later delighter, not the Green Belt’s primary Y.

Putting It Together — Translation Workflow

1. Identify customers (II.B.1).
2. Collect VOC with sound methods and clean questions (II.B.2).
3. Affinity-group statements into needs.
4. Build CTQ trees → measurable CTQs / CTX.
5. Classify with Kano (basic vs performance vs delighter).
6. Weight CTQs; align with sponsor strategy and regulations.
7. Optionally map through QFD to process features and targets.
8. Place primary CTQs into the charter metrics and Measure operational definitions.

Exam scenario cues

• “Customer says ‘easy to use’ → tree to clicks, error rate, time-to-complete” → CTQ tree
• “Matrix of customer wants vs design specs” → QFD / House of Quality
• “No one notices when present, fury when missing” → Basic/must-be (Kano)
• “Satisfaction rises linearly as speed improves” → Performance (Kano)
• “Unexpected feature creates buzz” → Delighter (Kano)
• “Which CTQ first?” → weighting + strategy, not the loudest single anecdote

Common trap: Treating every VOC quote as equal or jumping to a solution feature before a measurable CTQ exists. Another trap: optimizing a delighter while basics fail—Kano says customers still leave.

Master the translation chain—VOC → CTQ tree → prioritized measurable Y → QFD features → process control—and Define-phase requirement questions become systematic rather than essay-like guesswork.