> ## Documentation Index > Fetch the complete documentation index at: https://docs.planeconnection.com/llms.txt > Use this file to discover all available pages before exploring further. # How to Conduct Root Cause Analysis > Use the 5 Whys, Fishbone (Ishikawa), or Barrier Analysis methods to identify root causes during safety investigations. By following this guide, you will identify root causes during a safety investigation using one of three structured RCA methods: 5 Whys, Fishbone (Ishikawa), or Barrier Analysis. Each method produces documented findings that feed into investigation recommendations and CPAs. **Who should read this:** Lead investigators and investigators conducting safety investigations. Safety managers who review investigation findings will also benefit from understanding the methodologies. **Prerequisites:** An active investigation in **Data Collection** or **Analysis** status. Familiarity with the investigation workflow (see [Manage Investigations](/en/how-to/sms/manage-investigations)). ## Choose the Right Method PlaneConnection supports three RCA methods. Each is suited to different types of events. You may use more than one method on the same investigation if the complexity warrants it. | Method | Best for | Strengths | Limitations | | ----------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **5 Whys** | Simple, linear cause chains | Quick, intuitive, easy to document | May oversimplify complex events with multiple interacting causes | | **Fishbone (Ishikawa)** | Complex events with multiple contributing factors | Structured categorization across domains; reveals breadth of contributing factors | Does not inherently prioritize causes; can become unwieldy | | **Barrier Analysis** | Events involving multiple safeguard breakdowns | Directly identifies defense failures; maps to control improvements | Requires understanding of intended barriers; less useful when barriers were never defined | ```mermaid theme={} flowchart TD A[Safety Event Identified] --> B{Single clear
cause chain?} B -->|Yes| C[5 Whys] B -->|No| D{Multiple contributing
factors across
different domains?} D -->|Yes| E[Fishbone] D -->|No| F{Defense-in-depth
failures?} F -->|Yes| G[Barrier Analysis] F -->|No| H[Start with Fishbone
to map factors, then
apply 5 Whys to
each branch] ``` When in doubt, start with the Fishbone method to map out all potential contributing factors, then use the 5 Whys to drill into the most significant branches. This combined approach works well for moderately complex events. ## Method 1: 5 Whys The 5 Whys method traces a causal chain from the event back to its root cause through iterative questioning. Each "why" peels back a layer of causation until the fundamental systemic issue is revealed. ### Conduct a 5 Whys analysis ### Step 1: Open the RCA section 1. Navigate to the investigation detail page. 2. Open the **Analysis** tab. 3. In the **Root Cause Analysis** section, add a root cause. 4. Select **5 Whys** as the method. ### Step 2: Write the event statement State the event clearly and factually. Focus on the observable outcome, not assumptions about cause. **Example:** "Aircraft N12345 departed without the ground power unit being disconnected, resulting in damage to the GPU connector and aircraft receptacle." ### Step 3: Ask successive "Why" questions For each level, ask "Why did this happen?" and document the answer based on your investigation findings and evidence. | Level | Question | Example Answer | | :---: | ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Why 1 | Why did the aircraft depart with GPU connected? | The flight crew did not verify GPU disconnection during the pre-departure checklist. | | Why 2 | Why was GPU disconnection not verified? | The pre-departure checklist does not include a specific GPU disconnection check. | | Why 3 | Why is GPU disconnection not on the checklist? | The checklist was last revised in 2019 and did not account for the new GPU configuration installed in 2024. | | Why 4 | Why was the checklist not updated after the GPU change? | There is no Management of Change process that triggers checklist reviews when ground support equipment changes. | | Why 5 | Why is there no MOC trigger for GSE changes? | The MOC process scope was limited to aircraft modifications and did not include ground operations. | ### Step 4: Document the root cause Based on the chain, state the root cause clearly: **Root cause:** "The Management of Change process does not include ground support equipment changes in its scope, resulting in procedures that are not updated when ground operations change." ### Step 5: Save the analysis Save the analysis to record it. The root cause becomes a documented output linked to the investigation. The "5" in 5 Whys is a guideline, not a strict rule. Some root causes surface in 3 levels; others require 6 or 7. Stop when you reach a systemic cause that the organization can act on. If you find yourself asking "Why?" and the answer is outside your organization's control (e.g., "because physics"), you have gone too far. ## Method 2: Fishbone (Ishikawa) The Fishbone diagram organizes contributing factors into six standard categories, providing a structured view of all the conditions that may have contributed to the event. This method is particularly effective for complex events where multiple factors across different domains interacted. ### Categories | Category | Scope | Example factors | | --------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------- | | **People** | Human factors, training, fatigue, experience, communication | Crew fatigue from 14-hour duty day; new copilot with 30 hours in type | | **Procedures** | SOPs, checklists, regulatory requirements, documentation | Pre-departure checklist missing GPU step; no written taxi procedure for icy conditions | | **Equipment** | Aircraft systems, ground equipment, tools, software | GPU connector worn beyond service limits; caution light inoperative | | **Environment** | Weather, airport conditions, organizational culture, time pressure | Night operation; schedule pressure from delayed inbound flight | | **Management** | Supervision, resource allocation, scheduling, policies | No supervisory oversight of ground ops; MOC scope excludes GSE | | **Materials** | Fuels, fluids, parts, supplies, documentation materials | Replacement connector on backorder; maintenance manual section outdated | ### Conduct a Fishbone analysis ### Step 1: Create the Fishbone analysis 1. In the investigation's **Analysis** tab, add a root cause. 2. Select **Fishbone (Ishikawa)** as the method. 3. Enter the **event statement** -- this becomes the "head" of the fish. ### Step 2: Populate each category For each of the six categories: 1. Review your investigation findings, evidence, and witness statements. 2. Identify factors within that category that contributed to the event. 3. Enter each contributing factor as a separate item under the category. 4. For each factor, document the supporting evidence. Not every category will have contributing factors for every event. Leave categories empty if they are not relevant. ### Step 3: Identify primary root causes 1. Review the completed diagram across all categories. 2. Identify the factors that were most significant in causing the event. 3. Mark primary root causes -- these are the factors that, if addressed, would most effectively prevent recurrence. 4. Document why you consider each primary cause to be a root cause rather than a contributing factor. ### Step 4: Save the analysis Save the analysis to record the Fishbone with all categories and identified root causes. Conduct the Fishbone analysis collaboratively when possible. Different perspectives -- flight crew, maintenance, dispatch, management -- often reveal factors that a single investigator might miss. The six categories serve as prompts to ensure you consider all domains. ## Method 3: Barrier Analysis Barrier Analysis examines the defenses -- physical, procedural, and administrative -- that should have prevented the event, and identifies where they failed, were bypassed, or were absent. For the full field definitions and barrier status reference, see [Investigation Workflow](/en/reference/investigation-workflow). ### Conduct a Barrier analysis ### Step 1: Create the Barrier Analysis 1. In the investigation's **Analysis** tab, add a root cause. 2. Select **Barrier Analysis** as the method. ### Step 2: Define the hazard and target 1. Enter the **hazard** -- the threat or unsafe condition. Example: "Ground power unit connected to aircraft during engine start and taxi." 2. Enter the **target** -- who or what was at risk. Example: "Aircraft N12345 electrical system; GPU equipment; ramp personnel." ### Step 3: List all barriers Enumerate every barrier -- physical, procedural, and administrative -- that was intended to prevent the hazard from reaching the target. Include barriers that should have existed even if they were not in place. **Example barriers:** * Pre-departure checklist GPU disconnection step (procedural) * Ground crew hand signal for "all clear" (procedural) * GPU breakaway connector designed to disconnect under load (physical) * Ramp supervisor walkdown before pushback (administrative) * Aircraft external power annunciator light (physical) ### Step 4: Assess each barrier For each barrier, assign a status: | Barrier | Status | Gap Analysis | | -------------------------------- | ------------- | ----------------------------------------------------------------- | | Pre-departure checklist GPU step | **Absent** | Checklist does not include GPU disconnection verification | | Ground crew hand signal | **Bypassed** | Crew did not wait for ground crew signal due to schedule pressure | | GPU breakaway connector | **Failed** | Connector was worn and did not release under load as designed | | Ramp supervisor walkdown | **Absent** | No supervisor was assigned to the departure | | External power annunciator | **Effective** | Light illuminated but crew did not notice during night operation | ### Step 5: Document the gap analysis For each barrier that was not effective, document: * Why the barrier failed, was bypassed, or was never implemented * What systemic factors contributed to the barrier's inadequacy * What organizational conditions allowed the gap to persist ### Step 6: Identify root causes from barrier gaps The pattern of barrier failures reveals the root causes. In the example above, root causes include: * No MOC process covering ground equipment changes (absent barrier) * Normalization of deviance around ground crew signaling procedures (bypassed barrier) * Inadequate inspection intervals for GPU connectors (failed barrier) ### Step 7: Save the analysis Save the analysis to record the complete Barrier Analysis. Barrier Analysis requires a thorough understanding of what defenses should exist. If your organization has not formally defined its barriers for a given hazard, the analysis itself becomes a valuable exercise in identifying what controls need to be established. Document missing barriers as absent and create CPAs to implement them. ## From root causes to recommendations Regardless of which RCA method you use, the output follows the same path: ```mermaid theme={} flowchart LR A[Root Causes
Identified] --> B[Recommendations
Documented] B --> C[Investigation
Approved] C --> D[CPAs Created
and Assigned] D --> E[Actions
Implemented] E --> F[Effectiveness
Verified] ``` 1. Each root cause should produce at least one recommendation. 2. Recommendations become CPAs when the investigation is approved (see [Create a CPA](/en/how-to/sms/create-cpa)). 3. CPAs are tracked through implementation and verification, closing the loop from event to resolution. Per ICAO Annex 13 principles, the purpose of investigation and RCA is prevention, not blame. Focus your analysis on systemic and organizational factors -- procedures, training, oversight, design -- rather than individual performance. Root causes that point to "the person made a mistake" should be followed further to ask "what systemic conditions allowed or encouraged that mistake?" ## Related Full investigation workflow from assignment through approval. Statuses, RCA methods, and approval rules reference. How investigation recommendations become tracked corrective actions. Tutorial walkthrough of the complete investigation process.