What needs to be finished first
A written description or sketch of the process or system being analyzed exists with clear steps and interfaces.
Severity (S), occurrence (O), and detection (D) scales are defined and known to the team.
What needs to be ready before start
FMEA table with columns for function, failure mode, effect, severity (S), cause, occurrence (O), current control, detection (D), RPN, action, owner, date; shared document or spreadsheet; process diagram as a reference.
A facilitator with FMEA experience; three to ten participants with knowledge of all process sections; a quality lead who calibrates scales; and a scribe for the table.
Scope (product, process, or system); process diagram; previous incidents and complaints; binding S/O/D scales; threshold for "critical" (for example RPN over 100).
2-6 h
Prepare the table, fix scope and scales at the top. Pre-create one row group per function. Add an example row as a writing template. Rule: risk scoring only after complete description, not in parallel.
The one question this method answers
Which failure modes in the process have enough risk to require preventive or detective actions before deployment?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Scope and functions | 20-30 min | Define the scope of the FMEA (for example "order processing from order entry to shipping confirmation"). List the functions per process step. Mark interfaces explicitly. | If functions are too broad, failure modes become unclear. Formulate clearly what each function produces and under which condition. |
2Phase 2: Collect failure modes | 30-60 min | Ask for each function: how can this function fail, be done incorrectly, or be only partially completed? Capture at least two failure modes per function. Also include unlikely modes. | Participants who collect only the ordinary modes miss rare but critical ones. In safety-critical processes, completeness is more important than efficiency. |
3Phase 3: Effects and causes | 45-90 min | Describe the effect of each failure mode (what happens for customer or system), add one or more causes, and document current controls (tests, checks, reviews). | Multiple causes can exist per failure mode. Keep them as separate rows, otherwise risk scoring becomes distorted. |
4Phase 4: Rate risks (S, O, D, RPN) | 30-45 min | For each row, rate S, O, and D on the agreed scale (typically 1-10). Calculate RPN = S x O x D. Flag top rows above the threshold. | S and O are often agreed, D is often contested. If someone leaves current control empty, they cannot score D honestly. |
5Phase 5: Actions and owners | 30-45 min | Define action, owner, and date for each top row. Categorize action by effect (elimination, reduction, detection). Estimate follow-up RPN to verify effectiveness. | Not every top row needs an action; some risks can be consciously accepted. Document acceptance with rationale, do not skip it silently. |
What comes out at the end
FMEA table with all columns plus header (scope, date, participants, scale definition), action list with owner and date, acceptance rationale for untreated top risks, and re-review date.
Separate FMEA version per scope with date. For process changes, create a delta FMEA, do not overwrite. Review action status regularly and recalculate RPN after implementation.
Compact working template for Failure Mode and Effects Analysis with context, input, output artifacts, and next step.
Analyzes possible failure modes, effects, causes, and priorities for countermeasures.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Scope: From user sign-up to welcome-email delivery within 5 minutes. Scale 1-10 for S, O, D.
Table excerpt:
| Function | Failure mode | Effect | S | Cause | O | Control | D | RPN | Action |
|---|---|---|---|---|---|---|---|---|---|
| Send signup event | Event lost | User does not receive a mail | 8 | Queue overflow | 4 | no alerts | 7 | 224 | Add alert on queue backlog above 1000 and retry logic with DLQ. Owner @lisa, by 30.05. |
| Personalization | Missing first name | Mail says "Hello NULL" | 5 | Optional first name in signup | 6 | template test | 3 | 90 | Fallback "Hello!" in template. Owner @ben, by 22.05. |
| Delivery | Email in spam | User thinks system is broken | 7 | SPF/DKIM not configured | 3 | manual test | 8 | 168 | Set up SPF/DKIM and configure Postmaster tools. Owner @marcus, by 25.05. |
Threshold: RPN over 150 = mandatory action. Three rows exceed threshold, all addressed.
Recognize symptoms and steer against them
Different participants interpret S=7 as either "critical" or "moderate," so RPN values vary heavily.
Align scales with examples before Phase 4: what S=10 means concretely in this scope. Spend 10 min, otherwise the entire table becomes inconsistent.
Entries such as "process error" or "wrong output" without specification.
Require a concrete observation for each failure mode: what would be seen, measured, or complained about. Example: "Welcome email arrives later than 30 minutes after sign-up."
Actions are driven only by RPN; S=10 risks with low RPN are ignored.
Add an additional criterion "S >= 9 requires action." Never prioritize security or compliance risks only by RPN.
D is estimated without anyone being able to name an existing control.
Name a control for each row or leave it blank. If blank, set D to 9-10, which drives action planning.
The FMEA is created once and never revisited; action status stays unclear.
Fix a re-review date at creation (usually after 4-12 weeks). Recalculate RPN after action and keep follow-up RPN in the table.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.