Skip to main content

The FMEA Framework: How to Predict Engineering Failures

Failure Mode and Effects Analysis: The engineering science of predicting exactly how your system will break.

If you accept Murphy’s Law as a non-negotiable boundary condition of system design, you acknowledge that your product or manufacturing line is going to fail. But acknowledging failure is not enough. You must anticipate the exact mechanism of that failure before the design leaves the building.

In amateur engineering environments, risk analysis consists of a few engineers looking at a CAD model and asking, "Do we think this is strong enough?"

In high-reliability environments—such as aerospace, medical device manufacturing, and elite automotive design—teams do not rely on gut feelings. They use a ruthless, quantitative framework developed by the military in the 1940s to systematically strip risk out of a design: Failure Mode and Effects Analysis (FMEA).

Advertisement

Simple Definition of FMEA

FMEA is a structured, step-by-step approach for identifying all possible failures in a design, a manufacturing process, or a product or service.

A "Failure Mode" is the specific way in which something might fail. An "Effect Analysis" involves studying the consequences of those failures. By breaking a complex machine down to its individual components and interrogating every single part, engineers can stop reacting to unexpected catastrophes and start engineering them out of existence.

Why Engineers Trust FMEA

The true power of an FMEA lies in its ability to remove subjectivity from design reviews. Instead of arguing over which failure is "worst," the team calculates a Risk Priority Number (RPN) for every single failure mode using three variables (each scored on a scale of 1 to 10):

RPN = Severity × Occurrence × Detection
  • Severity (1-10): How catastrophic is the failure? (1 = no noticeable effect; 10 = critical safety hazard without warning).
  • Occurrence (1-10): How likely is this specific failure to happen? (1 = highly unlikely; 10 = practically guaranteed).
  • Detection (1-10): If the failure happens, how likely are our current controls to catch it before it reaches the customer? (1 = certain to detect; 10 = completely invisible to current tests).

If an O-ring failing causes a machine fire (Severity = 9), happens somewhat frequently (Occurrence = 5), and is completely hidden from inspection (Detection = 10), your RPN is 450 out of 1000. That is an unacceptable risk that requires immediate design action.

It is important to note that RPN is a prioritization tool, not an absolute measure of risk. Different combinations of Severity, Occurrence, and Detection can produce identical RPN values, which is why high-severity failure modes must always be addressed regardless of the final score.

“A high RPN is not a warning. It is a leading indicator of future downtime.”

Advertisement

The Contrast Insight: The Detection Blind Spot

Most engineering teams naturally focus on Severity and Occurrence. They want to make the product stronger or use better materials. But the most cost-effective way to drastically reduce an RPN is often to improve Detection.

In many mature systems, Detection becomes the dominant lever for risk reduction because it can be improved without fundamental design changes, making it the fastest path to lowering system-level risk. You cannot always stop a tool from breaking (Occurrence) or change the fact that a broken tool ruins the part (Severity). But if you install a sensor that instantly stops the machine the millisecond the tool breaks (Detection score drops from 9 to 2), your RPN plummets. This is how the Swiss Cheese Model is successfully implemented: by building detection layers that catch the failure before it escapes.

Engineering Controls for Running an FMEA

An FMEA is useless if it is treated as a paperwork exercise to satisfy an ISO auditor. To make it a functional engineering tool, enforce these controls:

  1. Cross-Functional Execution: Never let a design engineer do an FMEA alone. They suffer from creator's bias. You must put manufacturing, quality, and maintenance engineers in the room. The people who assemble the product know exactly how it will break.
  2. Set an RPN Threshold: Establish a hard limit (e.g., any RPN over 100). If a failure mode scores above that threshold, the product cannot be released to manufacturing until an engineering control is added—often via error-proofing methods like poka-yoke—to lower the score.
  3. Prioritize High Severity: A failure mode with a Severity of 10 (life-threatening) and an RPN of 90 must always be addressed before a nuisance failure with an RPN of 150. Severity always overrides the raw score.
Advertisement

Quick Self-Check: Is Your FMEA Process Broken?

  • Is your FMEA filled out after the design is finished, just to satisfy a checklist?
  • Do teams artificially lower the Detection or Occurrence numbers just to get the RPN under the threshold?
  • Are field failures regularly occurring that were never listed as a possible Failure Mode on the original FMEA?
  • Is the document ignored once production begins, rather than treated as a living "lessons learned" database?

Frequently Asked Questions (FAQ)

What is the difference between DFMEA and PFMEA?

DFMEA (Design FMEA) focuses on how the product itself could fail due to design flaws (e.g., a bracket snapping under load). PFMEA (Process FMEA) focuses on how the manufacturing or assembly process could fail (e.g., an operator using the wrong torque spec during assembly).

Why is the RPN detection score counter-intuitive?

Because a higher number is worse. If you have an excellent, foolproof detection system, your score is a 1. If the failure is completely invisible and you have no way to detect it, your score is a 10.

When should an FMEA be started?

As early as possible in the conceptual phase. The cost of mitigating a failure mode is practically zero when it is just a CAD model, but it can cost millions if the failure is discovered after tooling is cut and production begins.

The Framework for Reliability Engineering

Engineering is not about hoping for the best. It is about mathematically predicting the worst and designing a system that survives it. If you aren't calculating your risks, you are just waiting to be surprised by them.

Do not wait for a failure to tell you what went wrong. Calculate it before it happens.

To master the definitive industry framework for risk analysis and learn how to execute a flawless Failure Mode and Effects Analysis, explore the authoritative guide by reliability expert Carl Carlson, Effective FMEA.

Comments

Popular posts from this blog

Murphy’s Law: Why Defensive Engineering Expects Failure

Murphy's Law: Anything that can go wrong will go wrong. In 1949, aerospace engineer Captain Edward A. Murphy was working on Project MX981 at Edwards Air Force Base, testing human tolerance to extreme G-forces using rocket sleds. During a critical test, all 16 strain gauge sensors wired to the test subject returned a reading of zero. Upon inspection, Murphy discovered the problem: every single sensor had been wired backward. The sensors allowed for two possible methods of connection, and the technician had chosen the wrong one 16 times in a row. Frustrated, Murphy coined a principle that would forever alter the discipline of engineering: "If there are two or more ways to do something, and one of those ways can result in a catastrophe, then someone will do it." Pop culture eventually shortened this to Murphy’s Law , treating it as a pessimistic joke about bad luck. But for engineering leaders, it is not a joke. It is a non-negotiable boundary condition ...

Drum-Buffer-Rope: Finding Your True Bottleneck

The Theory of Constraints: A factory can only produce as fast as its slowest machine. In many High-Mix, Low-Volume (HMLV) manufacturing environments, the scheduling system consists of the sales team receiving a Purchase Order, running out to the production floor, and shouting at the supervisors to prioritize it immediately. This creates a catastrophic "Push" system. Management dumps raw materials onto the floor as fast as possible, believing that if everyone works at maximum speed, the product will ship faster. Instead, they trigger the exact Job Shop Chaos mathematically guaranteed by Little's Law . The floor clogs with Work-In-Progress (WIP), cycle times explode, and nobody knows what to work on next. To fix this, you must stop managing the entire factory and start managing the only thing that actually matters: The Bottleneck . Advertisement The Theory of Constraints (TOC) Introduced by Dr. Eliyahu M. Goldratt, the Theory o...

The Pike Effect: Overcoming Learned Helplessness

Imagine a large pike placed in an aquarium, separated from the smaller fish it usually hunts by a clear glass partition. Naturally, the pike strikes. It hits the glass. It tries again, and again, experiencing a painful collision every time. Eventually, the pike gives up. But here is where it gets interesting: when researchers remove the glass partition, the pike continues to stay on its side of the tank. It starves to death while surrounded by food, convinced the barrier is still there. This phenomenon illustrates a powerful cognitive bias known as The Pike Effect , a visual representation of learned helplessness . Advertisement The Mechanics of Learned Helplessness In human terms, the Pike Effect happens when past failures condition us to believe that success is impossible, even after the environment has changed and the original obstacles have been removed. We build invisible glass partitions in our minds. A failed project, a rejected p...