Course 1: Design for Problems and Risk

Welcome to lesson four, which is called FMEA in product development. We'll be building on what we talked about in the first lesson with our symptom, problem, and cause and learning how to take it a step further and use that information to proactively make design decisions.

Here's what else we're going to learn in this lesson.

• You're going to be able to explain the whole reason why we do FMEAs and how it fits into the design development process.
• You'll be able to construct an FMEA table and start to populate it.

FMEA is an analysis tool for risk management and it's probably the most popular. There are different standards and regulations about risk management that use FMEA as the primary tool and there are different standards for various industries authored by those independent governing bodies.

• If you work in automotive or as a supplier of automobile components, you'll likely be following the “FMEA handbook” published by the groups AIAG and VDA.
• If you're working in the medical device industry, you'll be following the ISO 14971 standard.
• If you work in civil aeronautics, you may need to comply with ARP-4761 issued by SAE.

The list goes on!

My point is that FMEA is a universally recognized, useful analysis that teams are expected to be using during design development. An iterative FMEA table that's completed for a project is what is used to show some evidence of compliance against these standards and regulations.

The mistake that most often happens is that teams will do an FMEA, but it's done as a checkbox item. You have a bunch of regulators telling you that you need this document, so let's just put it together and get it on the books. But this is such a waste of a fantastic analysis tool! Us and our team are missing out if we don't approach FMEA as an input tool, not to mention it's doing the wrong thing too late in the design process. This only makes it more likely that we’ll be in uncomfortable situations where we think something bad could happen but there's nothing we can do about it because our product is already designed.

A disclaimer in this course: I'm going to teach you about the Universal FMEA methods and how they fit into product development process. We won't be covering the details that will set you up with compliant FMEA files or business systems for your industries. That's the next step that you or your management need to take with your company for the industry in which you work.

Explain FMEA purpose and how it fits into the design development process

Now, let's get into the real reason why we do FMEAs and how it fits into the design process. FMEA is traditionally considered a reliability tool, but some people also look at it as a quality tool. Generally, how it works is that a team of people get together, talk about the potential ways things could go wrong, give values to those ideas to turn them into quantitative information, then assign teams actions or activities to eliminate or control risks. The end result of an FMEA is a completed table.

For some folks, that's as far as they take FMEA. But we know that FMEA itself isn't like a math problem. We don't solve an FMEA and get an answer. We instead use FMEA as a tool to help us do lots of things.

First, it helps us to collect our team's knowledge and by team, I mean our cross functional team which includes marketing, field operations, technical people like engineers and even our customers. We collect that knowledge and turn it into ideas about what we're developing and to better understand potential risks and issues.

Next, we turn those ideas into data using rating scales. We use that data to make decisions about what we're developing, what are the most serious risks. We weigh the risks against the benefits and determine if there needs to be action taken, like a redesign of a feature or a different component.

Then we reassess, essentially performing the loop again.

We went to iteratively use FMEA with our cross functional teams as early as we can in the development process  - as early as the concept evaluation phases. Yes, we can use FMEA as a tool before we have prototypes, even earlier. We can and should use FMEA before we started engineering development. FMEA is a framework a team can use to organize information about risks and can also help a team decide if the action that they took to reduce a serious risk was enough or if more work is needed.

I facilitated teams in developing an FMEA and the team has changed their design decisions, be it a product design and manufacturing process, design, or even labeling. And it was based on the team activity from doing FMEA.

This is important: most teams don't fully utilize the capabilities of FMEA. Think of FMEA as an information tool for us to continuously improve our design concept early on, as we're hashing out details about the design.

During the design process, we can use it to help us figure out tests that need to be performed, define confidence levels for our tests and define other controls, like detection controls.

Late in the product development process we can use it to make a final benefit risk decision.

After our product is released market, we use it to compare what we're seeing in the field against how we design the product, and we continue to evaluate the risks of our product.

If our product design and monitoring system were a conveyor belt, then FMEA is a way to continually measure risk and adjust our decisions.

Not all FMEAs are focused on the same thing. After all, development is not just about choosing parts and you all know this, it's about understanding if our design functions and performs against what it's expected to do and how our manufacturing processes are designed and developed in order to support the quality of product that we need. It's also about the user experience and the way our customers use our product and how our design works within the larger scope of the environment in which it's used.

To analyze all these ways of meeting customer needs and requirements, we may choose to use multiple FMEAs with a different focus on each of these areas. Common focuses of FMEA are system, use, design, and process FMEA.

Design FMEAs are focused on particular components or features of a product design and we can use these to help us make design decisions as we're designing a product.

Process FMEAs are focused on a manufacturing process. We could also use process FMEAs during the design process to help us evaluate our design against design for manufacture ability.

The other two FMEAs listed -  the system FMEA and the use FMEA - is the focus that we can take during the concept phase of our design development.

System FMEAs are the highest level of FMEAs as far as the scope. They're used to help teams analyze the products function and safety within a larger system, and that system could include the environment in which the product is used, human interfaces and interactions with our product, or the team could decide to structure the system FMEA to represent a collection of smaller components that act as their own system.

Use FMEA analyzes the user process. We can think of the steps that our customers take to use our product as a process. We can map out this user process step by step and analyze the potential failures of each step. We'll cover more about the user process and the tools to analyze it in another lesson.

Construct an FMEA table

The basic content and structure of all FMEAs are the same, which brings us to how to construct an FMEA table.

Each line of an FMEA is analyzing a potential failure, the effects of that failure on performance, functionality, safety or the environment and the causes of that failure. These potential failures are grouped by functions like a system function, a design component, or a user process step.

Its future forward and is in the spirit of potential failure modes, effects and causes. This means that we're estimating what will happen in the future based on our knowledge of today. I found that teams can get stuck in trying to figure out what's a failure mode and what is the effect and what are the causes.

Remember what we did in lesson one: we talked about symptoms versus problems and their causes. We can take this line of thinking and rearrange it into an FMEA table.

The problem is our potential failure mode.

The symptom is the potential effect of the failure and

the cause is still the cause.

The power of some team-based quality tools is that they help groups of people combine ideas and then rearrange them to get a different perspective. FMEA does this too.

We now want to do some FMEAs on the next generation bike stand and we want to design out the shortcomings of the current design. We want to learn from our mistakes from the first time and make an even better product this next time. We choose to perform a system FMEA as part of our concept evaluations. We can be doing this as part of a continuous improvement or we could do this as an input into our next generation stand design, just as a couple of examples.

Today we're focused on the function “The customer assembles the stand”. Our tree diagram mapped out our issue as symptom-problem-cause. Our symptom that we were experiencing was that customers cannot assemble the bike stand. Our problem was customers cannot assemble the angle and the support and answers “what's wrong with what”. And our cause at the time was the “top holes of the angle and the support do not align when assembled”.

We slightly rearrange our tree diagram and put it into the FMEA table.

• The potential failure mode is that customers can't assemble the angle and support.
• The effect is delayed use of the stand and the customer being troubled to fix this problem
• and the potential cause is the top holes do not align.

Now we have the start of an FMEA line item.

We add a column to capture the types of controls we want to put in place to prevent or detect the cause of this problem and we add a column to capture and record any actions we want to take about this cause.

That is how our symptom problem and cause model can fit into an FMEA for further analysis.

We had also previously worked with our cross functional team, taking a closer look at the symptom specific outcome and impacts. We came up with a list of outcome drivers and separate impact drivers. Let's now look at iterating on this work that we previously did with our team putting it into an FMEA so we can get better clarity about what it is. We're evaluating and continue to make design decisions on the technical inputs, the customer information needed and other controls we might need.

If you remember, the outcome and the impact have different drivers. The drivers for our outcome will block the risk and our drivers for the impact will help us reduce the loss and come up with prevention controls. For our “customers cannot assemble the bike stand” outcome, we came up with things like:

• parts are wrong,
• parts are damaged,
• missing parts and then
• confusing instructions
• too many parts and
• lack of tools

We can use these outcome drivers to develop potential causes in an FMEA to block risk. What we may want to do is take the last three drivers that our team came up with (the confusing instructions, too many parts, and a lack of tools) and group them as a “customer difficulty” cause in our system FMEA with the intention that we're going to evaluate those causes further in a use FMEA.

Let's take a look at what that might look like in our system FMEA. Now, we have more causes than what we originally started with. The original cause that we started out was that “the top holes of the angle and the support do not align when assembled” - that can be categorized as “parts are wrong”. Our team can make a decision, here. Our previous design (the one that's in the field) -  we've been getting a lot of complaints about this specific issue. We may want to leave it as its own cause in our system FMEA for our new bike stand. We may also feel like we don't need to do that and just leave it a generic “parts are wrong” with the intent that we're going to further evaluate specific ways that the parts can be wrong, leading to this failure mode in a design FMEA.

We don't want to forget those outcome drivers about our customers. So we're going to use a use FMEA to further evaluate the same potential failure mode but with causes relating to how the user is interfacing with our product and that potential causes of them “not being able to assemble the angle and the support” are:

• confusing instructions
• too many parts and
• a lack of tools.

If we have determined that this potential failure mode is significant and we want to control it, we're making sure that the drivers for that outcome are being captured in various FMEAs: at the system level, at the design level, and the use level.

The impact drivers we want to use to reduce losses and develop prevention controls. We can still do this within the system FMEA with the potential cause of “customer difficulty”. With our cross functional team, we can develop prevention controls that help prevent customers from having such a difficult time in assembling our product. This could be things like them knowing how to get help. Maybe the contact information for customer service is required to be on the instructions for use, on the outdoor packaging, and other places where the customers can easily find where to get help. We may also want to look at our quality management system and develop customer service protocols to make sure that they are available for our customers and that they are trained to be able to help troubleshoot with the customer so they can get their problem resolved more quickly. These are the type of prevention controls we may want to implement to help control this risk when building an FMEA with a team.

I like to first take the tree diagram approach. It's a graphical organizer so its visual, we can construct it with our team easily with real or virtual posted notes, whiteboards or flip charts and it follows a way of thinking that's stepwise intuitive (first this happens, then this, then this last thing). And once the team starts thinking in this way and we demonstrate how it fits into an FMEA table, the team has an easier time with FMEA.

And we're at the end of this FMEA lesson. Here's what we talked about today.

• We talked about the purpose of FMEAs and how it fits into the design development process. We can use different FMEAs to focus on different areas of our product design and we can use FMEA iteratively to help gather, organize and rank information about the risk of our product.
• We started building an FMEA table with a symptom, problem, or failure and causes in the correct places.
• We also talked about the controls column and the action items column.

Good work today! You're well on your way to proactively using a powerful analysis tool to help you with your design choices. I look forward to seeing you in the next lesson.

[progressally_media media_id="2"]