FMEA — failure mode and effects analysis — is a structured way of asking three questions about a product or a process: how could it fail, what would happen if it did, and how likely is the failure to happen or to slip past the checks already in place? A team works through the answers on a standard worksheet, scores each possible failure for severity, occurrence and detection, and combines the three scores into a single risk priority number. The highest numbers get fixed first.
In short, that is the whole idea. FMEA is done before failures reach customers — while a design is still on screen or a process is still being set up — so the fixes stay cheap: a design change, a stronger control, an extra check at the right step. The same failure found after launch means scrap, rework or a recall.
This guide explains how an FMEA analysis works in practice: the main types, the FMEA process steps, the three scores behind the FMEA RPN, a worked FMEA example, and where the method reaches its limits.
What Is FMEA?
Four terms carry the whole method.
First, a failure mode is the way something could fail. A seal that does not seal. A label applied to the wrong carton. A sensor that reads high when the real value is low. Each failure mode states a failure to do what the item or step is supposed to do.
Next, an effect is what that failure does — to the end user, to the next process step, or to both. Effects are written from the customer’s point of view, because that is what the severity score will judge.
Then, a cause is why the failure could happen: a worn tool, a look-alike label stored next to the correct one, a setting that drifts. And controls are what is already in place — prevention controls that stop the cause occurring, and detection controls that catch the failure before it moves on.
In practice, FMEA is a team exercise, not a form one engineer fills in alone. Design, manufacturing, quality and the people who run the process each see failure modes the others miss. The finished worksheet is a living document, updated when the design or process changes and when a real failure teaches the team something new.
A Short History of FMEA
Originally, the method started in United States defence work in the 1940s, where a formal procedure for studying how military equipment could fail was published in 1949. NASA took it up in the 1960s for the Apollo programme, where systems had to work first time, with no chance of repair.
Subsequently, the car industry adopted FMEA in the 1970s and 1980s, and it spread through the supply chain as vehicle makers required it from their suppliers. The Automotive Industry Action Group (AIAG) published a reference manual that standardised the worksheet and scoring tables. In 2019, AIAG and the German association VDA published a harmonised handbook that aligned the American and European approaches and changed how risks are prioritised — more on that below.
Types of FMEA
Design FMEA (DFMEA)
First, a design FMEA studies the product itself. It takes each function the design must deliver and asks how the design could fail to deliver it: a material that cannot take the load, tolerances that stack up until parts no longer fit, a component that wears out early. Design engineers lead it, and it is done before the design is released, while changes are still drawings rather than tooling.
Process FMEA (PFMEA)
By contrast, a process FMEA studies the steps that make and assemble the product. It asks how the process could produce a defect: torque not applied, a step skipped, the wrong label picked, contamination at a filling station. It is built before or during production launch, and its output feeds the control plan.
In short, the difference matters, because design FMEA vs process FMEA is a difference in the point of attack. A design FMEA asks whether the design can fail in use; a process FMEA asks whether the process can make the product wrong. A sound design can still be ruined by a weak process, and a capable process cannot rescue a design that fails in the customer’s hands. The two studies link: effects and severity usually carry over from the design study into the process study.
Other Types You Will Meet
For example, teams apply a functional FMEA early, at the level of system functions rather than physical parts. FMEA-MSR (monitoring and system response) covers failures that happen while a product is in use, where the product monitors its own condition and responds — vehicle diagnostic systems are the standard example.
The FMEA Process Steps
In practice, formats differ between companies, but the FMEA process steps follow the same logic everywhere.
- Define the scope. Fix the item or process step under study, its boundaries, and the team. A study with no boundary grows until it stalls.
- List the functions. State what the item or step must do, in plain terms, with measurable requirements where they exist.
- Identify failure modes. For each function, ask how it could fail: not at all, partly, too much, or when it should not happen at all.
- Describe the effects. Write what each failure mode would do to the customer and to the next step. Where there are several effects, the most serious one drives the severity score.
- Find the causes. For each failure mode, list the specific reasons it could occur. Vague causes (“operator error”) cannot be fixed; specific ones (“two look-alike labels stored side by side”) can.
- Record current controls. Separate prevention controls, which act on the cause, from detection controls, which act on the failure mode.
- Score and calculate. Score severity, occurrence and detection for each row and multiply them into the risk priority number.
- Agree actions and re-score. For the highest risks, assign actions with owners and dates. After the actions are in place, score the row again to confirm the risk fell.
However, step 8 is where many studies quietly die. On a well-run shop floor, open FMEA actions are tracked day to day on an SQCDP board, so an overdue fix stays visible instead of sitting in a spreadsheet nobody opens.
Severity, Occurrence and Detection: The Three Scores
Overall, teams score every failure mode on three scales, each running from 1 to 10. The published rating tables (the AIAG handbook is the common reference) describe what each score means, so teams score in roughly the same way.
Severity (S)
In practice, severity rates how serious the effect would be. A score of 1 means no noticeable effect. A score of 10 means the failure could affect safety or break legal requirements without warning. Severity judges the effect only — it does not matter how likely the failure is, or how good the checks are. Any row with a severity of 9 or 10 gets attention whatever its final RPN says.
Occurrence (O)
Similarly, occurrence rates how often the cause is expected to happen, given the prevention controls in place. A score of 1 means the cause has effectively been designed out or prevented by a proven control. A score of 10 means the failure is almost certain.
Detection (D)
Finally, detection rates how likely the current detection controls are to catch the failure mode or its cause before the product reaches the customer. This scale runs against first instinct: a low score is good. Detection of 1 means the control will almost certainly catch it — an automatic check that stops the line. Detection of 10 means there is no control, or the failure cannot be detected at all.
| Rating | Severity — the effect | Occurrence — the cause | Detection — the controls |
|---|---|---|---|
| 9–10 | Safety or legal risk, with little or no warning | Failure almost certain | No control, or detection almost impossible |
| 7–8 | Major loss of function; customer very dissatisfied | Failures happen often | Low chance of detection |
| 4–6 | Noticeable defect or reduced performance | Failures happen occasionally | Moderate chance of detection |
| 2–3 | Minor defect or annoyance | Failures are rare | High chance of detection |
| 1 | No effect | Cause eliminated by prevention | Detection almost certain |
The Risk Priority Number (RPN)
In fact, the FMEA RPN — the risk priority number — is the three scores multiplied together:
RPN = Severity × Occurrence × Detection
The result runs from 1 to 1,000. Teams sort the worksheet by RPN and work from the top down: the number turns a long list of worries into a short list of priorities.
Treat the number with care, though. Two very different risks can share one RPN: a severity 10, occurrence 2, detection 2 row scores 40 — the same as severity 4, occurrence 5, detection 2. The first row can hurt someone; the second cannot. Read the severity first, then the RPN. There is also no universal RPN threshold for action: companies set their own rules, and any threshold is a starting point for discussion, not a safety guarantee.
The lecture below walks through the method in more detail, with a scored example:
FMEA Example: A Packaging Cell
Here is a short FMEA example from a process FMEA on a small packaging cell. The cell packs pump bottles of detergent into cartons of twelve. Labels and cartons reach the cell through a kanban method of visual replenishment, so the team included both packing errors and stock-driven mistakes in the study.
| Process step | Failure mode | Effect | Cause | S | O | D | RPN | Action |
|---|---|---|---|---|---|---|---|---|
| Seal bottle | Safety seal missing | Leakage and no tamper evidence; complaints and possible batch recall | Seal roll runs out unnoticed during the shift | 8 | 3 | 6 | 144 | Fit a low-roll sensor and an automatic seal-presence check |
| Apply carton label | Wrong label on carton | Retailer rejects the delivery; relabelling and re-delivery cost | Two look-alike labels stored side by side | 6 | 4 | 5 | 120 | Store labels apart; add a barcode scan matching label to works order |
| Pack bottles | Carton under-filled (11 of 12) | Customer short-shipped; credit notes and extra delivery runs | Counting error at full line speed | 5 | 5 | 4 | 100 | Run every carton over a checkweigher that rejects underweight cartons |
| Close and stack carton | Carton damaged in transit | Returns and damaged stock | Carton grade too weak for the stacked load | 4 | 6 | 3 | 72 | Move heavy variants to a stronger carton grade |
In short, read the table the way a team would. The missing seal comes first — not because it happens most often, but because its effect is the worst (severity 8) and the current check, an operator glancing at bottles at line speed, is weak (detection 6). After the sensor and automatic check are fitted, detection falls to 2 and the row re-scores at 8 × 3 × 2 = 48. The scores are not the deliverable of an FMEA; the actions are.
The AIAG-VDA Approach and Action Priority
In fact, the 2019 AIAG-VDA handbook kept the core of the method — failure modes, effects, causes, controls and the three scores — but changed how teams decide what to fix. Instead of chasing the highest RPN, teams assign an Action Priority of High, Medium or Low to each row, using tables that combine severity, occurrence and detection.
In addition, Action Priority fixes two weaknesses of the RPN approach. It ends the false precision of treating a score of 144 as meaningfully worse than 138. And it weights severity first: a high-severity row can come out as High priority even when occurrence and detection are low — exactly the case a plain RPN ranking tends to bury. A High Action Priority means the team is expected to act; a Low one means action is optional, with the reasoning recorded. Many companies still calculate RPN alongside, but under the current handbook, Action Priority drives the decision.
When to Use FMEA
In practice, FMEA earns its time in a few clear situations:
- A new product or process is being designed, and failure is still cheap to prevent.
- An existing design, process, material, supplier or machine changes — changes quietly undo old assumptions.
- A production line is moved, copied to another site, or run at a higher rate.
- A quality problem has appeared, and the team wants to check whether the same failure mode exists in similar products or lines.
For example, on a line running just-in-time (JIT) inventory management, buffer stock is close to zero, so a single undetected process failure can stop the flow within hours — one reason a process FMEA before launch is standard practice there. Note the boundary of the method, though: FMEA works at the level of one product or one process. Supplier and transport failures belong to supply chain risk management; the two habits support each other but are not the same study.
The Limits of FMEA
Overall, FMEA is a strong method with real limits, and knowing them keeps the output honest.
First, it only finds the failures the team can imagine. A failure mode nobody in the room thinks of does not appear on the worksheet, however carefully the known rows are scored. It also studies one failure mode at a time; failures caused by two things going wrong together are harder for the classic format to catch.
Secondly, the scores are structured judgement, not measurement. Two good teams can score the same row differently, and an RPN of 120 is not twice as risky as an RPN of 60. The numbers sort and prioritise; they do not prove anything about the real level of risk.
And the study goes stale. A worksheet written for a product launch and never touched again describes a process that may no longer exist.
Common FMEA Mistakes
- First, writing it alone to satisfy a customer requirement. One person at a desk produces a document, not an analysis — the failure modes the operators know never appear.
- Next, vague failure modes. “Machine stops” or “part fails” cannot be scored or fixed. The mode has to say what fails to happen, in terms a cause can attach to.
- Also, generous detection scores. Claiming strong detection because “we inspect 100%” without asking how well that inspection actually performs is the most common scoring error.
- Then, stopping at the first score. No owners, no dates, no re-scoring after actions — the study becomes a snapshot instead of a control.
- Similarly, sorting by RPN alone. A severity 9 row with a modest RPN still needs a decision, and a pure number sort can push it off the action list.
- Finally, never updating it. Design changes, process changes and real field failures should all trigger a review; an untouched FMEA drifts from the process it describes.
Frequently Asked Questions
What is the difference between design FMEA and process FMEA?
In short, a design FMEA studies the product: how the design itself could fail in use. A process FMEA studies production: how the manufacturing or assembly steps could make the product wrong. The design study comes first, and its effects and severity scores carry into the process study, which then concentrates on causes and controls on the line.
How do you calculate RPN in FMEA?
Multiply the three scores for the row: RPN = severity × occurrence × detection. Each score runs from 1 to 10, so the RPN runs from 1 to 1,000. Severity 8, occurrence 3 and detection 6 gives an RPN of 144. Under the AIAG-VDA handbook, teams use Action Priority (High, Medium or Low) instead of the RPN to decide what to fix.
What RPN value means action is required?
In fact, there is no universal figure. Companies set their own thresholds, and a threshold is only a screening rule. Two checks matter more: any severity of 9 or 10 needs a decision regardless of RPN, and a high RPN driven by weak detection usually points to a cheap fix — a better check — that should not wait for a threshold debate.
Who should take part in an FMEA?
In practice, a cross-functional team: design engineering for a design FMEA, manufacturing or process engineering for a process FMEA, quality in both cases, and the people closest to the work — operators, maintenance staff, and sometimes the supplier of a key component. The team can only score the failure modes it knows, so who is in the room decides the quality of the study.
How often should an FMEA be updated?
Generally, whenever the thing it describes changes: a design revision, a new machine, a different material or supplier, a changed process step. Real failures and customer complaints should also trigger a review, because they reveal failure modes or scores the team got wrong. Many companies add a fixed periodic review for running processes on top of these event-driven updates.
Done well, FMEA is disciplined foresight: a team agreeing, in writing, how things could fail and what it will do about the worst of them before a customer finds out. Keep the worksheet current, act on the top rows, and re-score honestly, and the method pays for the time it takes.
