FMEA: arguing about how a process will fail before it fails

Design failure modes and process failure modes are separate conversations

A design analysis asks what the product can fail to do for the customer, given how it will be used, misused, assembled and serviced. A process analysis takes the design as fixed and asks what the manufacturing steps can do to it: wrong part fitted, feature out of tolerance, contamination introduced, step omitted, damage in handling. Mixing them produces a document that satisfies neither, because the design questions have no owner in the plant and the process questions get waved away as engineering's problem. Run them as separate exercises with different attendees, and let the design output feed the process one.

Who is in the room decides what the analysis is worth

The failure modes that matter are usually known to somebody already: the setter who knows the fixture can be loaded backwards, the assembler who knows two variants look identical in the bin, the service technician who sees what comes back. Without those people, the exercise recycles textbook failure modes and misses the ones that will actually happen. It also needs someone who can say no — a facilitator willing to reject a vague failure description or a control that exists only in principle. Long sessions with a large group produce fatigue and inflated agreement, so run them short and repeatedly.

Severity is reliable, occurrence is a guess, detection is flattered

Of the three rankings, only severity can be argued from the design and the application with any confidence, and it does not improve without changing the product. Occurrence is usually estimated from opinion because nobody has the failure data for a process that has not run yet. Detection is the one teams systematically overrate, crediting inspections that sample rather than screen, checks that depend on an operator noticing something subtle, or gauges that cannot see the failure mode at all. The most productive challenge in any session is asking, for each claimed control, what evidence exists that it has ever caught this.

If nothing changed, the analysis did not happen

The measurable output is a list of actions with owners and dates, and a set of changes that appear in the control plan, the inspection instruction, the tooling design or the product itself. Where the team decides to accept a risk, that acceptance belongs in the record with a name against it, because unrecorded acceptance is indistinguishable from oversight when someone reviews the document after a field failure. Ranking every line and acting on none is the common failure state; it produces a large document, a satisfied customer auditor, and no change to the probability of anything.

The triggers that force the document back open

A live analysis is revisited when reality contradicts it: a field failure or warranty claim for a mode ranked as unlikely, a defect that escaped a control rated as effective, a process or supplier change, a new material, a tooling replacement, transfer of the line to another site, or a design change however minor it looks. Someone has to own the trigger list and the review, or the document ages into fiction while the process moves on. Read-across from other products matters too — a mode confirmed on one line should be reassessed on every line that shares the mechanism.

Frequently asked questions

Is the risk priority number worth calculating?

It is useful for sorting a long list and dangerous as a threshold. Multiplying three subjective rankings hides the difference between a rare failure with catastrophic effect and a frequent nuisance, and teams learn to score just under whatever value triggers mandatory action. Better practice is to act on high severity regardless of the other rankings, then use the composite ordering only to sequence the remaining work.

How detailed should the process analysis be?

Detailed enough that each line corresponds to something a person or machine actually does and could get wrong, and no finer. Analysing every micro-movement produces hundreds of lines that nobody will maintain and buries the handful of modes that will bite you. A workable granularity is the operation as it appears on the routing, with sub-steps broken out only where the failure mechanisms genuinely differ between them.

Who owns the document once the launch team disbands?

The process owner for the area, with quality maintaining the revision history and calling the reviews. Leaving it with a launch or programme team means it is orphaned the day that team moves to the next project, which is exactly when production starts generating the real failure data. Handover should be explicit, with the incoming owner walking the analysis against the running process to confirm the described controls still exist.