Both fishbone diagrams and fault tree analysis (FTA) help teams find the causes of problems, but they work in fundamentally different ways. A fishbone diagram brainstorms possible causes qualitatively across categories. A fault tree models how specific failures combine using Boolean logic to produce a top-level event. Knowing when to use each — and when to combine them — depends on the complexity, safety criticality, and data requirements of your analysis.

Quick comparison

AspectFishbone (Ishikawa)Fault Tree Analysis
ApproachQualitative brainstorming; inductive (causes → effect)Quantitative deductive modeling (effect → cause combinations)
Best forBroad brainstorming, quality problems, team workshopsSafety-critical systems, failure probability, redundancy analysis
Time needed45–90 minutesSeveral hours to days (depending on system complexity)
Team size3–8 people1–3 specialists
Data neededTeam knowledge and experienceFailure rate data, system architecture, probability estimates
OutputCategorized list of potential causesFault tree with AND/OR gates, minimal cut sets, probability values
ComplexityLow — anyone can learn in minutesHigh — requires Boolean logic, probability math, specialized notation

How each method works

Fishbone Diagram

A fishbone diagram organizes potential causes into 4–6 categories (like People, Process, Technology). The team brainstorms causes under each category, creating a visual map of everything that might contribute to the problem.

  • Inductive: starts with individual causes, groups them into categories
  • Qualitative: no probability calculations
  • Collaborative: designed for team brainstorming
  • Fast: 45–90 minutes for a complete session

Fault Tree Analysis

A fault tree starts with an undesired event (the "top event") and works downward, modeling how combinations of lower-level failures lead to it. It uses AND gates (all conditions must be true) and OR gates (any condition triggers the event).

  • Deductive: starts with the top event, works down to basic events
  • Quantitative: calculates failure probabilities
  • Specialized: requires trained analysts
  • Rigorous: identifies minimal cut sets (smallest failure combinations)

Fault tree structure

A fault tree uses logic gates to show how failures combine. An OR gate means any single child event can trigger the parent. An AND gate means all child events must occur together to trigger the parent.

┌──────────────────────┐ │ SYSTEM FAILURE │ (Top Event) │ (Total Power Loss) │ └──────────┬───────────┘ │ ┌────OR────┐ │ │ ┌──────────┴──┐ ┌───┴───────────┐ │ Grid Outage │ │ Backup Failure │ │ (P = 0.01) │ │ │ └─────────────┘ └───────┬───────┘ │ ┌───AND───┐ │ │ ┌────────┴──┐ ┌───┴────────┐ │ Generator │ │ Battery │ │ Fails │ │ Depleted │ │ (P=0.05) │ │ (P=0.02) │ └───────────┘ └────────────┘ Grid OR (Generator AND Battery) = 0.01 + (0.05 x 0.02) = 0.011

When to use a fishbone diagram

Scenario 1: Quality brainstorming workshop

Your manufacturing line has a rising defect rate. You need the whole team to brainstorm possible causes quickly. A fishbone diagram gets 6 people contributing ideas across categories in under an hour. No failure rate data is needed — just experience and observation.

Scenario 2: Service incident postmortem

A SaaS platform had a four-hour outage. The engineering team needs to identify all contributing factors, not just the immediate trigger. A fishbone maps causes across People, Process, Technology, and Environment, ensuring no category is overlooked.

Scenario 3: Cross-functional problem-solving

Customer churn has increased. The problem spans sales, product, support, and pricing. A fishbone with custom categories (Onboarding, Product Fit, Support Quality, Pricing, Competition) lets diverse team members contribute without needing specialized training.

Scenario 4: Quick initial analysis

You need a starting framework for investigation, not a final answer. A fishbone generates a categorized list of hypotheses in 45 minutes that can then guide data collection and deeper analysis with other methods.

When to use fault tree analysis

Scenario 1: Safety-critical system design

You are designing a medical device and need to demonstrate that the probability of a hazardous failure is below 10⁻⁶ per operating hour. A fault tree quantifies how component failures combine and identifies which failure combinations (minimal cut sets) are most critical.

Scenario 2: Redundancy validation

Your data center has redundant power supplies, network paths, and cooling systems. A fault tree with AND gates proves that a single component failure cannot cause a total outage, and it calculates the probability that all redundant systems fail simultaneously.

Scenario 3: Regulatory compliance

Industries like aerospace (ARP4761), nuclear (NUREG-0492), and automotive (ISO 26262) often require formal fault tree analysis as part of safety assessment documentation. A fishbone diagram would not satisfy these regulatory requirements.

Scenario 4: Common cause failure analysis

You need to identify scenarios where a single root cause could defeat multiple safety barriers simultaneously. Fault tree analysis with common cause failure modeling explicitly identifies these dangerous scenarios, which a fishbone brainstorming session might miss.

When to use both together

Combined workflow

The most thorough analysis uses both methods in sequence. Start with a fishbone to brainstorm broadly, then model critical failure paths formally with a fault tree. Here is a practical combined workflow:

  1. Fishbone brainstorming (45–60 min). Gather the cross-functional team. Brainstorm all potential causes of the problem across categories. Do not filter at this stage.
  2. Prioritize critical paths (15 min). Use dot voting or expert judgment to identify the 3–5 most critical failure paths from the fishbone.
  3. Build fault trees for critical paths (hours–days). For each critical path, a trained analyst builds a formal fault tree with AND/OR gates, failure rate data, and probability calculations.
  4. Calculate minimal cut sets. Identify the smallest combinations of failures that lead to the top event. These are your highest-priority risks.
  5. Design corrective actions. For each minimal cut set, add barriers, redundancy, or monitoring to reduce the probability below acceptable thresholds.
  6. Verify and document. Update the fault tree with the new barriers in place. Recalculate probabilities to confirm the risk is acceptable.

Example: Analyzing the same problem both ways

Problem: A hospital medication dispensing system delivered the wrong medication to a patient.

Fishbone diagram approach

CategoryPotential Causes
PeopleNurse scanned wrong patient wristband; pharmacist misread handwriting; tech loaded wrong drawer
ProcessNo independent double-check step; override used without documentation; verbal orders accepted
TechnologyBarcode scanner firmware outdated; drug database not updated; alert fatigue from excessive warnings
EnvironmentDim lighting in medication room; noise and interruptions during prep; night shift understaffing

Outcome: The team identified 12 potential causes in 50 minutes. Dot voting highlighted "alert fatigue from excessive warnings" and "no independent double-check step" as top candidates. They then ran a 5 Whys analysis on each to find the root cause.

Fault tree approach

┌──────────────────────────┐ │ WRONG MEDICATION │ (Top Event) │ ADMINISTERED │ └────────────┬─────────────┘ │ ┌───AND───┐ │ │ ┌──────────┴────┐ ┌─┴──────────────────┐ │ Wrong Drug │ │ Verification │ │ Selected │ │ Failed │ └───────┬───────┘ └─────────┬───────────┘ │ │ ┌───OR────┐ ┌────OR────┐ │ │ │ │ ┌────────┴──┐ ┌────┴────┐ ┌─┴────────┐ ┌┴────────────┐ │ Pharmacist│ │ System │ │ Barcode │ │ Nurse │ │ Error │ │ Database│ │ Scanner │ │ Override │ │ P=0.003 │ │ Stale │ │ Failed │ │ Without │ └───────────┘ │ P=0.001 │ │ P=0.008 │ │ Double-Check│ └─────────┘ └──────────┘ │ P=0.04 │ └─────────────┘ Top Event = (0.003+0.001) x (0.008+0.04) = 0.004 x 0.048 = 0.000192

Outcome: The fault tree quantified that the probability of wrong medication administration is approximately 1.9 × 10⁻⁴ per dispensing event. It revealed that the AND gate (wrong drug AND verification failure) provides a critical safety layer, but the high probability of "nurse override without double-check" (P=0.04) is the largest contributor to the verification gate. Reducing that single probability would have the greatest impact on overall safety.

What each method revealed

InsightFishboneFault Tree
Breadth of causesIdentified 12 causes across 4 categories, including environmental factorsFocused on 4 failure modes in the critical path
ProbabilityNo probability dataCalculated 1.9 × 10⁻⁴ per event
Highest-impact fixQualitative: "alert fatigue" and "no double-check"Quantitative: reducing nurse override probability from 0.04 to 0.005 cuts overall risk by 87%
Time required50 minutes4 hours (including data collection)
Regulatory valueUseful for internal improvementMeets formal safety analysis requirements

Build your fishbone diagram now

Start with a qualitative brainstorm using our free fishbone tool, then decide if you need a formal fault tree for critical paths.

Start Free Fishbone Diagram →

Key differences in detail

Logic and structure

A fishbone diagram uses a flat category structure with no logic gates. Every cause on the diagram is implicitly connected to the effect by an OR relationship: any one of them could be a contributor. There is no way to express that two causes must occur together to produce the effect.

A fault tree explicitly models AND and OR relationships. This distinction is critical for systems with redundancy. An AND gate shows that a backup system must also fail before the top event occurs — something a fishbone cannot represent.

Quantitative vs. qualitative

Fishbone diagrams produce a qualitative list of potential causes. They answer "what might be causing this?" but not "how likely is it?" Fault tree analysis assigns probabilities to each basic event and calculates the probability of the top event, enabling risk-based decisions about where to invest in prevention.

Team dynamics

Fishbone diagrams thrive on diverse team participation. The brainstorming format encourages input from people who may not have formal training in analysis methods. Fault tree analysis is typically performed by 1–3 trained reliability engineers or safety analysts. Involving a large team in fault tree construction is impractical because of the technical notation and mathematical requirements.

Industry adoption

Fishbone diagrams are universal. They are used in manufacturing, healthcare, IT, services, education, and virtually every other sector. Fault tree analysis is concentrated in high-reliability industries: aerospace, nuclear, defense, automotive safety (ISO 26262), medical devices (IEC 62304), and process safety (chemical, oil, and gas).

Frequently asked questions

What is the difference between a fishbone diagram and a fault tree?

A fishbone diagram is a qualitative brainstorming tool that organizes potential causes into categories. A fault tree analysis is a quantitative, top-down deductive method that uses Boolean logic gates (AND/OR) to model how combinations of failures produce a top-level event. Fishbone is broader and faster; fault tree is more rigorous and calculates failure probabilities.

When should I use fault tree analysis instead of a fishbone diagram?

Use fault tree analysis when you need quantitative probability estimates, when the system has redundancy or safety barriers, when regulatory requirements mandate formal failure analysis, or when you need to identify minimal cut sets (the smallest failure combinations that cause the top event). FTA is standard in aerospace, nuclear, automotive safety, and medical device industries.

Can I use a fishbone diagram and fault tree analysis together?

Yes. Use the fishbone first to brainstorm all potential causes broadly. Then model the most critical failure paths using a fault tree with AND/OR gates and probability data. The fishbone ensures you do not miss causes. The fault tree ensures you rigorously analyze the ones that matter most.

Is fault tree analysis harder to learn than fishbone diagrams?

Yes, significantly. Fishbone diagrams can be learned in minutes. Fault tree analysis requires understanding Boolean logic gates, probability mathematics, minimal cut set analysis, and specialized notation. Most practitioners need formal training. However, the depth of insight a fault tree provides for safety-critical systems justifies the learning investment.

Which method is better for incident postmortems?

For most incident postmortems, a fishbone diagram combined with 5 Whys is sufficient and much faster. Use fault tree analysis for postmortems involving safety-critical systems, regulatory reporting, or incidents where you need to calculate the probability of recurrence. In software engineering, fishbone is far more common for postmortems.

Recommended Reading

Browse all recommended books →

Related resources