The FMEA Trap: When Risk Analysis Tools Become Risk Theater
Strategic Insights, October 2025 ed.
Most engineers think tool selection is about the problem. It’s actually about the decision stage. Front-end = discovery tools. Back-end = decision tools. Mismatch = theater.
Teams often use sophisticated risk tools as security blankets when what they really need is decision clarity. The tool becomes a substitute for hard conversations about ownership and trade-offs. If we shouldn’t reach for the risk tool we love, how should we analyze risk to help us make decisions?
The Misapplication of FMEA and the Ownership Problem
A frustrated engineering team came to me looking for help with Failure Mode and Effects Analysis (FMEA). They were struggling to complete their FMEAs and had hit a wall.
The Problem They Had
The core issue wasn’t the FMEA process itself. It was a critical design decision they were trying to make. They had used a 3D-printed prototype to test a design concept. The prototype worked, but the 3D-printed part was an obvious weak link.
The team already knew the risk: the 3D-printed material and process would not be suitable for final production. Now they faced execution decisions:
What should the final material be?
What manufacturing method should they adopt?
Would this change force a complete re-validation?
They had a critical unknown with low confidence in their ability to select the right solution.
The Tool They Chose vs. The Tool They Needed
The team chose FMEA, a tool excellent for systematically uncovering potential failure modes that might be unforeseen.
Yet, the major risk was already known. They didn’t need FMEA to identify the weak point; they needed a simple Risk-Based Decision Framework to resolve the known weak point and move forward. They were trying to force a known problem into the rigid structure of an FMEA when they should have been focusing on designing minimal, focused tests to close the information gap. They were documenting the risk instead of managing the decision.
Could an existing FMEA have helped? Only if they’d already completed one during concept development. Past FMEAs can be intelligence sources—reviewing impact data, causes, and controls might reduce uncertainty about current decisions. But this team didn’t have one, and creating a new FMEA from scratch wouldn’t resolve their immediate execution question.
Still, there are other ways to manage risks in a project that would’ve suited them better.
The Deeper Issue: Ownership and Politics
There were other reasons the team was stuck. The questions about Design FMEA versus Manufacturing FMEA weren’t actually about risk analysis structure—they were a symptom of a deeper problem: ownership.
The critical failure they were trying to document (the weak prototype material) straddled the line between engineering design and manufacturing validation. The team couldn’t agree on whose budget, process, or ultimate responsibility it was to spend the time and resources necessary to close the gap and select the final production method.
The FMEA became a political battleground used to justify or assign blame, rather than a collaborative tool for risk reduction. The issue wasn’t how to analyze the risk, but who owned the problem to solve.
What the Team Actually Needed
Instead of FMEA, the team needed a simple framework to answer three questions:
What’s the impact if we choose the wrong material? (Timeline delays, cost overruns, revalidation requirements)
How confident are we in our current approach? (Low—maybe 40%)
What evidence would increase our confidence enough to proceed? (Material testing, FEA analysis, supplier consultation)
This is risk-based decision-making, but it’s not FMEA. It’s the Impact vs. Likelihood Matrix I covered in this month’s AMA post—a tool designed for known unknowns during execution, not comprehensive failure mode identification.
The team was trying to fit a known problem into the wrong tool structure. Here’s how to avoid that trap...
When risk analysis becomes documentation theater vs. actual decision support
In Pierce the Design Fog, I cover early-stage risk analysis. I cover tools like Symptom-Impact Model and risk estimates that help teams evaluate concepts before committing resources. That front-end work is critical: it prevents you from executing the wrong concept.
But once you’re past concept selection and into execution, you need different tools. The 3D printing team had already validated their concept. The design worked. Their challenge was execution uncertainty: material selection, manufacturing method, validation requirements. Front-end tools like comprehensive FMEA weren’t helping because they already knew the primary risk.
You should get clearer about risks by doing a risk analysis. If it feels like you’re trying to fit or force your information to fit into a tool, then stop and consider that maybe it’s the wrong tool.
Red Flags You’re Doing Risk Theater, Not Risk Management:
✗ The risk analysis document is growing, but no decisions are being made
✗ Team members can’t agree which type of analysis to use (symptom of ownership issues)
✗ You’re analyzing risks everyone already knows about in detail
✗ The analysis deadline keeps slipping but the project isn’t blocked
✗ Management asked “Have you done an FMEA?” so you’re doing one, even though it doesn’t fit
What real risk management looks like:
✓ Analysis reveals a decision that needs to be made
✓ The analysis directly informs resource allocation (test budget, timeline, design changes)
✓ Team alignment improves because assumptions are now explicit
✓ You can articulate what evidence would change your risk assessment
Tools for risk assessments
Every risk-based decision needs three pieces of information:
Scenario: What could go wrong (or right)?
Impact: What happens if it does?
Likelihood: How confident are we in our current approach?
How to Choose the Right Risk Tool
Before reaching for a familiar tool, ask three questions:
1. Do I know what the risks are, or am I searching for hidden ones?
Searching: Use FMEA, HAZOP, PHA (discovery tools)
Known risk: Use Impact/Likelihood Matrix, Expected Value, Fault Tree (decision tools)
2. What stage am I in?
Concept/early: Use broad, qualitative tools (Symptom-Impact, Risk Index, PHA)
Execution/late: Use focused, quantitative tools (Impact/Likelihood, FTA, Expected Value)
3. What decision am I trying to make?
Which concept to pursue: Symptom-Impact Template, Risk Index
How to validate this design: FMEA, Impact/Likelihood Matrix
Is this specific failure scenario likely: Fault Tree Analysis
Should we proceed given cost/uncertainty: Expected Value
Match the tool to the question, not the question to your favorite tool.
Here’s a reference guide for the most common risk analysis tools. Notice the pattern: early-stage tools cast a wide net (FMEA, HAZOP, PHA), while late-stage tools focus on specific decisions (Impact/Likelihood, FTA, Expected Value). The 3D printing team was in late-stage execution but reached for an early-stage tool—a mismatch that created frustration without resolving their decision.
In most cases, these tools help you to better understand the risk scenario, its impact, and likelihood and reduce your own uncertainty about it. For early stages, they often don’t have an acceptable cut-off value. Rather, you’re identifying, analyzing, and evaluating what risk-inducing scenarios the team should be focused on reducing first. These early tools are combined with Risk Indexes and RPNs (Risk Priority Numbers), which do help you make decisions on what actions to take next. Eventually, you’ll need to decide if the level of risk that remains is acceptable, or if you need to do more.
Example: using the Right Tool (Fault Tree Analysis)
I was the quality engineer on a team where there was a potential problem with electromagnetic interference. The impact was apparent. But the chances of it happening was dependent on the situation and environment. They wanted to better understand how likely it could be, and to identify the combination of situations that could lead to it to further reduce risks, if possible.
To help us evaluate these risks, we used a Fault Tree Analysis with and/or gates. We used this tool to identify scenarios that could lead to this problem, and understand how likely they were to happen. We did research and interviews to understand the real problem. And, the Fault Tree Analysis came to help the team make decisions.
It was the right tool because it fit the scenarios we were struggling with, and it helped us better understand the impact and likelihood of our situation.
Back to the 3D Printing Team
The tool the 3D printing team actually needed? The Impact vs. Likelihood Matrix I introduced in this month’s AMA post. It’s designed specifically for this situation: known risks during execution and a decision that needs to be made now, not after weeks of comprehensive analysis.
They would map it as high impact (mold costs, timeline, revalidation) and low confidence (40% sure of material choice). Then design targeted tests—material property comparison, short-run prototypes, FEA validation—to move confidence from 40% to 75%+.
That’s risk-based decision-making. The analysis takes hours, not weeks. The testing is focused, not comprehensive. And the decision gets made, not documented.
The trap isn’t using risk tools—it’s using the wrong risk tool and calling it rigor.
What’s next for you?
Examine your risk analysis portfolio. Are you reaching for FMEA by default? Could some of your stuck projects benefit from simpler, more focused decision frameworks? The table above is your starting point—match the tool to the problem, not the problem to your favorite tool.
And if you’re facing a Critical Unknown like the 3D printing team, check out this month’s AMA post on the Impact vs. Likelihood Matrix. https://open.substack.com/pub/qualityduringdesign/p/frame-it-how-to-scope-high-stakes
Book readers: I’m running a dedicated Pierce the Design Fog Q&A week in mid-November for questions about ADEPT, Concept Space Model, and concept development facilitation. Mark your calendars - I’ll announce dates soon.