Your DFMEA review is defending the design, not probing it.
Engineers building a DFMEA on a product they designed will understate risk. That's a failure mode, and it isn't in anyone's DFMEA.
Give an engineer a competitor's product and they'll find ten things wrong in minutes. Their own gets handled with kid gloves. Then the DFMEA review is led by, you guessed it, the engineer who owns the design, and the review becomes a defense of the design instead of a probe of it.
The effect is predictable: issues that become visible at the worst possible time.
Why it happens
Economists call it the endowment effect: we value something more simply because it's ours. In the best-known experiment, people given a coffee mug asked roughly twice as much to sell it as other people were willing to pay for the same mug. Nothing about the mug changed. Only who owned it.
A design is a much bigger possession than a mug. It's months of work, dozens of decisions you defended in reviews, and a reputation. There's a second, related bias on top of that, the IKEA effect: we overvalue things we built ourselves. A designer reviewing their own design has both working against them.
None of this is a character flaw. It's how people are wired, and good engineers are not exempt. That's exactly why it belongs in the process, not in a pep talk.
Where it shows up in the DFMEA
It rarely looks like bias. It looks like reasonable judgment, one row at a time:
- Severity talked down. "The user would notice before it got that bad."
- Occurrence scored low. "We designed that out with the rib." The rib is the design being defended.
- Detection credited generously. A test that has always passed gets counted as a control that would catch the failure.
- Failure modes never written. The most expensive effect, and the hardest to see. The designer decides where to look, and nobody goes looking for the problems they don't believe exist.
The last one matters most. A low score can be challenged in the review. A row that was never written can't be challenged, because nobody knows it's missing.
The usual fix starts too late
The standard answer is a cross-functional team: bring in quality, manufacturing, reliability. That's right, but timing decides whether it works. Too often those people arrive at the review, after the designer has drafted the DFMEA.
By then the draft has set the frame. Reviewers edit the rows in front of them: tweak a score, sharpen a cause. That's anchoring bias at work. The starting document defines what gets discussed, and what isn't in it rarely comes up. Bringing quality in as a reviewer rather than a builder limits what they can contribute.
The independent perspective has to be there while the DFMEA is being built, not only when it's being reviewed.
What you can do about it
- Build it cross-functionally from the first row. Get quality, manufacturing and test into the room before anything is drafted, not after.
- Separate the author from the owner. Have someone other than the designer lead the session or write the first draft. The designer's knowledge is essential; their role is to answer questions, not to choose them.
- Make the review a probe. Give the review an explicit job: find what's missing. Ask "what else could this do?" before "is this score right?"
- Audit the process, not just the product. Pull your last ten field failures and open the DFMEA signed before launch. Count how many are in it. Teams run FMEAs on their products all the time; almost nobody runs one on the risk process that produces them.
Where RiskForge fits
This is one of the reasons I built RiskForge. It works out the first draft from the product's own materials, geometry and conditions of use, and it has no stake in the design. It doesn't remember defending the rib. Your designer's expertise still decides what ships: they review, amend and own the result. What changes is who sets the starting point, and the starting point is where anchoring does its damage.
How are you ensuring objectivity in your DFMEAs?