It’s one o’clock in the afternoon. You’re back from your lunch break, and the post-burrito slump is setting in. You’re stuck in yet another FMEA meeting for your latest design iteration. While your manager digs through old SharePoint folders trying to find the final revision of the previous system’s FMEA, you’re googling how to use lookup tables in Excel® to automate the Action Priority (AP) calculation required by the new standard. You read the same line in the wikiHow three times but can’t make sense of it through the haze.
The FMEA document you are working on is already so large, cumbersome and difficult to manage thatyou spent the whole morning just cleaning up formatting, merging cells, and fixing mismatched templates. When this FMEA is finished, you’ll send it off to the customer and forget about it. Your design won’t be impacted by what you do in this room, you’ll never follow up on actions and audit their effectiveness, and you won’t incorporate any lessons learned from the field, areas of risk you missed that could impact future designs. As you stare at the messy spreadsheet, the existential questions creep in: Why am I here? What’s the point of this?
FMEAs have been around for over 75 years and have been frustrating engineers for just as long. Many view FMEAs as a needless, box-checking exercise that wastes time better spent on other reliability activities.
But this is a self-fulfilling prophecy. FMEAs are as valuable as you make them. Treat them as a box-checking exercise, and that’s exactly what they become. However, with the right process and tools, they can be one of the most effective reliability methods in your arsenal.
One big reason engineers dislike FMEAs is that most teams still use spreadsheets to complete them. This is what leads to the pain described above: endless meetings spent searching for outdated data, redoing old work, fixing broken formulas, patching together inconsistent templates from teams working in their own silos, and formatting chaos - rather than focusing on design risk or failure prevention.
The result? Overgrown documents, sometimes thousands of rows long, that nobody wants to touch once they’re “done.” Actions are not followed up on. Additional failure modes discovered in testing, or the field aren’t documented. And when the next design iteration comes around, the whole cycle repeats itself.
If that sounds familiar, whether you're the engineer stuck in the meeting or the manager trying to drive engagement, this article is meant to be a reset. We won’t rehash what FMEAs are or why we use them (you can find that here). Instead, we’ll focus on where FMEA processes often break down- especially when managed through spreadsheets - and how switching to a centralised, cloud-based platform can eliminate those pain points and bring real efficiency and value to your process.
There is no denying one key fact, FMEAs look like a spreadsheet. They have columns with headers, rows corresponding to distinct functions, and cells where text and numbers can be entered. But anyone who has worked on an FMEA knows they are much more than that. FMEAs are structured as a hierarchy of parent-child objects: Functions have Failure Modes, Failure Modes have Effects and Causes, and Causes have Controls and Actions. Each of these core structural elements have other fields associated with them as well.
Despite this complexity, spreadsheet tools like Excel® are by far the most common method for filling out an FMEA. There are understandable reasons for this – spreadsheets are widely available, familiar to most users, and almost everyone can open and edit the files.
The other common way to perform FMEAs is using centralised, relational databases. While the term might sound technical or abstract, it simply means a system that understands how FMEA elements are connected, stores that data in a central location, and allows teams in different regions to work together more easily. These platforms are not free or as universally available, but they solve many of the core problems of using spreadsheets.
There are a handful of complaints about using spreadsheets for FMEAs that come up repeatedly from FMEA teams. In one way or another, they all relate back to a spreadsheet’s structural incompatibility with FMEAs. This is not to bash Excel® or any other spreadsheet tool. These tools are Swiss army knives that perform a million different functions remarkably well - FMEA just isn’t one of them. The complaints can be boiled down to three main difficulties:
Let’s dig deeper into why spreadsheet users are having these problems and how a centralised, relational database can address these issues.
Since FMEAs are a hierarchical tree of relational objects, a single function can result in multiple rows of data. For example, if three potential failure modes each have three potential causes and each cause has three controls, that's 27 rows in an FMEA worksheet. Creating and modifying this data, calculating risk for causes based on SOD (Severity, Occurrence, and Detection) scores, adding actions, as well as entering all the other fields associated with the main structural objects, takes a lot of work in terms of formatting. And if something changes in the underlying template - well, that’s an afternoon lost to reformatting the spreadsheet.
Once these spreadsheets become large, not only does the formatting get trickier, but navigating the document to find specific controls, actions, high risk causes, etc. becomes very time-consuming. At best, this only incurs the direct cost of however many hours you waste multiplied by your average engineer’s salary. More likely, this inefficiency leads to missed failure modes, missed causes, improperly identified risk, and so on, leading to much more expensive problems down the road.
FMEA software built on a centralised, relational database solves these problems. It understands the relationships between objects - so when you add a control, the system knows exactly where it fits in the hierarchy. You don’t need to manually format or restructure data.
It also allows you to restructure data to more efficiently analyse functions or other objects of interest. While you may prefer to enter data into a worksheet view during team meetings, you will find it’s much easier to navigate and modify large FMEAs in a tree structure that can condense and expand, allowing you to focus on areas of interest.
Dashboards integrated into the FMEA can also ease navigation of the document. For example, in the image below, the risk profile (first dashboard tile) illustrates trends in the effectiveness of applied actions while also depicting where risk has not yet been addressed. Ranking failure causes by risk (second dashboard tile) allows you to jump directly to that cause in the document, where you can then assess what actions need to be created or modified to address that high-risk cause.
Anyone who has worked on iterative FMEAs, those performed on products that have already been through the process, has likely run into this issue with spreadsheets. And since most FMEAs are iterative, this challenge affects most engineers.
Even when you manage to locate a past FMEA (which is often harder than it should be), it's typically difficult to search, access, and reuse the data. This creates unnecessary work, repeating analysis on mostly unchanged components and subsystems, and causes missed opportunities to apply past lessons learned. What risks were identified last time? What issues did we miss that emerged later in testing or in the field?
Having a centralised, searchable database solves this. It gives you quick access to past and current FMEAs, making it easy to reference or reuse relevant data during new analyses.
Advanced tools can take this further by using the structure of the database to surface related information automatically. For example, smart search tools, powered by AI, can quickly scan your FMEAs to find relevant information. Take an example where you are a bicycle design engineer working with a function like “The bicycle must be easy to use by the defined customer profile” and a failure mode such as “Difficult to steer.” Rather than manually searching through old files where you remember something similar to this might have been used in the past, AI can locate similar entries across past FMEAs, allowing you to select and adapt relevant causes or other fields. It can even suggest new causes based on the context of your current analysis.
The sad reality of FMEAs is that many die before they are given the chance to become useful. Hours are spent documenting functions, failure modes, causes, controls, and actions - only for the FMEA to be filed away and forgotten just when it could have made a difference.
A major reason for this breakdown is the difficulty of managing actions in a spreadsheet. When it’s hard to see who owns which action and when it’s due, accountability fades - and with it, follow-through. In large spreadsheets, it’s easy for actions to be missed entirely, especially for high-risk causes that remain unresolved.
Centralised, relational databases can leverage tools like dashboards to address this issue. Dashboards can quickly collect information across multiple FMEAs to list actions a specific user is responsible for and easily link that user to the location in the document that action was assigned. From there, they can see the relevant context and choose to modify or update that action as needed.
Databases also make linking relevant fields easy. What if the action you are updating is referenced in three separate locations? This is common as actions that address design flaws or testing can address risk in separate causes. In a relational database you can link those fields easily such that updating one will update the rest.
Spreadsheets, while powerful and flexible tools in their own right, are not well-suited for creating and managing FMEA data. For the reasons listed above, engineering teams that use spreadsheets for FMEAs waste time with formatting and redoing past work, miss areas of risk and lessons learned from the field, and fail to properly follow through on actions.
ReliaSoft Cloud, ReliaSoft’s newest FMEA tool, brings ReliaSoft’s decades of experience building centralised, relational databases for FMEAs to the Cloud. Cloud software makes accessing, managing, and collaborating on FMEAs easier than ever. Tools like dashboards and AI assistance increase the efficiency of modifying FMEA documents and staying on top of assigned actions, while ensuring lessons learned in prior FMEAs are leveraged.
If you’re tired of wrestling with spreadsheets for your FMEAs and want a more efficient way to manage risk, ReliaSoft Cloud is worth exploring. It offers a centralised platform that helps keep your data organised, makes collaboration easier, and supports tracking actions and lessons learned.
You can find out more on the ReliaSoft Cloud product page. If you want to talk through how it works, experts are available to answer questions you may have. If you’ve ever spent half your meeting just trying to fix a broken Excel® formula or hunting through endless tabs, you’re not alone - maybe it’s time to let the software do the heavy lifting for once.
Zachary Graves
Application Engineer
Hottinger Brüel & Kjær
Zachary Graves is an Application Engineer at HBK - Hottinger Brüel & Kjær, where he has worked for over five years. In his role, he supports clients in their reliability programmes through training, software demonstrations, and support solving reliability challenges.
Prior to his current role, he received his Bachelor’s degree in Engineering Mechanics and Astronautics from the University of Wisconsin and worked on applying statistical methods such as DOE, Gaussian Process Models, and Uncertainty Quantification to engineering problems.
Zachary is an expert in various reliability engineering techniques. He teaches and supports clients in applying methods such as FMEA, Life Data Analysis, Accelerated Life Testing, Reliability Growth Analysis, Systems Reliability Analysis, RCM, RAMS, and DFR. With a strong focus on customer success and technical communication, he is dedicated to helping clients optimise their reliability processes.
This will bring together HBM, Brüel & Kjær, nCode, ReliaSoft, and Discom brands, helping you innovate faster for a cleaner, healthier, and more productive world.
This will bring together HBM, Brüel & Kjær, nCode, ReliaSoft, and Discom brands, helping you innovate faster for a cleaner, healthier, and more productive world.
This will bring together HBM, Brüel & Kjær, nCode, ReliaSoft, and Discom brands, helping you innovate faster for a cleaner, healthier, and more productive world.
This will bring together HBM, Brüel & Kjær, nCode, ReliaSoft, and Discom brands, helping you innovate faster for a cleaner, healthier, and more productive world.
This will bring together HBM, Brüel & Kjær, nCode, ReliaSoft, and Discom brands, helping you innovate faster for a cleaner, healthier, and more productive world.
This will bring together HBM, Brüel & Kjær, nCode, ReliaSoft, MicroStrain and Discom brands, helping you innovate faster for a cleaner, healthier, and more productive world.
