Introduction
Failure Mode and Effects Analysis has been preventing defects from reaching customers since 1949, when the U.S. military first formalized it under MIL-P-1629. NASA leaned on it during the Apollo program. Today, it's baked into AS9100D, IATF 16949, and ISO 9001.
Yet many engineering teams still treat FMEA as paperwork. They score severity, occurrence, and detection, calculate an RPN, and file it away. No real analysis happens. The result: audit findings, repeat failures, and a document nobody trusts.
You'll get a clear definition of FMEA, the difference between DFMEA and PFMEA, when to run one, and a step-by-step framework you can use today—plus how FMEA fits into Six Sigma and modern quality systems.
Key Takeaways
- FMEA catches failure modes before they reach the customer through structured, team-based analysis.
- Design FMEA and Process FMEA target risk at different product development stages.
- RPN (Severity × Occurrence × Detection) ranks where to act first, not as a pass/fail gate.
- AS9100, IATF 16949, and ISO 9001 expect FMEA as evidence of risk-based thinking.
What Is FMEA? Understanding Design and Process FMEA
FMEA traces back to MIL-P-1629, a U.S. military procedure dated November 9, 1949, built to identify possible failure modes before they occurred. NASA adopted it for the Apollo program in 1966, and it later found permanent homes in civil aerospace (SAE ARP4761) and automotive manufacturing (AIAG/VDA).
At its simplest, FMEA runs on four building blocks:
- Failure mode — the specific way something can fail
- Effect — the consequence that failure has on the customer or process
- Cause — the underlying mechanism that triggers the failure
- Control — the measures already in place to prevent or detect it
FMEA doesn't replace good engineering judgment. It applies a cross-functional team's collective knowledge to surface risks a single engineer, working alone, would likely miss. That's the whole point — it's a group exercise, not a solo form-filling task.
Other variants exist too, and which one you need depends on the standard your team gets audited against:
- Functional FMEA — used early, before hardware details are locked
- Software FMEA — targets safety-critical code
- FMECA — adds a criticality classification on top of standard analysis
Design FMEA (DFMEA)
DFMEA examines potential product malfunctions rooted in material properties, geometry, tolerances, interface issues, and environmental "noise" factors — things like vibration, temperature swings, or humidity. It happens before the design is finalized, while changes are still cheap to make.
Process FMEA (PFMEA)
PFMEA looks at what can go wrong during manufacturing or assembly. It's typically organized around the classic 5M framework: method, machine, material, measurement, and environment. Where DFMEA asks "could this part fail," PFMEA asks "could my process build it wrong" — so teams catch process risk before it reaches the customer.
Why FMEA Matters — and Where Teams Get It Wrong
The financial case for early risk analysis is hard to argue with. A widely cited engineering study of large, complex systems tracked how defect fix costs escalate across the lifecycle, according to research published through NASA's Technical Reports Server:
- 1 unit to fix during requirements
- 3–8 units during design
- 7–16 units during manufacturing
- 29 to over 1,500 units once the product reached operations
The exact multiplier varies by industry, but the direction never does: catch it early, or pay for it later.
In aerospace, automotive, and medical devices, "paying for it later" can mean injury or worse. That's why FMEA sits inside AS9100D, IATF 16949, and ISO 13485 as an expected form of risk analysis, not a nice-to-have.
Auditors reinforce this. Under ISO 9001:2015 clause 6.1, organizations must determine risks and opportunities during quality system planning. An FMEA is one of the clearest ways to demonstrate that thinking actually happened, rather than being assumed.
FMEA data also feeds straight into root cause tools like 5-Why and fishbone diagrams, and into CAPA. Because potential causes are already brainstormed, problem-solving moves faster when something does go wrong.
Where Teams Get FMEA Wrong
Two mistakes show up constantly:
- Using a fixed RPN threshold as a gate. Teams start gaming the numbers, nudging a detection score down a point to duck under the cutoff, instead of confronting the actual risk.
- Treating FMEA as a one-time launch document. It gets completed, signed, and forgotten, even as field failures and design changes pile up around it.
An FMEA that never gets revisited isn't a living risk tool anymore. It's a historical artifact, and auditors can usually tell the difference.
When Should You Perform an FMEA?
FMEA delivers value in specific, recurring situations:
- Designing a new product or process
- Applying an existing process in a new way or environment
- Setting a quality improvement goal for an existing system
- Updating risk controls when field data reveals new failure modes
The earlier it starts, the more it's worth. Ideally, FMEA begins at the concept stage, when changes are still cheap, then narrows in scope as the design or process matures toward specific parts and subprocesses.
FMEA is not a set-it-and-forget-it document. Revisit it whenever there's a design change, a new regulation, a customer complaint, or a recurring nonconformity.
One useful test used inside QMS Learning's AI Workbench: if the same supplier defect shows up on three different jobs in a quarter, that's a systemic, existing failure. The right tools are 5-Why and Supplier CAPA, not a fresh FMEA. FMEA is for new processes and forward-looking risk, not for closing failures that already happened.
How to Perform an FMEA: A Step-by-Step Framework
Running a good FMEA follows a consistent sequence. Teams that skip steps or rush them usually end up with a compliance-theater document instead of a useful one.
- Assemble a cross-functional team and set ground rules. Pull in design, manufacturing, quality, service, and supplier representatives. Agree on consistent severity, occurrence, and detection scales before anyone starts scoring.
- Define scope and functions. Identify the system, process, or design element under review. Write each function in verb-noun form with a measurable requirement attached.
- Brainstorm failure modes and effects. For every function, ask "how could this fail?" Capture effects on the customer, the business, and regulatory compliance.
- Rate severity, then trace causes and rate occurrence. Score how serious each effect is first. Then work backward to root causes and rate how likely each one is to happen.
- Identify current controls and rate detection. Document what prevention or detection measures already exist, and score how likely they are to catch the failure before it reaches the customer.
- Prioritize actions and close the loop. Assign corrective actions to specific owners with due dates, implement them, then re-score to confirm the risk actually dropped.
That last step is where a lot of FMEAs stall: teams identify actions but never verify they worked.
AI-guided workbenches, like the one in QMS Learning's platform, help junior engineers run the full sequence—selecting the right method and generating an audit-ready FMEA artifact instead of starting from a blank spreadsheet.
Understanding the RPN Formula
RPN = Severity × Occurrence × Detection. Each factor is typically scored on a 1-10 scale, and the higher the resulting number, the higher the priority for corrective action.
But RPN has a well-known blind spot: two very different risk profiles can produce the identical score. A 9-2-2 (severe, rare, easy to detect) multiplies out the same as a 3-6-2, even though they represent very different risks.
That's part of why the 2019 AIAG/VDA FMEA Handbook introduced the Action Priority (AP) method as an alternative. Instead of multiplying three numbers into one score, AP uses a High/Medium/Low table that weighs severity first, then occurrence, then detection, according to Quality Digest's breakdown of the AIAG-VDA approach. It doesn't replace judgment, but it makes high-severity risks harder to bury under a low multiplied score.
How FMEA Fits Within Six Sigma and Your Broader Quality System
FMEA is one of the standard tools in the Analyze phase of Six Sigma's DMAIC framework, sitting alongside root cause analysis and process capability studies, according to ASQ's DMAIC process guide. If your organization runs Six Sigma projects, FMEA is likely already part of the toolkit your black belts reach for.
But FMEA doesn't belong exclusively to Six Sigma. It's expected — independently — under AS9100D, IATF 16949, ISO 9001, and ISO 13485, whether or not an organization has a formal Six Sigma program at all.
FMEA also connects directly to tools most teams already use:
- 8D and CAPA close out nonconformities once a failure has already occurred
- Control plans verify that a design or process change actually reduced risk in practice
- Root cause tools (5-Why, fishbone) draw on causes FMEA has already brainstormed
The hard part usually isn't knowing these tools exist. It's choosing the right one for the problem in front of you, fast enough to matter.
That selection gap is what QMS Learning's AI Workbench and Method Router target. A team describes a live compliance issue; the Method Router recommends 5-Why, FMEA, CAPA, or Gap Analysis instead of defaulting to FMEA for every case. In the Commercial Aviation pathway, FMEA sits inside the Root Cause Analysis & CAPA (AS13000) course next to 8D and CAPA effectiveness checks.
The point is not to replace engineering judgment. It is to help a team apply FMEA correctly and produce evidence a registrar will accept, without needing a black belt on staff for every decision.
Frequently Asked Questions
What is FMEA in engineering?
FMEA is a structured, team-based method for identifying and prioritizing potential failure modes in a design or process before they reach the customer. Teams score each risk using severity, occurrence, and detection ratings.
Is FMEA part of Six Sigma?
Yes, FMEA is a standard tool used in the Analyze phase of Six Sigma's DMAIC methodology. It's also used independently across many industries and quality standards, with or without a formal Six Sigma program.
What is the difference between DFMEA and PFMEA?
DFMEA addresses potential failures in product design, such as material properties, tolerances, and geometry. PFMEA addresses failures that could occur during manufacturing or assembly, tied to method, machine, material, measurement, and environment.
What does RPN mean in an FMEA?
RPN stands for Risk Priority Number, calculated as Severity × Occurrence × Detection. It's used to prioritize which failure modes need corrective action first, though it shouldn't be treated as a rigid pass/fail cutoff.
Who should be on an FMEA team?
A strong FMEA team includes representatives from design, manufacturing, quality, testing, service, and suppliers. This mix of perspectives catches a wider range of potential failure modes than any single department could alone.
How often should an FMEA be updated?
FMEA should be treated as a living document, not a one-time form. Revisit it whenever there's a design change, new regulation, customer complaint, recurring nonconformity, or at regular intervals throughout the product lifecycle.
