Failure modes and effects analysis

Failure Modes and Effects Analysis was developed by the United States Armed Forces in the late 1940s and codified in 1949 in MIL-P-1629, a procedure for the systematic identification of the ways in which a military system might fail and the consequences of each such failure. The technique migrated from the Department of Defence into the National Aeronautics and Space Administration in the 1960s — the Apollo programme is the largest single deployment of FMEA in the technique’s history — and from there into civil aviation, the offshore petroleum industry, food production, and, in the 1970s, into manufacturing as a discipline of design and process review. Three-quarters of a century later, FMEA is still the most-used contemporary instrument for the deliberate, structured anticipation of how a system can fail before the system has been built.

The discipline answers three questions, in order. What can go wrong? — the failure modes. What happens if it does? — the effects. What is being done about it? — the controls, both the controls that prevent the failure mode and the controls that detect it once it has occurred. The output of the analysis is a register of failure modes scored on three dimensions — severity (how bad is the consequence), occurrence (how likely is the failure), and detection (how reliably is the failure caught when it does occur) — multiplied together to yield a risk priority number by which failure modes can be ranked and acted on in order.

The technique comes in two principal flavours. Design FMEA (DFMEA) is performed during the design of a new product or process; the failure modes considered are the ways the design itself could be inadequate to the work it is meant to do. Process FMEA (PFMEA) is performed on a manufacturing or service process and considers the ways the process could fail to produce the intended output. Most operations the practice works with are running processes; PFMEA is consequently the more commonly deployed of the two, and the form most often integrated into a kaizen event.

Three structural points about FMEA are worth surfacing for clients new to it.

FMEA is not a one-time analysis. It is a living register that is meant to be updated as the operation learns: new failure modes get added when they occur, scores get adjusted when controls are improved, and items get retired when the underlying mode is genuinely eliminated. Operations that treat the FMEA as a document produced once and filed get the appearance of the discipline and almost none of its operational benefit.

The scoring is approximate, and is meant to be. The severity-occurrence-detection scoring is a comparative ranking, not an absolute measurement. The number is useful for ordering action; it is not useful for predicting outcomes. The first time most teams complete an FMEA they spend too much time arguing about whether a particular score is a six or a seven. The discipline rewards roughly correct ordering more than it rewards precisely calibrated numbers.

The detection score is the underweighted one. Most teams new to the discipline focus on severity and occurrence, which are intuitive. The detection score — how reliably will this failure be caught if it occurs? — is the structural complement to the other two and is the one that distinguishes a robust operation from a fragile one. A failure mode that has been allowed to remain in the operation because it is unlikely will surprise the operation when the unlikely happens. A failure mode that has been allowed to remain because the detection is reliable is a different kind of risk, and the difference matters.

The discipline has its critics. Some Lean practitioners argue that the FMEA’s bureaucratic apparatus — the worksheets, the scoring, the review meetings — is the kind of thing the operation should be eliminating rather than producing. The practice’s view is that FMEA earns its keep when the failure modes under consideration are consequential enough that the analysis is worth the work, and when the operation has a culture of revisiting the register as the operation learns. Operations that adopt the technique cosmetically — to satisfy a customer’s quality audit, say — get the bureaucracy without the benefit. Operations that adopt it seriously typically reduce the rate of consequential failure they were previously expecting to absorb as a cost of doing business.

Seventy-five years on, the analysis NASA used to get the Apollo programme to the Moon is still the analysis a contemporary manufacturing line should be running on its own design and process. The technique has not been improved on.

· · ·