DFMEA & DVP&R

Intended Audience

This class is intended for all product designers and New Product Introduction coordinators who lead design teams.

​

Description 

Design Failure Modes & Effects Analysis and Design Verification Plan & Report: This is a two day practitioners course typically held from 8:00 AM to 4:00 PM each day. You will learn so much in this jam packed course you will feel like you are the expert and extreemly well prepared to find value in your next DFMEA. Taking this course is the first step in qualifying the practitioner to be certified as a DFMEA Practitioner.

​

What is FMEA? 

Failure Modes and Effects Analysis is a systematic approach to the analysis of complex products and processes. It helps teams evaluate the risks associated with the various requirements of the product or process being evaluated. It is a methodical and mechanical approach used to identify and quantify risk so the team can take action. There should be no “brainstorming” or imaginary methods of discovering risk if done properly, and this class shows you how. FMEA takes the guesswork out of finding risk and leads the team to consistent results quickly.

​

Instructor:

The class is taught by an FMEA subject matter expert with over 20 years of experience. The instructor is engaging and passionate about FMEAs and has traveled the world teaching and showing practitioners how to find the value of both Design and Process FMEAs.

​

DFMEA & DVP&R

Objectives and intended outcomes: Upon successful completion of the course participants will be able to:

​

• Determine if an FMEA needs to be done and to state the specific objectives of each FMEA

• Create a Boundary Diagram that logically limits the scope of the DFMEA

• Identify and label the Requirements of the design

• Review and drive concessus regarding the scope of the DFMEA

• Complete an Interface Analysis

• Quickly fill in the FMEA and ready it for discussion before the team is ever assembled

• Create an FMEA agenda and assemble the tema members relevant to the agenda

• Define and prioritize risk

• Iterate Boundary Diagrams to reflect risk mitigating design changes and analyze those changes for potential failure modes

• Understand the fundamental definition of a Special Characteristic and assess if the design has any

• Understand how to mitigate Special Characteristics from a design perspective

• Engage the team in proactively solving risk priorities

• Follow up on risk mitigation 

• Develop a Design Verification Plan and Report and directly link it to the risk requiring Verification found in the DFMEA

• Report out to leadership on the findings and value of each FMEA

​

Prerequisites: 

This workshop focuses on the skills development and assumes those attending possess experience and understanding of design review and New Product Introduction processes, and have participated in continuous improvement teamwork. In lieu of direct experience, it is strongly recommended that learners have a degree in a higher education such as an engineering degree, and some leadership skills in team dynamics.

​

Can’t FMEA get you into legal trouble if the product fails?

It is a common misunderstanding that if you write down a risk you know about you are setting yourself up for legal troubles. Litigation does not happen because a company employee writes down a risk in an FMEA. Litigation happens because a product fails and pain or distress is inflicted. I work with legal departments regularly, and have found lawyers enjoy working with companies that do FMEAs correctly, because they are doing their due diligence in finding and eliminating risk. This makes them easier to defend if litigation does occur.

​

On the other hand lawyers dislike trying to defend a company that ignores FMEA, does FMEAs incorrectly, or worse those who try to omit or mask risk they have discovered. It takes a lawyer absolutely zero effort to de-mask a “thermal event” as a fire. Additionally employees have been known to use the FMEA as leverage to fulfill a personal agenda by exaggerating a failure into a safety issue. Luckily proper training in the rules of FMEA development will show you how to easily spot these exaggerations and limit them to their true effect. In short, both ignoring risk and exaggerating risk can get you into trouble. Only addressing the risk and using plain English to describe it are appropriate courses of action.

​

Are FMEAs required by Quality Systems?

The FMEA is the single most effective tool to proactively avoid problems before they get into your product or service. Because of this, Quality Management Systems will call out the need for your company to have an analytical method to ensure potential problems are considered and addressed. Some Quality Management Systems (QMS) will specifically call for the use of the FMEA while others will only reference it. However all QMS accept FMEAs as that analytical method.

​

Companies who choose to create their own analytical process often run into great difficulty in the implementation of their method, or find they are later forced to migrate to an FMEA standard. This is primarily because companies do not act alone in their risk mitigation efforts. All companies have both suppliers and customers. Sometimes the migration is required by the customer. While other times the company finds it far too expensive and time consuming to teach their home grown method to all of their suppliers.

​

When do we do the DFMEA? 

The FMEA is a proactive process. It is intended to identify, document and take action to limit or stop potential failure modes before they occur. This risk identification process drives the design team to know their design well, before it is physically created. Therefore it is important the FMEAs are started as early as possible. The timeliness of the DFMEA is a major contributor of the value of the DFMEA process. If the FMEAs are created late in the design process, the window of opportunity to complete the necessary risk mitigating actions become more constricted, and the costs of implementing those risk mitigating actions become more expensive.

​

It is important to recognize that when we design a product, we also design in all of the potential failure modes. The failure modes exist in the product whether we recognize them or not. They are there in the product just waiting for the right circumstances to trigger the failure. The purpose of the FMEA process is to acknowledge these failure modes exist, that there is risk associated with them, to systematically find them, quantify the risk associated with them, and to take action to mitigate those with significant risk.

​

Those organizations which do not have a systematic FMEA process find themselves in a state of constant reaction, often struggling to determine when an FMEA is needed and when it is not. If they are lucky, failures manifest themselves in the prototype and pilot phases of the design process, and in the customer’s hands if they are not.

 

It is the goal of the FMEA process to find these failure modes and their associated causes as early as possible. By doing so the design will be better conceived, create less reactive work late in the design cycle, and save the company and its customers money in late failure mode countermeasure development. The best way to find failure modes as close to their creation date as possible is through the FMEA process.

 

Do FMEAs have dependencies?

FMEAs are created to identify risk, so there are many things which depend on the FMEA. If the DFMEA is properly completed it will reveal exactly what you need to test and do to prove your design meets its intent. We call this FMEA extract a DVP&R which stands for Design Verification Plan & Report. Additionally the DFMEA will point you to those things which make your design hard to manufacture. We call these difficult to manufacture features Special Characteristics. So Special Characteristic identification depends on a properly executed DFMEA as well.

​

Are FMEAs dependent on anything?

Naturally FMEAs do have some dependencies. Since the FMEA is a process in the documentation of risk, it is important to understand how risk is defined and exactly what you are assessing. FMEAs start with the assessment of Requirements, so good requirements are required in order to perform the FMEA correctly. Thankfully we have tools like the Boundary Diagram and Interface Analysis which are part of the FMEA process, and help us identify exactly what those requirements are.