Here's the catch: most quality teams know FMEA from a training slide deck. They can define Severity, Occurrence, and Detection on command. But put them in a live meeting under audit or launch pressure, and the wheels come off. The result is a rushed, box-checking FMEA that satisfies nobody — least of all the auditor reviewing it six months later.
This guide breaks down what FMEA actually is, where it lives inside DMAIC, the variants you'll encounter, a step-by-step build process, and how to keep the document alive instead of shelved after one workshop.
Key Takeaways
- Apply FMEA as a proactive risk tool mainly in the Analyze and Improve phases of DMAIC
- Prioritize corrective action with RPN = Severity × Occurrence × Detection
- Use DFMEA for design risk and PFMEA for process risk, the two variants most teams need
- Treat FMEA as a living document; revisit it when a process, product, or control changes
What Is FMEA in Six Sigma?
FMEA is a structured method for answering three questions about any process or product step: how could this fail, why might it fail, and how bad would the consequences be?
It's a proactive tool—teams use it before a failure costs money or reputation. The American Society for Quality traces the method to the U.S. military in the 1940s, long before Six Sigma adopted it as a core analysis tool.
Within DMAIC, FMEA shows up primarily in two places:
- Analyze — helping teams evaluate potential root causes and decide where to focus investigation
- Improve — stress-testing a redesigned process to confirm it actually reduces risk before rollout
Core FMEA Terminology
Every FMEA rests on four building blocks:
- Failure Mode — the specific way a step or component could fail
- Effect — the consequence of that failure on the customer, process, or product
- Cause — the underlying reason the failure mode could occur
- Current Controls — whatever prevention or detection measures already exist for that failure
The Three Rating Scales
Each failure mode gets scored on three 1–10 scales:
- Severity — how serious the consequence is if it happens. A 1 means insignificant; a 10 means catastrophic.
- Occurrence — how likely the failure is to happen at all. A 1 means remote; a 10 means almost inevitable.
- Detection — how likely current controls are to catch it before it reaches the customer. A 1 means it will almost certainly be caught; a 10 means it will almost certainly slip through.
Multiply the three together and you get the Risk Priority Number (RPN). Higher RPNs point to where corrective action needs to happen first. What makes FMEA distinct from tools like fishbone diagrams or 5-Why is that it explicitly weighs customer impact (severity) alongside likelihood and detectability — not just how often something goes wrong.
One caveat: identical RPN scores can mask very different risk profiles. A failure mode with severity 9, occurrence 2, detection 5 produces the same RPN as one scored 3, 6, 5 — but they're not equally urgent. This is part of why SAE J1739:2021 introduced an Action Priority ranking alongside the traditional multiplication, giving teams a second lens for prioritization beyond raw RPN math.
Types of FMEA You'll Encounter
Not every FMEA looks the same. The type you build depends on what you're evaluating: a design, a process, or an entire system.
Design FMEA (DFMEA)
DFMEA evaluates potential failures baked into a product's design, before it ever reaches manufacturing. This matters because design-stage changes are the cheapest ones to make. Catch a weak tolerance or a poor material choice on paper, and you fix it with a redline. Catch it after tooling is cut, and you're looking at scrap, rework, and schedule slips.
Process FMEA (PFMEA)
PFMEA looks at the manufacturing or transactional process itself: the steps, inputs, and handoffs between them. Where DFMEA asks "could this design fail," PFMEA asks "could this process step fail, even with a sound design behind it."
Is PFMEA a Six Sigma tool? Yes, but it isn't proprietary to Six Sigma:
- Widely used in DMAIC's Analyze phase
- Equally common in Lean and AIAG-VDA automotive quality systems
Inside QMS Learning's Commercial Aviation pathway, FMEA is taught alongside AS13000 RCA/CAPA, 8D, and 5-Why. It's positioned as the tool for evaluating new processes, not for closing out failures that already happened.
If a defect already showed up three times this quarter, that's a 5-Why and Supplier CAPA conversation, not an FMEA.
System FMEA (SFMEA) and FMECA
System FMEA looks at how subsystems interact with each other, catching failures that only appear when components combine and aren't visible in a single-part design review.
FMECA takes this further by adding criticality analysis, ranking failures by both severity and probability. It's common in aerospace, defense, and nuclear work, where a single-point failure can be catastrophic. Defense procedures go back to MIL-STD-1629A, the 1980 standard that formalized FMECA practices still referenced today.
Step-by-Step: How to Build an FMEA in a DMAIC Project
Building an FMEA that actually holds up under scrutiny follows a consistent sequence.
Assemble a cross-functional team. Pull in design, manufacturing, quality, and where relevant, suppliers or customers. A single-function team misses failure modes outside its own lens. A designer won't spot a fixturing problem, and a machinist won't catch a tolerance stack-up issue.
Map the scope in detail. Use a process map or SIPOC to lay out every step or function that needs evaluating. Skipping this step is the fastest way to end up with an incomplete FMEA.
Brainstorm failure modes for each step. Combine structured brainstorming with historical defect and complaint data; don't rely on memory alone. Leaning only on history lets new or emerging failure modes (redesigned processes, new suppliers) slip through.
Score Severity, Occurrence, and Detection, then calculate RPN. This is where the team debates ratings. Expect disagreement, and treat it as a useful signal rather than something to rush past.
Assign corrective actions to the highest-RPN items first, then recalculate. After actions are implemented, re-score the affected failure modes to confirm the RPN actually dropped. If it didn't, the action wasn't strong enough.
ASQ describes an internal packaging FMEA example where reassessment moved several failure modes from RPNs above 125 to below that threshold after corrective action. Recalculation is part of the work, not a one-time checkbox.
Where FMEA Fits Into the Six Sigma DMAIC Cycle
FMEA is most closely tied to Analyze, where it shows teams where to focus root-cause investigation. But plenty of practitioners also apply it in Improve, using it to pressure-test a proposed solution before it goes live, catching new risks the redesign might have introduced.
The mistake teams make is treating FMEA as finished once Improve wraps up. It shouldn't be. In Control, an FMEA needs revisiting whenever:
- A new failure mode surfaces from ongoing SPC monitoring
- A process input, supplier, or control changes
- A corrective action from another investigation reveals a gap the FMEA didn't anticipate
FMEA also sits differently from other DMAIC tools. Fishbone diagrams and 5-Why are reactive. They dig into the cause of a defect that already occurred. FMEA is broader and preventive, scanning multiple potential failure paths before any of them happen. The two approaches complement each other; FMEA doesn't replace root-cause investigation once a failure is confirmed.
Benefits, Common Pitfalls, and Making FMEA Audit-Ready
Done well, FMEA delivers real, measurable value:
- Objective, evidence-based prioritization instead of guessing which risk to tackle first
- Reduced rework, scrap, and warranty cost from catching issues before they reach a customer
- Cross-functional alignment on who owns which risk
Done poorly, it becomes a liability. The most common pitfalls practitioners report:
- FMEAs built once during a launch and never touched again
- Inconsistent Severity and Occurrence scoring between team members: one engineer's "7" is another's "4"
- Treating the exercise as a paperwork requirement rather than a working risk tool
In regulated industries, this stops being just a process discipline problem and becomes an audit exposure. AS9100D's clause 8.1.1 requires an implemented, controlled operational risk process covering risk identification, assessment, and mitigation. Auditors expect that work documented, not described verbally.
The same pressure exists under ISO 13485 for medical devices. Auditors don't just want to see an FMEA exists. They want to see it's maintained, linked to real corrective actions, and traceable to actual process changes.
QMS Learning's AI Workbench closes that gap. Instead of guessing whether a problem calls for FMEA, 5-Why, CAPA, or Gap Analysis, the Method Router diagnoses the situation first. Describe a recurring supplier defect, and it routes you to 5-Why plus Supplier CAPA rather than FMEA, because FMEA evaluates new or changing processes, not failures that already happened.
Once FMEA is the right call, the Workbench generates the documentation and evidence trail as part of a single, indexed audit-evidence package, alongside training records and time-stamped activity logs.
The payoff is broader than one clean FMEA. Capability spreads across the team instead of staying locked in a senior engineer's head, and the institutional knowledge stays with the organization rather than walking out the door with a consultant.
Frequently Asked Questions
Is PFMEA a Six Sigma tool?
Yes. PFMEA is widely used in DMAIC's Analyze phase to score process-level failure risk. It also appears in lean manufacturing and automotive quality systems such as AIAG-VDA.
What does FMEA stand for in Six Sigma?
FMEA stands for Failure Mode and Effects Analysis. It's a proactive method for identifying how something could fail and prioritizing which risks to address first.
What is RPN and how is it calculated?
RPN, or Risk Priority Number, equals Severity multiplied by Occurrence multiplied by Detection. Teams tackle the highest-scoring failure modes first, then recalculate after fixes to confirm risk actually dropped.
What is the difference between DFMEA and PFMEA?
DFMEA addresses failure risk baked into a product's design. PFMEA addresses failure risk in the manufacturing or operational process that builds or delivers it.
In which DMAIC phase is FMEA typically used?
Primarily Analyze, where it helps direct root-cause investigation. Many teams reuse it in Improve to confirm a redesigned process actually reduces risk before rollout.
Who should be part of an FMEA team?
A cross-functional group spanning design, manufacturing, and quality at minimum—plus suppliers or customer-facing staff where relevant—so single-function blind spots don't slip through.
