FMEA (Failure Mode and Effects Analysis) for Project Teams

What is FMEA and where did it come from?

FMEA is a systematic method for identifying potential failure modes, tracing each to its effect and cause, and prioritising action. It began in US military reliability work — MIL-P-1629, published in 1949, is the commonly cited origin — and spread through aerospace and automotive supply chains before reaching healthcare, software, and service design.

Two versions dominate practice. The classic approach (AIAG’s fourth edition and IEC 60812 in its earlier forms) scores three dimensions and multiplies them into a risk priority number. The 2019 AIAG & VDA handbook, produced jointly by the Automotive Industry Action Group and the German Verband der Automobilindustrie, merged the North American and German methods into one standard, introduced a seven-step process, and replaced RPN as the decision driver with Action Priority tables.

The reason for the change is worth understanding even if your team never builds a car, because it is a lesson about how scoring systems get gamed.

How do the three scores work?

Each failure mode gets three numbers from 1 to 10. Higher is worse for severity and occurrence; for detection, higher means worse detectability, which is why the scale feels inverted.

Two rules keep the scales usable. Score severity on the effect, not the likelihood — a rare catastrophe is still a 10. And score each cause separately when one failure mode has several, because the occurrence score belongs to the cause, not the symptom.

> Important note: Severity only changes when the design or process changes. Adding a detection control cannot make a severity-10 failure less severe; it can only make it less likely to reach the customer. Teams that “reduce severity” after adding a test are usually recording optimism, not improvement.

How do you calculate and read RPN?

Multiply the three scores. That is the whole calculation, and the number is only as good as the conversation behind each factor.

RPN = S × O × D, giving 1 to 1,000.

A worked row: a nightly ledger export can write a duplicate entry when the job is retried after a partial failure. Effect: customers double-charged, finance reconciles manually. Cause: retry without an idempotency key. Current controls: a nightly reconciliation report, which finds duplicates the next morning.

• Severity 8 (financial loss and data corruption, core function affected)
• Occurrence 5 (retries happen roughly monthly)
• Detection 6 (found by a report, after customer impact)
• RPN = 8 × 5 × 6 = 240

Now the action: add an idempotency key at the writer and a duplicate check that blocks the commit. After the change, occurrence might fall to 3 and detection to 2, because the constraint is enforced in code rather than observed afterwards.

• Revised: 8 × 3 × 2 = 48
• Reduction: 240 → 48, an 80% drop, with severity unchanged at 8

Notice that the arithmetic gives you a defensible before-and-after, but it does not tell you whether 240 was worse than another row scoring 216. That is the flaw the next section addresses.

Why did the industry replace RPN with Action Priority?

Because multiplication treats three very different things as interchangeable. Two failure modes can share an RPN and require completely different responses.

Consider a seat-belt anchor that could fail in a crash:

• Row A: S=10, O=2, D=2 → RPN 40
• Row B: a cosmetic label misprint: S=2, O=5, D=4 → RPN 40

Classic RPN ranks them identically. Anyone who has run an FMEA recognises the argument that followed: the team sets a threshold of 100, and both rows fall below it, so neither gets action. The safety-critical failure disappears into the same bucket as the label.

Action Priority fixes this by using a lookup table rather than arithmetic. Severity is the first axis, occurrence second, detection third, and the output is one of three levels: High, Medium, or Low.

The practical rule inside the AP logic is blunt: any failure mode with severity 9 or 10 is High priority regardless of how unlikely or detectable it is. You cannot detection-control your way out of a hazard.

Most project teams do not need to adopt AP formally. They do need the underlying discipline: never let a multiplication hide a severity of 9 or 10. A simple local rule works — any row with S ≥ 9 requires an action or a documented, signed risk acceptance, whatever its RPN.

How do you run an FMEA on a project process?

Scope it to one process, list the steps, and ask what could go wrong at each. The unit of analysis is the step, not the whole project — a 200-row FMEA of everything is a document nobody uses.

Six steps fit into a half-day workshop:

1. Define the scope and boundary. “The monthly production release, from code freeze to post-release monitoring.” Write the start and end explicitly; scope arguments consume more workshop time than scoring.
2. List the process steps. Six to twelve steps, in order.
3. For each step, name the function. What is this step supposed to achieve? “Deploy the new schema without locking tables.”
4. List failure modes. How does that function fail? Omission, wrong output, too slow, duplicated, partial, unauthorised. The software failure-mode taxonomy is short and worth keeping visible.
5. Score S, O, D with the team. Use anchors from real incidents where possible. Where the team disagrees, record the higher score and note the disagreement rather than averaging.
6. Write actions with an owner and a date. Not “improve monitoring” — “add an alert when replication lag exceeds 30 seconds, owner: data platform lead, by 14 March.”

The output is a worksheet, and the worksheet is the least valuable artifact. The value is the argument about occurrence scores, which surfaces assumptions nobody had written down.

A worked example: release process FMEA

A six-person team runs an FMEA on its release process. Six steps, eleven failure modes, three hours. An extract:

Three rows stand out. The rollback row scores highest at 280, driven by a runbook that has never been rehearsed. The smoke-test row scores 243 with a severity of 9 — a category of failure that should not depend on the RPN ranking at all. The freeze row scores 224 because the only control is a verbal agreement, which is not a control.

The action plan:

• Rehearse the rollback on staging, including the schema revert; owner: release manager; two weeks. Revised D: 7 → 3, RPN 280 → 120.
• Seed the smoke test with a production-shaped dataset; owner: QA lead; three weeks. Revised D: 9 → 2, RPN 243 → 54.
• Enable branch protection with a required review; owner: platform lead; one week. Revised O: 4 → 1, RPN 224 → 56.

Cost of the three actions: roughly 11 person-days, about $9,350 at $850 per day. Against that, the rollback failure alone — one 90-minute outage on a service with 4,000 transactions per hour and a $12 average order — costs about $72,000 in lost transactions before reputational effects. Even at a 20% annual probability, the expected loss of $14,400 exceeds the cost of all three actions combined.

Where does FMEA break?

Four weaknesses are structural, and knowing them prevents the meeting from producing false comfort.

The score is ordinal arithmetic. Multiplying ordinal ratings is mathematically questionable, and the resulting number has no units. A RPN of 240 does not mean twice the risk of 120.

Identical scores hide different risks. As the seat-belt example shows, S10/O2/D2 and S2/O5/D4 are not comparable, yet the arithmetic says they are.

Scales drift between teams and between months. One team’s “occurrence 6” is another’s “occurrence 3”. Without anchors tied to real incident history, the numbers measure the room’s mood.

Thresholds invite gaming. When a gate says “fix everything above 200”, the cheapest route to release is to argue a score down, not to fix the cause. Practitioners have documented this pattern for years: severity ratings quietly soften as the deadline approaches.

Two further limits matter for projects. FMEA examines failure modes one at a time, so combinations — two independent failures producing a compound outage — are invisible. And it is a snapshot: the process changes, and the worksheet does not.

The mitigations are unglamorous. Anchor the scales to your own incident history. Keep severity reviews separate from the delivery team that owns the deadline. Re-run the FMEA after any process change. And record disagreement rather than averaging it away.

What are the common mistakes?

Scoring without a cause. A failure mode with no specific cause cannot have a credible occurrence score. “Human error” is not a cause; “the release checklist is not enforced by tooling” is.

Treating RPN as a budget. Sorting by RPN and fixing the top five ignores severity-9 rows scoring 90 and the systemic causes behind ten medium rows.

Vague actions. “Improve testing” is a wish. “Add a contract test that fails the build when the response schema changes” is an action with a verifiable result.

No re-scoring. An FMEA without a revised S, O, D column cannot show whether the action worked, only that it was discussed.

Running it once. A single workshop produces a document that ages badly. Re-run at each major process change, or at minimum annually.

Facilitator owns the answers. If the facilitator also owns the process, occurrence scores drift upward in optimism. Independent facilitation is cheap insurance.

When is FMEA the wrong tool?

FMEA earns its cost when a process is repeatable, the failure consequences are uneven, and the team genuinely does not know which step deserves attention. It is poor value when the process is still being invented, because the worksheet will describe a design that no longer exists by the time it is finished.

Where does project tooling fit?

The worksheet is easy. Keeping the actions alive is not. FMEA actions are typically small, unglamorous, and land on people who already have a full queue — rehearse the rollback, seed the test data, enable branch protection. They get deprioritised quietly, and the revised RPN column becomes fiction.

Doitify keeps the action items as tasks and sub-tasks with owners, due dates, checklists, and dependencies in the same workspace as the project work, so a High-priority FMEA action competes for capacity visibly rather than living in a spreadsheet tab. Risks and constraints records can reference the failure mode and its score, which keeps the reasoning traceable when the worksheet is six months old. Doitify is our product, so read this as a description of fit: a team that already runs FMEA actions through a working task system has no reason to move, and a regulated manufacturer still needs its qualified FMEA software.

Conclusion

FMEA is a disciplined way to ask “how could this fail, how bad would it be, and would we notice?” It is not a scoring competition, and the number at the end of the row is the least important part of the exercise.

Scope it to one process. Write real causes. Anchor occurrence and detection to incidents you have actually had. Treat severity 9 and 10 as unconditional, whatever the arithmetic says. Then convert the top rows into actions with owners and dates, and re-score afterwards so the worksheet reflects the process as it now is.

A team that does this once usually finds two things: one failure mode it had been quietly accepting for years, and one control it believed existed but never did. Both are cheaper to fix in a workshop than in a reconciliation meeting.

If this post on FMEA was helpful, you might also enjoy Project Assumptions vs Constraints: What’s the Difference? (2026) and How to Consolidate Your Project Management Tools (2026 Guide).