C2.3 Failure-mode decomposition

Failure mode and effects analysis [8]

What it requires. Every process in scope is broken into functions, each written as a verb and a noun, and each function into the ways it can fail to do what its verb says: not at all, late, partially, to the wrong party, in the wrong amount. For each failure mode the effect and the cause are recorded, and the controls in place are tagged by whether they act on the cause or on the mode. The decomposition applies to any process, a payment run or a hospital discharge as much as a weld.

Where it comes from. Failure mode and effects analysis [8] is the oldest technique in the book, from military reliability engineering at the end of the 1940s through aerospace into the automotive supply chain. The procedure names the functions of the item first, and only then lists failure modes, effects, severities, causes, occurrences and the controls that prevent or detect. A failure mode is always the negation of a function, so a register built this way cannot contain “IT risk” as a line, because that is not a function.

What it reconciles. C2.2 says what a well-formed risk looks like; C2.3 says where to look for one, and the two sources did not know about each other. A failure mode found by decomposition is written up as a statement: the condition is the cause, the departure the mode, the asset the function's output, the consequence the effect against an objective. The decomposition also gives chapter 11's event cluster its upstream term: a failure mode is a potential, a loss event is a mode that happened, and an incident in L5 can be matched to the mode that predicted it, or to the absence of one.