The Good DFMEA The Bad DFMEA and Ugly Outcomes

Picture of Adam Bahret
Adam Bahret

If you finish the Design Failure Mode Effects Analysis (DFMEA) before the product is out in the field, you have made a horrible mistake. The worst DFMEA that can occur is one that is completed and filed away mid-program. A high value DFMEA is a live tool that has both inputs and directive outputs throughout the program. A tool that is interwoven into the day to day activity of the program.  The DFMEA drives actions and aids decisions both technically and in project management.  It is updated with design changes that change risk and mitigative strategies.

I have always said that at it’s core it is a project management tool, directing resource to areas of greatest risk to success.  The key to this is shared ownership.  The project managers have to incorporate it into their other management tools.  The engineers have to incorporate it into their design history and actions tools.  Reliability has to incorporate it into their test program structure.

DFMEA’s done incorrectly is something you hope your competitors do.  It is truly the poster child of a double edged sword.

A DFMEA incorporated into the program incorrectly will

  • Absorb valuable team resource in long meetings that not only waste time but lower moral
  • Create conflict within the team that carries into other program activities.
  • Direct team engineering efforts to areas of low value

A well implemented DFMEA will

  • Require almost zero extra man power compared to a program without a DFMEA
  • Aid efficiency to important program tasks
  • Keep resource aligned with program and product objectives.
  • Ensure that previously unidentified areas of risk are brought to the center stage early and may be addressed.

The factor that surprises many of my customers is when I state that a DFMEA uses zero resource.  This is a shock to teams who have experienced them as an endless pit of resource drain.  The reason I can confidently state this is because if a DFMEA is done correctly it is simply formalizing activities that already occur.  These are

  • Teams evaluating risk. This happens in design reviews, by the water cooler, and late at night when concerned team members are trying to fall asleep.  It often occurs as an iterative process with many important individuals not included in critical conversations.  I have seen entire initiatives start from a conversation in the hallway.  If Joe hadn’t happened to be passing by in the hallway and overhear a conversation then the opportunity would have been missed.
  • Project Managers trying to prioritize resource allocation. Historically PM’s have a hard time getting into the “den” where the deep technical talk happens.  By engaging in the deeper technical discussion with the technical leaders they will have a better understanding on how their allocation decisions affect the design and it’s efficient development.

These are all simple steps that when implemented turn a dangerous sword into your best weapon.  Let your competitor swing it around wildly and cut themselves and everyone else around them up.



Share this post