How to run a PFMEA, step by step

A Process FMEA is only as good as the conversation that produces it. The AIAG-VDA handbook frames that conversation as a seven-step process — three steps of system analysis, three of risk work, and one of documentation. Here's how to run it without it turning into a box-ticking marathon.

Before the workshop

Two things decide whether a PFMEA succeeds, and both happen before anyone scores anything:

• Scope it tightly. One process, clearly bounded. "The whole plant" is not a PFMEA; "the machining and welding of the suspension bracket" is.
• Get the right people in the room. Cross-functional is not optional: process/manufacturing engineering, quality, an operator who actually runs the line, and design when the part is new. The operator catches what the engineers assume.

The seven steps

1. Planning & preparation. Define scope, boundaries and the team; gather the inputs (drawings, process flow, the DFMEA, lessons learned from similar parts). Decide what's in and what's explicitly out.
2. Structure analysis. Break the process into its steps and elements. The process flow diagram is the backbone here — every step you'll analyse should exist as a node first.
3. Function analysis. For each step, state its function — what it's supposed to achieve ("drill bore to position within tolerance"). You can't describe a failure until you've described the intended success.
4. Failure analysis. Now invert each function into its failure mode (bore position out of tolerance), the effect (bracket misaligns at assembly) and the cause (worn drill bushing). Keep cause and effect distinct — teams routinely blur them.
5. Risk analysis. Rate Severity (of the effect), Occurrence (of the cause given current prevention) and Detection (of current detection controls), each 1–10. The method then assigns an Action Priority of High, Medium or Low. (See Action Priority vs RPN for how AP works.)
6. Optimization. For the High and Medium items, decide actions that reduce risk — strengthen prevention to lower Occurrence, strengthen detection to lower Detection, or change the design/process to cut Severity. Assign an owner and a date to each, then re-rate once actions are in place.
7. Results documentation. Record what you found, what you decided and what changed — for the customer, the auditor and the next team who revises this part.

Facilitation tips

• Score the effect, not the failure, for Severity. Severity belongs to the consequence; the same failure mode can have different severities depending on the effect you're considering.
• Use your rating tables, every time. S, O and D should come from agreed 1–10 criteria, not gut feel. Consistency across the team matters more than precision.
• Don't reverse-engineer the score. Decide the rating from the criteria; never pick the number that gets you the priority you wanted.
• Time-box it. A PFMEA loses the room after about 90 minutes. Several focused sessions beat one death march.

Common pitfalls

• Detection theatre. Lowering a Detection score because "we'll add an inspection" without specifying the control. Prevention beats detection — reducing Occurrence is real risk reduction; adding end-of-line inspection is catching escapes.
• Severity inflation/deflation. A safety effect is 9–10, full stop — you can't talk it down because the cause is rare.
• The write-once PFMEA. A PFMEA that's never revisited after launch is a museum piece. Feed real escapes and process changes back into it.
• Special characteristics left implicit. If a step protects a special characteristic, link it — and make sure it reaches the control plan (more here).

Want to see the output of all this on a real part? Read the worked example.