Blog

What is FMEA?

Caution: When it's a Design FMEA, stay out of process!

As a teacher and consultant, the late Dr. W. Edwards Deming developed a new management philosophy. He devoted his life to helping leaders in business, education, and government service to understand and implement a process for transforming the Western style of management. Deming’s management system was grounded in what he called “the system of profound knowledge.” As he presented it, profound knowledge is made up of four components, each of which interacts with the others:

Appreciation for a system
Some knowledge of the theory of variation
Theory of knowledge
Psychology

A technique that combines the first two components of profound knowledge is Failure Mode and Effects Analysis (FMEA). When applied by cross-functional teams with representatives from different groups, departments, or functions, FMEA can be an effective way to benefit from a broad systems perspective. Statistical methods come into play when teams are studying processes for potential failures, especially in activities directed toward defect detection and process control.

Dr. Joseph M. Juran wrote that FMEA “provides a methodical way to examine a proposed design for possible ways in which failure can occur.” Effective application of FMEA techniques can result in dramatic improvements in quality and productivity. Among other benefits, FMEA provides a structured method for teams to make development plans more robust by addressing actions to reduce risk and increase yields before failures occur.

Failure Mode and Effects Analysis provides a means to study a design or process that seeks to anticipate and minimize unwanted performance or unexpected failures. FMEA seeks answers to the question, "What can possibly go wrong, even if the product meets the print or specification?" At the risk of over-simplifying it, the FMEA documents teams' and engineers' thought processes.

The American Society for Quality (ASQ) describes FMEA as a "step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service."

"Failure modes" means the ways, or modes, in which something might fail. Failures are any errors or defects, especially ones that affect the customer, and can be potential or actual. "Effects analysis" refers to studying the consequences of those failures.

Failures are prioritized according to how serious their consequences are, how frequently they occur and how easily they can be detected. The purpose of the FMEA is to take actions to eliminate or reduce failures, starting with the highest-priority ones.

Failure modes and effects analysis also documents current knowledge and actions about the risks of failures, for use in continuous improvement. FMEA is used during design to prevent failures. Later it's used for control before and during ongoing operation of the process. Ideally, FMEA begins during the earliest conceptual stages of design and continues throughout the life of the product or service.

Properly applied, FMEA is an iterative process that never ends. Even once completed, the FMEA document continues to communicate to everyone who accesses it in the future. To achieve the greatest return on the time invested, the FMEA must be done before a design or process failure mode has been unknowingly designed into the product, machine or process. Time spent up front in doing a comprehensive FMEA well, when changes can most easily and inexpensively be implemented, will alleviate late change costs and crises.

When performing a Design FMEA, stay out of the process!

Most often, Failure Mode and Effects Analysis comes in two species: Design and Process FMEA. FMEA is also applicable, however, to new machinery designs (Machinery FMEA) and to anticipating problems and failures once the product is in the hands of the customer (Application FMEA). In my experience, the species of FMEA that is most often applied incorrectly is Design FMEA.

The scope of a Design FMEA begins shortly after initial conceptualization (during Stage 1 of the design process) and is completed prior to design release. In other words, stay out of process! When viewing clients' Design FMEA documents, I find two common mistakes that result in an incorrect and/or ineffective Design FMEA effort.

Causes of failure. Too many people list possible causes of failure like "bad incoming material." No – this is a process-related cause of failure! The Design FMEA must be completed before design release. How can I have bad incoming material before design release? The difference between a Design FMEA cause of failure and a Process FMEA cause of failure is sometimes nothing more than the four-letter-word "spec." In other words, "bad incoming material" belongs on a Process FMEA. "Bad spec for material" or "material viscosity spec too low" would be a design-related cause of failure.
Design controls. Clients may also list process controls instead of design verification techniques. For example, "incoming inspection" or "in-process inspection" is sometimes listed as a control for a failure or potential cause of failure. I haven't yet released the design; how can I perform incoming inspection? Such controls are nothing but an excuse for releasing a bad design. Design verification is conducted to test and assure that the specifications are good prior to design release.

Let's wrap up this blog by just considering the procedure for a properly-conducted Design Failure Mode and Effects Analysis.

Design FMEA Procedure

List design function and requirements. What does the customer expect this product to do?
List potential failure modes. What could go wrong? How could it fail to meet its intended function?
List effects of the failure mode. What effects does the failure mode have?
Rank severity of the effects (1-10 scale). How bad is it?
List potential causes of the failure mode. What could have caused the failure from a design standpoint and from a design standpoint only? (Bad spec's; wrong material selected; incorrect specified settings; lack of adequate instructions provided; etc.)
Rank frequency of occurrence (1-10 scale). How often does it happen? How often might it happen?
List current controls/design verification. What gave us our confidence in our occurrence rankings? How can the cause or failure be prevented or detected prior to design release?
Rank ability to detect the failure mode or its cause prior to design release (1-10 scale). How good is this method at detecting it?
Calculate risk priority number (RPN). RPN is the product of the severity times the occurrence times the detection ratings. If the risk priority number is "in the red" or greater than some agreed-upon threshold (RPN > 100 is common)...
List and plan recommended actions. What can be done? (Design change; new design controls; special controls; changes to standards, procedures, etc.)
After the action is taken, record the results and date of completion. Estimate and record new severity, occurrence and/or detection ratings and re-calculate the RPN. If necessary, plan additional action to further reduce the RPN.

Notes

J. M. Juran and F. M. Gryna, Ed., Juran's Quality Control Handbook, Fourth Edition, McGraw-Hill Book Company, New York, NY (1988), p. 13.28.

J. F. Leonard, Failure Mode and Effects Analysis: FMEA Techniques for Study of Designs and Processes to Anticipate and Prevent Failures, Seminar Workbook, Jim Leonard Process Improvement, Woodstock, CT (2016), pp. i, 2.1, 2.10, 3.3.

N. R. Tague, The Quality Toolbox, Second Edition, ASQ Quality Press, Milwaukee, WI (2004), pp. 236-240.