FMEA

Overview

FMEA (Failure Mode and Effects Analysis) is a systematic method for identifying and evaluating potential failures in products or processes. The goal is to spot risks before they occur and tackle them by priority — it is a central tool of the Improve and Control phases but should already begin in Define or Analyze.

Function / step: What should the process or part do? Every row starts with the expected function or process step — from this target view the possible deviations are derived.

Failure mode: The possible kind of deviation from the function — e.g. "not snapped in", "wrong dosage", "delivered too late". Several failure modes per function are possible.

Effect: What happens if the failure occurs — at the next step, at the final product, at the customer? A failure mode can have several effects of different severity.

Cause: What might trigger the failure? Several causes per failure mode are the rule — each is rated separately because occurrence and actions differ.

S (Severity): How serious would the effect be for the customer? Scale 1–10: 1 = negligible, 10 = safety-critical. Defined by the product or requirement, not by the process.

O (Occurrence): How often does the cause occur in practice? Scale 1–10: 1 = very rare, 10 = nearly permanent. Ideally backed by data, otherwise estimated.

D (Detection): How likely is the failure detected before reaching the customer? Scale 1–10: 1 = will surely be found, 10 = guaranteed to slip through. Note: a high number is bad (counterintuitive).

RPN (Risk Priority Number): S × O × D. Values from 1 to 1000. The RPN is a rough prioritization — not an absolute risk measure. High severity (S ≥ 9) is often addressed regardless of RPN.

FMEA is a living document: updated on every relevant change. An FMEA filed away once loses its value.

Approach

• Define scope — which function, which process slice is analyzed?
• List functions or steps — ideally along the process map.
• Brainstorm possible failures per step — with the team, experts, and practitioners.
• Describe effects and causes per failure.
• Assign S, O, D collectively — a uniform rating frame is mandatory.
• Calculate the RPN and prioritize.
• Derive actions — reduce occurrence (lower O) or improve detection (lower D). Severity can only be lowered by design change.
• After implementation, re-rate and check whether the action worked.

Pitfalls

Done alone: An FMEA by one person is just one person's brainstorm. In an interdisciplinary team — design, manufacturing, quality, service — far more failures surface.

Inconsistent scales: When every rating runs against a different mental model of "severity 7", RPN values are incomparable. Calibrate the scale with examples before starting.

RPN threshold as only rule: "Anything above 100 gets addressed" misses the case S = 10, O = 1, D = 1 — RPN 10, but safety-critical. Always consider action when severity is high, regardless of RPN.

Actions without effectiveness check: An action "on the plan" is not the same as an effective action. After implementation re-rate S/O/D — if nothing changes, the action does not work.

Rating symptoms instead of causes: Listing "part breaks" as cause is not FMEA but a symptom list. The cause is "wrong material spec" or "load assumption too low".

FMEA as compliance exercise: If FMEA is created only to satisfy an audit, it is not lived. Value comes from real discussion and actionable outcomes.

Outdated FMEA: Processes and products change. An FMEA untouched for three years describes a state that may no longer exist.

Examples

This module ships with the following example datasets — load any of them in the app with a single click.

Available in the following cycles

• DMAIC: Analyze
• DMADV: Analyze
• 8D: D7 — Prevent Recurrence