8D problem solving is a structured approach for addressing a significant recurring or cross-functional problem. It separates immediate containment from investigation, permanent correction, validation, and prevention. The discipline matters more than the form: an 8D report should show evidence behind the decisions, not just eight completed headings.
ASQ's description of 8D sets out the eight disciplines and notes that some organizations add a preliminary D0 planning stage. The software example and closure checks below are original practical illustrations. For regulated or contractual work, follow the applicable requirements rather than treating a blog checklist as sufficient.
The eight disciplines at a glance
| Discipline | Purpose |
|---|---|
| D1 | Assemble people with the knowledge needed to investigate and act |
| D2 | Define the problem precisely |
| D3 | Protect affected people or outputs through interim containment |
| D4 | Verify the causes of occurrence and why the problem escaped detection |
| D5 | Select and verify a permanent correction |
| D6 | Implement the correction and validate its effectiveness |
| D7 | Change relevant systems or practices to prevent similar recurrence |
| D8 | Close the work and recognize the team's contribution |
D0, where used, establishes whether the approach is needed and what preparation or urgent response must happen. Organizations may name stages differently. Preserve the important distinctions rather than arguing over local report labels.
Decide whether 8D is proportionate
8D is useful when the cause is unclear, several functions contribute, or a temporary workaround could hide a recurring defect. It can also provide a shared record when a customer requires formal corrective action.
It may be excessive for a small isolated issue with an obvious correction and low consequence. Conversely, a security incident, product safety issue, or legal obligation may require additional processes and specialists. The existence of an 8D report does not replace them.
Define the problem boundary before assembling an oversized team. Invite the people who understand the failure, the detection controls, the affected workflow, and implementation constraints. Give the owner a route to obtain decisions and resources beyond the group's authority.
Containment is protection, not proof of a fix
Containment reduces exposure while investigation continues. Examples might include holding affected output for inspection or temporarily disabling a defective path. The right choice depends on the risk and operational context.
Record what the control covers and what it does not. Name who checks it, how failures are escalated, and which evidence will permit removal. A temporary control can create its own cost or risk if it becomes invisible routine work.
Avoid treating “we added another manual check” as the final correction without examining whether that check is reliable and sustainable. A control that depends on someone remembering an exceptional step deserves explicit scrutiny.
Worked example: duplicate account exports
Hypothetical example: a service occasionally generates duplicate exports when a user retries a request after a timeout. Support can remove duplicate files, but the recurrence crosses application behavior, background processing, and customer communication.
For D2, the team defines the observed scope: duplicate exports associated with repeated requests during a specified timeout condition. It records the cases examined and does not claim that every timeout creates a duplicate.
For D3, an approved temporary control identifies affected export requests and routes them for review. The team documents the limits of that control and checks whether it delays legitimate exports.
For D4, investigators test two distinct questions. What permits the duplicate job to be created? Why do existing checks fail to detect or reject it? They reproduce the behavior in an appropriate test environment and compare it with cases where retries do not duplicate the output.
For D5 and D6, the team evaluates a correction to request handling, tests relevant failure paths, implements it through the normal release process, and monitors the defined condition. A successful deployment is evidence of implementation; it is not enough evidence of effectiveness by itself.
For D7, the team reviews whether similar request paths share the same weakness. It records which paths were checked, what was changed, and where uncertainty remains. At closure, it preserves the investigation and thanks the people who contributed rather than making the report a record of blame.
Keep an evidence log beside the report
Use a compact record for each important claim:
- Claim: the condition or mechanism proposed.
- Evidence: reproducible observation, record, or test.
- Alternative explanation: what else could explain the result.
- Coverage: the cases or conditions examined.
- Limit: what the evidence does not establish.
- Decision: what action this evidence supports.
This log prevents a brainstormed cause from becoming a verified cause merely because it appears in D4. It also makes handovers easier when investigation spans several weeks.
For the duplicate-export example, “users click twice” is insufficient. The team needs to understand why repeated requests produce additional work and why that behavior escapes the intended controls. User behavior may trigger the condition without being an adequate explanation of the system's response.
Plan closure before you need it
Define closure criteria early enough that the team cannot quietly lower the standard to finish the report. Include verification of implementation, evidence of effect, decisions about containment removal, and ownership of remaining risks.
Ask whether the observation period is appropriate for the defect. A rare condition may need targeted testing as well as monitoring. “No complaints this week” is weak evidence when usage is low or complaints historically arrive late.
If the evidence is incomplete, record a provisional decision and a later review rather than writing “resolved” without qualification. Escalate material residual risk to the person authorized to accept it.
Connect 8D with everyday team learning
An agile retrospective can surface a recurring issue or inspect whether corrective work receives capacity. It does not replace the deeper causal and validation work of an 8D investigation.
Keep one authoritative action record. In the retrospective improvement process, link to the 8D action rather than creating a second owner and due date. Use a simple board format to discuss workload, coordination, and lessons from the investigation.
The most useful retrospective question may be, “What made it difficult to obtain the evidence?” That can reveal access, handoff, or documentation friction without reopening every technical conclusion.
Frequently asked questions
What is the difference between containment and corrective action?
Containment limits immediate exposure while the problem is investigated. Corrective action changes the verified conditions that produce the problem. Both need evidence, but they serve different purposes.
Does 8D always have nine steps because of D0?
The eight disciplines are D1 through D8. Some organizations add D0 for preparation. Use the structure required by your organization or customer while preserving clear decisions and evidence.
Can software teams use 8D?
Yes, when the problem warrants a formal cross-functional corrective-action process. Adapt examples and evidence to software behavior, but do not weaken validation or substitute a report for applicable incident procedures.