Apollo Root Cause Analysis (Apollo RCA) is a structured, evidence-based investigation method that maps cause-and-effect relationships to explain why an incident, failure, or quality deviation occurred. Unlike simpler tools that follow a single line of questioning, Apollo RCA builds a visual “reality chart” showing how multiple causes combine and interact to produce an outcome.
It’s most commonly used for equipment failures, process safety incidents, reliability problems, and quality deviations where more than one factor is likely at play — a pump trip, a compressor failure, a batch quality rejection, or a near-miss with several contributing conditions. By the end of this article, you’ll understand what Apollo RCA is, how the workflow runs step by step, how it stacks up against 5 Whys, Fishbone, and Fault Tree Analysis, and how to decide which method fits a given problem.
What is Apollo RCA?
At its core, Apollo RCA is built on a simple but rigorous idea: every effect has at least two causes — an action and one or more conditions that allowed that action to produce the effect. Investigators keep asking “why” at each node, but instead of a single downward chain (as in 5 Whys), they branch outward whenever more than one cause contributes to an effect. Each cause on the chart must be supported by evidence; unsupported causes are marked as assumptions and either validated or discarded.
This branching, evidence-driven structure is what separates Apollo RCA from linear methods. It’s most useful when an event has multiple, interacting causes — a combination of a maintenance gap, an operating decision, a design limitation, and an environmental condition, for example — because it forces the team to capture all of them rather than stopping at the first plausible explanation.
Apollo RCA vs 5 Whys vs Fishbone vs Fault Tree
| Method | Best For | Strengths | Weaknesses | Typical Output |
| Apollo RCA | Complex, multi-causal incidents (equipment failures, major incidents) | Captures multiple interacting causes; evidence-based; avoids single-cause bias | Takes longer to learn and facilitate; needs trained facilitator | Cause-and-effect chart with validated causes and solutions |
| 5 Whys | Simple, single-thread problems | Fast, easy to teach, no special tools needed | Tends to follow one causal path; can miss contributing factors | Short list of sequential “why” answers |
| Fishbone (Ishikawa) | Brainstorming possible cause categories | Good for team workshops; organizes causes by category (people, process, equipment, etc.) | Doesn’t show cause-and-effect logic or evidence links; can generate long unranked lists | Categorized diagram of potential causes |
| Fault Tree Analysis | Safety-critical, probability-driven systems | Rigorous, quantifiable, supports reliability/probability calculations | Requires technical/statistical expertise; heavier setup | Logic tree with AND/OR gates and failure probabilities |
Apollo RCA Workflow (Step by Step)
- Define the problem — State the event precisely: what happened, when, where, and what the significance is (safety, production, cost, quality).
- Collect evidence — Gather data, records, interviews, photos, and physical evidence before forming theories. Evidence should be time-stamped and traceable.
- Build the cause-and-effect chart — Starting from the primary effect, ask why it occurred and branch out for every action and condition involved, continuing until causes reach an organizational or systemic level.
- Validate causes — Test each branch against the evidence gathered. Causes without supporting evidence are flagged and either confirmed or removed.
- Identify solutions and controls — For each validated root cause, generate solutions that reduce the probability of recurrence, and select those that are effective, within control, and don’t introduce new risks.
- Document and follow up — Record the chart, evidence, and chosen actions, assign owners and dates, and track implementation and effectiveness over time.
Example Scenario (Generic)
This is an illustrative example only — not actual client data.
Scenario: Pump trip leading to production loss.
A centrifugal pump trips unexpectedly, halting a process unit for several hours. A 5 Whys approach might stop at “the bearing failed because of inadequate lubrication.” An Apollo RCA chart typically surfaces several parallel, contributing causes, such as:
- Maintenance: a lubrication schedule that had slipped past its due date
- Operations: the pump running outside its designed flow envelope during a process upset
- Design: a bearing specification marginally suited to the operating conditions
- Environment: elevated ambient temperature accelerating lubricant breakdown
None of these alone fully explains the failure — it was the combination that produced the trip. Apollo RCA’s branching structure is what allows all four threads to be captured, validated, and addressed, rather than closing the investigation after the first workable explanation.
Common Mistakes in RCA
- Jumping to solutions too early. Teams often propose a fix before the causal chain is validated, which risks addressing a symptom instead of a root cause.
- Blaming “human error” without deeper causes. An operator or technician action is rarely a root cause on its own — the conditions that made the error possible (training, procedures, workload, equipment design) usually matter more.
- Weak evidence handling. Causes based on assumption rather than verified evidence weaken the whole investigation and make corrective actions harder to justify.
How to Choose the Right RCA Method
- If the problem is simple and single-threaded → use 5 Whys.
- If the problem is complex with multiple interacting factors → use Apollo RCA.
- If the problem needs early-stage brainstorming across categories → use Fishbone (Ishikawa).
- If the problem is safety-critical and needs probability or logic modeling → use Fault Tree Analysis.
- If unsure, or if the event is significant (safety incident, major production loss, repeat failure) → default to Apollo RCA, since it’s built to handle unknown complexity rather than assume a single cause.
In One Paragraph: Apollo RCA Explained
Apollo RCA is a structured, evidence-based root cause analysis method that maps how multiple causes — actions and conditions — combine to produce an incident, rather than following a single line of “why” questions. It is best suited to complex, multi-causal failures such as equipment breakdowns, process safety incidents, and recurring quality problems, where simpler tools like 5 Whys risk stopping at the first plausible cause. By requiring every cause to be validated with evidence, Apollo RCA helps teams move past blame, uncover systemic contributing factors, and design corrective actions that actually prevent recurrence.
Want to build this capability in-house? Explore the Apollo Root Cause Analysis™ Methodology training course at EnergyEdge.
RCA Glossary
- Corrective action: A specific action taken to eliminate or reduce the recurrence of a validated root cause.
- Contributing factor: A condition or action that helped produce an effect but is not, on its own, sufficient to explain it.
- Barrier: A control or safeguard designed to prevent a cause from producing its effect, or to limit the consequences if it does.
- Control: An ongoing measure — procedural, physical, or administrative — put in place to keep a validated cause from recurring.
Frequently Asked Questions
Apollo RCA is a methodology, not a specific software product. It is commonly practiced using RealityCharting® software, which helps teams visualize the cause-and-effect chart, but the underlying discipline — evidence-based, branching cause analysis — is what defines the method.
It depends on the complexity of the event. A straightforward Apollo RCA investigation might be completed in a few days once evidence is gathered, while a major incident with many contributing factors can take several weeks, particularly if evidence collection or specialist input is required.
Facilitating Apollo RCA effectively generally requires structured training in the methodology — how to build a valid cause-and-effect chart, apply evidence-testing rules, and facilitate a team through the process without bias toward a predetermined conclusion.
