Walk into any manufacturing plant during an audit and you will find a pristine Failure Mode and Effects Analysis (FMEA) binder. It will have revision controls, sign-offs from cross-functional teams, and Risk Priority Numbers (RPN) neatly colour-coded. What you will rarely find is evidence that the document prevented a single failure. The FMEA has been reduced to an artefact for IATF 16949 or AS9100 auditors, not a functional tool for engineers.

I have audited plants where a machine failure caused three days of lost production. When we pulled the PFMEA, the exact failure mode was listed in row 42. The recommended action column read 'Implement predictive maintenance sensor.' The status column read 'Open.' It had been open since the document was created two years prior.

This is the core dysfunction. Quality teams treat the completion of the spreadsheet as the deliverable. The arithmetic becomes the focus, the cross-functional review becomes a rushed data-entry session, and the action items remain perpetually open. FMEA was designed to drive preventive action, but in most facilities, it functions as a post-compliance rationalisation.

The Static Spreadsheet Trap

A well-constructed PFMEA or DFMEA is a living document. It must evolve every time a process changes, a new material is introduced, or field data reveals an unforeseen defect mode. In practice, the FMEA is drafted under deadline pressure, usually by copying a template from a previous product line and changing the part numbers. Once archived, it is never updated.

This static approach creates a dangerous illusion. Because the analysis was documented and filed, management assumes the risk was addressed. But the process described in the FMEA has changed three times since it was written. New equipment has been installed, tooling has worn, and new operators are running the line. The document describes a process that no longer exists.

To fulfil its actual purpose, an FMEA must incorporate real production data. Internal nonconformances, 8D corrective actions, and warranty claims must feed directly back into the risk analysis. If a failure mode occurs on the floor and is not immediately added to the FMEA for review, the FMEA is obsolete. It must reflect current reality, not historical wishful thinking.

The Static Spreadsheet Trap — where the principle meets the process.
The Static Spreadsheet Trap — where the principle meets the process.

The Arithmetic Fallacy of RPN Prioritisation

The RPN is where FMEA goes from being an engineering tool to a meaningless exercise in arithmetic. Teams spend twenty minutes arguing whether an occurrence rating should be a 3 or a 4, as if the difference between 'occasional' and 'isolated' has objective mathematical meaning. The resulting score drives prioritisation, but the math is fundamentally flawed.

Consider two failure modes. The first has a severity of 10, an occurrence of 1, and a detection of 1, yielding an RPN of 10. The second has a severity of 1, an occurrence of 10, and a detection of 1, also yielding an RPN of 10. A team managing by the numbers will treat these as equal priorities. They are not.

The AIAG-VDA harmonised manual attempted to fix this by replacing RPN with Action Priority (AP), forcing teams to address high-severity failures regardless of occurrence or detection. This is an improvement, but it still relies on subjective scoring. The goal of the analysis should be engineering understanding, not arithmetic sorting.

Why RPN Misleads Engineering Teams

S x O x DTraditional RPNProduces a false mathematical equivalence between different risk profiles.
100Typical thresholdAn arbitrary cut-off where actions are required, usually written in a procedure and never questioned.
High SSeverity dominanceCatastrophic single-point failures must be addressed regardless of the calculated score.
1.33Statistical realityProcess capability indices (Cpk) provide objective occurrence data that subjective rating scales attempt to approximate.
The traditional 1-1000 RPN scale obscures catastrophic edge cases by multiplying subjective scores, treating a rare catastrophic event identically to a constant nuisance.

The Cross-Functional Illusion

Methodology demands cross-functional participation because no single discipline understands the entire process. Design engineers know the intended function. Manufacturing engineers know the production realities. Operators know what actually happens at 2:00 AM when the material is slightly off-spec and the machine is drifting toward tolerance limits.

Under deadline pressure, the facilitator usually abandons the team approach. Instead of a discussion, the FMEA is divided into silos. The design engineer takes the top half, the process engineer takes the middle, and the quality engineer fills in the detection controls. The document is stitched together and signed without a genuine review.

This division of labour produces a document that reflects individual assumptions, not collective understanding. No one steps back to ask if the failure modes are realistic or if the controls are actually effective. The FMEA must be built on the reality of the floor, not the theory of the procedure.

Why Recommended Actions Never Close

The most visible failure of FMEA is the action plan. Teams identify critical risks, write recommended actions, and then immediately abandon them. The actions are written down but assigned to no one, or assigned with no due date, no budget, and no accountability. The document is filed, and the failure modes continue to exist in the process.

An FMEA with open actions older than 90 days is not an engineering document. It is a wish list.

When the inevitable failure occurs, the corrective action team opens the FMEA and finds the exact failure mode identified months earlier with the action status marked 'Open'. This pattern destroys trust. The team learns that the analysis is a paperwork exercise, and they invest even less effort the next time. Every unassigned action guarantees the next 8D investigation.

The FMEA Action Closure Loop

  1. 01Identify and AssignEvery recommended action gets an owner, a budget, and a hard due date before the meeting ends.
  2. 02Implement the ControlExecute the process change, Poka-Yoke device installation, or SPC implementation.
  3. 03Verify EffectivenessConfirm the control actually works using objective data, not assumptions.
  4. 04Recalculate RiskUpdate the occurrence or detection rating based on the verified new process reality.
Without a closed-loop verification step tied to a reduction in occurrence or an increase in detection, the FMEA remains a purely theoretical exercise.

Rebuilding FMEA as a Living Tool

Fixing FMEA requires abandoning the template-first approach. Before opening a spreadsheet, walk the floor. Look at the actual process running today. Review recent customer complaints and internal nonconformances. The FMEA must be built on current production data, not a copy of last year's compliance documentation.

Stop treating the review as a data-entry exercise. The value of FMEA is in the discussion. When an operator explains that the procedure says one thing but the floor reality is different, that is where risk understanding is built. The spreadsheet captures the output, but the conversation is the actual work.

Tie every recommended action to a person, a date, and a verification method. If the action cannot be assigned a specific owner and budget before the FMEA is signed, it is not a real action. Track these actions in the same management review cycle as your open 8Ds. Treat the FMEA as a living standard, not a project deliverable.

Measuring Actual Preventive Success

The measure of a successful FMEA program is not the number of documents on file. The measure is whether the analysis prevented failures that would have otherwise occurred. You must be able to point to specific examples: a design change made because FMEA revealed a vulnerability, or a process control added because the analysis identified a detection gap.

If your quality system holds hundreds of FMEAs but cannot cite a single preventive action directly attributed to the analysis, the program is failing. The failures you were supposed to prevent do not care that you have a spreadsheet. They care whether someone understood the risk and acted on it.

FMEA is an engineering tool for thinking. When it becomes a compliance tool for auditing, it loses its power entirely. The difference between an FMEA that prevents disasters and one that merely documents them is entirely dependent on the discipline applied after the spreadsheet is closed.