Failure Mode and Effects Analysis (FMEA)

A process can fail in several ways before a customer notices: a shipment might carry the wrong label, a sensor could misread, or a software rule might reject a valid payment. Failure mode and effects analysis organises those possible failures before they cause harm.

The American Society for Quality describes FMEA as a structured way to identify and prioritise potential failures and their effects, and the AIAG and VDA handbook describes a formal automotive approach, though exact scoring and priority rules depend on the method being used. Set the scope, since a product design, manufacturing process, service workflow and software change need different boundaries and a vague study of the whole company will miss details.

Map the steps by describing what each operation or component should do, because without a clear function it is difficult to define a failure. Then identify failure modes by stating what could go wrong at the step, such as an incorrect dosage, missing seal or delayed approval, and avoid simply writing "human error." Describe effects by explaining what the customer, next process or system would experience, since a minor internal rework and a safety-critical failure have different consequences.

Identify causes, because a supplier defect, unclear instruction, worn tool or software configuration might generate the same failure mode, and controls should address causes where possible. List current controls too: prevention controls reduce the chance of failure and detection controls find it before harm, so describe what the control actually does, not merely that a checklist exists.

Consider severity, occurrence and detection in turn: many methods use a scale to rate the seriousness of an effect, and the highest-severity hazard deserves attention even if its estimated frequency is low. Estimate occurrence using suitable evidence, because sparse data calls for uncertainty, not a false precise score, and ask how likely the failure is to escape the existing checks, since a visual inspection may perform differently from an automated test.

Use scoring carefully: some FMEA methods multiply severity, occurrence and detection into a risk priority number, but equal products can hide very different risk profiles, and a high-severity failure should not be ignored just because its product score falls below an arbitrary threshold, so follow the relevant framework. Assign actions, with each priority needing an owner, deadline and proposed change, since "Train staff" may be inadequate when a process design can prevent the error.

Prefer prevention where feasible, because an interlock that stops the wrong material can be stronger than a final inspection that catches some mistakes after production. Test new controls, since a proposed barcode check is only useful if it rejects wrong codes and operators cannot routinely bypass it, then rescore after action by recording what control was implemented and how occurrence or detection changed, without reducing severity just because a better detection step was added.

Include cross-functional voices, since operations, engineering, customer support, safety and suppliers can see different failure paths and the team should match the scope, and update the analysis when things change because new materials, demand, software or field failures can make an old FMEA stale, so link it to change control and incident review. Distinguish analysis from compliance: a completed template does not prove a machine is safe or a regulatory standard is met, and specific sectors may require other analyses and formal approval.

For an owner, FMEA turns "what might go wrong?" into a traceable list of effects, causes, controls and actions, and its value comes from tested changes, not the number of rows scored.