We want to assure the quality of our designs. We want to prove to ourselves and to our business leaders that we are appropriately addressing risk, but we don’t want to waste time or turn risk management into a overburdening task.
Our process improvement and risk management tools are nothing more than a means of organizing and communicating information. There are many tools to choose from and each serves a purpose. Sometimes we have more than one tool for the same purpose and we develop our preferences depending upon our critical concerns.
What we don’t always consider is that using two tools can be faster than using one. It is true when we achieve a synergy between the two tools. My favorite combination of risk management and quality assurance tools is a synergy of Fault Tree Analysis and Failure Modes and Effects Analysis (FMEA). Let me explain why.
The FMEA has been the go-to tool for risk analysis and failure prevention since the 1940s. It is an excellent tool because its proper use drives us to identify potential failure modes and root causes, predict the effects of failures, assess the severity of such outcomes, predict the probability of the occurrences and prioritize how we will address each. It is a very thorough process and tool.
The down side of “thorough” is that it is necessarily time consuming. When the FMEA matrix begins to exceed 100 lines of potential failures, it’s no longer a practical exercise, it’s drudgery and the effectiveness of the tool as a tracking and communication instrument begins to break down. When the possible failures stretch to 400 line items, it can take a month just to fill out the matrix.
As a result, many engineering teams that I have encountered prefer a Fault Tree Analysis, or one of many similar tools to predict and proactively address risk. There are hundreds of practical and useful ways to deploy a fault tree, beginning at a high level and running over the whole system, or doing a miniature tree for each component. It can be relatively quick and efficient, especially if the design is already mapped in a component tree or function diagram format.
The limit to the fault tree tools is that they don’t plainly identify and track the most important potential failures, the plans to mitigate or prevent them, or the progress toward the completion of those plans. It is typically quicker to perform than FMEA, but it lacks the depth of information.
So, many years ago, some of my engineering partners and I developed a way to have our “quick and dirty,” and our assurance of quality too. We began using them both. On top of that, we achieved better information and tracking instead of having to compromise. Synergy.
We decided to use the fault tree tool to rapidly map out the realistic failure modes of a system. We did this in our favorite way without modification. Once we were satisfied that we had the right fault tree, we began identifying those faults that promised the most disastrous effects if they were to manifest. We marked a corner of the box on the tree for each of those.
At this point our mark didn’t try to assess a relative or comparative value, we just wanted to identify those of significant concern. Then we did the same thing for those that were likely to occur often enough that a design plan to address their possibility was worth considering. We put a mark in the opposite corner of the box for these.
Once we had our marked up fault tree, we broke open the FMEA. We transferred only the faults or failures with a mark in the box to the FMEA. Then we performed the standard FMEA rigor on those items. The result was very successful.
Because we began with the fault tree discipline, we ended up with a better breakdown of the failure modes that we typically did with FMEA alone. If we are conducting the FMEA properly, we begin with a component list and a function list to identify failure modes, but the fault tree proved to be an improved method.
One of the unfortunate side effects of the FMEA method, beginning with a parts list and a function list is that, conceivably, every part can fail, and every function can fault. If you don’t have a good rule-of-thumb or common sense filter, the FMEA is populated with a great deal of unnecessary considerations. Even though the method enables us to filter these out as we go, the very process of doing so is extraordinarily time consuming, and tedious, and is not real constructive.
The fault tree method made it easier to put a pragmatic filter on our fault and failure identification process, and it also made it easier to perceive potential interactions or interferences between the functions, which our FMEA method did not. We had a quicker, more pragmatic, and, in some ways, more realistic breakdown of the potential failures.
Our FMEA was populated only by those things that we knew deserved some attention, and it was much more efficient to assess and score these items and to allocate priority and plans. Our FMEA was useable and we were confident it addressed the important issues.
There was one final advantage. At that time, our team had a habit of trying to design out risk using a principle from Axiomatic Design practices. We tried to find ways to eliminate several potential faults with a single design change or element, to simplify the design and consequently eliminate potential failure modes. The FMEA made it easy to pick out our primary targets and the fault tree helped us imagine the opportunities and predict the interactions.
It worked so well for our first team that it caught on without any process improvement push. Immediately everyone in the design center replicated the approach and so did some teams in other design centers. I have used the combined approach ever since.
I have seen, too, that we were not the only ones to discover the benefits of the combined tools, nor do I believe we were the first. I also know, that not everyone has, and that everyone who uses FMEA dreads it, and that fault tree analysis alone simply cannot produce the same quality planning and failure elimination.
So, I offer this lesson up to everyone. If you need better failure-modes analysis, if you are worn out of doing FMEA, or if you are disenchanted with using tools to no practical effect, try combining FMEA with fault tree analysis. Use each to overcome the weaknesses of the other, find that synergy, and rebuild your confidence that you can practically, efficiently, and effectively design out failures.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com
Filed Under: Rapid prototyping
