Skip to main content
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).

​
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.
MethodBest forStrengthsLimitations
5 WhysSimple, linear cause chainsQuick, intuitive, easy to documentMay oversimplify complex events with multiple interacting causes
Fishbone (Ishikawa)Complex events with multiple contributing factorsStructured categorization across domains; reveals breadth of contributing factorsDoes not inherently prioritize causes; can become unwieldy
Barrier AnalysisEvents involving multiple safeguard breakdownsDirectly identifies defense failures; maps to control improvementsRequires understanding of intended barriers; less useful when barriers were never defined
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

1
Step 1: Open the RCA section
2
  • Navigate to the investigation detail page.
  • Open the Analysis tab.
  • In the Root Cause Analysis section, add a root cause.
  • Select 5 Whys as the method.
    • 3
    Step 2: Write the event statement
    4
    State the event clearly and factually. Focus on the observable outcome, not assumptions about cause.
    5
    Example: “Aircraft N12345 departed without the ground power unit being disconnected, resulting in damage to the GPU connector and aircraft receptacle.”
    6
    Step 3: Ask successive “Why” questions
    7
    For each level, ask “Why did this happen?” and document the answer based on your investigation findings and evidence.
    8
    LevelQuestionExample AnswerWhy 1Why did the aircraft depart with GPU connected?The flight crew did not verify GPU disconnection during the pre-departure checklist.Why 2Why was GPU disconnection not verified?The pre-departure checklist does not include a specific GPU disconnection check.Why 3Why 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 4Why 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 5Why is there no MOC trigger for GSE changes?The MOC process scope was limited to aircraft modifications and did not include ground operations.
    9
    Step 4: Document the root cause
    10
    Based on the chain, state the root cause clearly:
    11
    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.”
    12
    Step 5: Save the analysis
    13
    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

    CategoryScopeExample factors
    PeopleHuman factors, training, fatigue, experience, communicationCrew fatigue from 14-hour duty day; new copilot with 30 hours in type
    ProceduresSOPs, checklists, regulatory requirements, documentationPre-departure checklist missing GPU step; no written taxi procedure for icy conditions
    EquipmentAircraft systems, ground equipment, tools, softwareGPU connector worn beyond service limits; caution light inoperative
    EnvironmentWeather, airport conditions, organizational culture, time pressureNight operation; schedule pressure from delayed inbound flight
    ManagementSupervision, resource allocation, scheduling, policiesNo supervisory oversight of ground ops; MOC scope excludes GSE
    MaterialsFuels, fluids, parts, supplies, documentation materialsReplacement connector on backorder; maintenance manual section outdated

    ​
    Conduct a Fishbone analysis

    1
    Step 1: Create the Fishbone analysis
    2
  • In the investigation’s Analysis tab, add a root cause.
  • Select Fishbone (Ishikawa) as the method.
  • Enter the event statement — this becomes the “head” of the fish.
    • 3
    Step 2: Populate each category
    4
    For each of the six categories:
    5
  • Review your investigation findings, evidence, and witness statements.
  • Identify factors within that category that contributed to the event.
  • Enter each contributing factor as a separate item under the category.
  • For each factor, document the supporting evidence.
    • 6
    Not every category will have contributing factors for every event. Leave categories empty if they are not relevant.
    7
    Step 3: Identify primary root causes
    8
  • Review the completed diagram across all categories.
  • Identify the factors that were most significant in causing the event.
  • Mark primary root causes — these are the factors that, if addressed, would most effectively prevent recurrence.
  • Document why you consider each primary cause to be a root cause rather than a contributing factor.
    • 9
    Step 4: Save the analysis
    10
    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.

    ​
    Conduct a Barrier analysis

    1
    Step 1: Create the Barrier Analysis
    2
  • In the investigation’s Analysis tab, add a root cause.
  • Select Barrier Analysis as the method.
    • 3
    Step 2: Define the hazard and target
    4
  • Enter the hazard — the threat or unsafe condition. Example: “Ground power unit connected to aircraft during engine start and taxi.”
  • Enter the target — who or what was at risk. Example: “Aircraft N12345 electrical system; GPU equipment; ramp personnel.”
    • 5
    Step 3: List all barriers
    6
    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.
    7
    Example barriers:
    8
  • 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)
    • 9
    Step 4: Assess each barrier
    10
    For each barrier, assign a status:
    11
    BarrierStatusGap AnalysisPre-departure checklist GPU stepAbsentChecklist does not include GPU disconnection verificationGround crew hand signalBypassedCrew did not wait for ground crew signal due to schedule pressureGPU breakaway connectorFailedConnector was worn and did not release under load as designedRamp supervisor walkdownAbsentNo supervisor was assigned to the departureExternal power annunciatorEffectiveLight illuminated but crew did not notice during night operation
    12
    Step 5: Document the gap analysis
    13
    For each barrier that was not effective, document:
    14
  • 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
    • 15
    Step 6: Identify root causes from barrier gaps
    16
    The pattern of barrier failures reveals the root causes. In the example above, root causes include:
    17
  • 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)
    • 18
    Step 7: Save the analysis
    19
    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:
    1. Each root cause should produce at least one recommendation.
    2. Recommendations become CPAs when the investigation is approved (see Create a 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?”

    Manage Investigations

    Full investigation workflow from assignment through approval.

    Investigation Workflow

    Statuses, RCA methods, and approval rules reference.

    CPA Lifecycle

    How investigation recommendations become tracked corrective actions.

    Run Your First Investigation

    Tutorial walkthrough of the complete investigation process.
    Last modified on April 11, 2026