Has your FMEA entered the realm of the paperwork exercise that we force ourselves to do for no real reason than someone says we must do it?

I have enjoyed analysis using FMEA. I first learned it existed when I was working for Ford. FMEA was the first Ford Technical Education Program assessment of prior experience and learning certificate that I qualified with in June of 2000. I took a class at the training center that was written and delivered by ASQ Fellow, Dr. Dean H. Stamatis. 

Since then, I have worked on hundreds of FMEAs collaborating with many different teams, on many different projects, systems and products. In addition to spreadsheets, I have also used two popular commercial tools. Both struck me as written / specified by people who never really understood the point - the focus of the tool felt more like generating lots of text rather than being an enabler to capturing high priority actionable activity succinctly. 

FMEA should to be valuable and useful. Not something that gets in the way of the work but a method that allows me to see how much work and unknown there really is. Unfortunately, this is not the experience of everyone - authors and reviewers alike. FMEAs that have repeating information all the way through as an author finds a turn of phrase that the team (or reviewer) likes and replicates that. Or reviews that focus on formatting, spelling mistakes, calculation errors, and similar are soul destroying. Reviews rarely get to grips with the subject and point out missing failure modes, causes or easy to implement prevention mechanisms. Fundamental and dangerous structural errors where failure modes, causes and design mitigations are not correct are rarely noticed. Despite how important this is to the reliability and safety of the design. Basic omissions that influence the sufficiency and completeness of the whole analysis such as the architecture diagram / scope, completeness of the function definition are even less commonly noticed.

Too many FMEAs end up being picked from a small pool of words and phrases available to the engineer with little to no meaningful design mitigations reflecting the real status of the maturity of a design. If your FMEA has no actions, it is unlikely your design is robust. If you have a mature robust design and an exceptional team performing the FMEA of such a design, they will always find opportunities for future enhancement. If you spend a lot of time fussing about RPM numbers, you are more likely to miss the key issues.

An FMEA that is led by an inexperienced facilitator, done with people who are not motivated to perform the analysis is likely a total waste of time. And, at the end many engineers will conclude the FMEA made no difference.  These are all too common and performed day in and day out at some of the largest corporations. 

Over time I have learned that people don't think from left to right, top to bottom according to many FMEA spreadsheets and tools. The process should be not hampered by having to fill in function 1, row 1, column 1, column 2, ... in the template. A good analysis technique is far more fluid, almost random, composing of concerns and solutions. If someone is brainstorming failure mode/causes/mitigations, then capture them. If it is mentioned that there is an important action, capture it right away. Our eyes and intuition can at once see the gap and come back to that another time - maybe with another person.  

Some FMEAs have evolved far from the magical experience I had when I learned about this tool and just how valuable it can be when performed correctly with a team who find the most unlikely of weaknesses in a design that have been overlooked by many prior reviews. This is especially true for functional safety projects. 

Functional safety requirements have two principles – design quality and probabilistic failure hardware analysis. A DFMEA has been the main architecture design verification technique in the world for many decades – for both hardware and software.  But it is best modified for functional safety product development given the probabilistic failure analysis.  Some functional safety requirements can replace the traditional FMEA items. This evolution has been called DDMA – Design Deviation and Mitigation Analysis . Hopefully some of this FMEA evolution can be incorporated into FMEAs done by designers with a good DDMA tool. Can we get back to the FMEAs I enjoyed from my past?