Root Cause Analysis

Root Cause Analysis

Introduction: Why This Matters

Problems in projects are symptoms of deeper issues. Root Cause Analysis (RCA) is the systematic technique used to identify the underlying cause of a problem rather than simply addressing its surface effects. By finding the true source, project managers can prevent recurrence and implement long-lasting solutions.

On the PMP exam, RCA is often tested in questions related to quality management, risk management, and lessons learned. In practice, it is a vital tool for improving processes, reducing defects, and strengthening project outcomes.

Purpose and Objectives

Primary Purpose: To go beyond symptoms and identify the fundamental reason a problem occurs.

Key Objectives:

  • Distinguish between symptoms and true causes of problems.
  • Apply structured techniques to investigate issues.
  • Develop corrective and preventive actions that eliminate recurrence.
  • Strengthen quality management and continuous improvement processes.
  • Use RCA results to update lessons learned and organizational knowledge.

Overview

Root Cause Analysis helps you identify why a problem happens, not just what happened. It focuses on eliminating recurrence by targeting the underlying drivers.

  • When to use: Recurring issues, repeated defects, recurring breakdowns, or persistent stakeholder complaints.
  • Where it shows up: Quality management, risk management, and lessons learned activities.
  • Outcome focus: Corrective and preventive actions that address the real cause, not just the symptom.

Characteristics

  • Systematic: Uses structured methods to investigate the problem.
  • Cause-focused: Separates surface symptoms from underlying drivers.
  • Actionable: Produces corrective and preventive actions that reduce recurrence.
  • Continuous improvement: Strengthens processes and supports organizational learning.
  • Non-blaming: Focuses on process and system gaps, not personal fault.

Practical Example

Context: In a software project, repeated defects were occurring in the customer login module. Users reported frequent login failures.

Activities:

  • Defined the symptom: Frequent login failures reported by users.
  • Applied the Five Whys: Asked “why” repeatedly until the underlying driver was uncovered.
  • Documented the cause and actions: Identified what needs to change to prevent recurrence.

Five Whys (Example Walkthrough):

  1. Why are users experiencing failures? Because the login function crashes.
  2. Why does it crash? Because error handling is missing in the code.
  3. Why is error handling missing? Because requirements did not specify exceptions.
  4. Why were requirements incomplete? Because stakeholders were not fully engaged.
  5. Why were stakeholders not engaged? Because the schedule did not allocate sufficient time for requirements workshops.

Outcome: The root cause was inadequate stakeholder engagement during requirements collection. The solution was to improve stakeholder workshops, validate requirements thoroughly, and add error-handling standards to coding practices.

Common Pitfalls

Stopping Too Early

  • Pitfall: Addressing a surface issue instead of digging deeper.
  • Prevention: Use a structured method like Five Whys or a fishbone diagram and validate the cause with data.

Turning RCA into Blame

  • Pitfall: Focusing on who made the mistake instead of what system allowed it.
  • Prevention: Keep the analysis process-focused and create solutions that improve the process.

Overcomplicating the Investigation

  • Pitfall: Using too many tools without clarity, which slows decision-making.
  • Prevention: Choose the simplest tool that fits the scenario and keep the analysis practical.

No Follow-Through

  • Pitfall: Identifying root causes without implementing corrective or preventive actions.
  • Prevention: Assign owners, due dates, and tracking in the issue log and lessons learned register.

Sensei Tip : In RCA, you are hunting patterns, not culprits. If the room gets defensive, your analysis will get shallow.

Exam Alert : If the problem is recurring, the exam usually wants the “why” tool. If it is a one-time decision, the exam usually wants an analysis or evaluation method instead.

Exam Lens

Patterns on the PMP Exam:

  • RCA is used to identify the true cause of a recurring issue, not just treat symptoms.
  • Common RCA tools: Five Whys, fishbone diagram (Ishikawa), and fault tree analysis.

Sample Question

Question: A project manager is investigating repeated equipment breakdowns on a construction site. Instead of addressing each breakdown individually, the manager wants to determine the underlying reason for the failures. Which technique should be used?

  1. Variance Analysis
  2. Root Cause Analysis
  3. Decision Tree Analysis
  4. Benchmarking

Correct Answer: B. Root Cause Analysis
Rationale: Root Cause Analysis focuses on identifying and addressing the fundamental cause of an issue, not just the symptoms.

Quick Recap Table

Concept Description Exam Watch Point
Root Cause Analysis Identifies underlying reasons for problems Look for “symptom vs. cause” language
Tools Five Whys, fishbone diagram, fault tree analysis Exam may mention Ishikawa or “why” analysis
Outputs Corrective and preventive actions, process updates Expect scenarios about problem recurrence

Key Takeaways

  • Root Cause Analysis digs beneath symptoms to reveal true causes.
  • Common tools include Five Whys, fishbone diagrams (Ishikawa), and fault tree analysis.
  • RCA prevents recurrence, supports continuous improvement, and strengthens quality outcomes.
  • On the PMP exam, RCA usually signals “identify the fundamental cause of a recurring issue.”

Next Step

With root cause analysis covered, we now move to the next data analysis technique: Variance Analysis.

Bibliography

Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (Project Management Body of Knowledge Guide) (7th ed.). Project Management Institute.

Scroll to Top