FMEA Step by Step: Scoring RPN Without Guesswork

Most teams don't struggle with the idea of FMEA — list what could go wrong, score it, fix the worst of it. They struggle with the scoring. Put the same failure mode in front of five people and ask for a severity, occurrence, and detection rating, and you'll often get five different sets of numbers. The method doesn't fail because the framework is wrong; it fails because the scoring is done from gut feel, in a room where the loudest opinion wins.

This is a working walkthrough of the steps that keep FMEA scoring consistent — not just what the ratings mean, but how to anchor them so the resulting Risk Priority Number (RPN) reflects the process, not whoever spoke first. For the underlying definitions, our glossary covers What Is FMEA? (/blog/what-is-fmea) and What Is RPN? (/blog/what-is-rpn) — this piece assumes you know the vocabulary and walks through applying it.

Step 1: Scope the process before you list anything

The most common way an FMEA goes sideways happens before a single failure mode is written down: the scope is too wide. "Order fulfillment" is not a scope — it's a department. Break the process into discrete steps first, the way you would for a process map, and run the FMEA against each step's inputs, function, and output separately. A step-level FMEA produces failure modes specific enough to act on; a department-level one produces generalities like "communication breakdown," which nobody can score honestly because it isn't really one failure.

If you haven't already broken the process into steps, do that first — our SIPOC and process mapping guide (/blog/process-mapping-101-from-sipoc-to-value-stream) covers how to get from a vague process name to a step list worth analyzing.

Step 2: List failure modes per step, not per person's worry

For each step, ask three questions in order: how could this step fail to deliver its function (the failure mode), what happens downstream if it does (the effect), and what usually causes it (the cause). Keep these three distinct — teams new to FMEA routinely write a cause in the failure-mode column or an effect in the cause column, which quietly breaks the scoring later, because severity is supposed to rate the effect, not the failure mode or the cause.

• Failure mode: the specific way the step doesn't do its job — "wrong shipping label applied," not "shipping errors."
• Effect: what the customer or the next process step actually experiences — "package delivered to wrong address, customer complaint, reshipment cost."
• Cause: the mechanism that produces the failure mode — "label printer queue pulls the previous order's label when reprinting."

A single step can have several failure modes; list them separately rather than folding them into one row, since they'll usually score differently.

Step 3: Score severity, occurrence, and detection against anchors, not instinct

This is where most of the inconsistency lives, and it has a simple fix: write a shared scoring table before anyone scores anything, and score against the table's language, not a number that "feels right."

• Severity (1-10) — how bad is the effect if it happens? Anchor the ends concretely for your process: a 1 might be "no noticeable effect," a 10 might be "safety hazard or regulatory violation." Write two or three anchor points in between (a 5, a 7) so the middle of the scale isn't a guess either.
• Occurrence (1-10) — how often does the cause actually happen? Anchor this to real frequency bands where you can — "less than 1 in 10,000" at the low end, "more than 1 in 10" at the high end — pulled from your own process data when it exists, not estimated fresh each time.
• Detection (1-10) — how likely is the current control to catch the failure before it reaches the customer or next step? This one runs backwards from the other two: a 1 means the control is almost certain to catch it, a 10 means there's effectively no control at all. Score the control that exists today, not the one you're planning to add.

Build this table once, with the team, before the first scoring session — then reuse it for every FMEA the team runs afterward. A table built in the room, from memory, scored differently for each failure mode, is where most of the inconsistency teams blame on "the method" actually comes from.

Step 4: Multiply, but don't stop at the multiplication

RPN = Severity × Occurrence × Detection. The number tells you where to look first — it doesn't tell you what to do.

A worked example: a step that mislabels shipments has a severity of 7 (wrong-address delivery, reshipment, customer complaint), an occurrence of 4 (happens somewhat regularly, tied to a specific printer queue bug), and a detection of 8 (no control currently catches it before the package leaves the building). RPN = 7 × 4 × 8 = 224.

Compare that to a second failure mode on the same step: a packing error caught by a required weight-check scale before shipment. Severity 6, occurrence 5, detection 2 (the scale catches almost everything). RPN = 6 × 5 × 2 = 60. Even though the packing error happens more often, the mislabeling failure outranks it by a wide margin — because nothing is currently catching it. That's the value RPN adds over ranking by frequency alone: an existing control changes the priority even when the underlying cause is common.

Step 5: Don't compare RPNs across different FMEAs

A 224 from one team's FMEA and a 224 from another team's aren't the same risk unless both teams built their severity, occurrence, and detection tables from the same anchors — which they usually didn't. Use RPN to rank failure modes within a single FMEA, not to compare risk across departments or to set a single company-wide "anything above 150 needs action" rule unless every team is scoring against the identical table. If leadership wants to compare risk across processes, that's a separate exercise from what RPN was built to do.

Step 6: Act on the top of the list, then re-score

Take the highest-RPN failure modes and assign a specific action, an owner, and a date — redesign the step, add a control, mistake-proof the operation so the failure can't physically happen. Once the action is in place, re-score that failure mode. If detection improved because a new control was added, the RPN should drop; if it doesn't, the fix probably didn't do what the team thought it did. This re-scoring step is where a lot of FMEAs quietly stop — the initial table gets built, scored, and filed, and nobody checks whether the numbers actually moved. A living FMEA gets reopened whenever the process changes; treat it as a document you revisit, not a deliverable you finish once.

Where this fits with root cause work

FMEA is proactive — it anticipates failures before they happen, using the team's collective knowledge of the process. That's different from root cause analysis, which is reactive — investigating a failure that already occurred. Our guide to 5 Whys, fishbone diagrams, and Pareto charts (/blog/root-cause-analysis-5-whys-vs-fishbone-vs-pareto) covers the reactive side; the two work well together, since an FMEA built after a root-cause investigation often surfaces related failure modes nobody had scored yet.

FMEA and RPN scoring are core Green Belt tools (/courses/green-belt), where you build one against a simulated process and practice anchoring the scoring table before you ever run it on live data — a much cheaper place to make the early mistakes than on a real production line. If the vocabulary above is new, our free White Belt (/courses/white-belt) covers the basics of risk thinking and failure-mode language first, with the same timed, closed-book exam format used across every Averon level.