FMEA: failure mode and effects analysis, step by step

Every FMEA template uses roughly the same columns. Here they are, filled in for one illustrative line from a packing process:

Severity rarely moves after an action, because the effect of a wrong label is the same. What changes is how often it happens and how likely it is to be caught.

The steps below follow the order most handbooks use. Keep the scope small enough to finish.

1. 1

   Define the scope. Name the product, subsystem or process, its boundaries and what is out of scope. One line or one service flow is plenty for a first FMEA.

2. 2

   Assemble the team. Bring design, operations, quality, maintenance and the people who do the work. The facilitator keeps entries specific and the discussion moving.

3. 3

   Map the functions or steps. For a design, list functions and requirements. For a process, draw the steps from input to output.

4. 4

   List failure modes and effects. For each step, ask how it could fail and what the next user would experience.

5. 5

   Find causes and current controls. Write down why each failure could happen and what prevents or detects it today. Record controls honestly, including the informal ones.

6. 6

   Score and prioritize. Rate severity, occurrence and detection, then rank by RPN or action priority.

7. 7

   Assign actions. Give each high-priority line a specific action, an owner and a date.

8. 8

   Re-score after action. Update the ratings once the change is in place, and keep the worksheet alive as the design or process changes.

Vague entries are the most common reason an FMEA leads nowhere. Each entry should point at something you can observe and change:

'Operator error' may be true, but it gives the team nothing to fix. Ask what makes the error possible: similar part numbers in adjacent bins, a missing check, an unclear instruction. That deeper cause leads to a stronger action.

FMEA separates two kinds of control, and the difference matters when you choose actions:

Controls that depend on memory are weaker than they look on the worksheet. In the Uptime Institute's 2025 outage analysis, 85% of major data center outages caused by human error stemmed from staff not following procedures. A written procedure is a control, but a fragile one.

Most worksheets rate each factor from 1 to 10. Severity rates the effect, with 10 for a safety or regulatory failure. Occurrence rates how likely the cause is. Detection rates how unlikely current controls are to catch it, so 10 means almost certainly missed.

The numbers are estimates, so the habits around them matter more than the scale:

• Agree the scale first: Write what a 3, a 6 and a 9 mean for your product before anyone scores.
• Use evidence: Complaints, test data, maintenance logs and audit findings ground the discussion.
• Keep severity separate: Severity reflects the effect only, not how likely or detectable it is.
• Avoid false precision: Arguing between a 6 and a 7 rarely changes the action.
• Re-score only after real change: If the cause, control or effect did not change, the rating should not either.

These examples are illustrative, with made-up ratings, to show the chain from failure mode to action:

The pump case shows why maintenance lines deserve attention. A NIST study of US manufacturing estimated that preventable maintenance issues cost manufacturers $119.1 billion in 2016, mostly in sales lost to defects and downtime.

The worksheet is the same, but the subject changes:

A PFMEA usually feeds a control plan, which lists what is checked, how and how often in production. The SPC page covers how those checks are charted.

An FMEA done after every decision is locked has little power. Common triggers:

• New design or product launch: While choices are still open.
• New or changed process: Including automation and new equipment.
• Transfer of work: To a new site, supplier or team.
• A recurring problem: When complaints or defects keep coming back.
• A safety or compliance concern: Before an audit finds it.
• A supplier or material change: That could shift how often causes occur.

Most FMEA problems come from treating the worksheet as a form to fill rather than a way to think:

1. 1

   Starting too late. The design or process is already fixed, so actions are limited to inspection.

2. 2

   Vague language. Failure modes and causes too general to act on.

3. 3

   Overrating weak controls. Informal checks and reminders scored as if they were reliable.

4. 4

   Arguing over scores. More time spent defending numbers than reducing risk.

5. 5

   Unclear actions. 'review process' instead of a specific change with an owner and a date.

6. 6

   Dismissing high severity. A low occurrence guess used to skip a serious effect.

7. 7

   A stale document. New failures, changes and lessons never added.

A good test is whether someone outside the meeting could read the worksheet and follow the logic:

• Failure modes linked? Each one ties to a step or requirement.
• Effects from the user's view? Written as the customer or next step would see them.
• Causes specific? Specific enough that someone could prevent them.
• Controls real? Active and relevant, not just written down.
• Top risks acted on? The highest-priority lines have real actions.
• Owners and dates? Every action shows who and by when.
• Re-scored? Ratings were updated after actions closed.
• Still in use? The worksheet comes up in reviews, launches and changes.