Failure Modes and Effects Analysis Basics

The idea in one paragraph

Failure modes and effects analysis, usually shortened to FMEA, is a structured way to ask “how could this fail, and what would happen if it did?” before the failure occurs. The team lists the parts or functions of a design, writes down the ways each one could fail, describes the consequences, and then decides which items deserve attention first. It is a thinking tool and a record of that thinking, not a guarantee that nothing will go wrong.

This article covers the general idea only. Industries differ in the formats, scoring scales and procedures they expect, and in regulated work you should follow the standards and professionals that apply to you.

Key terms

• Function: what a part or step is supposed to do, such as “supply 5 V” or “seal the joint”.
• Failure mode: the way the function could fail to happen, such as “no output”, “output too high”, “intermittent” or “leaks”.
• Effect: what the failure causes, ideally at more than one level: locally, in the wider system, and for the user.
• Cause: why the failure mode might occur, such as wear, a manufacturing variation, a wrong assumption at an interface or misuse.
• Current controls: what already exists to prevent the cause or to detect the failure, such as a design margin, an inspection or a self-test.

A common mistake is to confuse these. “Cracked housing” might be a failure mode, “fatigue” its cause, and “water ingress and a short circuit” its effect. Keeping the three apart makes the table far more useful.

The usual steps

1. Define the scope and boundary. Decide which system, subsystem or process is being examined. A block diagram of the parts and their flows is a good starting point, and the same care about system boundaries applies.
2. List functions. Work through each block or step and write what it must do.
3. List failure modes for each function. Ask “what if it does not happen, happens too much, too little, too early, too late, or at the wrong time?”
4. Describe effects of each failure, including on neighbouring parts and on the end user.
5. Identify causes and existing controls.
6. Score and prioritise (described below).
7. Decide actions, assign owners and later re-score once the actions are done.

The work is best done as a group discussion with people who know different parts of the design, including those who will build, test and maintain it. A single author working alone tends to miss the failures that sit between parts.

Scoring and prioritising

Many teams score each failure on three scales, often 1 to 10, where higher means worse:

• Severity (S): how serious the effect is.
• Occurrence (O): how likely the cause is to happen.
• Detection (D): how hard it is to catch the problem before it reaches the user. A high number means poor detection.

Multiplying the three gives a risk priority number, RPN = S x O x D. The following is an illustration with invented scores for a hypothetical battery-powered device.

Checking the arithmetic: 5 x 6 x 2 = 60; 9 x 2 x 8 = 144; 8 x 3 x 4 = 96. Ordered by RPN, the overheating cell comes first, then the stale display, then the connector.

Notice what the scores do and do not say. The connector failure is the most likely, but it is the least severe and easy to detect, so it ranks last. The overheating case is rare but severe and hard to detect, so it ranks first.

Cautions about scoring

The number is a convenience, not a measurement. Several well-known weaknesses are worth keeping in mind.

• Different combinations can give the same RPN while representing very different risks. A severity of 10 with low occurrence and detection scores might equal a mild problem that occurs often.
• Scores are judgments, and teams can disagree. The discussion that produces the score is often more valuable than the score itself.
• Because severity matters most where people could be harmed, many teams look at severity separately and address high-severity items regardless of the RPN.
• Scales need written definitions, so that “7” means the same thing to everyone, and they should be applied consistently.

For these reasons, treat RPN as a way to start a conversation about priorities, not as a threshold that decides what is safe. Hazard-related decisions belong with qualified people and applicable standards. Related ideas appear in hazard identification and in the hierarchy of controls.

Making the analysis useful

• Start early. An FMEA done while the design can still change is cheap to act on. Done after release, it mostly documents risks that are hard to remove.
• Use real history. Past incidents, returns and test failures are better inputs than imagination alone. Learning from engineering failures elsewhere can also suggest failure modes you might not have thought of.
• Keep it alive. Revisit it when the design changes, when testing finds something new, or when field experience arrives. A table filed and forgotten becomes another form of stale documentation.
• Link actions to the design. Each high-priority item should lead to something concrete: a design change, a margin, a test, a warning or a procedure. An analysis with no actions has not done its job.
• Avoid blame. The point is to expose weaknesses in the design, not to judge the people who designed it.

Limits of the method

FMEA works from a list of known parts and known failure modes, so it is weaker at finding failures that come from interactions among many parts, from unusual operating conditions, or from things nobody thought to include. Pairing it with system-level thinking, such as tracing flows and interfaces, helps cover some of that gap. It also relies on honest scoring, which can be hard when schedules are tight.

Used with these limits in mind, FMEA gives a team a shared, written view of how a design might fail, and a reasoned order in which to deal with the possibilities. Outcomes always remain uncertain, and no analysis can promise a failure-free product.