*) DFMEA stands for Design Failure Mode and Effects Analysis and is a type of FMEA that analyses errors in the product design, design development process.

When I talk or read about the practical application of the DFMEA, I often come to the conclusion that everyone understands its importance, has heard that it works well somewhere (the example of the aviation industry often comes up here – I wonder if it is right…), but exactly in this particular project we are talking about or in this particular company, the approach to the DFMEA is different and finally the DFMEA document exists… But its value is not very high. 

Once production has started, no one looks at it, unless someone writes ‘review and verification/update of the DFMEA’ into the post-production corrective plan (claim), or the client or auditor asks during an audit… Arguments often quoted to explain this state of affairs include: lack of time in the project, difficulties in completing the various categories (failure, occurrence, detection),  and estimating risk levels. 

There is positive news. Most people (whom I have met) involved in product development are aware that this document should be important. So what can be done to make it so?

Let’s consider for a moment what is the main goal of a new product design team? Looking from the organization’s perspective, it is to deliver the product to the market within the set time, budget and quality. In practice, this usually boils down to choosing the best idea (see article “Recipe for a good idea”) for a product and then making that vision a reality by preparing the necessary documentation. What I am getting at is that the main challenge, from the very beginning to the end of the project, is risk management. At the outset, it is about identifying all the risks (technical, commercial…), then planning how to eliminate or minimize them in order to ultimately bring a product to market with an acceptable level of risk. 

If this perspective is taken, the project team needs tools to identify, manage and minimize risks. An FMEA is just such a tool. In this article I focus mainly on DesignFMEA (DFMEA) but ProcessFMEA (PFMEA) is virtually the same tool focused on the manufacturing process. 

So how to combine these three elements?

• awareness of the importance of the DFMEA
• the need for risk management
• the use of the DFMEA as a practical tool for defining project tasks.

The first and most important step is to put the DFMEA at the center of project management. I do not mean a visual presentation as in the illustration below (although it certainly helps) but, above all, the real use of this tool when planning the next project tasks.

We can group these tasks in the following way. This is just a suggestion to help further describe how to effectively support each of these areas when working with DFMEA. 

Group 1 – Technical requirements

Group 2 – Test scenarios (laboratory and FEA)

Cognitive tests

Verification tests

Group 3 – Test specifications

Group 4 – Test equipment

Group 5 – Special characteristics

Group 6 – Technical drawings

Group 7 – Recommendations for the production process

Group 8 – Technical specifications

Visually, this can be represented as follows:

Each group (1-8) is linked to the DFMEA by two arrows: input data (orange) and output (green). During the DFMEA meetings, the team defines the need that needs to be realized in each group (these are the orange arrows symbolizing the input to the activity). Once the task has been completed, the team returns to the DFMEA analysis with the result obtained (these are the green arrows symbolizing the outputs) and decides whether to change or maintain the associated risks. 

The process of generating inputs and outputs continues as long as the value of the risks is at an unacceptable level for the organization. This approach allows a clear criterion for the completion of project work to be defined. Sometimes the project team is not able to clearly declare when the end of their work will occur – after all, something can always be improved or done a little differently… The assessment of the level of risks is very helpful here and, despite its subjective nature, can be an objective criterion for the end of project work. It is also easy to build a project KPI based on this criterion.

It is worth noting that this way of working is only possible when the technical solution has already been defined. This means that the team knows what the product will look like, is able to visualize it (sketches, 3D models, technical drawings) and its key functionalities are known.

Below I have provided some examples of what project management might look like using DFMEA as the main tool, giving direction to product development. I refer to the groups suggested earlier. My focus is not on how to complete the DFMEA worksheet. This is a skill that can be acquired in training and, like any competency – needs to be practiced. My aim is to show how DFMEA meetings can be used to plan essential project tasks.

Imagine a team considering what technical requirements (group 1) a product should meet. However, this process is not just about building a list, but thinking about the risks of the product not meeting these requirements. 

A company plans to launch a product that must be rust-resistant. The requirement may be regulatory (imposed by law) or driven by customer expectations. Depending on how severe the appearance of rust will be for the Customer, the team will assess the risk with the appropriate level of indicator. The most interesting part, however, is the search for reasons for the appearance of rust.

The first reason: the wrong material was used. 

I encourage you to specify potential reasons in such a way that they are objectively verifiable. In this case, it could be, for example: a material was used that does not meet the quality criterion outlined in the XYZ standard after a salt chamber test according to the ABC standard. A reason defined in this way is easily verifiable. The first definition of unsuitable material in no way brings the team any closer to eliminating this risk. Of course, it may be that the team does not know which standard to perform the test according to. And this is the point at which the DFMEA meeting becomes a design task planning meeting for test specifications (group 3). In this case, the task is: Identify salt chamber test standards in line with the expectations of the target clients. 

Second reason: the product has been misused.

Another example of a vague definition of a potential reason, which could be formulated, for example, as follows: the product has been exposed to direct moisture (above 80%). If the product has to be kept under cover or in a closed room, this information must be included in the product specification (group 8) that the customer receives. 

At this point, it is worth considering how we want to limit the use of the product? If we need to ensure a certain period of time in which the product should be resistant to moisture, then the potential risk reason should be written as follows: the product has been exposed to direct moisture (above 80%) for more than 24 hours.  A reason defined in this way can be explicitly tested and verified. If the team feels that the previously defined salt chamber test is inadequate to verify this reason for occurrence, they should propose another test. However, if there are doubts as to what this test should be, we have just defined another design task from Group 8.

It is worth considering one more aspect when planning salt chamber tests. Due to the design of the product, it may be necessary to design and manufacture a stand that will provide adequate orientation during the test. If so, the team should plan to make a test equipment (group 4).

Another reason for the risk: unprotected machined edges will not meet the ABC standard of the XYZ test. 

Described in this way, the reason for occurrence seems quite precise… However, knowing that unprotected edges will rust, it is worth considering the form of protection right away and changing the definition. For example, like this: Hot-dip galvanizing according to the VYZ specification does not protect the treated edges so as to meet the ABC standard, a test made according to the XYZ standard. 

The galvanizing specification should be included in the product drawing (group 6) and be marked as a special characteristic (group 5). A reason for occurrence thus defined, in the event that the test evaluation criteria are not met, immediately leads the team to verify the galvanizing specification or to define another protection. 

The precision of the descriptions makes it possible to ensure that the method of verification of the reason for occurrence, chosen later, clearly leads the team to the next step, i.e. verification of the risk level after the test results have been received. 

It may happen that the team is not experienced in this type of process and does not know which corrosion protection to define on the drawing. In this case, a cognitive test scenario (group 2) can be planned by making prototypes protected with different technologies. Once the results are obtained, it is known which protection is most likely to meet the test conditions. It is also the basis for changing the risk level to a much lower one, and part of the recommendation for the production process (group 7). 

The example above shows that a properly moderated DFMEA meeting is the place where, by analyzing the risks associated with product design, we naturally define the next steps in the project. Steps that identify further risks, plan methods to verify them and are focused on minimizing them – which is the goal of the project. 

By analyzing just one risk and several potential reasons for its occurrence, the team defined tasks in each of the eight identified groups. And this is no coincidence. This will be the case in the analysis of each subsequent risk. 

For this to happen, one just has to remember to keep the moderation of each meeting focused on a precise description of the risk and the reasons for occurrence, for which a precise action will be defined, after which the risk level will be easy to verify/modify.