Pinpointing D4 Root Causes via Strategic D2 Description

8D.wiki Editorial — Drafted with AI assistance, then reviewed, edited and formatted by the founder — facts, numbers, tables and terminology are checked before publication.
Reviewed & edited by: Alvin Jin — IATF 16949 expert · Certified Product Engineering (PE) coach · DRBFM expert
Published 2024-01-23 · Last reviewed 2026-10-25

Use Is/Is Not analysis in 8D D2 to narrow failure scope, build a five-filter problem description, and accelerate D4 root cause identification.

In the 8D problem-solving framework, the quality of the D2 (Problem Description) stage directly dictates the efficiency of D4 (Root Cause Analysis). A detailed expansion of the problem allows teams to eliminate noise and converge on the true cause.

1. Core Tool: Is/Is Not Analysis

The essence of Is/Is Not analysis is to identify gaps between what the failure is and what it is not, helping to isolate unique changes or differences.

Example: Power Outage Troubleshooting

IS: My unit lost power; the living room is dark.
IS NOT: The entire building is not out (rules out grid failure); the bedroom still has power (rules out the main breaker).
Deduction: The scope is narrowed to a specific circuit or appliance fault in the living room.

The same logic applies to a manufacturing defect. If a burr appears on parts from Cavity 3 but not Cavity 1 or 2, the cavity difference is the clue — not the material lot, not the operator, not the shift.

2. Multi-Dimensional Comparative Analysis (5W2H)

In industrial scenarios (e.g., IATF 16949 QMS environments), we apply Is/Is Not logic across the 5W2H dimensions:

Dimension	Is / Is Not Analysis Focus	Potential Clues
When	Does it occur only after a specific design change or supplier switch?	Correlates failure with Engineering Change Notices (ECN).
Where	Does it occur in Market A but not Market B? Is it climate or shelf-life dependent?	Identifies environmental factors or logistical influences.
How Many	Is the failure rate 100% or 43%? Does it vary by site?	Uncovers hidden variables and distinguishes between systemic and random defects.

Two further dimensions are worth adding to the matrix: Who (which operator, shift or line — and which ones never see the defect) and What/Which (which part number, material lot or supplier — and which ones are clean). The pattern of absence is often more informative than the pattern of occurrence.

3. Worked Example: Seal Leak on an Assembly Line

A leak test rejects 43% of units on one line. The team completes the Is/Is Not matrix before touching the process:

Dimension	IS	IS NOT
What	Leak at the inlet seal, 0.4–0.6 bar decay	Leak at outlet seal or housing joint
Where	Line 2, Station 40 press-fit	Line 1, same station, same fixture design
When	Since the lot change on 12 March, night shift	Day shift before 12 March; all of February
Who	Both operators on night shift	Day-shift operators on the same fixture
How Many	43% of night-shift units, 0% of day-shift units	Not 100%, so not a design fault
Trend	Step change, not gradual drift	Not a wear-out pattern

The step change plus the shift split points away from tooling wear and toward a lot-related seal dimension or a night-shift setup difference. D4 then verifies seal durometer and compression set on the new lot rather than re-auditing the whole line — days saved.

4. Step-by-Step Checklist for a Complete D2

Write the problem statement in measurable terms (defect, location, magnitude, date).
Populate the Is/Is Not matrix across What, Where, When, Who, How Many and Trend.
Record at least five IS NOT characteristics — each one is a filter.
Verify every entry with data (inspection records, test logs, photos), not opinion.
Flag any dimension where IS and IS NOT cannot be distinguished — that gap is itself a clue.
List the differences and changes associated with each IS entry (ECN, lot, shift, supplier).
Have the team lead sign off that the description is complete before D3 containment closes and D4 opens.

5. Common Failure Modes and How to Detect Them

Opinion instead of evidence — entries like "probably the operator." Detect by asking for the record behind each line.
No IS NOT data — a matrix with only IS entries. Detect by counting IS NOT rows; fewer than five means D2 is incomplete.
Scope too broad — "all defects on the line." Detect by checking whether the statement names a location, magnitude and date.
Confirmation bias — the team lists only data supporting its favourite theory. Detect by assigning someone to argue the opposite case.
Stale description — D2 written once and never updated as containment data arrives. Detect by dating the matrix and reviewing it at each D4 session.

6. Verifying the Output and Linking to Neighbouring D-Steps

A D2 description is verified when an independent reviewer can read the matrix and predict which causes are already excluded. Cross-check it against D3 containment data (does the escape path match the Where/When entries?) and against D4 — every verified root cause should sit inside the remaining IS space, and every rejected cause should map to a specific IS NOT filter. If D4 produces a cause that contradicts an IS NOT entry, one of the two is wrong; resolve it before proceeding to D5.

7. Conclusion

The key to effective D2 analysis is the deliberate search for 'Is Not' information. By defining where the problem could have occurred but didn't, you filter out irrelevant factors, enabling a surgical strike on the root cause in D4. The Is-Is-Not tool is based on a fundamental principle: every failure has a unique pattern defined not just by what the failure IS but by what it IS NOT. If a defect occurs on Machine A but not Machine B that difference IS a clue. If it occurs on the night shift but not the day shift that difference IS a clue. The more IS NOT characteristics you can identify the more precisely you can narrow the root cause. I recommend teams identify at least five IS NOT characteristics before considering the D2 description complete. Each IS NOT characteristic is a filter that eliminates a set of potential causes, and five filters will eliminate most possibilities. The Is-Is-Not tool transforms root cause analysis from a guessing game into a systematic elimination process. By defining not just what the failure is but also what it is not the team generates a matrix of comparisons that narrows the investigation space exponentially. Five well-chosen IS NOT characteristics eliminate most potential causes. The most valuable investigative insight often comes not from the IS side of the equation but from the IS NOT side.