← Insights

Risk

A PFMEA that engineers will actually use

July 2026 · 8 min read

Walk into most factories and ask to see the PFMEA for a production line. Someone will find it. It will be dated around the time the line was launched, it will have been written in a two-day workshop under deadline pressure, and it will not have been opened since. The scores were negotiated rather than assessed, the actions were closed with a signature rather than evidence, and the document now exists for one purpose: to be shown to auditors.

That is not a failure of the tool. A Process FMEA is one of the best pieces of thinking equipment quality engineering has ever produced. It is a failure of how the tool is run - and it is fixable.

What a PFMEA is actually for

Strip away the acronyms and a PFMEA answers three questions for every step of your process:

• What could go wrong here? (the failure mode)
• How much would it hurt, how often would it happen, and would we catch it? (Severity, Occurrence, Detection)
• What are we going to do about the ones that matter? (the actions)

The output is not the spreadsheet. The output is a ranked list of process risks and a set of actions that demonstrably reduce them. The spreadsheet is just where the thinking lives - which is exactly why a PFMEA written to satisfy a customer checklist, rather than to find risk, produces nothing but paperwork.

Scoring: where good PFMEAs go to die

Severity, Occurrence and Detection are each scored 1-10 against published scales. The mechanics are simple. The failure is nearly always behavioural, and it takes two forms.

Negotiated scores. The team knows that S9 x O4 x D5 gives an RPN of 180, and that the company rule says anything over 150 needs an action. So the Occurrence quietly becomes a 3. Nobody lied, exactly - the scales are wordy and there is always room for interpretation - but the document is now recording what the team can live with, not what the process does.

Anchorless scores. The opposite failure: scores assigned without data. Occurrence should come from scrap rates, first-pass yield, warranty and NCR history wherever that data exists. Detection should come from an honest look at whether the current control would really catch the failure - a visual check at the end of the line is not a 3, however much everyone wishes it were.

The cure for both is the same: score against the written scale, out loud, with the data on the table, and record the rationale for any score anyone challenged. Ten minutes of honesty per line beats a beautifully formatted fiction.

RPN had a design flaw. Action Priority fixed it.

For decades the standard output was the Risk Priority Number: S x O x D, giving a number from 1 to 1000, with a company threshold (commonly 100 or 150) above which action was required. RPN is still useful as a coarse ranking - but it has a known design flaw: it treats the three inputs as equal, and they are not.

An RPN of 90 can be S9 x O5 x D2 - a severe failure that happens regularly. An RPN of 100 can be S2 x O5 x D10 - a cosmetic niggle you never catch. The threshold flags the second and waves the first through.

The AIAG-VDA FMEA handbook (2019) replaced threshold-chasing with the Action Priority table: a published lookup that considers the combination of S, O and D and returns High, Medium or Low priority for action. Severity dominates, as it should. A severe failure mode with meaningful occurrence is High priority even when detection looks strong; a trivial one is Low priority even with weak detection. It is not a different calculation - it is a different, and better, decision rule on the same three scores.

In practice you want both: RPN for continuity with your existing system and for coarse ranking, Action Priority for deciding where the engineering hours go. High AP lines get actions, no debate. Medium AP lines get actions or a documented reason why not. That is the standard auditors increasingly expect to see.

Running the study so it stays alive

Walk the process, do not imagine it. The PFMEA follows the routing: every operation, every transport, every inspection. The failure modes worth finding live in the gap between the process as documented and the process as run - and you only find those at the line, talking to the people who run it.

Small team, right people. Process engineer, quality engineer, and at least one operator or team leader from the line. The operator contribution is consistently where the surprising failure modes come from.

Actions with owners and dates, then re-score. An action is not complete until the line is re-scored with evidence that Occurrence or Detection actually moved. The revised score columns are not decoration - they are the proof the exercise was worth the time.

Trigger the reviews. A living PFMEA is re-opened on triggers, not anniversaries: a customer complaint or significant NCR on the line, an engineering change, a new failure mode found in production, a process move. Wire the PFMEA into your change control and NCR processes and it stays current without a standing meeting.

Where the PFMEA feeds next

A PFMEA is the first document in a chain. Every High and Medium Action Priority line should land in your control plan as a controlled characteristic - with an evaluation method, a sample size and frequency, and a reaction plan. If the characteristic is measured, the gauge doing the measuring needs a Gauge R&R behind it, and the stable ones belong on a control chart. If your PFMEA's top risks do not appear in your control plan, one of the two documents is wrong.

And if the risk you keep finding is in the design rather than the process, that conversation belongs in a DFMEA - a sibling tool with the same mechanics and a different subject.