D2 — Problem Description
D2 creates the factual problem statement that the rest of the investigation can trust. Describe the defect, its scope and its significance without assuming a cause. A clear D2 separates observable facts from hypotheses and gives D3 containment and D4 analysis a stable evidence base.
Key takeaways
- State the defect signature and requirement that was not met.
- Record product, lot, location, timing, detection method and affected quantity.
- Separate known facts from assumptions and open questions.
- Update the description when evidence changes, keeping the evidence trail visible.
Build a factual problem statement
- What: the exact defect, symptom or requirement not met.
- Where: product, line, cavity, site, customer location or process step.
- When: first and last known occurrence, lot/date/shift boundaries and pattern.
- Who and how: who detected it, using which inspection, customer feedback or record.
- How many and why significant: affected quantity, population and customer or operational impact.
Use Is / Is-Not to define the boundary
For each observable dimension, record what is affected and what is not. The contrast prevents the team from treating a broad assumption as a fact and gives D4 a disciplined starting point.
- Is: the defect appears on cavity 3 during second shift.
- Is-Not: cavities 1, 2 and 4 and the other shifts show no confirmed occurrence in the same window.
- Evidence: cite the record, sample, photo or measurement that supports each statement.
Evidence and open questions
- Link the complaint, inspection records, measurements, transaction history or photos that support the facts.
- State missing data explicitly and assign how it will be obtained.
- Keep candidate causes out of the factual statement; D4 tests them against the evidence.
- Use the agreed problem description as the reference for containment scope and later validation.
Common mistakes
- Writing a cause hypothesis instead of a measurable problem statement.
- Using adjectives such as "often" or "many" instead of quantities and dates.
- Describing only confirmed defects without defining the wider affected or suspect population.
How Qhubio structures D2
Qhubio uses the complaint and observable facts as the primary input for D2, with evidence retained alongside the problem description before the investigation advances.
- Structured fields for what happened, where, when, detection and affected quantity.
- Evidence linked to the factual statement rather than buried in a separate document.
- A stable D2 description reused by D3 containment and D4 root-cause analysis.
Frequently asked questions
- Is D2 the root cause analysis?
- No. D2 records the factual problem description. D4 tests root-cause hypotheses against that evidence.
- How detailed should D2 be?
- Detailed enough that another engineer can understand the defect, scope, timing, detection and impact without guessing. Unknown facts should be identified as gaps, not invented.
- Can the D2 description change?
- Yes. Update it when new evidence changes the known facts, while keeping the evidence trail and avoiding retrospective assumptions.
Related guides
Run this D-step inside a structured workspace
Qhubio is a structured 8D workspace: evidence-grounded phases, phase-gated approvals and audit-ready exports.
