DFMEA buy-in strategies for Design Engineers

[Ninja]

Certainly...always...

I guess the clearest way I can say it is how closely related I view:
1. "The significant problems we face, cannot be solved using the same level of thinking we used, when we created those problems "
2. "Design Engineer should be leading the effort {of dFMEA} " and
3. Auditors auditing their own work.

Can it be done? Sure.
Can it be done objectively? Sure, and should be.
Can it be done objectively by the person intimately involved? Sure...but it's a lot harder.
IMO, dFMEA is best done by an outside person, just like auditing...and for the same reason.
Can it work some other way and still be effective? Sure, but as you say, it depends on the person.

 

[Jim Wynne]

Certainly...always...

I guess the clearest way I can say it is how closely related I view:
1. "The significant problems we face, cannot be solved using the same level of thinking we used, when we created those problems "

We aren't talking about creating problems; we're talking about creating products. The quote isn't apropos to the situation. As I said earlier, regardless of who runs the meetings, the impetus must come from the top, and when that happens it doesn't make much difference.

 

[Ninja]

Fair enough.
I see it as apropos since the "F" in dFMEA stands for "Failure". You already knew that, so I guess we just look at it differently.
To my eyes, the main purpose/benefit of performing dFMEA or pFMEA is to identify problems (potential failures) that might but have not yet occurred.

When I design something, considering how it might fail is part of the design idea...and designed around to prohibit/mitigate it.
All of the things (at least the vast majority) that would be failure modes I think of have already been handled by the time dFMEA comes around.
All the more reason to have another pair of eyes leading the effort. IMO, the designer should be a participant...just not the leader.

I can't say you're wrong...this is just two different ways of going about the same thing. The donuts get made either way.

 

[Jim Wynne]

Fair enough.
I see it as apropos since the "F" in dFMEA stands for "Failure". You already knew that, so I guess we just look at it differently.
To my eyes, the main purpose/benefit of performing dFMEA or pFMEA is to identify problems (potential failures) that might but have not yet occurred.

When I design something, considering how it might fail is part of the design idea...and designed around to prohibit/mitigate it.
All of the things (at least the vast majority) that would be failure modes I think of have already been handled by the time dFMEA comes around.
All the more reason to have another pair of eyes leading the effort. IMO, the designer should be a participant...just not the leader.

I can't say you're wrong...this is just two different ways of going about the same thing. The donuts get made either way.

FWIW, I was involved in training design engineers on the DFMEA process in the design center of a large company, and it was made clear from the top that (a) the process would be properly executed and (b) design engineers would be responsible for getting it done. Of course it was viewed by several as useless extra work, and the initial iterations were done under guidance from me and a few other knowledgeable people, but responsibility did get handed off to the design engineers and it was executed properly.

 

[Ronen E]

it was made clear from the top that (a) the process would be properly executed and (b) design engineers would be responsible for getting it done. [...] it was executed properly.

Sounds to me more like a brutal exertion of force than an inspiring leadership. From a more lighthearted perspective, it reminds me the scenes from Star Wars where a Jedi comes to a potential opponent, lightly waves a hand in the air and says "You will cooperate..."
Sure it got done... but did it add value? Did it add all (or most) value it could? It's quite easy to tick a box, to do something "properly", but if your heart (or mind in this case) is not in it, it is going to be mostly a waste.

 

[Watchcat]

Design Engineers design, other people do paperwork.

I usually work with design engineers designing medical devices. I always vote to let them choose the type of risk analysis (DFMEA, fault tree) that will be used. I am aware of the arguments for one over the other, but, IMO, this is in fact part of the design process, so it's not my call, it's theirs. I expect them to see the risk analysis as a key part of the design process, which they usually do, and therefore to take the lead, which they usually do. I don't expect them to see it as "paperwork," which they usually don't.

Based on this experience, I'm puzzled as to why someone would expect the design engineer to take the lead on a PFMEA. Why wouldn't that be the domain of a process engineer?

...it IS an added task from the quality department. If you want it done, do it yourself. Try to shove it on me, you better watch for sugar in your gas tank...

As I understand it, it's the new VP that wants this, not the quality department. In that case, I would expect my new VP to talk to the design (or whichever) engineer's VP and for the two of them to decide whether or not a DFMEA is needed and, if so, to also decide who is the appropriate person to do it, and then for that person's VP to take it to them.

 

[Ninja]

A good discussion, and "Thank you" to Jim for being open and clear about implementation and effectiveness by a completely different method than I propose.
...perhaps that's why I work only in small companies, and leave when big companies buy them.
Small and big companies do things radically differently on average...and preference seems to be the common thread through this, not effectiveness or right vs. wrong.

 

[Jim Wynne]

Sounds to me more like a brutal exertion of force than an inspiring leadership. From a more lighthearted perspective, it reminds me the scenes from Star Wars where a Jedi comes to a potential opponent, lightly waves a hand in the air and says "You will cooperate..."
Sure it got done... but did it add value? Did it add all (or most) value it could? It's quite easy to tick a box, to do something "properly", but if your heart (or mind in this case) is not in it, it is going to be mostly a waste.

Nobody knows for sure what "add value" means. As I said, it got done properly. If it's not clear that the impetus comes from the top, it will fail sooner or later. Part of leadership is ensuring that what needs to get done does get done.

 

[GRP]

Hello everyone,

I wanted to post about DFMEA implementation strategies. I am currently working at a defense contractor and our new VP wants to flow down APQP elements across operations. Within this includes DFMEA.

I believe (and from my past experience in the automotive world) that DFMEAs are a Design engineering tool which Quality can help facilitate, brainstorm failure modes and provide input regarding detection controls and occurrence levels. However, in order for the tool to be effective, the cognizant Design Engineer should be leading the effort and utilizing it in conjunction with their other designing efforts (3d modeling, testing, etc). Unfortunately at my organization, the onus is on me, the Quality Engineer, to lead the DFMEA effort on one of our new product designs. I have been sitting with the lead Engineer and completing the boundary diagrams with him, p-diagrams, and system level DFMEAs. My concern is that since this tool is not incorporated into his designing process, him like most of the engineers believe this is just an added task from the quality department. I don't believe DFMEAs can be affective with such implementation

What are some change management/buy-in strategies when it comes to DFMEAs and having them led by the lead Design Engineers? The perception that this is a Quality Engineer led tool is not value add. I am open to peoples other views if they don't agree with that statement as well.

Thanks

From the few DFMEAs I have worked on as facilitator I can say you don´t have to be a Lead Design Eng to lead the task.

Two key things mentioned by Jim Wynne: participants need i) training on FMEA and ii) they have to be willing to cooperate. The cooperation can come from an understanding of the tool -the DFMEA- or by pressure from management.

The owner of the DFMEA can be anyone trained in FMEA. I would not be surprised it is someone from quality. Make sure you are given sufficient time to perform the activity rather than trying to accomplish a quality job "in the sidelines". Here management support is key.

Just you and 1 design engineer might not be enough for a proper DFMEA. Depends on the context, product, if it is a carry-over, plus others. Books like Carlson´s Effective FMEAs recommend between 4-8 participants. The lower limit is to avoid blind spots, the maximum limit is to avoid entropy.
I have had some degree of success both with D- and PFMEA in tackling separate processes or aspects of design on a one-to-one basis.

I would suggest you create the DFMEA with as much content as you can and bring it partly structured rather than trying to work it up from scratch in the meetings.

Finally, to prep you for success and before you jump too deep into it think what will be the outcome of identifying a gap or shortcoming in the design:
will the outputs of the dfmea lead to an improvement in the design verification and validation or will they sit forgotten in a file that no one will look at?

 

[Ronen E]

Nobody knows for sure what "add value" means.

Oh, I do. At least I know what it means to me. I can even share my opinion if you're interested. You might disagree, but that won't negate my knowledge. It's more about a consistent system of definitions than about absolute knowledge.

If it's not clear that the impetus comes from the top, it will fail sooner or later. Part of leadership is ensuring that what needs to get done does get done.

I beg to differ.
I wholeheartedly agree that a clear drive from the top is essential for any lasting quality initiative. I also agree that ensuring decisions implementation is a pivotal part of management. I just don't see policing as part of leadership. To me real quality leadership is about inspiring and motivating staff at all levels to take responsibility for Quality, especially for the quality of their own work, because they understand how important it is to the success of the organisation and their own well-being (if it's not, that should be sorted out first).