Dealing With Risk In Product Development

Failure Modes & Effects Analysis is an incredibly valuable tool for assessing and dealing with risk in product development. However, the traditional “Risk Priority Number” or RPN-taken alone-doesn’t always give clear indications about how you should deal with risk.

What Are Some of the Other Ways to Assess Risk in FMEA?

One way is to simply look at each row on the FMEA form as a self-contained story about one limited aspect of a design or a process. Certainly, developing the FMEA yields a much more useful and meaningful result if you work through the form on a column by column basis—but that doesn’t change the fact that each row tells a tale.

And those line-by-line stories are built around specific cause-mode-effect (C-M-E) chains, because the occurrence and severity ratings are the major factors that determine risk. Certainly, the ability to detect a cause or an effect prior to design release or to process completion does have some impact on risk, and detection is not without importance. Detection, though, is less significant because it is always an imperfect element of risk management.

The biggest impact on risk arises from the severity and occurrence ratings.

With this in mind, the simplest way to assess risk is to read each row, and then, without any kind of calculation or formal rules, just sort the rows into three categories:

    • Those that make you worry a great deal—these are red risk
    • Those that you don’t think are really significant or worth much worry—green risks
    • All of the other rows, with a level of concern between the other two categories—yellow risks

I’ve been looking at FMEA studies—both those I’ve worked on personally and those completed without my participation—for many years and I’ve never had trouble sorting every row into one of these three categories. And, while doing that, I’ve rarely had much disagreement about these judgments from others.

Adding More Formality–But Potentially Less Understanding

Of course, there’s a lack of formality in assessing risk this way, and that informal approach makes many people—particularly senior managers and executives, who don’t always want to apply the effort and take the time to fully understand the details of risk and just want a more recognized and less opinion-based judgment. There’s also a very real concern about bias when it’s done just by high-level judgment.

There are more structured ways to do approximately the same thing, and most of these are based on the concept of criticality—the product of the severity rating and the occurrence rating. The original idea was simple—a higher value means more risk. But, as I explained in the previous Lighthouse post, this still assumes that severity and occurrence have equal significance, and that’s just not true.

So, over the years, various schemes have been proposed to evaluate the concept of criticality. Most are based on these ideas—and detection is not really a factor:

    • Any C-M-E chain with a severity of 9 or 10 is critical. Since human safety and/or serious regulatory issues are likely if a failure mode arises, the impact of occurrence (or detection) does not diminish the fact that this is a potentially serious chain of events.
    • A C-M-E chain with a reasonably high severity (say 5, 6, 7, or 8) in combination with a moderately high occurrence, typically 4 or more, is significant. Moderate severity with a lower occurrence doesn’t meet this test, nor does a high occurrence with a low severity.
    • Anything else is neither critical nor significant.

In this approach, any row—or C-M-E chain—that is either critical or significant requires a classification designation. This is what that skinny “classification” column is all about on most FMEA forms. However, this does not directly identify critical and significant characteristics; the classification is all about the C-M-E chain of events. Characteristics (or parameters for PFMEA) are a separate consideration, and it doesn’t necessary jump out from the FMEA form, unless the concept of function and functional requirements have been carefully worked out as part of the FMEA study.

So, if a C-M-E chain is classified as critical, there must be one or more critical product characteristic that drive the risk. In DFMEA, this can be found in the Function/Functional Requirements columns of the DFMEA. In PFMEA, this often requires a cross-reference to the associated DFMEA, as critical characteristics are always features or requirements that relate to the design of the product, and these don’t always show up clearly in a PFMEA study.

Significant classifications can lead to either a significant characteristic (again, a design element) or to a significant process parameter. Significant characteristics should be available directly from the functional section of the relevant DFMEA. Similarly, in Process FMEA, significant process parameters should be evident in the functional section of the PFMEA itself.

The major drawback with this approach is that less understanding and less attention is paid to risk that ends up leading to a product characteristic or process parameter that’s identified this way. That happens because the rules don’t force careful consideration of the risk issues. The other drawback is that this still assumes that severity and occurrence are equally significant, so sometimes distortion of risk is the result.

 

The Latest Method–Worth Considering

Finally, the 2019 Edition of the Automotive Industry Action Group (AIAG)-Verband der Automobilindustrie (VDA) FMEA handbook takes an approach that may bridge the gap between a simple “red-yellow-green” approach and more formal criticality methods. The AIAG-VDA approach has these features:

    • The results will be organized into three categories, called Action Priorities
    • There will be high, medium, and low categories
    • High issues must be acted on, medium issues should be acted on, and low issues may be considered for action
    • This is not explicitly about risk; instead, this is prioritization of issues that should be undertaken to diminish risk
    • There are guidelines about how to identify high, medium, and low priorities, but they are not completely dissimilar from the ideas that have been used to specifically define criticality using severity and occurrence

There are guidelines about how to identify high, medium, and low priorities, but they are not completely dissimilar from the ideas that have been used to specifically define criticality using severity and occurrence.
Severity is still called severity, but what’s been called occurrence is now called frequency, and detection is now called monitoring. Still, these are still basically the same ideas. There are (as always) new rating tables for these three concepts

After using the Action Priority approach a few times, I’ve found it to be a useful tool that is about the same as the very simple red, yellow, and green assessments I explained above.

As an example of why “action” is more useful than just high risk, consider a safety device that has several C-M-E chains with severities of 10. If the occurrence associated with these chains are all 2, and the detection is 2 in each chain (bearing in mind that getting to an occurrence rating and a detection rating of 1 requires some extraordinary evidence in most rating tables), is there really anything that can be done about this risk—at least at any practical cost?

In these cases, I’ve always said that the main response is to have a very high coverage limit product liability umbrella insurance, because the probability that something will go wrong is very low, and you are very likely to find this before it gets to the marketplace. But if it does, and something goes awry, the consequences can be harsh.

Risk Is Never Just a Number

When you really step back and think about it, any way you approach this, you are using less-than-purely-quantitative methods to assess the factors that drive risk, and then use less-than-purely-quantitative rules to decide what you might do to address the risk you’ve found. And risk can never be eliminated, but can always be managed.

In the end, it’s still judgment, as risk assessment has always been (and may forever be).  Nevertheless, intelligent decision-making based on circumstances and risk preferences can be improved signficantly by applying these ideas.

Author: Michael A. Anleitner

Michael A. Anleitner is founder and President of Livonia Technical Services Company. He has 47 years of industrial experience, and holds a B.A. degree in technical communications from Michigan Tech, a B.S. degree in engineering from Wayne State University in Detroit, and an MBA from the Ross School of Business at the University of Michigan.

One thought on “Dealing With Risk In Product Development”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.