A Tier 1 automotive supplier shipped 40,000 fuel injector assemblies that passed final inspection with flawless dimensional data and impeccable PPAP documentation. Over a year later, vehicles caught fire because a microscopic crack formed during assembly. The crack only occurred on the night shift when a worn fixture was paired with a specific operator angle, propagating under thermal cycling until fuel vapour escaped.
The supplier had performed a process FMEA. A cross-functional team spent three weeks identifying 47 failure modes, ranking risks by severity, occurrence, and detection. They missed the one that mattered—not from incompetence, but because they executed the spreadsheet mechanically. When applied as a compliance exercise, FMEA is an elaborate way for competent teams to convince themselves they have covered every eventuality while systematically missing the critical interaction.
Failure Mode and Effects Analysis is a structured conversation about what could go wrong. The risk priority numbers, the scoring matrices, and the AIAG-VDA harmonized handbook are scaffolding. The core mechanism is forcing a team to analyse how a process fails, what happens when it does, and whether current controls will catch it. If your team treats the spreadsheet as the end goal, you are running risk theatre, not risk analysis.
Mapping the Three Faces of FMEA
FMEA is not a single tool. System FMEA analyses the product architecture to catch interface vulnerabilities between subsystems that no individual owner would check. This happens early in the concept phase, when changing the architecture is still cheap and drawing modifications do not require tooling rework.
Design FMEA zooms into the product design itself. This is where you discover that your specified seal material degrades at temperatures generated by an adjacent component during normal operation. It forces you to calculate worst-case tolerance stack-ups, identifying gaps that are statistically rare in a 30-piece sample but mathematically certain across a million units.
Process FMEA dissects the manufacturing sequence. It examines every operation, handling step, and transfer point to catch the worn fixture, the ambiguous work instruction, or the gauge incapable of detecting the specific defect you are trying to prevent. All three types follow the same underlying logic and fail in identical ways when teams prioritise filling out forms over thinking through the process.
Defining the Scope and Mapping the Reality
Scoping an FMEA too broadly guarantees failure. If you announce you are doing an FMEA on the entire fuel injector assembly, your team will drown in failure modes and produce an unreadable document. Defining the scope as the retaining clip installation operation, from bowl feeder through final seating verification, makes the analysis thorough and bounded.
Before brainstorming failures, map the process or structure. For a process FMEA, build a detailed flow diagram that captures every handling step, transfer, and rework loop. For a design FMEA, construct a boundary diagram showing energy, material, and signal flows. This mapping alone reveals risks when the process engineer draws the flow and the operator points out that the documented procedure does not match reality.
The gap between procedure and practice is itself a failure mode. A team cannot assess risks accurately if they are analysing an idealized version of the production line. The flow map must reflect exactly how the operator runs the station on a Friday night, not how the industrial engineer designed it in a clean office.
Brainstorming failure modes is where mechanical FMEA diverges from real risk analysis. A failure mode is how the process fails to deliver its intended function, not the cause or the effect. Mixing these up destroys the FMEA logic. The team must define what could go wrong during normal operation, setup, and changeover. They must consider what happens when incoming material sits at the edge of its specification tolerance, or when environmental factors like humidity shift.
Evaluating Severity, Occurrence, and Detection
Severity is the voice of the customer. A severity 10 means potential injury or regulatory non-compliance. This rating is the one variable you cannot engineer away. If a retaining clip fails and fuel vapour escapes into an engine bay, the severity remains catastrophic regardless of how unlikely the event is. High-severity failure modes demand attention even with low occurrence rates.
Occurrence is the voice of the process. It measures how likely the failure is given your current controls. Teams often anchor on historical data, assuming that a failure they have never seen cannot happen. If you have produced 50,000 units without a defect, you only know the occurrence rate is below 1 in 50,000. It tells you nothing about whether the rate is 1 in 100,000, which guarantees five failures in the next half-million units.
The AIAG-VDA Action Priority Framework
- 01Establish SeverityDetermine the consequence if the failure reaches the customer.
- 02Evaluate OccurrenceAssess the likelihood of the cause based on current process controls.
- 03Determine DetectionRate the ability of current controls to catch the defect before shipment.
- 04Assign Action PriorityCategorize the risk as High, Medium, or Low based on the rating combinations.
- 05Implement ActionsAssign specific owners, dates, and re-evaluate the risk ratings post-implementation.
Detection is the voice of your controls, and it is where most teams are dishonest. They list final inspection and SPC charts and assign optimistic scores. Detection must be evaluated for the specific failure mode, not the general quality of the inspection system. If the defect is a microscopic crack only visible under specific conditions, a visual check at final inspection warrants a poor detection score.
Building Action Plans That Change Ratings
The AIAG-VDA harmonized approach uses Action Priority rather than traditional Risk Priority Number multiplication. The RPN method created a mathematical illusion of precision, where a rare but catastrophic risk scored identically to a frequent but minor inconvenience. Action Priority tables force a judgment call. High severity combined with poor detection dictates high priority, full stop.
An FMEA without concrete actions is just a diary of risks you chose to accept. Every high and medium-priority failure mode requires a specific action plan. "Improve process" is not an action. "Add a proximity sensor that verifies seating depth within 0.2mm before the assembly advances" is an action. Assign a specific human being, not a department, and lock in a calendar date for completion.
The action plan must include a mandatory re-evaluation step. After the sensor is installed, the team must recalculate the detection rating. If the new fixture design reduces variability, they must update the occurrence rating. If the risk ratings do not change, the action failed. The re-evaluation is the proof that your preventive action actually worked.
In my experience auditing plants, the most common reason actions fail is that they address the symptom instead of the root cause. A team will add an extra inspection station to catch a defect, improving detection but doing nothing to reduce occurrence. The most effective actions redesign the process to make the failure mode physically or statistically impossible to achieve.
The Patterns That Derail Risk Analysis
Copy-paste FMEA is the most visible symptom of a broken quality culture. Last year’s document gets a new date in the header, and the failure modes and ratings remain identical. Nothing was learned from a year of production, warranty claims, or near-misses. The document grew older but provided no new intelligence. A living document becomes a dead artifact.
The RPN threshold trap is equally destructive. Setting an arbitrary cutoff, such as addressing only failure modes with an RPN above 120, means a severity 10 risk with an occurrence of 3 gets ignored. You end up protecting your spreadsheet logic instead of protecting the customer. High-severity risks deserve attention regardless of the math.
An FMEA without actions is a diary of risks you chose to accept.
Retroactive FMEA is another persistent failure. The tooling is built, the design is frozen, and production has started before someone realizes the compliance requirement. The team scrambles to document decisions already locked in. This is not risk analysis; it is retroactive justification. The value of FMEA lies in influencing design and process decisions while they are still malleable.
Siloed execution destroys cross-functional insight. The design engineer fills out the design FMEA alone. The process engineer fills out the process FMEA alone. Nobody consults the maintenance technician who knows exactly which fixtures wear out fastest, or the operator who has developed an informal workaround for a persistent assembly issue.
Mechanical vs. Living FMEA
Risk Theatre
- Uses last year's spreadsheet and identical failure modes
- Assigns optimistic detection scores to pass audits
- Sets arbitrary RPN cutoffs to limit required actions
- Treats the document as a compliance milestone
Actual Risk Mitigation
- Updates ratings based on field returns and near-misses
- Scores detection honestly against specific failure modes
- Prioritizes actions based on severity first
- Treats the document as a driver of design decisions
Sustaining FMEA as a Living Practice
Organizations that extract real value from FMEA treat it as a continuous practice, not a milestone. They update the FMEA when the process changes. Every engineering change, every new supplier approval, and every equipment modification triggers a review of the relevant sections. If a new material enters the supply chain, the occurrence ratings for associated failure modes must be recalculated.
They connect FMEA directly to the control plan. The control plan is the operational expression of the risk analysis. Every high-severity failure mode in the FMEA must have a corresponding control in the plan. If the FMEA lacks a risk that the control plan addresses, you have an undocumented risk assessment, which creates audit findings and operational blind spots.
A robust quality system feeds field failures back into the FMEA. Every customer complaint and internal nonconformance gets checked against the document. If the failure was previously identified, the team asks why the ratings failed to trigger prevention. If it was missed, they analyse the gap in their logic and train the team to recognize that interaction next time.
Effective organizations train their operators and maintenance technicians to think in failure modes. When an operator notices a fixture feels different during a night shift, they report it because they understand it represents a potential deviation. FMEA does not guarantee perfection, but it guarantees that the organization genuinely thought about the risks. In quality engineering, rigorous proactive analysis is the strongest defence against catastrophic failure.