FMEA: List How It Can Fail, Then Rank What to Prevent
FMEA helps you list how a scoped product, process, or system could fail, what each failure would do, why it might happen, what already catches it, and which modes to act on first. Severity, occurrence, and detection (and RPN) are teaching aids. They are not required if another ranking is explicit.
Framework Card
- Name:
- FMEA
- Goal:
- List how a scoped product, process, or system could fail, judge effects, causes, and controls, then prioritize action (often with severity, occurrence, and detection).
- Flow:
- Scope the item → Identify failure modes → Assess effects → Identify causes and controls → Prioritize action
- Best For:
- Ranking how a process could fail before it ships; Focusing prevention on the worst plausible modes; Checking existing controls against detection gaps
Why it matters
Teams often wait for a break, then argue about the last incident. The next incident may be a different mode.
When everything is “a risk,” nothing is first. When only the last outage is discussed, silent modes stay unlisted.
FMEA is a way to put plausible failures on one page before they all compete as equal worries. The useful output is a short action list, not a worksheet that nobody will reopen.
What it is
Failure Modes and Effects Analysis is a structured inventory of failure modes for a defined item. For each mode you record effects, causes, existing controls, and a priority.
Teaching often rates Severity (how bad if it happens), Occurrence (how likely), and Detection (how likely you catch it before harm). RPN is Severity times Occurrence times Detection. Production teaching already says you can skip RPN if it creates extra work, as long as you still say which modes come first. High-severity rare events can look moderate on RPN depending on the scale. Say so when that happens.
FMEA can be used before launch or after a scare. It is still a mode list with ranking, not a Fishbone of an unexplained effect.
How it works
1. Identify the scope
Name the product, process, or system and its boundary. “The whole company” is not a scope.
2. Brainstorm potential failure modes
List specific ways it can fail (“payment capture times out,” not “bad experience”). Cross-functional listing helps. Do not invent modes the case cannot make plausible.
3. Assess effects
What happens to the user, safety, compliance, or downstream process if this mode occurs?
4. Identify causes and controls
Why might it happen, and what already prevents or detects it?
5. Prioritize and take action
Use SOD/RPN if the team has a scale. Otherwise rank with an explicit rule (highest severity first, detection gaps first). Name the action on the top rows. A table without action is inventory.
How it compares
When another lens fits better, or when you need a complementary view, these frameworks do different jobs.
| Framework | What it helps you see | How it differs from FMEA |
|---|---|---|
| Fishbone Diagram | Cause families of a named effect | Map of an existing problem. FMEA is a mode inventory with ranking. |
| 5 Whys | One cause chain | Depth on one line. FMEA is breadth plus priority. |
| PDCA Model | Plan, do, check, act | Cycle after you pick a change. FMEA picks what to prevent. |
FMEA is the lens for ranked failure modes. Other methods help when the question is a cause map, one chain, or an improvement loop.
When to Use This Framework
- Risk prioritization. Many ways to fail, limited prevention time.
- Failure prevention planning. A process is about to ship or scale.
- System reliability analysis. You need to see detection gaps, not only causes of the last defect.
Example
A concrete example makes the structure easier to reuse when you are under uncertainty.
Example: Checkout capture timeout (illustrative ratings, not a standard table)
Scope: web checkout capture step.
| Failure mode | Effect | Cause / control | Priority note |
|---|---|---|---|
| Capture API times out | Order looks paid to the user, unpaid in ledger | Retry exists but user sees success too early | High: money and trust; detection is weak |
| Address validator false fail | User abandons | Timeout 2s; no fallback | Medium: revenue leak; easier to detect in logs |
| Duplicate click double-charges | Chargeback | Button not disabled | High severity if it happens; control missing |
Implication: Act first on the success-on-timeout mode (detection gap plus money). The numbers are teaching placeholders. A real FMEA would use the team’s scale or skip RPN and still name the same priority.
Takeaway
What FMEA can help with
- Listing plausible failure modes inside a scope
- Separating how bad, how likely, and how detectable
- Finding detection gaps
- Naming which modes get prevention work first
What FMEA cannot replace
- Fishbone. Categories of causes for an effect you already see. FMEA lists modes of a scoped item.
- 5 Whys. One chain. FMEA ranks many modes.
- PDCA. Running a change. FMEA decides what to prevent; it does not run the experiment.
- A complete process-safety study. HAZOP and similar cousins are not this page’s method.
- A guarantee. RPN can hide high-severity rare events. Invented scores are worse than labeled uncertainty.
Honest scope: FMEA structures a ranked mode list. It should not be sold as complete risk management.
Frequently asked questions
No. Production teaching allows another ranking if it is explicit. RPN is Severity times Occurrence times Detection when you use that scale.
A named scope, specific failure modes, effects, causes or controls, and a short action list on the top-priority rows. If every row is “medium,” you have not prioritized.
Fishbone maps candidate causes of an effect you already have. FMEA lists how a scoped item could fail and ranks those modes.
Yes, depending on occurrence and detection scores. Call that out. Do not hide severity behind a product.
No. It can point tests at detection gaps. It does not execute the tests.