3 Actions To Make FMEA Worthwhile

FMEA is critical tool in Product Development processes, and you should understand why that’s true.

In this article, I’m going to explain why it’s worthwhile to complete an FMEA. Let’s start with a general discussion, without regard to Process FMEA or Design FMEA. The major issues are the same, although the details can (and often do) diverge. FMEA is critical tool in Product Development processes, and you should understand why that’s true.

Point 1: FMEA is NOT an End Point

If you complete an FMEA, heave a sigh of relief, and don’t use the results for meaningful and significant actions, don’t waste your time doing FMEA studies. FMEA is all about improving products and processes, and if you think a finished FMEA is useful because it checks off a “to-do” on some list of deliverables in a project, you are missing the point completely. You’ll spend time (and money) and get little or nothing in return. The FMEA form is just a place to keep track of what can and should be done as a result of the study.

Point 2: You Need to Make Changes As A Result of Every FMEA Study

If you’ve done an FMEA study correctly, you are going to find some cause-mode-effect chains (or rows on the FMEA form) that have a risk you aren’t comfortable with. In those cases you have two choices. You can agree, with an eyes-wide-open perspective, to accept the risk as it sits and move on. But you can also devise a plan to take a direct action, choosing a design change (for either DFMEA or PFMEA) or a process change (PFMEA only) that will address the risk.

If you never try to do anything except go forward the way you planned before starting the FMEA, you are making a terrible mistake. Worse, you are devaluing the FMEA process. Once you do that, you will find that each successive FMEA has less and less significance. Eventually, you’ll just be checking the box and filing the form away in some obscure folder, drive, or database.

Point 3: You Need to Implement The Controls

If you’ve done a decent job on the FMEA study, you will have a long list of prevention controls as well as detection controls. Do you need to add every single one to the Design Verification Plan (DFMEA) or the Manufacturing Control Plan (PFMEA)?

In a perfect world, the answer would be yes. And, there are plenty of OEM customers (and engineering managers) who will insist that you reach for a perfect world. However, reality is somewhat different. In a sound FMEA, there will be a number of controls that you would like to apply, but are either too expensive, take too long, or are otherwise unlikely to be carried out.

In those situations, you again have to deal with an eyes-wide-open risk. Either spend the money and/or time to carry out the controls, change the design or process, or accept the risk.

On the other hand, there will also be one, two, or even several controls that you really should add to the list for verification or control plans. They might add a bit of cost, they might add time to a project, or they might intrude on issues that veer into the “we don’t do that here” mentality of your organization.

If you aren’t actually applying some of these out of every FMEA, you simply aren’t getting to the main point. At the same time, if you are skipping or omitting one, two, or more of the controls you’d normally do for the same kind of product or process, you are—again—missing the boat.

What You Can Do

I’ve been doing FMEA studies since 1978. I’ve learned something about the methodology every time I use it. I’ve been involved, either as an active participant, instructor, or facilitator, in hundreds of DFMEA and PFMEA studies.

When the results are applied, good things happen. When results are not applied, the outcome is worse than “nothing happened.” What almost always occurs is that FMEA becomes devalued, and another group of engineers walks away with more than a bit of loathing for using this valuable technique.

And, while I suspect that many of you think this advice is too obvious to worry about, I will add this. Even in the past five years, the number of FMEA’s I have seen that have resulted in no meaningful action exceeds 80%. I would say 95%, but in truth I don’t always know if action has been taken in every case.

Use the results. Make something positive happen with what you learn from each and every FMEA.

The ABC’s of Warranty Reduction

If you want to reduce warranty claims for your products, here are three things you must be aware of before you tackle this challenge.

If you want to reduce warranty claims for your products, there are very few roadmaps available for this kind of effort. I’ve personally been involved in three major multi-year efforts of this type with large corporations, and I’ve learned more than a bit about what does and doesn’t work.

Let’s start by considering three basic ideas you should be aware of if you are asked to lead or participate in a significant attempt to reduce warranty for your company’s product lines. Here they are:


If you are asked to lead or support major warranty reduction activities, don’t expect to be loved for doing so, at least not for some time. In fact, it may take years before your work is appreciated, even by the executives who asked you to take this on.

Why? To start, highlighting warranty claims and expenses will indirectly criticize a large number of people and organizations in the business. No matter how you how it’s presented, focusing on warranty focuses on failure. Few will respond positively. Many will be out-and-out hostile. Be prepared. Don’t respond with anger, either. That will make things worse.

You are almost certain to discover that everyone, and I mean everyone, who needs to act to resolve a problem will question your every move. They’ll nit-pick every presentation, debate every metric, and they’ll even question your motives. This will include field personnel who work with customers daily, because they’ll vent their dissatisfaction with the situation to you as the representative of “headquarters” or whatever the central location of the business is called.


A company suffering from excess warranty claims and costs needs data to make anything other than educated guesses about the scope and nature of the issues they face. However, even if a warranty data system exists, you are all but certain to learn several hard lessons about the data that has been collected—or about new data collection methods you initiate.

You will probably learn that the information in any warranty tracking database is riddled with errors. Some are trivial; many are systematic. And more than a bit of the information will be downright misleading. If you can get to the point where you have 70-80% confidence in the accuracy of the data, you are doing very well indeed.

You’ll also need to take a very hard look at the metrics you extract from warranty data. To paraphrase Dr. W. E. Deming, there is no such thing as a warranty metric until you develop an operational definition for each and every metric. And, you will quickly learn that one simple number—something that managers and executives will want to see—will never tell you enough to understand what’s really going on or whether you are making any progress.

You’ll probably have to settle on about a half-dozen metrics to have any real hope of being able to see the big picture, or even a small picture for that matter.

You will also find that obtaining and analyzing returned goods that have failed will rarely tell you the whole story. They may also lead to confusion and debate about any analyses that are done. That doesn’t mean you shouldn’t try to understand specific failures, but, in the absence of broad-based metrics, field return analyses aren’t as revealing as you might think.


Even when you succeed, your results won’t bring instant financial payback. While a major warranty problem can be created in a very short time, it nearly always takes years to see the full impact of corrective action.

When a new or altered product enters the marketplace, warranty issues are unlikely to appear immediately. The worst problems can’t be identified with any confidence for one, two, or even three years after a new product is sold to end customers. Then, it will take more time to understand the cause-and-effect relationships that led to an issue (and there are many pitfalls in doing that).

A change in design and/or production will be needed. Picking and validating the right “fix” takes time and may lead to extensive debate and/or handwringing. You can easily make things worse if you botch this phase of the cycle.

At every point in the supply chain, existing inventory will have to be dealt with, and no one will want to scrap anything unless it’s hopelessly flawed. There will be resistance to rework, too. None of these actions are in anyone’s budget or have been included in their annual performance plans, so expect stiff resistance.

Finally, new-and-improved products have to enter the production stream and be sold. Then it will take the same amount of time needed to see the problem in warranty results to confirm that the corrective action was effective. So, if it took 3 years to see the issue clearly, it would take another 3-4 years to see if you actually did anything positive.

At the same time, everything produced in the time consumed to see the issue clearly, formulate a corrective action, and get the revised product into the marketplace will continue to add to the warranty mountain you are climbing.

The finance staff won’t be able to book any cost reduction results for a long time. A discounted cash flow based on the costs associated with diagnosis and correction will be unlikely to show a rate of return that excites anyone. That will make financial justification for changes difficult. This will also test the patience of those who chartered your activities.


Making progress is slow, difficult and, unless you like irritating people, frustrating. I’ll expand on how you can do better in Livonia Technical Services articles–coming soon.