Which Of The Following Is Not Accurate Regarding FMEA? You’re Missing This One Key Detail

What You Got Wrong About FMEA: Common Misconceptions and Myths

Let me guess — you've sat through an FMEA training, maybe even led a few sessions, and somewhere along the way you picked up an idea about how this tool works. Maybe someone told you something in passing. Maybe you read it in a procedure. And you've been operating on that assumption ever since Easy to understand, harder to ignore. No workaround needed..

Here's the thing: FMEA (Failure Mode and Effects Analysis) is one of the most widely used risk assessment tools in engineering, manufacturing, healthcare, and beyond. But it's also one of the most commonly misunderstood. I've seen teams spend weeks building FMEA documents based on fundamental misunderstandings — scoring things wrong, prioritizing the wrong items, or expecting results the tool was never designed to deliver.

This article is about clearing that up. I'll walk you through what FMEA actually is, how it works, and most importantly — the common inaccuracies, assumptions, and flat-out myths that trip people up. If you've ever been unsure whether something you "knew" about FMEA was true, this is for you.

What Is FMEA (Failure Mode and Effects Analysis)?

FMEA stands for Failure Mode and Effects Analysis. At its core, it's a structured worksheet — really a thinking process — used to identify potential ways a product or process could fail, understand what would happen if those failures occurred, and decide what to do about them before they happen Which is the point..

Honestly, this part trips people up more than it should Worth keeping that in mind..

That's the key part: before they happen. FMEA is a proactive tool, not a reactive one. You build it while you're designing a product or setting up a process, not after something breaks.

The analysis typically centers on three questions:

• What could go wrong? (the failure mode)
• What would happen if it did? (the effect)
• How likely is it, how bad would it be, and how soon would we catch it? (occurrence, severity, and detection)

These three factors get scored — usually on a scale of 1 to 10 — and multiplied together to produce a Risk Priority Number, or RPN. Here's the thing — higher RPN means higher risk. Simple enough in theory.

But here's where things get messy in practice, because the way people interpret and apply this varies wildly — and that's where the inaccuracies creep in.

Why FMEA Misconceptions Matter

Here's why this matters in the real world: when teams get FMEA wrong, they make bad decisions. They either ignore real risks (because they misunderstood the scoring) or chase low-priority issues (because they misread the numbers). Either way, resources get wasted and defects still make it to customers That's the part that actually makes a difference..

I've seen automotive suppliers spend months reworking FMEAs because they misunderstood what "detection" actually means. I've seen aerospace teams miss critical failure modes because someone assumed low severity meant "don't worry about it." These aren't obscure edge cases — they're everyday mistakes that happen because of the myths floating around about how FMEA works.

The stakes are real. FMEA is used in medical devices, nuclear plants, aircraft, automotive safety systems — places where getting it wrong doesn't just mean a warranty claim. It means people can get hurt Turns out it matters..

So let's clear some of this up.

How FMEA Actually Works

The Basic Structure

An FMEA is built around a worksheet with several columns. The main ones are:

• Item/Function — what component or process step you're analyzing
• Potential Failure Mode — the specific way it could fail
• Potential Effect(s) of Failure — what happens to the customer or system
• Severity (S) — how bad the effect is, on a scale (usually 1-10)
• Potential Cause(s) — what could cause that failure mode
• Occurrence (O) — how likely the cause is to happen (1-10)
• Current Controls — what you already have in place to prevent or detect it
• Detection (D) — how likely you are to catch the failure before it reaches the customer (1-10)
• RPN — Severity × Occurrence × Detection

You fill this out for every significant failure mode you can think of, then prioritize based on RPN Simple as that..

Design vs. Process FMEA

There are two main types, and people sometimes confuse them:

• Design FMEA (DFMEA) — analyzes potential failures in a product design. It looks at what could go wrong with the product itself.
• Process FMEA (PFMEA) — analyzes potential failures in the manufacturing or assembly process. It looks at what could go wrong with how you make the product.

Using the wrong type, or mixing them up, is one of the simpler mistakes people make. If you're analyzing a welding process, that's a PFMEA. If you're analyzing whether the weld joint design can handle vibration, that's a DFMEA Practical, not theoretical..

The RPN Calculation

We're talking about where a lot of the confusion lives. RPN = Severity × Occurrence × Detection. Each factor is scored from 1 to 10, where:

• Severity — how serious is the effect? 1 = no effect, 10 = catastrophic (safety issue, regulatory failure, total loss)
• Occurrence — how often does the cause happen? 1 = unlikely, 10 = inevitable
• Detection — how likely are you to catch it? 1 = almost certain to detect, 10 = almost impossible to detect

The numbers get multiplied, giving you an RPN between 1 and 1000. Teams then "action" items with high RPNs.

But here's what most people miss: RPN alone doesn't tell the whole story.

Common Misconceptions About FMEA

This is the heart of your question — what isn't accurate about how people think about FMEA. Here's what I've seen trip people up, over and over:

Myth 1: "High RPN Always Means Take Action First"

This is probably the most common misconception. Teams see an RPN of 300, panic, and throw resources at it — while ignoring a severity-10 issue with an RPN of 150 because the numbers look smaller.

Here's what's wrong with that: severity matters more than RPN. You can't "engineer out" a low-occurrence risk if the outcome is catastrophic. A failure mode with a severity of 10 (someone could die) is always a priority, even if occurrence is low and detection is high. The severity score is telling you something fundamental about the failure — and it's not something you can just multiply away.

Smart teams use severity as a threshold. Any severity-9 or 10 issue gets attention regardless of RPN. Then they use RPN to prioritize among the rest.

Myth 2: "Detection Is About Finding Failures After They Occur"

I see this one in almost every FMEA training I observe. People score "detection" based on how well they can find the failure mode after it happens — like inspecting a part to see if it's defective That's the whole idea..

That's not quite right. Detection in FMEA is about catching the failure before it reaches the customer. It's about your ability to detect either the cause or the failure mode during design, development, or production — before it causes an effect in the field.

If your detection control catches a defect at final inspection before shipping, that's a detection score of somewhere around 4-6 (depending on the scale you're using). If it only gets caught when the customer calls to complain — that's a 9 or 10.

The common mistake? On top of that, scoring detection based on how well you find the root cause after a failure has already occurred. That's not detection. That's reaction.

Myth 3: "FMEA Is a One-Time Activity"

You finish the worksheet, get it approved, file it away, and move on. Right?

Wrong. As you learn more — from testing, from production, from field data — you update it. FMEA is a living document. The whole point is that it's a tool for continuous improvement, not a checkbox exercise.

If your FMEA hasn't been reviewed in two years, it's probably wrong. In practice, processes change. Day to day, new failure modes emerge. Designs evolve. An outdated FMEA gives you a false sense of confidence.

Myth 4: "Low Severity Means Low Priority"

Someone sees a severity-2 issue and assumes it's not worth worrying about. But severity is about the effect on the customer, not the likelihood of fixing it. A low-severity issue that happens constantly (high occurrence) can still create massive cost, rework, and customer dissatisfaction.

Severity tells you how bad it is if it happens. It doesn't tell you whether it's worth fixing. You need to look at the whole picture — severity, occurrence, detection, and the cost of action versus the cost of inaction.

Myth 5: "FMEA Guarantees You Won't Have Failures"

This one is dangerous. It doesn't prevent failures. But " But FMEA is a tool for identifying and reducing risk, not eliminating it. Some organizations treat FMEA as if it's a compliance exercise — do the worksheet, check the box, and now you're "safe.It helps you make informed decisions about where to focus your energy.

If you build an FMEA and then don't act on it — or worse, act on the wrong things — you're not safer. You're just more confident in your own paperwork.

Myth 6: "You Have to Fix Everything with High RPN"

Here's a reality check: you probably can't fix everything. You have limited resources, time, and budget. The purpose of FMEA is to help you prioritize, not to give you a to-do list of 47 items that all say "fix this now.

Good FMEA practice means making engineering judgments. Sometimes you decide the cost of action exceeds the cost of the problem. Sometimes you accept a risk. Sometimes you mitigate it partially. That's not cheating — that's responsible resource management That alone is useful..

Myth 7: "FMEA Is Only for New Products"

People often think FMEA is something you do during new product development, and then you're done. But FMEA is just as valuable for existing products and processes — especially when something changes. In real terms, a new supplier. A new machine. In real terms, a revised process step. Any change is a reason to ask: "Could this introduce new failure modes?

Process FMEAs in particular benefit from ongoing review. As you produce more parts and learn more about what's actually going wrong, you update the PFMEA to reflect reality.

Practical Tips for Getting FMEA Right

If you're running an FMEA — or reviewing one — here's what actually matters:

1. Start with the customer. Every failure mode should trace back to an effect on the end user or the next process. If you can't explain what happens to someone who matters, the failure mode might not be worth including.

2. Use severity as a gate, not a suggestion. Any severity score of 9 or 10 should get immediate attention, regardless of RPN. Don't let the math override engineering judgment on safety-critical issues.

3. Score detection honestly. This is where optimism creeps in. Be realistic about your ability to catch failures. If your current control is "visual inspection by operator," that's probably a detection score of 5-7, not a 2 Practical, not theoretical..

4. Focus on causes, not just failure modes. A single failure mode can have multiple causes. Each cause gets its own occurrence and detection score. That's where the real insight lives.

5. Review and update regularly. Set a schedule — quarterly, annually, or whenever something changes. An FMEA that's never updated is worse than no FMEA, because it gives you false confidence But it adds up..

6. Don't chase RPN numbers. Use RPN as a guide, not a dictator. If something feels wrong — if a high-severity issue is getting ignored because its RPN is "only" 120 — trust your gut and escalate it anyway Turns out it matters..

Frequently Asked Questions

Does a low RPN mean I can ignore a failure mode?

No. Because of that, always look at the individual scores (S, O, D) before making decisions. Think about it: a low RPN could still represent a high-severity issue that just happens to have low occurrence and high detection. RPN is a ranking tool, not a go/no-go decision Simple, but easy to overlook..

And yeah — that's actually more nuanced than it sounds.

Can I skip FMEA for simple parts or processes?

You can simplify it, but skipping it entirely is risky. Day to day, even simple parts can fail in ways that matter to the customer. The depth of your FMEA should match the complexity and criticality of what's being analyzed — but some analysis is almost always better than none And it works..

What's more important: severity, occurrence, or detection?

Severity is usually the most important, because it represents the consequence to the customer and can't be changed by better detection or lower occurrence — it's inherent to the effect. But you need all three to make good decisions. A balanced view beats any single number.

How often should I update my FMEA?

At minimum, review it whenever something changes — a design revision, a new supplier, a process change, a new failure observed in production. Many organizations do formal reviews on a set schedule (annually is common). The key is that it should reflect your current understanding of risk, not what you thought a year ago Turns out it matters..

Is an FMEA the same as a fault tree analysis?

No. Both are risk analysis tools, but they work differently. FMEA is a bottom-up approach — you start with components or processes and work up to effects. Fault tree analysis is top-down — you start with a top-level failure (like "system doesn't work") and work down to find what could cause it. They're complementary, not interchangeable Worth knowing..

The Bottom Line

FMEA is one of the most useful risk tools we have — but only if you're using it correctly. That said, the myths and misconceptions I've covered here aren't academic. They're the reason teams waste time, miss real risks, and eventually lose faith in the tool entirely.

The short version: FMEA is a thinking process, not a paperwork exercise. So naturally, use it to prioritize, but don't let the numbers override your engineering judgment. Keep it current. And remember — it's there to help you make smarter decisions, not to give you a false sense of security.

If you take one thing away from this, let it be this: the worksheet is just the output. The real FMEA is the conversation you have about what could go wrong, and what you're going to do about it. That's where the value lives Not complicated — just consistent..