Estimated reading time: 7 minutes
In a recent article, I argued that 8D is not a problem solving method; it’s an investigation framework. The response was immediate. Quality professionals from aerospace, manufacturing, and Lean organizations reached out to say, “We have the same problem with 9S,” or “This is exactly what happens with A3,” or “DMAIC suffers from this too.”
The issue isn’t limited to 8D. In fact, it’s a systemic confusion that spans across industries. Organizations confuse root cause investigation frameworks with methods for problem solving. And then, they wonder why problems keep recurring, despite perfect compliance documentation!
Let me be clear about the distinction: frameworks organize investigations; methods teach you how to think. In other words, if your team doesn’t understand the difference, you’re training them to fill out forms, not solve problems.
The pattern repeats across industries
Every major industry has developed its own structured corrective action framework. These frameworks have different names, different step counts, and different compliance requirements. However, despite their differences, they all share one fundamental characteristic: They tell you what to do, not how to think. Let’s look at the most common frameworks and see where they fall short:
9S: Aerospace’s Extended Framework
In aerospace, the dominant framework is 9S methodology, codified in standards AS13000 (2014) and ARP9136 (2016). When I ask aerospace quality professionals to explain 9S, they typically say: “It’s basically 8D with one more step.” That’s accurate. Here’s the structure:
- Step 0: Start immediate containment actions
- Step 1: Build the team
- Step 2: Define the problem
- Step 3: Complete and optimize containment actions
- Step 4: Identify the root cause(s)
- Step 5: Define and select permanent corrective actions
- Step 6: Implement permanent corrective action and check effectiveness
- Step 7: Standardize and transfer knowledge across business
- Step 8: Recognize and close the team
The additional step (number 7), explicitly focuses on knowledge management and standardization. It ensures that lessons learned are documented and transferred across other production lines, factories, suppliers, or similar processes. This is valuable. For example, knowledge transfer prevents the same problem from occurring elsewhere in the organization.
However, here’s the critical question: How do you execute Step 4, “Identify the root cause(s)”? 9S doesn’t tell you. Just like 8D, it’s a placeholder. It assumes you already know how to isolate cause from symptom, how to test hypotheses, how to distinguish correlation from causation. 9S is a framework, not a method.
A3: Toyota’s Visual Framework
In Lean manufacturing, the gold standard is A3 Problem Solving – an 8-10 step framework based on PDCA (Plan-Do-Check-Act) that fits on a single A3-sized sheet of paper (11×17″).
A3 emphasizes:
- Visual communication
- Concise documentation
- Reflection and learning
- Management-level problem solving
It’s typically structured as:
- Background/Current Situation
- Problem Statement
- Goal/Target
- Root Cause Analysis
- Countermeasures
- Implementation Plan
- Follow-Up/Check
- Results
A3 is excellent for cross-functional collaboration and strategic alignment. Toyota uses it to develop managers’ PDCA thinking and problem-solving skills. However, look at Step 4: Root Cause Analysis. A3 tells you that root cause analysis is required. But unfortunately, it doesn’t tell you how to conduct it. The framework provides the reporting structure, but assumes that you already possess the analytical capability. Like 8D and 9S, A3 is a framework, not a method.
DMAIC: Six Sigma’s Data-Driven Framework
In Six Sigma environments, the dominant framework is DMAIC: Define, Measure, Analyze, Improve, Control. DMAIC is a 5-step framework designed for complex, data-intensive problems:
- Define: Scope the problem and align with business goals
- Measure: Collect data to understand current performance
- Analyze: Identify root causes with statistical tools
- Improve: Implement and optimize solutions
- Control: Sustain improvements through monitoring and standardization
DMAIC projects typically run for 3+ months and incorporate sophisticated statistical tools like hypothesis testing, regression analysis, and Design of Experiments (DOE).
Again, look at the “Analyze” phase. DMAIC requires root cause analysis. It emphasizes data-driven investigation. It calls for statistical rigor. However, it does not provide a thinking process for systematically isolating causal mechanisms. DMAIC practitioners typically use tools like Ishikawa diagrams, 5 Whys, or Pareto analysis, but those tools are imported into the DMAIC framework. They’re not inherent to it. DMAIC is a problem solving framework, not a method.
PDCA: The Grandfather of them all
PDCA (Plan-Do-Check-Act) is the foundation of most modern frameworks. PDCA is also often called the Deming Cycle or Shewhart Cycle. PDCA is the conceptual grandfather of continuous improvement:
- Plan: Identify the problem, analyze root causes, define actions
- Do: Implement solutions on a small scale
- Check: Measure effectiveness
- Act: Standardize improvements or adjust
PDCA is elegant in its simplicity. It structures the improvement cycle and emphasizes learning through iteration.
Once again, the “Plan” phase, where root cause analysis happens, is a “black box”. PDCA tells you to analyze root causes, but again, doesn’t tell you how to do it systematically. It also doesn’t provide a method for distinguishing true causes from apparent causes. And it doesn’t guide hypothesis testing or evidence validation. Again, PDCA is a framework, not a method.
The common thread: Frameworks organize, methods teach
All of these frameworks (8D, 9S, A3, DMAIC, PDCA) are issue investigation and project management structures. They answer:
- What sequence should we follow?
- Who should be involved?
- How do we document and communicate?
- What verification steps are needed?
- How do we ensure sustainability?
These are critical questions. Frameworks bring discipline to corrective action. They ensure consistency, accountability, and organizational learning. But none of them answer the fundamental question: How do we systematically isolate root cause from symptom?
That’s where problem-solving methods come in:
- Kepner-Tregoe Problem Analysis (Comparative IS/IS NOT Analysis and systematic cause testing)
- 5 Whys (Iterative causal questioning, when done with evidence, not speculation)
- Fault Tree Analysis (Deductive logic modeling)
- Cause-and-Effect Analysis with hypothesis testing
- Designed experiments to isolate causal variables
These are problem solving methods. They have logic structures. They guide thinking. They teach you how to move from symptom to cause through rational inquiry. The framework gives you the roadmap. The method gives you the navigation tools.
Why does the confusion persist?
Organizations train people on frameworks and assume they’ll figure out the thinking on their own. That assumption is costly. Here’s what happens:
- A company implements 9S, or A3, or DMAIC as their “problem-solving process”
- Teams are trained on the framework steps
- Compliance templates are created
- Reports are submitted and closed
- Problems recur
Why? Because the team never learned how to think through causation. They only learned how to complete a report. The framework provided structure, but didn’t provide problem solving skills. And six months later, when the same failure mode reappears under slightly different conditions, leadership asks: “Didn’t we already solve this?”
No. You documented it. You didn’t solve it.
What organizations should do instead
If you want to build real problem-solving capability, you need to:
1. Acknowledge the difference between frameworks and methods
Stop saying “We use 9S for problem-solving” or “We’re trained in A3.” That’s like saying “We use Microsoft Project for construction.” The tool organizes the work – it doesn’t build the building. Be precise and say: “We use 9S as our investigation framework, and we apply Kepner-Tregoe Problem Analysis for root cause identification.”
2. Train teams in actual problem solving methods
Not just frameworks. Teach people how to isolate cause from symptom, how to do comparative analysis, hypothesis testing, and evidence validation. The German VDA explicitly recommends Kepner-Tregoe Problem Analysis as best practice for root cause analysis in 8D. Why? Because decades of automotive quality data prove it works.
3. Integrate methods into your framework
Make it explicit. Your templates should specify: “Root cause determination conducted using [Method]. Evidence attached.” Don’t allow teams to jump from problem description to proposed corrective action without demonstrating logical, evidence-based causal analysis in between.
4. Stop conflating compliance with capability
Completing a 9S report, an A3, or a DMAIC project is a compliance activity. Solving the problem is a capability activity. They are not the same thing. You can have perfect framework documentation and terrible problem-solving. Or you can have brilliant problem solving poorly documented in a framework. The goal is of course both compliant documentation and skilled problem solving!
Final thought
Frameworks are valuable. They bring discipline, consistency, and accountability to corrective action. They ensure problems are contained, solutions are verified, and knowledge is transferred.
But frameworks are not a substitute for critical thinking. They are not a substitute for root cause analysis. And they are certainly not problem-solving methods.
If your organization wants to build real problem solving capability (the kind that prevents recurrence, reduces warranty costs, and protects your customers), you need to invest in teaching people how to think, not just how to fill out forms.
Frameworks give you structure. Problem-solving methods give you substance.
Without both, you’re just managing paperwork.
About the author
Phillip Thompson is Senior Vice President of Client Experience at Kepner-Tregoe Inc., a consulting firm specializing in critical thinking and rational problem solving methodologies. With nearly 40 years of experience, Phillip has worked with Fortune 100 companies across 15 industries to build organizational capability in systematic problem-solving and decision making.
