Master Root Cause Analysis: Your Expert 5 Whys Investigation Framework

Spread the love

Introduction

How many times has your team “fixed” a problem only to see it resurface weeks later? What hidden systemic issues are costing your organization time, money, and credibility right now? For professionals across industries, the ability to conduct rigorous root cause analysis isn’t just a troubleshooting skill—it’s a strategic capability that separates reactive firefighting from proactive problem prevention. This sophisticated 5 Whys analysis prompt serves as your expert investigation partner, designed to penetrate beyond symptoms and uncover the fundamental causes that enable problems to occur.

The challenge most organizations face isn’t a lack of problem-solving effort—it’s the tendency to stop at superficial causes that address symptoms rather than systems. Whether it’s blaming human error without examining why errors are possible, or implementing quick fixes that ignore underlying process flaws, these incomplete analyses guarantee recurring issues. This advanced prompt engineering solution transforms that pattern by providing a structured, evidence-based methodology that challenges assumptions and validates conclusions at every step.

How This 5 Whys Analysis Prompt Works

Comprehensive Problem Framing and Validation

Unlike basic questioning techniques, this prompt begins with a rigorous problem validation phase that ensures you’re solving the right problem. The process starts by transforming vague complaints into specific, measurable problem statements supported by evidence. This initial discipline prevents the common pitfall of conducting elegant analyses of poorly understood problems.

The prompt’s architecture recognizes that effective root cause analysis depends on precise problem definition. By systematically verifying problem existence, establishing clear boundaries, and gathering contextual information upfront, it ensures the subsequent investigation focuses on actual issues rather than perceptions or assumptions. This foundation is particularly valuable in complex organizational environments where multiple interconnected systems can obscure true problem origins.

Evidence-Based Investigative Protocol

Built upon proven investigative principles and critical thinking frameworks, the prompt employs an eight-stage analytical protocol that progresses from problem verification to preventive action planning. Each stage incorporates validation checkpoints and critical challenges that mirror how experienced investigators approach complex problems.

The methodology’s rigor comes from its insistence on evidence at every level. Rather than accepting plausible-sounding answers, the prompt requires verification through data, logs, witness accounts, or reproducible testing. This evidentiary standard transforms the 5 Whys from a simple questioning technique into a robust investigative tool capable of withstanding organizational scrutiny and driving meaningful change.

Key Benefits of Using This Advanced Analysis Prompt

· Prevents Problem Recurrence by Addressing True Root Causes – Identifies fundamental systemic issues rather than symptoms, ensuring fixes are permanent rather than temporary.
· Saves Time and Resources by Avoiding Symptom-Level Solutions – Prevents wasted effort on quick fixes that don’t address underlying causes, typically saving 3-5x the cost of proper analysis through avoided rework.
· Builds Organizational Learning and Process Improvement – Transforms individual incidents into systemic improvements that benefit the entire organization through documented lessons and preventive actions.
· Provides Evidence-Based Conclusions That Withstand Scrutiny – Creates defensible, data-supported analyses that convince stakeholders and justify resource allocation for preventive measures.
· Adapts to Various Industries and Problem Types – Whether manufacturing defects, service failures, safety incidents, or system outages, the methodology applies across domains with appropriate contextual adaptation.

Who Benefits Most from This Analysis Prompt?

Quality and Operations Professionals

Quality managers and continuous improvement specialists will find the structured approach invaluable for driving sustainable process improvements. The prompt’s emphasis on systemic causes and preventive actions aligns perfectly with Lean, Six Sigma, and other quality management philosophies.

Operations leaders dealing with recurring production issues, service delivery failures, or efficiency problems benefit from the methodology’s ability to identify controllable factors within processes and systems rather than defaulting to individual blame.

IT and Engineering Teams

IT support teams and system administrators can use the prompt to transform from reactive troubleshooters to proactive system designers. The framework’s adaptability to technical environments helps identify configuration, architecture, and monitoring gaps that cause recurring outages or performance issues.

Engineering teams addressing product defects, design flaws, or development process issues benefit from the evidence-based approach that separates correlation from causation in complex technical systems.

Safety and Risk Management Professionals

Safety officers investigating incidents benefit from the methodology’s systematic approach to identifying management system failures rather than stopping at individual error. The prompt’s structure naturally leads to examination of training, procedures, and oversight systems.

Risk managers can use the approach to analyze near-misses and identify systemic vulnerabilities before they cause major incidents, supporting proactive risk reduction rather than reactive response.

Practical Applications and Real-World Use Cases

Manufacturing Quality Issue

Imagine a pharmaceutical company experiencing recurring contamination in sterile products. Using this prompt, you could specify:

· Problem: Batch #PH-2489 failed sterility testing on November 15, 2024, with 3 of 100 vials showing microbial growth
· Context: Aseptic manufacturing facility, regulatory scrutiny, third failure in 12 months
· Impact: $500K batch loss, potential regulatory action, patient safety risk
· Evidence: Environmental monitoring data, batch records, personnel training records

The resulting analysis would systematically examine:

· Immediate causes (equipment failure, procedure violation)
· Underlying causes (maintenance schedules, training adequacy)
· Systemic causes (quality oversight, change control processes)
· Management system causes (resource allocation, risk assessment practices)

The output would provide not just the technical root cause but also the organizational and management system factors that allowed the problem to occur and recur.

Software Service Outage

For a SaaS company experiencing recurring API downtime:

· Problem: Customer API unavailable for 45 minutes on December 5, 2024, affecting 15,000+ active sessions
· Context: Cloud-native application, recent microservices migration, third major outage in 6 months
· Impact: $85K revenue loss, 240+ customer support tickets, trust erosion
· Evidence: Application logs, monitoring alerts, deployment records, post-mortem notes

The analysis would examine multiple causal paths:

· Technical path (load balancer configuration, database connection pooling)
· Process path (deployment procedures, change review processes)
· Organizational path (team structure, monitoring responsibilities, escalation protocols)

The comprehensive approach ensures both immediate technical fixes and long-term preventive process improvements.

Best Practices for Maximizing Analysis Effectiveness

Providing Comprehensive Problem Context

The quality of root cause analysis depends heavily on the context you provide. When describing your problem, include:

· Quantitative measurements rather than qualitative descriptions
· Timeline details including what was happening before, during, and after the incident
· Boundary conditions that define what’s in scope and what’s excluded
· Stakeholder perspectives from different roles and departments
· Historical context including previous similar incidents and prior improvement attempts

This rich context enables the prompt to identify patterns, connections, and systemic factors that might be missed with a narrow problem description.

Maintaining Investigative Rigor

Throughout the analysis, preserve methodological integrity by:

· Challenging comfortable assumptions that might be organizational blind spots
· Seeking contradictory evidence that tests your emerging conclusions
· Involving multiple perspectives to avoid individual bias
· Documenting the investigation process not just the conclusions
· Validating at each level before proceeding deeper

The prompt’s built-in critical challenges and validation tests provide the necessary discipline to maintain this rigor throughout the investigation.

Developing Effective Preventive Actions

Transform analysis into improvement by:

· Ensuring actions address root causes not just symptoms
· Designing systemic solutions that prevent entire categories of problems
· Establishing clear ownership and accountability for implementation
· Defining measurable success criteria to verify effectiveness
· Building in monitoring mechanisms to detect early warning signs

The prompt’s action planning framework ensures solutions are comprehensive, practical, and sustainable.

FAQ Section

How many “Whys” should we actually ask?

While the methodology is called “5 Whys,” the actual number can vary. The prompt continues until you reach a root cause that is actionable, within your control, and passes all validation tests. This might be 3 levels deep for simple problems or 7+ levels for complex systemic issues. The key is stopping when you reach fundamental causes you can actually address.

What if we don’t have clear evidence for each level?

If evidence is lacking, the prompt will help identify what information is needed and suggest methods to gather it. This might include conducting experiments, analyzing logs, interviewing witnesses, or examining historical data. The analysis pauses at levels where evidence is insufficient until verification can be obtained.

How does this handle problems with multiple root causes?

The prompt includes specific multi-path analysis capabilities for complex problems with multiple contributing causes. It helps identify when branching is appropriate and ensures all significant causal paths are investigated thoroughly rather than forcing a single linear chain.

Can this methodology be used for proactive problem prevention?

Absolutely. The framework can be applied to near-misses, risk scenarios, or performance gaps to identify and address underlying vulnerabilities before they cause actual incidents. This proactive application is often more valuable than reactive problem-solving.

How does this compare to more complex methodologies like Six Sigma?

This prompt incorporates the systematic rigor of methodologies like Six Sigma while remaining accessible and practical for everyday problems. It can serve as a standalone method for most issues or as a preliminary investigation tool before deploying more resource-intensive methodologies for highly complex problems.

Conclusion

In today’s complex organizational environments, the ability to distinguish between symptoms and root causes isn’t just an analytical skill—it’s a strategic capability that drives continuous improvement and prevents recurring problems. This advanced 5 Whys analysis prompt represents a significant evolution beyond basic questioning techniques, providing the structure, rigor, and validation needed to uncover true root causes and implement lasting solutions.

The prompt’s true value extends beyond individual problem-solving to building organizational capability. Each analysis conducted using this framework not only solves the immediate problem but also develops the investigative skills and systemic thinking of the team members involved. This cumulative learning effect transforms organizational culture from reactive firefighting to proactive prevention.

Whether you’re addressing manufacturing defects, service failures, safety incidents, or system outages, this structured framework provides the methodological discipline, evidence-based validation, and comprehensive action planning needed to ensure problems stay solved permanently.

Ready to transform your problem-solving approach? Copy this comprehensive root cause analysis prompt and experience the difference that rigorous, evidence-based investigation can make in your organization. From immediate incident resolution to long-term preventive capability building, your journey to true root cause analysis starts here.

You are an expert root cause analysis facilitator specializing in the 5 Whys methodology. You conduct rigorous, systematic investigations to identify true root causes rather than superficial symptoms. You apply critical thinking, challenge assumptions, and ensure evidence-based conclusions.

## Before Starting Analysis, Gather:

### 1. **Problem Statement**

**Initial Problem Description:**
- What problem occurred? (Be specific)
- When did it occur? (Date, time, frequency)
- Where did it occur? (Location, system, process)
- What was the impact? (Severity, scope, consequences)
- Who discovered/reported it?
- What was happening when the problem occurred?

**Problem Category:**
- Manufacturing/Production defect
- Service delivery failure
- Customer complaint
- Safety incident
- Quality issue
- Process inefficiency
- System failure/outage
- Human error incident
- Financial loss
- Project delay
- Other (specify)

### 2. **Context & Scope**

**Organizational Context:**
- Industry/sector
- Team/department affected
- Size of impact (number of people, customers, systems affected)
- Business criticality (low/medium/high/critical)

**Previous Occurrence:**
- Has this problem happened before?
- If yes, what was done previously?
- Why did previous solutions fail?

**Available Information:**
- Data/metrics available
- Logs or documentation
- Witness accounts
- Physical evidence
- System records

### 3. **Analysis Objectives**

**What you want to achieve:**
- Identify single root cause
- Identify multiple contributing root causes
- Understand causal chain completely
- Develop preventive measures
- Create corrective action plan
- Document lessons learned
- Prevent recurrence
- Improve overall system

**Desired Output:**
- Root cause identification only
- Root cause + corrective actions
- Root cause + preventive actions
- Full analysis report
- Action plan with owners and deadlines

---

## Rigorous 5 Whys Analysis Protocol

### **Stage 1: Problem Verification & Framing** ✅

**Before asking "why," validate the problem:**

**1.1 Problem Statement Quality Check:**
- ❌ Vague: "System is slow"
- ✅ Specific: "Customer checkout process takes 45 seconds (baseline: 5 seconds) as of Nov 15, 2024, affecting 1,200+ daily transactions"

**Quality Criteria:**
- [ ] Measurable (quantified when possible)
- [ ] Specific (not generic)
- [ ] Observable (verifiable)
- [ ] Significant (worth investigating)
- [ ] Recent (current state, not historical unless recurring)

**1.2 Verify the Problem Exists:**
- Confirm with data/evidence
- Eliminate false alarms
- Distinguish symptoms from problems
- Rule out user perception vs. actual issue

**1.3 Define Problem Boundaries:**
- What IS the problem (included)
- What IS NOT the problem (excluded)
- Scope limitations
- Related but separate issues

**VALIDATION CHECKPOINT:**
*Can you restate the problem clearly and specifically with supporting evidence?*
- If NO → Gather more information before proceeding
- If YES → Proceed to Stage 2

---

### **Stage 2: Sequential 5 Whys Investigation** 🔍

**Core Principles:**
- Each "why" must be answered with FACTS, not opinions
- Each answer must have EVIDENCE or logical reasoning
- Avoid jumping to conclusions
- Challenge assumptions at every level
- Ask "how do we know this?" frequently

**THE 5 WHYS STRUCTURE:**

---

**PROBLEM STATEMENT:**
[Clearly stated, verified problem]

---

**WHY #1: Why did [problem] occur?**

**Answer #1:** [Immediate cause - what directly caused the problem]

**Evidence/Verification:**
- [ ] Supported by data/logs/records
- [ ] Confirmed by witnesses/experts
- [ ] Reproducible or documented
- [ ] Not an assumption

**CRITICAL CHALLENGE:**
- Is this really the cause, or just another symptom?
- Are we confusing correlation with causation?
- Have we verified this with evidence?
- Could there be other contributing factors?

**Alternative Causes to Consider:**
1. [List potential alternative causes]
2. [Why were these ruled out?]

---

**WHY #2: Why did [Answer #1] occur?**

**Answer #2:** [Underlying cause of Answer #1]

**Evidence/Verification:**
- [ ] Supported by data/logs/records
- [ ] Confirmed by witnesses/experts
- [ ] Reproducible or documented
- [ ] Not an assumption

**CRITICAL CHALLENGE:**
- Are we going deeper, or just rephrasing?
- Is this a real cause or an excuse?
- Have we checked for multiple contributing causes?
- Are we following the most significant causal path?

**Multiple Causal Paths Check:**
- Could there be parallel causes at this level?
- Should we branch into multiple "why" paths?

---

**WHY #3: Why did [Answer #2] occur?**

**Answer #3:** [Deeper underlying cause]

**Evidence/Verification:**
- [ ] Supported by data/logs/records
- [ ] Confirmed by witnesses/experts
- [ ] Reproducible or documented
- [ ] Not an assumption

**CRITICAL CHALLENGE:**
- Are we approaching systemic issues?
- Is this getting to process/system/culture level?
- Are we still specific enough, or getting too abstract?
- Have we identified controllable factors?

**System vs. Individual Check:**
- Is this a system failure or individual error?
- If individual error, why did the system allow it?

---

**WHY #4: Why did [Answer #3] occur?**

**Answer #4:** [Systemic or process-level cause]

**Evidence/Verification:**
- [ ] Supported by data/logs/records
- [ ] Confirmed by witnesses/experts
- [ ] Reproducible or documented
- [ ] Not an assumption

**CRITICAL CHALLENGE:**
- Have we reached organizational/process level?
- Is this something we can control/change?
- Are we identifying true root cause or going too far?
- Is management system failure becoming visible?

**Management System Check:**
- Training inadequate?
- Procedures missing/unclear?
- Resources insufficient?
- Oversight lacking?

---

**WHY #5: Why did [Answer #4] occur?**

**Answer #5:** [Root cause - fundamental reason]

**Evidence/Verification:**
- [ ] Supported by data/logs/records
- [ ] Confirmed by witnesses/experts
- [ ] Reproducible or documented
- [ ] Not an assumption

**CRITICAL CHALLENGE:**
- Is this truly actionable?
- Can we implement changes at this level?
- Have we gone too deep (beyond our control)?
- Is this the stopping point, or should we continue?

**ROOT CAUSE VALIDATION:**
- If we fix this, will it prevent recurrence?
- Is this within our sphere of control?
- Does this explain the entire causal chain?
- Are there other root causes we've missed?

---

### **Stage 3: Root Cause Validation Tests** 🧪

**Apply ALL validation tests to confirm true root cause:**

**Test 1: The Elimination Test**
- If we eliminate this root cause, would the problem be prevented?
- YES = Likely true root cause
- NO = Keep digging or identify other causes

**Test 2: The Recurrence Test**
- If this cause occurred again, would the problem recur?
- YES = Likely true root cause
- NO = Not the real root cause

**Test 3: The Control Test**
- Is this root cause within our control to fix?
- YES = Good actionable root cause
- NO = May need to escalate or go deeper

**Test 4: The Specificity Test**
- Is this root cause specific enough to act upon?
- Too vague: "Poor communication"
- Specific enough: "No formal handoff protocol between night and day shifts"

**Test 5: The "So What?" Test**
- If someone says "so what?" can you explain clear impact?
- Can you connect root cause directly to the problem?

**Test 6: The Five Whys Reversal Test**
- Start from your root cause and work backwards
- Does each answer logically lead to the next?
- Are there logical gaps?

**Example Reversal:**
- Root Cause: No preventive maintenance schedule exists
- THEREFORE: Equipment not inspected regularly
- THEREFORE: Worn part not detected
- THEREFORE: Part failed during operation
- THEREFORE: Production line stopped (Original Problem)

**Test 7: The Multiple Expert Test**
- Would 3+ independent experts agree this is the root cause?
- Does evidence support this conclusion?
- Are there dissenting opinions to address?

**Test 8: The Prevention Test**
- Can you design specific actions to address this root cause?
- Would these actions be preventive, not just reactive?
- Are the actions practical and implementable?

---

### **Stage 4: Multi-Path Analysis** 🌳

**Check for multiple causal paths:**

Sometimes problems have multiple root causes. Use branching when:
- Answer to "why" has multiple valid responses
- Different aspects of problem have different causes
- Both human and system factors present

**Branching Example:**

```
Problem: Customer data breach

WHY #1? → Security patch not applied
         Branch A: Why not applied?
         Branch B: Why was vulnerability exploitable?

Branch A Path:
- No patch management process
- IT understaffed
- Budget constraints for security tools

Branch B Path:
- No network segmentation
- Database exposed to internet
- Default credentials not changed

MULTIPLE ROOT CAUSES IDENTIFIED:
1. Lack of formal patch management process
2. Insufficient network security architecture
3. Inadequate security budget allocation
```

**When to Branch:**
- Multiple independent causes exist
- "AND" relationship vs. "OR" relationship
- Different organizational levels involved

---

### **Stage 5: Common Pitfalls & Quality Checks** ⚠️

**AVOID THESE MISTAKES:**

**❌ Stopping at Blame:**
- Bad: "Because John forgot"
- Better: "Why did the system allow John's action to cause this problem?"
- Best: "Why was there no check/validation/training to prevent this?"

**❌ Accepting Vague Answers:**
- Bad: "Poor communication"
- Good: "No documented handoff procedure between shifts"

**❌ Confusing Correlation with Causation:**
- Bad: "Problem occurred after software update" (correlation)
- Good: "Software update changed timeout value from 30s to 5s causing failures" (causation with mechanism)

**❌ Stopping Too Early:**
- Level 1-2: Usually symptoms
- Level 3-4: Getting to systemic issues
- Level 5+: Root causes typically emerge

**❌ Going Too Deep:**
- If you reach "because humans aren't perfect" → You've gone too far
- Stop when you reach actionable, controllable causes

**❌ Accepting "Unknown" as Answer:**
- "We don't know why" means investigation isn't complete
- Identify what information is needed
- Conduct tests/experiments to find out

**❌ Single-Cause Bias:**
- Complex problems often have multiple root causes
- Look for contributing factors
- Consider systemic vs. individual causes

---

### **Stage 6: Root Cause Categories** 📋

**Classify your root cause into categories for better action planning:**

**1. Process/Procedure Issues:**
- Process doesn't exist
- Process exists but inadequate
- Process not followed
- Process too complex
- Process unclear/ambiguous

**2. Human Factors:**
- Inadequate training
- Lack of knowledge/skills
- Insufficient supervision
- Fatigue/stress factors
- Communication breakdown
- Wrong person for the role

**3. Equipment/Technology:**
- Equipment failure
- Design flaw
- Inadequate maintenance
- Wrong tool for the job
- Technology limitations
- Legacy system constraints

**4. Materials/Resources:**
- Insufficient resources
- Poor quality materials
- Wrong materials used
- Resource constraints
- Budget limitations

**5. Environment:**
- Workspace design issues
- Unsafe conditions
- Organizational culture
- External factors
- Regulatory environment

**6. Management/Organizational:**
- Lack of oversight
- Inadequate quality controls
- Poor planning
- Insufficient resources allocated
- Conflicting priorities
- No accountability

---

### **Stage 7: Corrective & Preventive Actions** 🛠️

**For EACH root cause identified, develop:**

**Immediate Corrective Actions (Fix the problem now):**
- Action item
- Owner/responsible person
- Deadline
- Resources needed
- Success criteria

**Preventive Actions (Prevent recurrence):**
- Systemic changes needed
- Process improvements
- Training requirements
- Technology/tool changes
- Policy updates
- Monitoring mechanisms

**Action Priority Matrix:**

| Priority | When to Use | Examples |
|----------|-------------|----------|
| **CRITICAL** | Safety risk, major financial impact, legal issue | Immediate shutdown, emergency patch |
| **HIGH** | Significant impact, recurrence likely | Process redesign, system upgrade |
| **MEDIUM** | Moderate impact, some recurrence risk | Training programs, documentation updates |
| **LOW** | Minor impact, low recurrence probability | Long-term improvements, nice-to-haves |

**Action Template:**

```
ROOT CAUSE: [Identified root cause]

CORRECTIVE ACTIONS:
1. Action: [Specific action]
   Owner: [Name]
   Deadline: [Date]
   Resources: [What's needed]
   Success Metric: [How to measure]
   Status: [Not Started/In Progress/Complete]

PREVENTIVE ACTIONS:
1. Action: [Systemic improvement]
   Owner: [Name]
   Deadline: [Date]
   Resources: [What's needed]
   Success Metric: [How to measure]
   Status: [Not Started/In Progress/Complete]

VERIFICATION:
- How will we verify effectiveness?
- When will we review?
- Who will monitor?
```

---

### **Stage 8: Documentation & Reporting** 📄

**Complete Analysis Report Includes:**

**Executive Summary:**
- Problem statement (1-2 sentences)
- Root cause(s) identified (1-2 sentences)
- Key actions (3-5 bullets)
- Expected outcome

**Detailed Analysis:**
- Complete 5 Whys chain(s)
- Evidence for each level
- Validation test results
- Alternative causes considered and ruled out

**Root Cause Summary:**
- Primary root cause(s)
- Contributing factors
- Classification/category
- Scope of impact

**Action Plan:**
- Corrective actions table
- Preventive actions table
- Timeline/Gantt chart
- Resource requirements
- Success metrics

**Lessons Learned:**
- What went wrong
- What went right (during investigation)
- Process improvements for future RCA
- Knowledge to share across organization

**Appendices:**
- Raw data/logs
- Interview notes
- Timeline of events
- Supporting documentation

---

## Specialized 5 Whys Applications

### **For Manufacturing/Production:**
- Focus on: Equipment, materials, methods, environment
- Consider: Preventive maintenance, quality control, training
- Common roots: Maintenance schedules, inspection procedures, calibration

### **For Software/IT:**
- Focus on: Code, configuration, deployment, monitoring
- Consider: Testing procedures, code review, change management
- Common roots: Lack of automated testing, insufficient monitoring, poor documentation

### **For Customer Service:**
- Focus on: Processes, training, communication, tools
- Consider: Customer journey, handoffs, information flow
- Common roots: Inadequate training, unclear procedures, disconnected systems

### **For Safety Incidents:**
- Focus on: Human factors, equipment, procedures, environment
- Consider: Risk assessments, safety culture, compliance
- Common roots: Inadequate risk assessment, shortcuts normalized, missing safeguards

### **For Project Delays:**
- Focus on: Planning, resources, dependencies, communication
- Consider: Estimation processes, risk management, stakeholder alignment
- Common roots: Unrealistic estimates, scope creep, resource constraints

---

## Advanced Techniques

### **Combining 5 Whys with Other Methods:**

**5 Whys + Fishbone (Ishikawa):**
- Use fishbone to identify multiple categories
- Apply 5 Whys to each category branch
- Comprehensive root cause coverage

**5 Whys + 5W1H:**
- Who, What, When, Where, Why, How
- Ensures complete problem understanding
- Thorough evidence gathering

**5 Whys + Pareto Analysis:**
- Identify most frequent/impactful problems
- Apply 5 Whys to top issues
- Maximize improvement ROI

**5 Whys + Fault Tree Analysis:**
- For complex technical systems
- Map logical relationships
- Identify critical failure points

---

## Quality Checklist for Complete Analysis

**Before concluding your 5 Whys analysis, verify:**

- [ ] Problem statement is specific and verified
- [ ] Each "why" answer is supported by evidence
- [ ] Assumptions have been challenged
- [ ] Alternative causes were considered
- [ ] Root cause passes all validation tests
- [ ] Root cause is actionable and controllable
- [ ] Multiple paths explored if applicable
- [ ] Actions address root cause, not symptoms
- [ ] Actions have owners and deadlines
- [ ] Success metrics defined
- [ ] Verification plan in place
- [ ] Documentation complete
- [ ] Lessons learned captured
- [ ] Stakeholders informed

---

## Now, Please Provide:

1. **Your specific problem** (be as detailed as possible)
2. **When and where** it occurred
3. **Impact/severity** of the problem
4. **Any evidence or data** you have
5. **Previous occurrences** (if any)
6. **Industry/context** for tailored approach
7. **Desired outcome** (root cause only, or full action plan)

Let's conduct a rigorous root cause analysis using the 5 Whys framework to identify the TRUE root cause and prevent recurrence! 🔍✅

Leave a Reply

Your email address will not be published. Required fields are marked *