Course 1: Design for Problems and Risk

Welcome back to the course. We are on lesson seven, which is called “Iterating through the development process.” This is the topic that we're going to be covering today, which is an understanding of FMEAs as a living document: what ‘living document’ means and what that means for our design development process.

Now, I've called FMEAs a living document, but that also means that they need to be managed. I don't see that as a downfall, especially if we take the approach of the team responsibility for FMEA. Depending on where you're working, you may have a different product development process. You may have strict design control with phase gates and design reviews. Your product development may be more agile focused, or it could be a mixture of the two (which is a wagile approach: waterfall/agile approach). No matter what product development framework that you're working in, you can still intuitively apply FMEA.

All FMEA tables are pretty much set up the same, but then again, not any two FMEA tables are exactly alike from company to company or industry to industry. It's an adaptable analysis that we need to iterate to be able to use properly. Here's what I mean by that:

When we start an FMEA, we do have an open mind about potential things that could happen. But we do have an end goal in mind - what it is we want to achieve with this analysis. We're not going to be thinking, “I want the risk of this product to be okay and acceptable, so we're going to arrange the FMEA so it looks that way.” That's not what I mean! What I mean by endpoints is thinking about the types of outputs you want to get from the FMEA.

• What's the additional information that you need?
• What information do you need to be able to make design decisions?

This all depends where we are in the product development lifecycle.

In the early phases of concept development, we can look at the bigger picture with a system FMEA. And we can look at how a customer could potentially interact with and use our product with a use FMEA.

Through the development process, as we learn more about our product, we're going to iterate the design itself and along with that we're going to iterate the FMEAs. In fact, I would say the FMEAs would be done first and then we would change our design. So, through the design development process, we're learning about our product, we're iterating on the FMEAs, and we're iterating on the design.

Later on in product development (when we're engineering products, when we're choosing components and tolerancing dimensions, making sure that different systems work together) we're getting into the details of our product as an engineer. I think this is probably the most fun part. We've done a lot of work to get to this point. Finally, we're at design engineering! This is the perfect time to do a design FMEA, when we are in the headspace of the details of our product. What we can expect to get out of a design FMEA are those features that are critical to the function, the safety, the performance of our product. It'll become really clear what we need to focus our efforts on in speaking out and making sure it’s correct.

These are all FMEAs. We can do during the development of our product from concept development through the design process and even in test. Now, testing fits back into the FMEA. In fact testing is one of the ways that we learn about our product. We're either doing some engineering benchtop testing, formal testing in the lab, or maybe some summative or formative studies with our different user groups.

As we learn about our products, the potential ways that they could fail and how they interact with each other, we want to update the FMEAs. That's part of iterative FMEA.

• We may find out that there's a failure mode that we never even considered and it's happening!
• Or there may be a limitation on our product that we really hadn't considered before, an environmental or shipping vibration limitation that we hadn't expected.
• We may have gotten feedback from our user groups that this part worked okay. This part, they really didn't like that.

All of this can feed into our FMEA so we can step back and analyze it within the context of the whole product system and the design and individual components themselves.

• The failure modes that we thought could potentially happen - are they happening? And if they are happening, are they happening as often as we thought, or maybe not as often.
• We're working with our internal customers. The manufacturing people are saying that they thought they would be able to detect this defect in line but now they can't. So what does that mean to the overall risk of our product? How does that information feed into our design decisions and then that design decision feed into the system level risk?

When we get to the end of our product development lifecycle, we can use our FMEAS Again to assess:

• Where do we think we were going to start at the beginning of the project?
• What have we learned through the project?
• And finally, what have we learned from all the final tests that we've performed?
• Is what we thought going to happen still happening?

Is the final level of risk of our system acceptable to us or not? And this is where we weigh the benefits and the risks. Remember that we can't create a product that is risk free, but we do have a responsibility to understand the risks of our product and try to effectively manage them.

• We can reduce the risk, how often it happens, or how severe it is.
• We can try to eliminate them with proactive choices,
• and we can try to control them through monitoring.

How do we just go about this iterative use of FMEAs? You're going to have to set up some meetings with your cross functional team. Your team should be aware of and understand how you want to use FMEA through the design development process and have a basic understanding of what FMEA is and the rating scales that are applied. This is going to be unique to your company. Not only your company's policies and procedures, but what industry you're working in and the culture of the company that you work in.

As design engineers, you make decisions daily about the product, how it looks, how it works. And it affects how it will function in the field, but also all the internal customers that come after the design of the product. Those people that are making the design a reality and getting it into the hands of the customers. FMEA is a way that we can analyze our design concepts and our designs themselves to make sure that they're the best they can be. It's a great way to communicate with our team, incorporate their feedback and make decisions with data.

So, what did we talk about today? We talked about FMEAs as a living document, what that means for our design development process. That we want to iterate and continuously update these documents so that we can have proper design input as we learn throughout the product development process.

Thanks for joining me for this important lesson, and I'll see you in the next lesson.

[progressally_media media_id="1"]