INNsight · cascading risk

Cascading risk: from project risk down to FMEA

An industrial company that does things properly has three risk analyses: the strategic one, the project one and the technical one. They are almost always disconnected, and that disconnection is what turns FMEA into paperwork. This piece covers the last stretch, with three cases taken down to the failure mode.

01 · The problem

Three levels of risk that almost never talk to each other

In an industrial company doing things reasonably well, three risk analyses coexist. Each has its own meeting, its own template and its own owner. And they are almost always disconnected from one another.

LevelToolWho owns itHow often it is looked at
Strategic SWOT, portfolio matrix, the “risk of not doing it” Management Once or twice a year
Project Risk register: probability, impact, owner, response plan Project management At every project review
Technical Design and process FMEA: severity, occurrence, detection The technical office and quality At design milestones and before industrialising

There is plenty published about each of them separately. About how they link together there is very little, and that is exactly where projects get lost: a risk management identified in January that never became anything anybody could check on a drawing.

— Where this INNsight fits

The first two levels — from SWOT to the risk register — are already covered in From SWOT to risk register. They are not repeated here: this piece starts where that one ends and covers the last stretch, the one that reaches the FMEA.

02 · The missing link

A risk is only actionable when somebody can check it

“We depend too much on a single supplier” is a true and completely useless sentence. It cannot be assigned, cannot be verified and cannot be closed. Nobody can open a drawing on Tuesday and do anything with it.

The descent between levels means answering the same question three times —and where does that show up?— until you reach something measurable:

— The test that it has descended all the way

A risk has reached the technical level when it can be written in this form: “if [cause], then [failure mode] in [part or step], and whoever suffers it notices [effect]”. If the sentence cannot be completed without inventing, the descent is not finished.

03 · The descent

Three cases, taken all the way down

Pick a case and follow the full descent. All three are ordinary situations in industrial products; none is a textbook example. At the last level you can move severity, occurrence and detection to see how the action priority changes.

From strategic risk to failure mode

Pick a case · move S, O and D below
Level 1 · Strategic

—

Where it appears—
Horizon—

—

Level 2 · Project

—

Probabilidad—
Impacto—
Owner—
Response—

—

Level 3 · Technical · FMEA

—

Part or step—
Cause—
Effect—
NPR 192 = S × O × D
High priority

— On RPN and action priority

RPN (severity × occurrence × detection) is the classic indicator and is still useful for sorting a list. It has a known defect: identical numbers can mean very different things — 8×2×5 and 2×8×5 both give 80 and have nothing in common. This is why the current automotive reference replaced RPN with an action priority in bands, which weights severity above everything else. The band shown above follows that criterion as a guide; the full official table is in the manual, and anybody auditing under IATF should check against it.

04 · The three numbers

What justifies each one, and the mistake that invalidates them

The most expensive confusion in FMEA is treating S, O and D as three opinions from the same team in the same meeting. They are not: each is justified by different evidence and lowered by a different action.

— The rule that organises all of the above

Prevention acts on the causa and justifies occurrence. Detection acts on the failure mode and justifies detection. When both columns are filled in with the same thing — “visual inspection” in each — the FMEA has stopped measuring anything.

And a practical consequence: a severity of 9 or 10 is reserved for personal safety or legal non-compliance. If a table has fifteen rows at severity 9, either the product is extraordinarily dangerous or the scale has been inflated, and the second is far more common.

05 · Quick diagnosis

Five signs that the FMEA is paperwork

None of these signs needs an audit to be seen. You check them by opening the document:

— The cost of it not descending

When the descent is not made, the risk does not disappear: it simply reappears later and more expensively. What is solved at concept stage by changing one dimension is solved, once the tooling is cut, with a new mould. It is the same risk; what has changed is how many degrees of freedom are left to respond with.

06 · Further reading

Where each level comes from

This INNsight links together frameworks that exist separately. These are the references for each, for anybody wanting the detail.

— International standard

ISO 31000 · Risk management

Principles and guidelines applicable to any organisation. It provides the common vocabulary and the cycle identify → analyse → evaluate → treat → monitor, which is what the three levels run through.

— Project management

PMBOK Guide · PMI

Its project risk management area defines the register, qualitative and quantitative analysis and response planning. It is the reference for level 2.

— Failure analysis

AIAG-VDA FMEA Handbook

The joint reference of the North American and German automotive industries. It introduces banded action priority in place of RPN and separates prevention controls from detection controls.

— The underlying method

IEC 60812 · Failure modes and effects analysis

The international standard defining the FMEA method independently of sector. Useful when the product is not automotive and the AIAG-VDA handbook does not apply directly.

— Medical devices

ISO 14971 · Risk management for medical devices

For medical devices this is the risk framework, and its logic is different: risk is weighed against clinical benefit and acceptability is documented explicitly.

— Product development

Donald Reinertsen · Principles of Product Development Flow

A rigorous treatment of uncertainty in product development. Its central argument — reducing variance is worth more than reducing the mean — is what justifies taking risks down early.