Analytical Tools: FMEA, Fault Tree, Fishbone, and Change Analysis

Choose the analysis tool that fits the question

Safety professionals use structured tools to reduce guessing, and the tool must match the decision. Some tools look forward to find failures before an event; some work backward from an event; some organize candidate causes for discussion; some compare a changed condition with the expected condition. ASP items frequently give a scenario and ask which tool is most appropriate — the cue words in the stem decide the answer.

FMEA — forward, component-level

Failure modes and effects analysis (FMEA) is forward-looking. A team reviews each process step, component, or task and asks how it can fail, what the effect would be, the cause, the existing controls, and the actions needed. FMEA ranks items with a Risk Priority Number (RPN) = Severity × Occurrence × Detection, where each factor is typically scored 1–10 (so the RPN ranges from 1 to 1000). The highest RPNs get attention first. FMEA fits design, procedure development, equipment selection, maintenance planning, and process change — anytime the question is "how could this fail before we run it?"

Fault tree analysis — backward, top-down logic

Fault tree analysis (FTA) starts with an undesired top event — explosion, fall from elevation, chemical release, or unexpected startup — and maps the combinations of failures that could produce it using Boolean AND/OR gates. An AND gate means several things must fail together; an OR gate means any one failure suffices. FTA reveals how barriers interact: a serious event may require that isolation was not performed AND verification was skipped AND another worker initiated startup. It can be quantified if failure probabilities are known.

Fishbone and change analysis

Fishbone (Ishikawa / cause-and-effect) diagrams organize possible causes into categories — commonly the 6 Ms: People (manpower), Methods, Machines, Materials, Measurement, and Environment (Mother Nature). Fishbones structure brainstorming during investigations, but they are not proof; each branch still needs evidence.

Change analysis compares the incident or new condition with the normal or expected baseline, asking what changed in people, equipment, materials, methods, environment, timing, workload, supervision, software, layout, production rate, maintenance, or contractors. It is most powerful when a familiar process suddenly produces an unexpected result.

Matching cue words to tools

A common error is picking a tool because it sounds sophisticated. Read the cue: "how could each component fail before startup" → FMEA; "what combinations of failures could lead to a catastrophic top event" → fault tree; "organize the many possible causes the team brainstormed" → fishbone; "it ran fine for years until something changed" → change analysis.

Worked example: a press that operated safely for three years suddenly double-cycles and injures an operator. Nothing in the written procedure changed. The strongest first tool is change analysis — it surfaces that a control-relay vendor was switched during the last PM, a change MOC never captured. A fishbone could then organize candidate causes, and an FMEA of the new relay could prevent recurrence.

These tools must lead to controls. Analysis without action is not risk reduction. Results should produce higher-level controls, procedure changes, training, maintenance changes, purchasing changes, alarms, interlocks, inspections, or management-system improvements — each assigned, tracked, verified, and reviewed for residual risk.

Finally, use evidence to avoid bias. Interviews, records, photographs, monitoring data, maintenance history, training records, inspection reports, and field observations confirm or reject suspected causes. Do not stop at the first explanation — especially one that blames the worker while ignoring design, scheduling, supervision, or system contributors.

Related tools the exam may name

The blueprint can reference several adjacent techniques you should recognize. Root cause analysis (RCA) is the broad goal — finding the underlying system causes rather than the immediate symptom — and the tools above are means to that end. The 5 Whys is a simple iterative questioning method that drills from a symptom toward a root cause; it is quick but can stop too early or follow a single line.

Hazard and operability study (HAZOP) is a structured process-industry technique that applies guide words (such as no, more, less, reverse) to process parameters to find deviations; it is forward-looking like FMEA but organized around process flow rather than components. Energy trace and barrier analysis examines each energy source and the barriers meant to separate it from people, identifying which barrier failed or was missing.

Bow-tie and combining methods

The bow-tie model joins the two directions visually: the left side is a fault-tree-style view of threats leading to a top event, and the right side is an event-tree-style view of consequences, with preventive barriers on the left and mitigative barriers on the right. It is valued because it shows, on one diagram, both why an event could occur and what limits the harm if it does.

In practice, experienced safety professionals combine tools. Worked example: after a chemical release, a team uses change analysis to spot what differed from normal, a fishbone to organize candidate causes across the 6 Ms, the 5 Whys to drill the most likely branch to its system root, and finally an FMEA of the redesigned procedure to prevent recurrence. No single tool proves causation alone; each narrows the search, and every conclusion must be backed by evidence and converted into tracked, verified corrective actions that reduce residual risk.