FMEA Pitfalls

Perhaps the most common FMEA pitfall is too much subjectivity in apply the ranking guidelines. To overcome some of this subjectivity there should a detailed explanation and example of its application. Include data criteria where applicable. For example, the number of failure rates of similar products or process operations can be used to narrow selection of an Occurrence ranking.

Here are 21 additional pitfalls:

1:  Prioritizes, Doesn’t Correct

The initial output of an FMEA is the prioritizing of failure modes based on their risk priority numbers.

This alone does not eliminate the failure mode. Additional action that might be outside the FMEA is needed such as mistake proofing.

2:  Only as Good as the Team

Identifying failure modes is a team brainstorming activity. If the right people are not on the team it is easy to miss failure modes.

If the team forgets to list it, an important failure mode could be missed.

3:  Time Consuming

It takes time to get into the details. However, time spent upfront preventing a problem is usually cheaper than fixing a problem after it happens.

4:  Unknown and Unknowable

Might miss a failure mode or an effect outside the experiences of the company.

5:  Not Customizing Rating Scales

Rating scales should be meaningful to everyone in the organization.

The generic rating scales might be confusing to some teams.

Management will not be able to compare RPNs in order to prioritize activities between teams.

6:  Not Starting in the Design Stage

The earlier in the design process a FMEA is started, the better. It should be started at the design concept stage.

A DFMEA can point out where design verification is needed.

7:  Taking on Too Large a Scope

Taking on an entire process may be a daunting task.

Break a large process down into sub-processes.

8:  Not Including Operators

Experienced operators should be on the PFMEA team to add their perspective.

They often have good information on failure modes and on the effectiveness of control systems.

They might have information on occurrence as well. Not every issue is recorded on production worksheets and checklists.

9:  Not Including Customers

Customers, especially end-users, often have a better view on failure modes than internal personnel. They can tell you what annoys them when using the product.

10:  Not Including Suppliers

Suppliers also bring an outside perspective to the team. They are the experts for their product or service.

They may be able to tie your process in with theirs.

11:  Becoming a Full-Time Job

Sometimes people use an FMEA as an excuse to get out of doing their regular job.

You can’t afford to have people who are just conducting FMEAs.

They won’t get their duties completed.

Even if FMEAs are made their “regular” work, they will lose touch with the process and the FMEA will become mere paperwork. This is common when a company assigns the job to one person instead of a team.

12:  Not Using Concept of a Process

This will cause the team to forget some failure modes.

The team should brainstorm failure modes in each of People, Methods, Measure, Equipment, Materials, and Environment. Use a Fishbone diagram to brainstorm against.

13:  Not Getting into the Details

A superficial look at the process will miss many failure modes. The "Just Finish It" attitude produces an ineffective outcome.

14:  Forgetting there are Internal and External Failure Modes

Many FMEAs focus only on the customer requirements (specifications).

Sometimes internal productivity losses, equipment damage, scrap, and rework have very severe effects on the company.

Ergonomics and Safety should also be considered.

15:  Confusing Root Cause and Failure Mode

Teams often have root causes as failure modes.

A failure mode is the failure to perform the intended function. Sometimes simply stating the function in negative terms helps to keep this straight. For example, if the function is "to drill", the failure mode could be "doesn't drill". Then the team would brainstorm all the possible causes as to why it "doesn't drill".

16:  Not Looking at Each Product

Templates are great but every product being made in a process is not exactly the same.

The template should be used as a starting point and each product should be evaluated:
          Could this failure mode occur with this product?
          Would this effect occur?
          Is this the correct root cause?
          Are these controls applicable?
          Should any of the three ratings be changed?

When using templates always ask "What is different about this product or process?"

17:  Assuming Detection Controls Are Better Than They Are

Some controls are not as good as they are perceived to be such as 100% manual inspection.

High repeatability and reproducibility.

Don’t test for what we think they test for.

Only test part of the product.

18:  Assuming Detection Controls Apply When They Don’t

A control might apply to one effect of a failure mode but not another.

For example, final inspection is a control against a defect escaping to a customer, but it may not be a control against rework or scrap.

19:  Not Linking with Mistake-Proofing

FMEA is a prioritization tool. It doesn’t eliminate failure modes or effects by itself.

Companies need to apply tools such as mistake-proofing to eliminate the root causes of failure modes.

This is especially true with failure modes that have very severe effects.

20:  Not Tying into Control Plans

The control plan tells people how to react (reaction plan) when a failure mode occurs.

The FMEA will not be a living document if it is not tied to the control plan.

21:  Failing to Update the FMEA

As new potential failure modes are identified, they should be added to the FMEA and control plans developed for them. Process changes occur constantly and rapidly. Checking the FMEA for revision is critical if it is to effective.

It is critical that the template also be updated.

We don't guarantee that the above covers every possible pitfall, only those that are most common. It is suggested that you develop a FMEA process checklist to help in avoiding pitfalls.