Failure Mode and Effects Analysis (FMEA) Explained

A brake actuator that passes every component test can still fail in the field if no one anticipated how it interacts with a software update at low temperatures. Catching that interaction during an early design review, before tooling is cut and code is frozen, is exactly what Failure Mode and Effects Analysis(FMEA) exists to do.

Engineering teams across automotive vehicle development programs, aerospace, and medical device development use it to surface failures while the design is still cheap to change. This guide covers what FMEA is, how teams run it, and how Risk Priority Number (RPN) and Action Priority shape risk decisions.

What Is FMEA?

FMEA is a forward-looking risk analysis method for finding and ranking the ways a design, process, or system might fail. A failure mode is the specific way something fails, whether potential or actual. Effects analysis studies what happens downstream when that failure occurs. Teams use the worksheet to choose which corrective actions deserve attention before release.

The method prioritizes failures by three weighted risk factors, rated on a 1 to 10 scale. Severity measures how serious the consequence is, and occurrence measures how likely the failure is to happen. Detection measures how well current controls catch the failure before it reaches the customer. Multiplying the three produces the RPN, the figure teams traditionally use to focus corrective action.

Why Teams Use FMEA in Product Development

The cost of fixing a defect climbs steeply the later you catch it. FMEA pulls failure discovery earlier, when teams can still change the requirements that shape the design, architecture, interface, or control strategy.

Early Risk Identification and Cost Reduction

FMEA has the greatest effect during concept and architecture. At that stage, teams can adjust a design, tighten a tolerance, or add a process control before changes ripple into tooling, validation, and field returns.

Improved Product Reliability and Safety

Single-team reviews miss failures that live between disciplines. A subsystem can meet its own requirements and still fail when it interacts with another. Cross-discipline FMEA helps teams find those interaction risks and document knowledge that carries across programs.

Supporting Regulatory Compliance

FMEA produces a documented evidence trail used in regulated development. Automotive quality programs use risk-based methods to prevent potential failures, and the Automotive Industry Action Group (AIAG) and German Association of the Automotive Industry (VDA) FMEA Handbook is an industry reference. 

For medical devices, FMEA can support a broader life-cycle risk management process under the medical device risk management standard. Automotive functional safety programs likewise use failure-analysis methods alongside hazard analysis and Automotive Safety Integrity Levels (ASIL), including how ASIL levels are classified. In each case, the FMEA provides documented input to the compliance program.

Types of FMEA: Design, Process, and System

Three types of FMEA cover different layers of a product’s failure areas. Design FMEA examines the product, process FMEA examines how it is made, and system FMEA examines how subsystems interact. Programs may run more than one type, with outputs from one feeding the next.

Design Failure Mode and Effects Analysis (DFMEA)

DFMEA examines what could fail in the design itself, including component functions, material properties, geometric tolerances, and interfaces. It applies to new designs, modified designs, or existing designs used in a new environment or duty cycle. Product engineers own it, and DFMEA does not assume process controls exist to catch the problem. Failure modes include loss of function, degradation, intermittency, partial functioning, and unintended functionality.

Process Failure Mode and Effects Analysis (PFMEA)

PFMEA analyzes how manufacturing or assembly could introduce defects, assuming product design failures have already been considered. It examines failures derived from the six-factor 6M framework of man, method, material, machine, measurement, and environment. Operators often know these failure modes firsthand, so direct process owner involvement matters. The output is the Control Plan for day-to-day production controls.

System Failure Mode and Effects Analysis (SFMEA)

SFMEA focuses on interfaces and interactions between subsystems, including failures that individual element analysis cannot find. It is valuable when the system does not deliver the intended feature even though each element meets its own requirements. In automotive handbook usage, design and process FMEA are the formal categories. SFMEA remains part of systems engineering practice even when it sits outside that taxonomy.

How to Perform an FMEA: A Step-by-Step Process

FMEA work can be organized into a structured seven-step FMEA approach across system analysis, failure analysis, risk mitigation, and communication. Before starting, gather the scope, boundaries, functions, current controls, drawings, specifications, and previous comparable FMEAs:

1. Planning and preparation. The project plan covers intent, timing, team, task, and tools.
2. Structure analysis. The team defines boundaries and identifies systems, subsystems, components, and interfaces. Boundary diagrams and structure trees support this work.
3. Function analysis. Each element’s intended function is documented. Function-based analysis is the foundation for identifying failures.
4. Failure analysis. The team builds the failure chain of function, failure mode, effects, and causes. Each effect is assessed at the next higher level and on the end user.
5. Risk analysis. Prevention and detection controls are evaluated, severity, occurrence, and detection ratings are assigned, and the Action Priority (AP) is derived. RPN may still be calculated for trending.
6. Action planning. Actions are set in priority order. The sequence is to eliminate the failure effect first, reduce the occurrence second, and improve the detection third. Re-scoring follows verified actions.
7. Results documentation. The FMEA report summarizes the scope and results and confirms that actions have been completed.

The AIAG-VDA Handbook also defines a Supplemental FMEA for Monitoring and System Response (FMEA-MSR), which evaluates how onboard monitoring and system responses maintain a safe state during customer operation. FMEA-MSR is used mainly in functional safety contexts.

How RPN Works

RPN multiplies Severity, Occurrence, and Detection. Each rating uses a 1 to 10 scale, so the value ranges from 1 to 1,000. A flat tire might score severity 10, occurrence 2, and detection 3 for an RPN of 60. Teams sort failure modes by RPN, act on priorities, then recalculate after actions. A high detection rating reflects low detection capability, and a score of 10 means the failure is almost impossible to catch.

RPN carries structural flaws. Because severity, occurrence, and detection are measured on ordinal rating scales, multiplying them is statistically questionable, and identical RPN values can hide different risk profiles. A failure scoring S=10, O=2, D=2 yields an RPN of 40 and could be ranked below a failure scoring S=7, O=5, D=4 at RPN 140, even though the severity-10 failure should be addressed first. Fixed RPN cutoffs can also encourage teams to treat the number as permission to defer judgment.

AIAG-VDA-style risk analysis uses AP as the primary decision tool rather than relying only on RPN. AP is a lookup table with High, Medium, and Low levels, weighting severity first, then occurrence, then detection. That structure helps prevent severe safety risks from being buried by low-occurrence or high-detection scores. Risk assessment approaches still in use include RPN-based ranking, AP, and military-style criticality analysis.

Root Cause Analysis and FMEA

FMEA and root cause analysis sit on opposite sides of an event. FMEA is prospective, asking what if before a problem occurs. Root cause analysis is retrospective, asking what happened after a failure occurred.

The link between the two runs through the cause column, where causes must describe mechanisms rather than blame. In a DFMEA, causes should be concrete enough to point to material properties, geometry, dimensions, and interfaces. Words like bad, poor, defective, and failed should be avoided because they do not define the cause well enough for sound risk calculations. PFMEA causes typically follow a fishbone diagram around the 6Ms.

Root causes identified in an FMEA can start an Eight Disciplines (8D) or 5 Whys investigation, and those findings should flow back into the FMEA. When a production problem surfaces, the team should check whether the existing FMEA anticipated it and how accurately the risk was rated.

Common FMEA Pitfalls and Limitations

FMEA failures usually come from culture rather than scoring math, surfacing when teams chase a finished report instead of the insight the analysis should produce. These pitfalls damage the value of the work and make the FMEA harder to maintain as the product changes. Four patterns often damage FMEA quality:

• Stale analysis: Teams complete the scoring but never update the FMEA when requirements, designs, or processes change.
• Overreliance on RPN: Threshold gaming can bury a high-severity failure beneath a low-detection one.
• Scope creep: A project without agreed boundaries can expand until it tries to do too much and helps with nothing.
• No action ownership: Scoring should lead to a documented, prioritized action assigned to named personnel with due dates.

A related failure is excluding the operators, technicians, and field engineers who know how the work actually behaves. Facilitator experience matters too, since a seasoned moderator keeps the team from drifting.

FMEA Template and Example

The failure chain shapes the AIAG-VDA worksheet, moving from the focus element through function, failure mode, effect, and cause into risk analysis and action planning. The table below shows two failure modes scored under both RPN and AP to show where the methods diverge.

Field	Failure Mode A	Failure Mode B
Function	Brake actuator applies a clamping force	Dashboard indicator displays status
Failure mode	Insufficient clamping force	Delayed indicator refresh
Effect	Loss of braking, safety hazard	Minor user inconvenience
Severity (S)	9	3
Occurrence (O)	2	6
Detection (D)	3	6
RPN (S×O×D)	54	108
AP	H	L or M

Under pure RPN ranking, Failure Mode B at 108 would be prioritized over the safety-critical Failure Mode A at 54. AP corrects this by prioritizing the safety-critical failure mode instead of letting the lower RPN control the decision. After corrective actions are implemented, the worksheet records verification evidence and the re-scored occurrence or detection ratings.

How Jama Connect® Supports FMEA

Risk items become harder to maintain when they drift away from requirements, changes, and the design they analyze. Jama Connect® manages requirements and end-to-end traceability across development for complex, regulated product development, and it keeps each FMEA item traceable to the requirement it depends on. Teams build FMEA matrices directly in Jama Connect with automatic RPN calculation, and the medical device and automotive frameworks align the work to regulated development needs.

When an upstream requirement changes, Live Traceability™ flags every downstream artifact that traces to it. Traceability Information Models (TIMs) define which relationships the analysis is expected to maintain. That structure keeps the FMEA connected to the design it analyzes.

For medical device customers who need risk calculations beyond the built-in FMEA matrix, Jama Connect Interchange™ extends the connection further. Its Excel Functions module links live Jama Connect data to spreadsheet calculations, so teams can run custom risk scoring without losing traceability back to the source FMEA items. This video walkthrough of the integration shows how the Excel connection works in practice.

Keeping FMEA Connected to Change

As requirement baselines shift over time, every design change, process revision, and verified corrective action shifts the assumptions behind the original ratings. Updating the FMEA at phase transitions, after design or process changes, and when production failures surface, keeps it predictive. Filing it after design review leaves a historical record.

If your team needs a structured traceability workflow as development moves forward, Jama Connect can make FMEA easier to maintain. You can start a free 30-day trial of Jama Connect today.

Frequently Asked Questions About FMEA

What is the difference between FMEA and FMECA?

Failure Mode, Effects, and Criticality Analysis (FMECA) adds criticality analysis. After failure modes and effects are identified, FMECA classifies each effect by severity and probability of occurrence, and may include conditional probability and mission phase duration. FMEA is used broadly across design, manufacturing, and service through a structured seven-step FMEA process, while FMECA is common in military and aerospace work.

What is the difference between FMEA and root cause analysis?

FMEA is useful before a failure appears because it asks teams to identify mechanisms, effects, controls, and actions in advance. Root cause analysis is useful after a failure appears because it investigates what happened and how to prevent recurrence. Use the FMEA cause column as the handoff point between the two, then run change impact analysis on findings and feed confirmed results back into the analysis.

When should you perform an FMEA?

Start as early as the conceptual design stage and continue through the product life cycle. Trigger a new analysis for a new design or process, a modification to an existing one, or an existing design used in a new environment or duty cycle. Include the product engineers, process owners, operators, technicians, and field engineers who understand the in-scope functions and failure mechanisms, and connect the analysis to requirements verification and validation as the design matures.

How often should an FMEA be updated?

Update it whenever the assumptions behind the ratings change, including phase transitions, design or process changes, verified corrective actions, and production failures not captured in the existing analysis. When a requirement, baseline, or control changes, review the linked failure modes rather than waiting for the next scheduled review. Maintaining live traceability rather than after-the-fact traceability keeps that review continuous, and when FMEA items are linked to requirements and changes, Jama Connect can help teams see which risk assumptions need attention.

This article was authored by Mario Maldari and published on July 9, 2026