Failure Mode and Effects Analysis (FMEA)
Also known as: FMEA, Failure Modes and Effects Analysis, FMECA, Failure Mode Effects and Criticality Analysis
Failure Mode and Effects Analysis (FMEA) is a structured, proactive risk management technique used to identify potential failure modes in a system, process, or product design, evaluate their consequences, and prioritize corrective actions before failures occur. Originally developed for the U.S. military in 1949 and later adopted by NASA, automotive, and manufacturing industries, FMEA is now a cornerstone quality-engineering tool embedded in standards such as AIAG-VDA and ISO 9001-aligned processes.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
+49 more
When to use it
Use FMEA during the design or process development phase — ideally before prototypes are built or production begins — when there is still freedom to make changes at low cost. It is mandatory in many regulated industries (automotive via AIAG-VDA, medical devices via FDA guidance, aerospace via AS9100). FMEA is also appropriate when analyzing an existing process after a significant failure or customer complaint, or when qualifying a supplier or transferred process. Do not apply FMEA as a retroactive paperwork exercise after decisions are already fixed; its value is prospective. It is also not suited as the sole safety tool for highly complex or software-intensive systems, where additional methods such as fault tree analysis or HAZOP are needed alongside it.
Strengths & limitations
- Proactive — catches potential failures before they reach customers, reducing warranty costs and recalls.
- Cross-functional — forces collaboration across design, manufacturing, and quality teams, surfacing siloed knowledge.
- Quantified prioritization — the RPN metric gives teams a defensible, consistent basis for resource allocation.
- Living document — the FMEA can be updated throughout the product or process lifecycle as new information emerges.
- Industry-standard — accepted and required by automotive (AIAG-VDA), medical device (FDA), and aerospace (AS9100) standards.
- Versatile — applicable to product design (DFMEA), manufacturing processes (PFMEA), and systems (SFMEA).
- RPN can be misleading — two failure modes with the same RPN may have very different risk profiles (e.g., S=10, O=1, D=1 vs. S=1, O=10, D=10); RPN alone should never be the only decision criterion.
- Resource-intensive — a thorough FMEA on a complex system requires significant cross-functional time and must be kept up to date to remain useful.
- Rating subjectivity — Severity, Occurrence, and Detection scales require calibrated team consensus; without structured guidelines, ratings drift and lose comparability.
- Does not address interaction effects — FMEA considers one failure mode at a time and can miss cascading or combinatorial failures that fault tree analysis or HAZOP handle better.
Frequently asked
What is the difference between DFMEA and PFMEA?
Design FMEA (DFMEA) focuses on the product design itself — it asks how a component or subsystem could fail to meet its design intent. Process FMEA (PFMEA) focuses on the manufacturing or assembly process — it asks how a process step could produce a nonconforming product. Both use the same RPN framework but are conducted at different stages and by different teams.
What RPN threshold should trigger corrective action?
There is no universal threshold. Common practice sets an action threshold around RPN 100–125, but this is organization-specific. More important: any failure mode with a Severity rating of 9 or 10 must trigger action regardless of RPN, because the consequence of occurrence is safety-critical or regulatory. Teams should document their threshold rationale and apply it consistently.
How is FMEA different from fault tree analysis (FTA)?
FMEA is a bottom-up inductive approach — it starts from individual failure modes and traces their effects upward to the system level. FTA is a top-down deductive approach — it starts from an undesired top-level event and traces downward through Boolean logic to identify root causes. They complement each other; FMEA is better for comprehensive coverage of all failure modes, while FTA is better for analyzing complex combinations of causes for a specific critical event.
Can FMEA be applied to software?
Yes. Software FMEA (sometimes called SFMEA) adapts the framework to software functions and failure modes such as incorrect output, missing function, or unintended function. However, software failure modes are often best analyzed with complementary techniques such as fault tree analysis or software hazard analysis, because software failures frequently arise from interaction effects that are difficult to enumerate mode-by-mode.
How often should an FMEA be updated?
An FMEA should be treated as a living document and reviewed whenever there is a design change, a process change, a new supplier, a field failure, or a customer complaint that was not anticipated. Annual reviews are also good practice even without triggering events, to incorporate lessons learned and new engineering knowledge.
Sources
- Stamatis, D. H. (2003). Failure Mode and Effect Analysis: FMEA from Theory to Execution (2nd ed.). ASQ Quality Press. ISBN: 978-0873895989
- Failure mode and effects analysis. Wikipedia. link ↗
How to cite this page
ScholarGate. (2026, June 3). Failure Mode and Effects Analysis (FMEA). ScholarGate. https://scholargate.app/en/experimental-design/failure-mode-and-effects-analysis
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- Control chartExperimental design↔ compare
- Fault Tree AnalysisReliability↔ compare
- Reliability AnalysisReliability↔ compare
- Root Cause AnalysisQuality Management↔ compare
- Six Sigma DMAICQuality Management↔ compare
- Statistical Process ControlExperimental design↔ compare