An FMEA (Failure Mode and Effects Analysis) is a structured team exercise that walks through every way a product or process can fail, rates how bad each failure is, how often it happens, and how likely you are to catch it, then drives action on the worst risks before they reach a customer. This guide is the step-by-step how-to: the prep, the worksheet, the scoring, and how to run the session so it produces action instead of a filed spreadsheet.
Plenty of teams know what an FMEA is and still produce a useless one, because the value is entirely in the doing. A worksheet filled out alone by one engineer is documentation theater. A worksheet built by the right people, in the right order, with real numbers behind the scores, becomes the backbone of a reliability program. If you want the concept-level overview first, read our FMEA explainer; this page is the walkthrough for the person who has to actually run one on Monday.
When should you run an FMEA?
Run an FMEA whenever failure carries real cost and the design or process is still changeable. The classic triggers are a new product or process, a significant change to an existing one, a recurring field failure, a new safety or regulatory requirement, or a transfer of production to a new line or plant. The rule of thumb: do it early enough that fixing a finding is a design edit, not a recall.
Two families cover most work. A Design FMEA (DFMEA) examines how a product can fail because of its design. A Process FMEA (PFMEA) examines how a manufacturing or assembly process can produce a defective part. Maintenance and reliability teams also lean on FMEA to decide what to inspect and how often, which is why it sits under equipment reliability as much as under quality. The mechanics below apply to all of them.
What do you need before the first session?
Do not open the worksheet until three things are ready: a scoped boundary, the right people, and the reference material. Skipping prep is the single most common reason FMEAs stall halfway and never finish.
Scope. Draw a hard boundary around what you are analyzing. One subsystem, one process, one line. "The whole plant" is not a scope; "the filler and capper on Line 3" is. Write the boundary down so the team stops itself when it drifts.
Team. FMEA is a cross-functional exercise, not a solo one. You want design, manufacturing, quality, maintenance, and an operator or technician who actually runs the equipment. Four to six people is the working size. Name a facilitator whose job is to keep the session moving and neutral, not to supply every answer.
Inputs. Bring the drawings, the process flow, prior FMEAs on similar items, warranty and downtime history, and any field-failure data you have. Real failure history is what separates a scored FMEA from a guessed one.
How do you fill out the FMEA worksheet, column by column?
The worksheet is a chain of questions read left to right, one row per failure mode. Each column answers the next question the previous one raises. Work one item at a time and finish its row before moving on.
Start with the item or function: what is this part or step supposed to do? Then the failure mode: how could it fail to do that? A single function usually has several modes. Next the effect: what happens downstream and to the customer if it fails that way, which sets the severity. Then the cause: the mechanism or root reason the mode occurs, which drives occurrence. Then the current controls: what you already do to prevent the cause or detect the failure, which sets detection. Finally the three scores, the risk number, and the recommended action.
How do you score severity, occurrence, and detection?
Each failure mode gets three ratings on a 1-to-10 scale, and the whole method lives or dies on scoring them honestly against defined criteria rather than gut feel. Agree on the rating tables before you start and keep them visible so a "7" means the same thing on row 40 as it did on row 4.
| Rating | Severity (S), how bad is the effect? | Occurrence (O), how often does the cause happen? | Detection (D), how likely are current controls to catch it? |
|---|---|---|---|
| 1–2 | No or minor effect; customer unlikely to notice | Very unlikely; no known history of failure | Almost certain to be detected before it escapes |
| 3–5 | Noticeable performance loss; annoyance or minor rework | Occasional; isolated past failures | Moderate chance controls catch it |
| 6–8 | Major function loss; dissatisfied customer; downtime | Frequent; repeated failures in similar designs | Low chance; controls often miss it |
| 9–10 | Safety or regulatory hazard, with or without warning | Almost inevitable; failure nearly certain | No effective control; escape is essentially undetected |
Two scoring traps are worth calling out. First, detection is not "do we have a control" but "how good is that control at catching this specific failure", a visual check a tired operator does at 2 a.m. is not a low detection number. Second, occurrence should lean on real history from your downtime records and warranty data, not on optimism about the new design.
Should you use RPN or Action Priority?
The traditional output is the Risk Priority Number: RPN = Severity × Occurrence × Detection, ranging 1 to 1,000. You sort the worksheet by RPN and attack the top. It is simple, but it has a real flaw: a safety-critical failure that is rare and detectable (S=10, O=2, D=2) scores 40, while a cosmetic nuisance (S=3, O=5, D=4) scores 60, and a pure RPN sort would tell you to fix the cosmetic issue first.
The 2019 AIAG & VDA handbook replaced RPN thresholds with Action Priority (AP) which assigns High, Medium, or Low priority from the specific S-O-D combination and, critically, lets severity dominate so a safety issue is never buried by a low occurrence number. Many teams now record RPN as a rough sort and use AP to decide what actually gets worked. Whichever you use, the number is a ranking tool, not a target to game.
How do you actually run the session?
The session is where an FMEA succeeds or fails. Run it as a facilitated working meeting, not a form-filling chore, and follow this order.
- Set the frame (10 minutes). Restate the scope and the boundary out loud, confirm the rating tables everyone will use, and assign a scribe so the facilitator can keep eye contact with the room instead of typing.
- Walk the functions. Go through the item or process step by step and state what each part or step is supposed to do. Do not jump to failures yet, a clear function statement makes the failure modes obvious.
- Brainstorm failure modes per function. For each function, ask "how could this not happen?" Capture every plausible mode. Techniques like a fishbone diagram help pull causes out of the room.
- Trace effects and causes. For each mode, follow the effect downstream to the customer and back to the root cause. This is where root cause analysis and the five whys earn their place.
- Score S, O, and D against the tables. Score by consensus, not by the loudest voice. When the team splits, that disagreement is itself a finding worth a note.
- Rank and assign actions. Sort by RPN or Action Priority, then for every high-risk row write a specific recommended action with a named owner and a due date. An action without an owner is a wish.
- Re-score after actions close. Once an action is done, re-rate the row. A real fix lowers occurrence or detection; if the numbers do not move, the fix did not work. This is the loop that makes FMEA a living document.
What happens after the session?
The FMEA is worthless the moment it becomes a static file. The actions are the product. Track each recommended action to closure the same way you track any preventive maintenance task, owner, due date, status, and feed the highest-risk failure modes into your predictive maintenance and condition-based maintenance plans so the analysis changes what the crew actually inspects.
Revisit the FMEA whenever the design or process changes, whenever a new failure appears in the field, and on a periodic review even when nothing has changed. Findings that turn into corrective action should tie into your CAPA process so nothing falls through the gap between "we noticed" and "we fixed it."
What does the standard say, and where do you go for detail?
FMEA is codified, not folklore. If you need the authoritative rating tables and process steps, these are the primary references.
- The AIAG & VDA FMEA Handbook (2019) defines the current seven-step approach and replaced RPN thresholds with the High/Medium/Low Action Priority tables now used across the automotive supply base (AIAG FMEA overview).
- ASQ maintains a widely used plain-language FMEA reference covering severity, occurrence, detection, and RPN for teams outside automotive (ASQ: Failure Mode and Effects Analysis).
- The underlying standard IEC 60812 defines FMEA and FMECA methodology internationally for reliability engineering, which is the reference maintenance and reliability teams cite (IEC 60812).
The one line to remember from all three: the score is a decision aid, not a deliverable. An FMEA that ends with a ranked worksheet and no closed actions has done half the job.
Where do the findings live?
An FMEA generates a list of the failure modes most worth watching and the exact checks that catch them, which is precisely the input a maintenance program needs. The problem is that most FMEAs die in a shared drive while the inspections they recommended never make it onto the floor. The link between "the FMEA said watch this" and "the technician checked it Tuesday" is where the value leaks out.
Harmony's role is to keep that link intact: turn the high-priority failure modes into checks technicians actually see at the asset, capture the results in a searchable history, and surface the trend so a re-score is backed by data instead of memory. It layers onto the systems a plant already runs. No rip-and-replace. The CLS case study shows the move from paper to real-time capture, and the platform overview shows how the pieces connect. A good FMEA points at the right risks; the plants that beat those risks are the ones that keep the checks alive after the meeting ends.