5 Common Failure Analysis Mistakes

This is an article from DesignNews.com about failure analysis.  This is an area that I see people have a really hard time with.  When something breaks it is time to check the ego (if you designed the thing that broke) and be methodical.

_________________________________________________________________________________

When a part breaks unexpectedly, it usually sets off a flurry of activity. Often, a team is formed and charged with finding the root cause of the failure. In my career, I have led or been a member of many failure analysis teams. Based on my experience, there are five mistakes that engineers often make when investigating failures. (I know because I've made them all myself.) Recognizing these mistakes can help you avoid them.

1. Looking at a part in isolation. As a materials engineer, people often send me a broken part in a cardboard box and ask, "Why did it break?" Of course, if the part had been in a cardboard box the whole time, it's unlikely that it would have broken.

Although there are many things that can be learned by inspecting a failed part, the part itself rarely tells the whole story. It's important to understand the mechanical system to which the part belongs and the part's role in that system. What loads does the part feel? Where do the loads come from? What might cause the loads to be higher or lower? It's also important to understand the environment in which the mechanical system operates. In what ways might the operating environment differ from what was anticipated in design?

Remember, no part ever fails by itself. It fails as a part of a given mechanical system under a given set of environmental conditions.

2. Focusing on conformance to specifications rather than root cause. When a part breaks, one of the first questions asked is, "Did it meet the print?" Of course, it's important to establish whether or not the part conformed with the design requirements.

But finding a non-conformance is not the same as finding the root cause of the failure. If a part is found to be defective, it's important to understand what role (if any) the defect played in the failure. In some cases, a defect may be a red herring, which leads you away from the root cause. In other cases, early failure of a defective part may reveal an underlying problem, which would also cause non-defective parts to fail over a longer period of time.

There's another reason not to focus excessively on the issue of conformance or non-conformance: It can result in a confrontational relationship with parts suppliers. This can undermine cooperation, which may be necessary for the success of the investigation. Failure analysis should always be about solving problems, not assigning blame. Of course, this is not to say that suppliers shouldn't correct non-conformances, or that there shouldn't be consequences for suppliers who consistently provide non-conforming parts. But this should be separate from the work of the failure analysis team.

3. Jumping to conclusions. In failure analysis, comparing parts or assemblies that failed with ones that didn't can be a very valuable exercise. However, there is a temptation to latch onto any difference and immediately assume that it was responsible for the failure. You may even have a reasonable-sounding theory, which explains how this difference could have caused the failure.
Unfortunately, the fact that something sounds reasonable is no guarantee that it is true. You can't determine the root cause of a failure by simply thinking or talking about it. You need to test your theories against reality. Without data to back it up, a reasonable-sounding theory is just a reasonable-sounding theory.
4. Collecting data instead of thinking. Instead of jumping to conclusions, some engineers go to the opposite extreme: They try to perform every test and collect every piece of data possible, regardless of how relevant it may be to the problem at hand. Of course, this provides them with a ready response when managers ask why the problem hasn't been solved yet: They're waiting for test results.
Clearly, it's important to have data, and too much is better than not enough. But before performing a test, ask yourself: What information do I expect to get from this test? What questions will this information allow me to answer? What are the limitations of this test? Thinking clearly about your test plan before you start testing will help you to stay focused on the root cause.
5. Throwing the kitchen sink at the problem. Often, there are competing theories as to why a part failed. Based on these theories, different engineers may suggest three or four possible changes to the design or manufacturing of the part, which might (or might not) fix the problem. Pressure from management to "just get it fixed" might mean forgoing testing to determine which theory is correct, implementing all of the changes at the same time, and hoping one of them works.
Sometimes, this results in the problem going away, and the engineers look like heroes to management for solving the problem in such a timely manner. But really, nothing has been learned. Worse, in the tribal knowledge of the engineering organization, one of the changes, which actually had no effect, may undeservedly get the credit for fixing the problem. Once this becomes part of the conventional wisdom, it may prove very difficult to dispel. Learning the wrong lesson from a failure can be worse than learning nothing at all.