W
wslabey
PFMEA Training and Learning
I guess I have to offer something to this thread. I have taught FMEA and created FMEAs for several years but I am still a student of the methodology and learn from everyone I do. I find the hardest thing for people to grasp is that a failure mode is a failure of function. So it all begins with defining the function of the design (DFMEA) or the function of a process step (PFMEA). Identifying functions of a product design or a process is really a challenge especially when team members assume the unspoken functions are too basic because "everybody knows" why that feature exists or why that process element is required. Sometimes this task reverts requires some basic value engineering training where we apply rules for creating a function such as it must begin with an active verb and end with an object (for example, the function of the fuel system on you car is to "store fuel," "accept fuel," "indicate fuel level." "protect fuel from a crash," etc. ).
It helps sometimes to use simple examples which may or may not translate based on the language differences.
Teaching FMEA IS NOT difficult. A 2 day FMEA course is almost an overkill it really can be done is day and half. However, good training requires three things:
1. Explanation of the topic
2. Illustration and
3. Practice (in a safe haven).
Illustations and practice are key. When training I use three common, everyday examples. Throughout the course a ballpoint pen FMEA is used for illustration. For practice, I switched to two other common, everyday examples. For DFMEA I used a mousetrap example and for PFMEA I used Making Popcorn (the old fashioned way on stove with a pot). Both were a safe haven for participants to practice, make mistakes and learn. It also permitted me, the trainer, to see when the breakout group conversations were going off base. Doing a real time (read real project) FMEA before knowing the FMEA concepts is troublesome because of the emotion that surrounds a specific project. Learning requires practice and mistakes from which to learn. The learning environment should be a safe haven so when mistakes are made they can be acknowledged by the person who made the mistake thereby enabling learning. If admitting mistakes is not allowed, no learning will occur.
REGARDING THE AIAG manuals.
They have the right content, but lack effective examples and the writing is somewhat opaque as is typically the case with most of the literature of quality function. Remember, that these manuals were written by a committee of quality specialists from the automotive OEMs.
I guess I have to offer something to this thread. I have taught FMEA and created FMEAs for several years but I am still a student of the methodology and learn from everyone I do. I find the hardest thing for people to grasp is that a failure mode is a failure of function. So it all begins with defining the function of the design (DFMEA) or the function of a process step (PFMEA). Identifying functions of a product design or a process is really a challenge especially when team members assume the unspoken functions are too basic because "everybody knows" why that feature exists or why that process element is required. Sometimes this task reverts requires some basic value engineering training where we apply rules for creating a function such as it must begin with an active verb and end with an object (for example, the function of the fuel system on you car is to "store fuel," "accept fuel," "indicate fuel level." "protect fuel from a crash," etc. ).
It helps sometimes to use simple examples which may or may not translate based on the language differences.
Teaching FMEA IS NOT difficult. A 2 day FMEA course is almost an overkill it really can be done is day and half. However, good training requires three things:
1. Explanation of the topic
2. Illustration and
3. Practice (in a safe haven).
Illustations and practice are key. When training I use three common, everyday examples. Throughout the course a ballpoint pen FMEA is used for illustration. For practice, I switched to two other common, everyday examples. For DFMEA I used a mousetrap example and for PFMEA I used Making Popcorn (the old fashioned way on stove with a pot). Both were a safe haven for participants to practice, make mistakes and learn. It also permitted me, the trainer, to see when the breakout group conversations were going off base. Doing a real time (read real project) FMEA before knowing the FMEA concepts is troublesome because of the emotion that surrounds a specific project. Learning requires practice and mistakes from which to learn. The learning environment should be a safe haven so when mistakes are made they can be acknowledged by the person who made the mistake thereby enabling learning. If admitting mistakes is not allowed, no learning will occur.
REGARDING THE AIAG manuals.
They have the right content, but lack effective examples and the writing is somewhat opaque as is typically the case with most of the literature of quality function. Remember, that these manuals were written by a committee of quality specialists from the automotive OEMs.
Last edited by a moderator: