DFMEA’s definitely have a bad reputation as exercises that consume an enormous amount of time and unfortunately yield little value to the program.
And can be miserable to experience.
A quote from a customer “We aren’t going to do any more DFMEA’s because we feel a bit traumatized by the last round.”
I have also seen DFMEA’s be a cornerstone to a design program using its resources with surgical precision to improve the product.
I started to think about the differences between the ineffective and effective DFMEA’s. Here are some of the steps that I believe make the “good ones” GOOD.
Step one: Cleave the system. This is the process of breaking the product down into its major sub-systems by functionality.
If it was a toaster the cleave would result in
- heating system
- casing
- toast loading/unloading
- electrical system
- controls
Step two: Define the parameters for use cases. The way the product is going to be used in detail is critical for defining failures and the likelihood of occurrence.
Many extended debates (time wasted) can be due to team members have differing opinions on use case parameters. Define the use case and distribute it to the DFMEA team in advance of the first meeting. Allow enough time for responses and updates.
Everyone should arrive in agreement of the definitions.
Step Three: Failure definitions. What do the main failure modes look like? Is it a failure if the toaster “under-toasts” the bread? “What is burned?”Do we want to categorize failure modes by type?
A) Going to put us out of business: “Damage to household”
B) Warranty claim: “Damage to toaster”
C) Product did not produce: “Damage to toast”
D) Product completed process but poorly: “Toast dog will probably still eat” (i.e. change target market)
Step Four: Prep the team on the technology.
Not everyone invited (you created a multi-disciplinary team, right?) understands the product technology.
Wasting time during the DFMEA session syncing up everyone on technical details can significantly increase session length and boredom.
Not to mention these people won’t be able to contribute effectively until they understand these details and can participate in the discussion.
Step Five: Stop deep technical debates.
Discussions/debates between a few core people should be stopped. They should take an action to continue the debate/discussion off-line and return to the next session with the resolution for the team to consider.
There is no way quicker to get everyone to roll their eyes and open their email than to have a geek fest of hot debate that is over everyone’s head.
Step Six: All DFMEA matrix rows have actions to be executed/followed up on.
There should never be a high ranking line item that does not have an executable action with a delivery date. Just because the team is no longer meeting to complete the DFMEA doesn’t mean they are no longer a team.
All are accountable for actions assigned to them to all others who agreed it was a valuable action.
Give those guidelines a shot and see if DFMEA’s can become a valuable tool again…or for the first time?
Leave a Reply