FMEA (Failure Mode and Effects Analysis) is a structured, preventive method for identifying how a product or process could fail, scoring each failure by severity, occurrence, and detection, and fixing the highest risks before they reach the customer. It is done before launch so problems are corrected while changes are still cheap.

How do you calculate RPN in FMEA?

RPN, the Risk Priority Number, is severity times occurrence times detection (RPN = S x O x D). Each factor is scored 1 to 10, so RPN ranges from 1 to 1000. You calculate it for every failure mode, sort high to low, and act on the top risks first, checking severity independently.

What is the difference between severity, occurrence, and detection?

Severity is how bad the effect is if the failure happens; occurrence is how often the cause is likely to happen; detection is how likely your current controls are to catch it first. All three use a 1-to-10 scale where higher is worse, including detection, where 10 means you would not catch the failure.

What is a good RPN threshold to act on?

There is no universal number. Many teams historically used an RPN threshold like 100 or 125, but that flat cutoff misses high-severity items with modest RPNs. The 2019 AIAG-VDA handbook replaced the single threshold with an Action Priority table that weighs severity most. Always act on high-severity failures regardless of RPN.

How do you reduce RPN?

Lower any of the three factors. A design change can lower severity by removing the bad effect; mistake-proofing the cause lowers occurrence; better inspection or gauging lowers detection. After the action is in place, re-score the line to confirm the risk actually dropped rather than assuming it did.

Is FMEA a one-time exercise?

No. FMEA is a living document. Its occurrence and detection scores are claims about how the process behaves right now, and they go stale when the process changes or the field reveals a new failure. Revisit the FMEA after every significant change and feed real failure data back into the scores.

FMEA: Failure Mode and Effects Analysis

Q: What is the difference between design FMEA and process FMEA?

Design FMEA (DFMEA) analyzes how a product's design could fail and is owned by engineering before release. Process FMEA (PFMEA) analyzes how the manufacturing process could fail to build a good product and is owned by manufacturing and quality. The scoring mechanics are identical; only the failure modes differ.

Score severity, occurrence, and detection, rank every failure by risk, and fix the worst ones before they ever reach the customer. A plain how-to for running an FMEA.

FMEA (Failure Mode and Effects Analysis) is a structured method for finding how a product or process could fail, then ranking each failure by severity, occurrence, and detection so you fix the highest risks before they reach the customer. The three scores multiply into a risk priority number that tells you where to act first.

FMEA started in aerospace and defense in the 1960s and spread into automotive and every other regulated industry because it does one thing well: it forces a team to think through failure on purpose, before it happens, and to spend its limited time on the risks that matter most. This guide covers the types of FMEA, how to score the three factors, how to calculate and use the risk priority number, and the mistakes that turn a good FMEA into a box-ticking exercise.

What is FMEA?

FMEA is a bottom-up, preventive risk analysis. A cross-functional team lists the ways a product or process could fail (the failure modes), traces what each failure would do (the effects), scores how bad, how likely, and how detectable each one is, and then works down the ranked list fixing the worst. The American Society for Quality describes it as a step-by-step approach for identifying all possible failures in a design, process, product, or service, so problems can be corrected before they reach the customer (ASQ, What is FMEA?).

The word "preventive" is the whole point. FMEA is meant to be done before a launch, a changeover, or a new line, while changing the design or the process is still cheap. Run after the fact, it becomes an autopsy. Run on time, it is the difference between catching a failure mode on a worksheet and catching it in a customer complaint or a recall.

What are the types of FMEA?

The two you will meet most are Design FMEA and Process FMEA. A Design FMEA (DFMEA) analyzes how a product's design could fail, a material that fatigues, a tolerance that stacks up, a component that overheats, and is owned by engineering before the design is released. A Process FMEA (PFMEA) analyzes how the manufacturing process could fail to build a good product, a missed torque, a mislabel, a contamination path, and is owned by manufacturing and quality. This guide is the general how-to that applies to both; the scoring mechanics are the same, only the failure modes differ. If your work is design-side specifically, a dedicated design FMEA treatment goes deeper on component-level failure physics.

There are others, System FMEA for interactions between subsystems, and FMECA, which adds a criticality analysis on top, but for most plants, PFMEA on the line and DFMEA on the product cover the ground. Whichever type you run, the structure below is identical.

How do you score severity, occurrence, and detection?

You rate every failure mode on three separate 1-to-10 scales. Each scale points the same direction, higher is worse, but they measure different things, and keeping them straight is what makes the numbers mean anything.

Factor	What it measures	1 means	10 means
Severity (S)	How bad the effect is if it happens	No noticeable effect	Catastrophic / safety hazard, often without warning
Occurrence (O)	How often the cause is likely to happen	Failure nearly impossible	Failure is almost certain / persistent
Detection (D)	How likely current controls catch it first	Controls will almost certainly catch it	No control exists, or the failure is undetectable

The three FMEA scales, each 1 to 10, each with higher meaning worse. Detection is the one teams reverse: a 10 means you would not catch the failure, which is bad. Scales follow the ASQ / AIAG convention.

Two scoring rules keep an FMEA honest. First, severity is a property of the effect not the cause, if a failure mode has several effects, you score the worst one. Severity does not drop because a failure is rare; a rare catastrophe is still a 10 on severity. Second, detection scores your current controls, not the ones you plan to add. If the only thing catching a defect is an operator's eye at the end of the line, that is a poor control and a high detection number, however good the operator is.

What is RPN and how do you calculate it?

The Risk Priority Number is severity times occurrence times detection: RPN = S × O × D. With three 1-to-10 scales, RPN ranges from 1 to 1000. You calculate it for every failure mode, sort the list high to low, and start working at the top. A high RPN means a failure that is serious, likely, and hard to catch, the exact combination you want to attack first.

Multiply the three scores to rank failure modes. But never let a big RPN hide a severity-10 line: anything that can hurt someone gets attention regardless of how the math lands.

RPN has one well-known weakness: it is not a smooth scale. An RPN of 200 built from severity 10 is far more urgent than an RPN of 200 built from three middling scores, even though the numbers match. That is why good teams never rank on RPN alone, they always look at severity first, act on every high-severity item regardless of its RPN, and then use RPN to order the rest.

By the numbers. ASQ standardizes the three factors on 1-to-10 scales, where severity 1 is insignificant and 10 is catastrophic, and RPN is their product, ranging 1 to 1000 (ASQ, FMEA). The 2019 AIAG & VDA harmonized FMEA handbook, used across the automotive supply chain, replaced the single RPN threshold with an Action Priority (High / Medium / Low) lookup table that weighs severity most heavily, a direct response to RPN's flat-scale problem, so a safety-critical failure can never be masked by low occurrence. Both approaches score the same three factors; they differ only in how they turn the scores into a priority.

How do you run an FMEA?

An FMEA is teamwork on a worksheet. One person filling in a spreadsheet alone produces a document nobody trusts; a cross-functional team arguing through the failure modes produces real risk knowledge. Here is the sequence:

Scope it and build the team. Pick one process or design and pull together the people who know it, operators, process and design engineers, quality, maintenance. Break the scope into functions or process steps so nothing gets skipped.
List the failure modes. For each step or function, ask how it could fail to do its job. Be specific: not "bad weld" but "weld incomplete on the left seam." Use history, warranty data, and root-cause analysis from past problems to seed the list.
Trace effects and causes. For each failure mode, write what it would do downstream and to the customer (the effect), and what would make it happen (the cause). One failure mode can have several causes; list them.
Score severity, occurrence, and detection. Rate each line 1 to 10 on all three scales, using agreed criteria so different people score the same way. Base occurrence and detection on your current controls, not intentions.
Calculate RPN and rank. Multiply the three scores, sort the list, and flag every high-severity item on top of the high-RPN ones.
Act on the top risks. Assign each priority line an action, an owner, and a date. Reduce risk by design change (lowers severity), mistake-proofing the cause (lowers occurrence), or better detection controls (lowers detection).
Re-score and keep it living. After the actions are in place, re-rate the affected lines to confirm the risk actually dropped, and revisit the whole FMEA whenever the process changes or a new failure shows up in the field.

A single FMEA row carries the whole logic: failure mode, its effect and severity, its cause and occurrence, the current control and detection, the resulting RPN, and the action that closes it.

What are the most common FMEA mistakes?

The biggest is treating FMEA as paperwork for an auditor instead of a working tool. When a team fills in the worksheet to satisfy a checklist, the scores get soft, everything lands around 120, nothing stands out, and no action follows. A real FMEA is uncomfortable, it surfaces failure modes people would rather not discuss and forces trade-offs.

The other frequent errors: scoring alone instead of as a team, so the numbers reflect one person's blind spots; inflating detection scores by counting controls you intend to add rather than the ones that exist today; ranking purely on RPN and missing a severity-10 line hiding at a modest number; and, most common of all, building the FMEA once and never touching it again. FMEA is a living document. Its occurrence and detection scores are claims about how your process behaves right now, and those claims go stale the moment the process changes or the field teaches you a new failure. Feed real failure and detection data back into it, and the FMEA stays honest.

How does FMEA connect to the rest of the quality system?

FMEA is the front end of risk management, and it hands off to everything downstream. Its high-occurrence causes become the targets for mistake-proofing and for statistical process control on the line, and its equipment failure modes feed directly into reliability work and machine downtime reduction. Its high-detection failures point to where your inspection and gauging are weak, and if a detection score depends on a measurement, you had better know that measurement is trustworthy, which is what a gage R&R study confirms. When a failure mode does escape, the corrective-action record links straight back to the FMEA line that predicted it, so you can ask why the ranking was wrong. Used this way, FMEA is not an isolated form; it is where a plant decides where to spend its quality effort, the same way the five focusing steps decide where to spend improvement effort. It belongs inside the broader discipline of lean manufacturing and reliability, feeding the same goal: catch failure early, where it is cheap.

The scores are only as good as the data behind them, and this is where most FMEAs quietly rot. Occurrence and detection are supposed to reflect how the process actually performs, but when defect counts, escapes, and downtime live on clipboards and month-end tallies, the team re-scores from memory and gut feel. When that data is captured live at the point of work, every defect, every escape, every machine stop tied to the line and the cause, the FMEA can be re-scored against reality instead of recollection, and a failure mode that is trending worse shows up before it becomes a complaint. That live feedback is what Harmony gives a plant, and it is the difference between an FMEA that ages into fiction and one that stays a true picture of risk. CLS made that shift, from failure data found the next morning to failure data visible during the shift, which is exactly the loop an FMEA needs to keep earning its place.