fmea
fmea
Failure Mode and Effects Analysis (FMEA, military/aerospace lineage, later AIAG-VDA) anticipates how a process, product, or design can fail by listing each way it can break, scoring severity, occurrence, and detection, then acting on the worst before they happen. It catches the failure where a known risk is named and scored but never acted on: every high-priority mode must leave with a specific change that reduces S, O, or D.
The seven columns (failure mode, effects, severity, causes, occurrence, controls, detection), the three anchored 1-to-10 scales, the RPN and criticality computations, the action-priority rules, and the pitfalls live in references/fmea.md. Load that file before scoring.
When to use
Use before launching or changing a process, product, or design where failures carry real cost, safety risk, or regulatory exposure, and where the system is decomposable into functions, steps, or components worth scoring one at a time. Pairs with pre-mortem, its qualitative cousin: a pre-mortem imagines one big failure of a plan and works backward through its story, FMEA enumerates and scores many failure modes of a system. Also pairs with six-sigma-dmaic, where an FMEA often supplies the Analyze and Improve phases. Reach for pre-mortem when the subject is a one-off plan with a single dominant way to fail; reach for FMEA when the subject is a system with many independent failure points.
Language
Conduct the session and write the report in the language the user is writing in. The reference file is English; keep the framework keyed to it regardless of the output language.
Inputs
- SUBJECT (required): the process, product, or design under analysis, and its BOUNDARY (where it starts and stops, what is in scope and what is assumed reliable outside it). If only a vague subject is given, fix the boundary with the user in Stage 1.
- TYPE (optional): whether this is a process FMEA (PFMEA, scoring process steps), a design FMEA (DFMEA, scoring components and functions), or mixed. If absent, infer from the subject.
- CONTEXT (optional): known failure history, safety or regulatory requirements, existing controls, and the action threshold the team will commit to. Absent a stated threshold, propose one in Stage 3.