FMEA — Failure Mode and Effects Analysis
In plain English
FMEA (Failure Modes and Effects Analysis) is a structured method for identifying potential failures in a product, process, or system — before they happen — and prioritizing actions based on risk.
It asks three basic questions:
• What can go wrong?
• What happens if it does?
• How bad would that be?
FMEA is a way of imagining failure while you still have time to prevent it.
Depending on when it’s used, it shows up in two main forms:
DFMEA (Design FMEA) — used early, to explore how a product or system could fail before it’s built.
PFMEA (Process FMEA) — used later, to identify where the manufacturing or operational process might break once the design is fixed.
Instead of fixing problems after customers, audits, or production discover them, FMEA tries to surface risks early — on paper.
Done well, it saves money, time, and reputation.
Done poorly, it becomes a spreadsheet no one believes in.
What they actually mean
FMEA often becomes a document instead of a thinking process.
Filled in once.
Reviewed during audits.
Ignored during real decisions.
If nothing changes after the FMEA, it didn’t work.
Most FMEAs don’t fail because the method is bad.
They fail because:
• they’re done too late
• by the wrong people
• for the wrong reason
In many organizations, FMEA exists to:
• satisfy auditors
• fill a template
• prove “risk was considered”
Not to actually reduce risk.
So the document gets completed.
The system stays fragile.
Example
A team launches a new process.
The FMEA lists:
• “Human error”
• “Machine failure”
• “Supplier delay”
All with medium scores.
Three months later, the line stops — due to a very specific setup mistake no one discussed.
The failure wasn’t unpredictable.
It just wasn’t comfortable to talk about.
Where you’ll hear it
Quality meetings, project gates, audits — and anytime someone says:
“We already did an FMEA.”
Usually right before something breaks.
Does it actually matter?
✅ Yes — when used honestly.
FMEA is one of the few tools that:
• forces trade-offs into the open
• makes assumptions visible
• connects design decisions to real-world consequences
But it only works if the organization is willing to admit:
“This could fail — and it would be our fault.”
Common misconceptions
FMEA prevents failures
No. It reduces known risks.
FMEA predicts the future
No. It documents current thinking.
FMEA is just paperwork
Only when leadership treats it that way.
High RPN means fix it
Not always. Context matters more than math.
Red flags
🚩 The FMEA is done after design freeze
(The risks are already locked in.)
🚩 One person fills it out alone
(This becomes fiction.)
🚩 Failure modes are vague (“operator error”)
(No learning happens.)
🚩 RPN math is trusted more than judgment
(The spreadsheet is in charge.)
🚩 No actions are followed up
(The FMEA exists only to be shown.)
Worth learning?
5/5
You don’t need to love FMEA.But if you work with quality, engineering, or operations, you need to understand:
• what it can do
• and why it so often doesn’t
Deep dive
How FMEA actually works (and why it often doesn’t)
DFMEA vs PFMEA (why timing matters)
FMEA is not one thing — it depends on when you do it.
DFMEA (Design FMEA) happens early, when:
• the product is still being designed
• drawings can change
• materials, tolerances, and functions are still negotiable
DFMEA asks:
• What can fail in the design itself?
• What happens if this feature doesn’t work as intended?
• What assumptions are we making that could bite us later?
This is where FMEA has the highest leverage.
Fixes are cheap. Changes are possible.
PFMEA (Process FMEA) happens later, when:
• the product is already defined
• the design is “frozen”
• production has to make it work
PFMEA asks:
• Where can the process fail while building this?
• Where are we relying on people, setup, or tribal knowledge?
• What happens when reality hits the line?
PFMEA doesn’t fix bad design.
It tries to survive it.
That’s why many people (like you) mostly experience PFMEA — and why it often feels reactive.
What an FMEA actually looks at (step by step)
A real FMEA is not “brainstorming risks”.
It’s a structured way to walk through how things are supposed to work — and imagine how they won’t.
A typical FMEA flow:
1. Define the scope
• Design function (DFMEA) or
• Process step (PFMEA)
2. Describe the intended function
• What is this step / feature supposed to do?
• Under what conditions?
3. Identify failure modes
• How could this fail?
• Not why yet — just how
4. Identify effects
• What happens if it fails?
• To the customer, the next process, safety, compliance?
5. Identify causes
• Why would this failure happen?
• Wear, variation, human factors, assumptions, environment?
6. List current controls
• How do we prevent this?
• How do we detect it if prevention fails?
7. Evaluate risk
• Severity (how bad)
• Occurrence (how often)
• Detection (how likely we catch it)
8. Decide actions
• Improve design?
• Improve process?
• Add controls?
• Accept the risk?
That’s it.
No magic — just uncomfortable honesty.
A simple PFMEA example (real-world)
• Process step: Manual assembly of a critical bolt
• Failure mode: Bolt not torqued correctly
• Effect: Component loosens in use → failure in field
• Cause: Operator forgets step / tool out of calibration
• Current controls: Visual check
• Severity: High
• Occurrence: Medium
• Detection: Low
A paper FMEA stops here.
A useful FMEA asks:
• Why is this manual?
• Why is detection visual?
• What happens under time pressure?
That discussion might lead to:
• torque-controlled tool
• poka-yoke
• error-proofed sequence
• training update
• Control Plan update
What FMEA is supposed to lead to
A finished FMEA is not the goal.
A good FMEA feeds directly into:
• Control Plans (what we actually monitor and how)
• Work instructions
• Process changes
• Design changes (if done early enough)
• Training and audit focus
If your FMEA doesn’t change:
• how work is done
• how risk is controlled
• or what gets checked
…it didn’t do its job.
What is RPN (Risk Priority Number)?
RPN is a simple way to rank risks inside an FMEA.
It’s calculated by multiplying three factors:
• Severity – how bad the failure would be
• Occurrence – how likely it is to happen
• Detection – how likely you are to catch it before it causes harm
RPN = Severity × Occurrence × Detection
The idea is not to predict the future —
it’s to compare risks against each other and decide where attention should go first.
Used correctly, RPN helps teams focus.
Used blindly, it replaces judgment with math.
useful, dangerous, overrated
RPN exists to compare, not decide.
Classic mistakes:
• chasing high RPN while ignoring high severity
• averaging scores to look “acceptable”
• changing numbers instead of fixing problems
Low RPN does not mean safe.
High RPN does not mean urgent.
Judgment still matters — which is why FMEA fails in low-trust cultures.
Why FMEA usually fails in practice
Not because people don’t understand the method.
But because:
• it’s done too late (after design freeze)
• the wrong people are in the room
• risks are politically inconvenient
• actions have no owner
• the document exists to satisfy an audit, not reality
In those cases, the FMEA becomes:
proof that no one expected the failure
Which is exactly what reality ignores.
When FMEA actually works
FMEA is powerful when:
• it’s done early (especially DFMEA)
• cross-functional voices are present
• uncomfortable scenarios are allowed
• trade-offs are acknowledged
• actions are followed up
At that point, it stops being a spreadsheet —
and becomes a shared understanding of fragility.
The uncomfortable truth
FMEA doesn’t prevent failure.
It exposes which failures you’re choosing to live with.
That’s why organizations either:
• take it seriously
• or neuter it quietly
There’s very little middle ground.
Report an error
Found something wrong or misleading? Let us know — we want this site to stay fact-based (even when we joke).