The Lighthouse: FMEA Software—The Pros and Cons (Mostly Cons)

I am frequently asked about the value of software in the FMEA process. To get straight to the point, I have seen more negative than positive aspects of using dedicated software to carryout FMEA studies.

Now, before I anger every company out there working hard to develop FMEA software, I want to acknowledge that it isn’t easy to write software for FMEA. It looks simple enough, but it can be devilishly difficult to create a look and feel that will make FMEA less of a chore. I know; I tried to develop a web based package just a couple of years ago, and it was much harder than I thought it might be. And my results weren't very good.

I will also add that some of the FMEA software that is now on the market looks good, and is relatively easy to use. In fact, most FMEA apps produce beautiful output that appears to be first rate. The best products on the market will allow automatic linkages to Design Verification for DFMEA and to Control Plans for PFMEA. They can also show statistical assessments of risk, and can, over time, build a valuable and searchable database that can be difficult to create using spreadsheets.

Many of the new apps include tools to track FMEA results in a large system, to compile and track recommended and corrective actions, and can even link different projects across several domains in the same organization. All of this is worthwhile and can create tools that will help drive continual improvement in a business.

More and more FMEA packages include libraries of common causes, modes, and effects. And the software interfaces put these libraries within simple reach, either through drop-down menus or other common look-and-feel interfaces. These lists are usually amenable to customization, and some products offer a wide array of common templates to assist with compliance with regulatory requirements or industry standards.

Some FMEA applications also provide straightforward links to other reliability tools, such as fault tree analysis and Weibull plotting. They may also integrate with common Product Lifecycle Management (PLM) systems to facilitate communication and record management across a large and diverse organization.

Despite all of these potential advantages, I don’t count myself as a fan of FMEA software. Most of the features that are helpful are what I might call ‘peripheral’ aids, things that can ease information dissemination, make it easier to find specific issues in previous FMEA work, and make report generation much simpler than spreadsheets (even when augmented with complex macro commands) can manage.

The concerns I have involve the most fundamental concepts of FMEA. There are 5 very common factors that I find troubling about most FMEA software.

1.      The software is so easy to use that one person can (and usually does) carry out the FMEA. Using this software in a team setting is often confusing unless everyone on the team understands how the software works. If they don’t, the “FMEA expert” who is leading the session often—even usually—blows through the work so fast that other participants (either via projector or web conference) don’t really see what’s going on and don’t contribute much. In reality, one person often does the work in isolation and only submits the work to others for review.

2.      There are plenty of indirect incentives to use software by yourself, because if you can’t reduce the number of people or work hours involved with FMEA, you typically can’t generate the cost savings to justify the purchase price and/or license fees for the software. And, a single license for an “FMEA specialist” is far cheaper than dozens of licenses for a full-on team approach. These less-than-obvious factors amplify the tendency to fall into the trap described in the first drawback listed above.

3.      The lack of intense cooperation in developing the FMEA leads to very little learning occurring. It also means that the FMEA captures one person’s view, and that view is almost always incomplete. I’ve tried this myself on a number of occasions, and even when I know a product or a process very well, I almost always either miss something that I should have caught, or miss something important because there was something about the project I didn’t really understand, even though I believed I understood it well. Also, a "solo" FMEA is rarely read thoroughly by anyone other than the author--unless it's a lawyer working on a product liability case after something serious goes wrong.

4.      In many cases, the software starts to take on the ‘look and feel’ of artificial intelligence. This leads to errors, sometimes serious errors, because that's just beyond current capability and might be 20 years or more into the future. Moreover, I have seen more than a few FMEA software packages that don’t have a sound understanding of the differences between causes, modes, and effects—and that shortcoming itself is a profound weakness.

5.      Printable output looks very, very good. It has an aura of infallibility about it, and it is easily presented in large groups. After all, if it fits the prescribed template or format, the rows and columns are arranged nicely, the header section has all of the pertinent information, the grammar and spelling are always correct, then it’s easy to either expect the content to be excellent or, worse, to just gloss over the content and not question any of the results.

All of these negative factors detract from the benefits that come from thinking deeply and sharing your insights with others. In my view, and in my 40 years of experience with FMEA, thinking long and hard about a project is one of the most valuable results of a sound FMEA study.

After facilitating, leading a team, or being a member of a team for more than 1,000 FMEA studies (both DFMEA and PFMEA) over my career, I found that any team that digs intensely into a design or process will end with something far better than they would when they don’t put that kind of effort into their work. The result is nearly always a better product or a better process than teams that don’t develop serious skull sweat while creating an FMEA.

More importantly, I’ve found that people who use FMEA properly, and work hard during studies, become better engineers than their peers who do otherwise. (I realize that this correlation might not prove there is a cause and effect relationship in this—those who have the intelligence, curiosity and drive to be better engineers might be more inclined to work through FMEA at a deep level.)

When I’ve been a facilitator for a project where I have little or no practical experience with a project, I’ve found that I walk away at the end with a very substantial understanding of the project and the underlying subject matter (even when I'm not knowledgeable about the foundation technology), partly because of the logical structure of FMEA and partly due to the education I receive from leading a team through FMEA via that logical structure. I’m often mentally exhausted when I’m done, but I always learn a great deal simply by following the rationality of FMEA at a very detailed level.

At the same time, there are huge disincentives to this kind of mental exertion when using software. You usually lose most of the positive elements of FMEA studies through excessive efficiency.

Finally, before I receive a long list of negative comments from software suppliers or from fans of FMEA software, I will add that using a spreadsheet approach can result in many of these same problems. Spreadsheets, or even paper and pen, can fall victim to any and all of these pitfalls.

Software, however, invites you into these traps. And it makes you feel comfortable with and, in most cases, blissfully ignorant of the superficial nature of the output you’ve produced with software. When that happens, FMEA results becomes meaningless paper exercises designed to show someone—management, a regulatory body, or an auditor for an international or industry standard—that you did something that’s required.

It usually doesn’t drive better products or processes. With proper effort, good software could be an amazingly useful tool. It just turns out that it is rarely used that way, and it seduces you into not using it that way.

Many years ago, I was taught the “Four P’s” of quality. Push Paper, Pretend, and Pray. Software can lull you into that, at least when it comes to FMEA.