Effects analysis in FMEA: practitioner guide for engineers

Effects analysis in FMEA is the disciplined identification and assessment of the consequences of each potential failure mode, recorded as the effect on the item itself, the next-higher assembly, and the end user — then prioritised for corrective action. Run it whenever you introduce a new design, change a manufacturing process, or update a control plan. The output is a completed worksheet row for each failure mode, carrying a severity rating (1–10), an occurrence rating, a detection rating, and an Action Priority (AP) or Risk Priority Number (RPN) that tells you where to act first. Your immediate next step: identify the highest-severity effects in your system, assign an owner to each, and schedule a mitigation action before the design or process is released.

Three things to know before you read further:

  • When to run it: at the earliest feasible stage of design or process development, and again whenever a significant change occurs, a field failure recurs, or a new regulatory requirement applies.
  • What it produces: a prioritised list of failure modes with their effects, scores, and assigned actions — the foundation of a living risk register.
  • Immediate action: capture every effect rated Severity 9 or 10 first. Those rows demand action regardless of occurrence or detection scores, per ASQ’s FMEA guidance and the AIAG & VDA FMEA Handbook (2019).

IfM Cambridge frames FMEA as a systematic technique for identifying failure modes and their effects on systems, with direct application in design management and process control. The American Society for Quality (ASQ) reinforces this with structured resources covering worksheet design, scoring criteria, and team facilitation.

Key takeaways

Effects analysis in FMEA produces its highest value when severity drives prioritisation, actions are assigned to named owners, and verification is built into the maintenance workflow from the outset.

Point Details
Severity drives priority Record the highest-severity effect per failure mode; any S=9 or S=10 demands action regardless of occurrence or detection scores.
Use Action Priority over RPN alone The AIAG–VDA 2019 AP matrix gives clearer action signals than RPN, particularly for high-severity, low-frequency failure modes.
Convert effects to work orders Every High AP action should map to a specific PM task or corrective work order with a named owner, due date, and verification metric.
Treat FMEA as a living document Assign a custodian, trigger reviews after design changes or field failures, and update scores after verification.
Fullyops closes the loop Fullyops links FMEA actions to work orders, PM schedules, and analytics dashboards, making verification automatic and auditable.

Table of Contents

What does effects analysis actually examine?

Effects analysis is the specific step within FMEA where the team asks: if this failure mode occurs, what happens? The answer is recorded at three levels, each serving a different purpose in the analysis.

Failure mode versus effect. A failure mode is the way in which a component or process step can fail to perform its intended function — for example, a pressure relief valve failing to open. The effect is the consequence of that failure: at the local level, pressure builds in the sub-assembly; at the next-higher level, the containing vessel is over-pressurised; at the end-user level, the operator faces a safety hazard. These three levels are not interchangeable. Recording only the local effect understates severity; recording only the end-user effect loses the traceability needed to assign a corrective action to the right component.

Choosing the severity rating when multiple effects exist. A single failure mode often produces several simultaneous effects. ASQ’s FMEA resources are explicit: when multiple effects exist, record the highest severity. Severity is rated on a 1–10 scale, where 1 is insignificant and 10 is catastrophic or safety-critical. This rule prevents teams from averaging down a genuinely dangerous consequence.

How to phrase effects on the worksheet. Effects should be written in user-facing or system-facing language, not in engineering jargon that obscures the real consequence. Useful phrasings include:

  • “Loss of braking function — vehicle cannot be stopped by the driver”
  • “Unplanned production line stoppage — output rate falls to zero”
  • “Incorrect dosage delivered — patient receives sub-therapeutic treatment”
  • “Sensor reads zero — control system enters fail-safe mode, halting operation”
  • “Visible surface defect — product rejected at customer incoming inspection”

Pro Tip: Write the end-user effect first on your worksheet, then add the local and next-higher effects in separate columns. This order keeps the team focused on what the customer or operator actually experiences, which is where severity scoring must be anchored.

A brief contrast illustrates the difference in scope. For a conveyor belt drive motor, the local effect of a bearing seizure is motor shaft locked. The end effect is a complete production line halt, with downstream assembly starved of parts. The severity score belongs to the end effect — a rating of 8 or 9 in most manufacturing scales — not to the local mechanical event, which on its own might seem less consequential.

It is worth noting that effects analysis in the technical FMEA sense is narrower than the broader policy-level concept. The European Commission’s impact assessment guidance uses “effect analysis” to cover intended and unintended economic, social, and environmental consequences of proposed legislation — a useful comparison for teams working in regulated industries where FMEA outputs feed into wider impact assessments.

Which type of FMEA should you use?

FMEA is not a single method but a family of related techniques. The type you choose determines the scope of your effects analysis, the language you use to describe failure modes and effects, and the sources of evidence for your occurrence and detection ratings.

Design FMEA (DFMEA)

DFMEA examines potential failures in a product’s design before it reaches manufacture. The team analyses components, sub-assemblies, and interfaces to identify how design decisions could lead to functional failures. Effects are expressed in terms of what the end user or the next-higher assembly experiences.

Typical effect focus: loss of function, degraded performance, safety hazard to the user, regulatory non-compliance.
Example effect phrasings: “Steering column collapses under normal load — driver loses directional control”; “Seal leaks under rated pressure — fluid contaminates adjacent electronics.”

Process FMEA (PFMEA)

PFMEA targets manufacturing or service process steps. The failure modes are deviations from the intended process — wrong torque, incorrect sequence, omitted inspection — and the effects are expressed in terms of the product characteristic that is compromised or the downstream process that is disrupted. FMEA as a proactive methodology is particularly well-established in PFMEA for automotive and aerospace supply chains.

Typical effect focus: out-of-specification product, rework, scrap, customer return, line stoppage.
Example effect phrasings: “Weld bead undersize — joint fails fatigue test, part scrapped”; “Incorrect label applied — product shipped to wrong destination, recall risk.”

Functional FMEA

Functional FMEA operates at the system or sub-system level, before detailed design is complete. Failure modes are expressed as functional failures (“fails to provide hydraulic pressure”) rather than component failures. This makes it useful early in a programme when component-level detail is not yet available.

Typical effect focus: loss of system function, degraded system output, inability to meet a performance specification.

Software FMEA

Software FMEA applies the method to software modules, interfaces, and data flows. Detection sources differ markedly from hardware FMEA: code reviews, static analysis tools, unit tests, and integration tests replace physical inspection and measurement. Effects are expressed in terms of system behaviour — incorrect output, system crash, data corruption, security vulnerability.

The table below summarises the key distinctions across FMEA types.

FMEA type Primary scope Typical effect language Detection sources
DFMEA Product design User-facing functional loss, safety hazard Prototype testing, design review, simulation
PFMEA Manufacturing/service process Product non-conformance, line disruption Process inspection, SPC, audit
Functional FMEA System functions (early design) Loss of system output, spec non-compliance System-level test, functional review
Software FMEA Code, interfaces, data Incorrect output, crash, data corruption Code review, static analysis, unit/integration test

How to run an FMEA workshop step by step

The CMS FMEA guidance sets out a clear workshop sequence: identify process steps, identify failure modes, determine outcomes, rate seriousness, design and implement changes, then measure success. The sequence below adapts that framework for engineering and industrial contexts, with worksheet fields and facilitation ground rules.

Workshop sequence

  1. Define scope and boundaries. Agree the system, sub-system, or process step being analysed. Write a one-sentence scope statement and confirm it with the sponsor before the team assembles.
  2. Assemble a cross-functional team. Include design, manufacturing, quality, maintenance, and — where possible — a customer or end-user representative. Five to seven participants is a practical ceiling for a productive session.
  3. Map functions and requirements. For each item in scope, state what it is supposed to do and the performance standard it must meet. This is the baseline against which failure modes are defined.
  4. Identify failure modes. For each function, ask: in what ways could this item fail to perform its intended function? Record each failure mode as a separate worksheet row.
  5. Conduct effects analysis. For each failure mode, identify local, next-higher, and end effects. Record the highest-severity effect. Use user-facing language.
  6. Identify causes. For each failure mode, identify the root cause or mechanism. This is distinct from the effect — causes drive occurrence ratings; effects drive severity ratings.
  7. Identify current controls. List existing prevention controls (which reduce occurrence) and detection controls (which catch the failure before it reaches the customer).
  8. Score S, O, and D. Apply the rating scales (see Section 5) consistently. Use data where available; document the rationale for each score.
  9. Calculate RPN or assign Action Priority. Prioritise rows for action.
  10. Assign actions and owners. For each high-priority row, define a specific action, name an owner, and set a target completion date.
  11. Verify and update. After actions are implemented, re-score O and D (severity does not change unless the design changes) and confirm the new AP or RPN.

Worksheet fields

Each row of the FMEA worksheet should contain the following fields, completed in the order above:

Field Description Ground rule
Item / process step Component or step being analysed Use the same naming convention as the engineering drawing or process flow
Function / requirement What the item must do State the performance standard, not just the function name
Failure mode How the item fails to perform One failure mode per row; be specific
Effect(s) of failure Consequence at local, next-higher, end-user level Record the highest-severity effect for scoring
Severity (S) Rating 1–10 for the worst effect Score the effect on the end user or system
Cause(s) Root cause or mechanism of the failure mode One cause per row where possible; use fishbone or 5-Why to identify
Occurrence (O) Rating 1–10 for likelihood of the cause occurring Use historical data, field data, or engineering judgement
Current controls Prevention and detection controls in place List both types separately
Detection (D) Rating 1–10 for ability to detect before reaching customer Lower score = better detection
RPN or AP Priority indicator Use AP (AIAG–VDA 2019) as primary; RPN as supplementary
Recommended action Specific mitigation or improvement Assign to a named owner with a due date
Verification Evidence that the action was effective Define the metric before implementation

Pre-work checklist for the facilitator:

  • Confirm scope statement is approved by the sponsor.
  • Distribute the process flow diagram or design schematic at least 48 hours before the session.
  • Collect historical failure data, field returns, and warranty claims in advance.
  • Prepare blank worksheet rows with field headers.
  • Agree the rating scales to be used and circulate them with the pre-read.

Pro Tip: Reserve the first 20 minutes of every FMEA session for a structured review of historical failure data. Teams that skip this step consistently underestimate occurrence ratings, because they rely on optimism rather than evidence. The equipment performance analysis guide from Fullyops provides a practical framework for pulling and interpreting asset history before a workshop.

IfM Cambridge’s FMEA guidance reinforces the importance of systematic worksheet use and practitioner-led facilitation, noting that the method’s value depends heavily on the quality of team input rather than the template itself.

How to score severity, occurrence, and detection

Scoring is where effects analysis produces its most tangible output: a number that tells the team how urgently to act. The three dimensions — Severity (S), Occurrence (O), and Detection (D) — each carry a 1–10 rating, and they combine to produce either an RPN or an Action Priority.

Severity (S)

Severity rates the worst consequence of the failure mode on the end user, the system, or the process. It does not change unless the design or the function changes. A score of 9 or 10 indicates a safety hazard or regulatory non-compliance. Scores of 7–8 indicate significant functional loss; 4–6 indicate degraded performance; and 1–3 indicate minor or cosmetic impact.

Occurrence (O)

Occurrence rates how likely the cause is to occur during the expected life of the product or process. Use historical failure rates, field data, or engineering models where available. A score of 9–10 means the failure is almost inevitable; 7–8 means it occurs repeatedly; 4–6 means occasional; 1–3 means rare or unlikely.

Detection (D)

Detection rates the ability of current controls to find the failure mode or its cause before the effect reaches the customer. Counterintuitively, a low detection score means good detection. A score of 9–10 means the failure is virtually undetectable; 7–8 means detection is unlikely; 4–6 means moderate chance of detection; 1–3 means detection is almost certain.

RPN and its limitations

RPN = S × O × D. The maximum is 1,000 (10 × 10 × 10). Teams traditionally prioritised rows with the highest RPN. The problem is that RPN treats all three dimensions as equally weighted and multiplicative, which can produce misleading results. A failure mode with S=10, O=1, D=1 produces an RPN of 10 — yet it carries a catastrophic severity that demands action regardless of how rarely it occurs or how reliably it is detected.

AIAG–VDA Action Priority

The AIAG–VDA FMEA Handbook (2019) replaced sole reliance on RPN with Action Priority (AP), which uses a matrix of S, O, and D to assign one of three priority levels: High (H), Medium (M), or Low (L). Any failure mode with S=9 or 10 automatically receives a High AP, regardless of O and D scores. This directly addresses the RPN weakness described above.

Approach Calculation Key strength Key weakness
RPN S × O × D (max 1,000) Simple, widely understood Can mask high-severity, low-frequency risks
Action Priority (AP) S/O/D matrix → H/M/L Severity-led; clearer action signal Requires the full AIAG–VDA matrix to apply correctly

Pro Tip: Never use RPN as the sole prioritisation criterion. A failure mode with S=9 and an RPN of 36 (because O and D are both 2) still demands a mitigation action. Adopt AP as your primary signal and use RPN only as a supplementary ranking within the same AP band. For teams tracking maintenance KPIs, linking AP bands to KPI thresholds makes prioritisation transparent and auditable.

A practical rule of thumb: address all High AP items before any Medium AP items, and document the rationale for deferring any High AP action beyond the next design gate or process review.

Worked example: pressure relief valve in a UK process plant

The scenario is a pressure relief valve (PRV) on a steam distribution system at a UK industrial facility. The FMEA team includes a process engineer, a maintenance technician, a quality engineer, and a safety representative. The scope is the PRV sub-assembly, from inlet flange to discharge outlet.

Key scoring decisions:

  • The disc corrosion row carries S=10 because vessel rupture is a credible end effect, placing it in the safety-critical band regardless of the relatively low occurrence rating (O=2). Under the AP matrix, S=10 automatically assigns High priority.
  • The pilot line blockage row has the highest RPN (210) and also High AP. Both signals agree here, but note that the seat erosion row (RPN=108) also carries High AP because S=9 — a team relying solely on RPN might deprioritise it relative to the spring fatigue row (RPN=140, Medium AP).
  • Detection for the pilot line blockage is rated D=7 (unlikely to detect) because there is no current functional test in the PM schedule. The recommended action directly addresses this gap.

Converting effects to mitigation: each High AP row maps to a specific preventive maintenance task or design change. The seat erosion action, for example, becomes a new PM work order (install strainer, add leak-check to daily round) with a verification metric of zero unplanned steam leaks attributable to seat failure over the next 12 months.

When should you use FMEA, and what are its limits?

FMEA is a proactive tool. Its value is highest before a failure occurs, not after. The CMS guidance frames it explicitly as a method for addressing potential failures before adverse events occur — a distinction that separates it clearly from reactive investigation methods.

Typical triggers for FMEA:

  • New product or process design, before design freeze or process sign-off.
  • Significant design or process change, including material substitutions or supplier changes.
  • Development of a new control plan or quality management plan.
  • Recurring field failures or warranty claims that suggest a systemic cause.
  • Entry into a new regulatory environment or customer requirement (e.g. ISO 9001, IATF 16949, BS EN standards).
  • High-consequence items identified through a risk register or safety case.

FMEA versus root cause analysis (RCA):

FMEA is prospective — it asks “what could go wrong?” before it does. RCA is retrospective — it asks “what went wrong and why?” after a failure has occurred. The two methods complement each other: FMEA outputs can inform RCA investigations by providing a pre-existing hypothesis set, and RCA findings should feed back into the FMEA to update occurrence ratings and add previously unidentified failure modes.

Known limitations:

  • Subjectivity in scoring. Without historical data, S, O, and D ratings depend on team judgement, which varies. Mitigate by using data from equipment performance analysis and documenting the rationale for each score.
  • Completeness depends on team knowledge. Failure modes that no team member has encountered or imagined will not appear on the worksheet. Use structured brainstorming, historical failure databases, and cross-functional teams to reduce this gap.
  • False sense of security from low RPN. A low RPN does not mean a failure mode is safe — it may simply mean detection is rated optimistically. This is precisely why the AIAG–VDA AP approach anchors priority to severity first.
  • Static snapshot. An FMEA reflects the system at a point in time. Without a governance process to update it after design changes, field failures, or process modifications, it becomes misleading rather than protective.

Effect-size thinking is relevant here: when designing verification checks after FMEA actions are implemented, teams need to define a minimum detectable effect and plan sample size and measurement duration accordingly. A mitigation that reduces occurrence from O=6 to O=4 may require months of production data to confirm statistically.

Turning FMEA outputs into maintainable actions

Completing the FMEA worksheet is not the end of the process. The CMS guidance is explicit that the final steps — implementing changes and measuring success — are as important as the analysis itself. Without a mechanism to track actions, verify outcomes, and update the FMEA, the worksheet becomes a compliance document rather than a living risk management tool.

Mapping actions to work orders and preventive tasks

Each recommended action from the FMEA should translate directly into one of the following:

  1. A preventive maintenance task added to the asset’s PM schedule, with a defined frequency, procedure, and acceptance criterion.
  2. A corrective work order for an immediate design or process change, with a named owner and target completion date.
  3. A root-cause investigation project for failure modes where the cause is not yet fully understood.
  4. A design change request for DFMEA actions that require engineering sign-off.

Implementation checklist

For each FMEA action row, confirm the following before closing:

  • Owner named and notified.
  • Target completion date set and agreed.
  • Verification metric defined (what will be measured, how, and over what period).
  • Closure evidence specified (test report, inspection record, updated control plan, zero-recurrence period).
  • FMEA worksheet updated with the new S, O, D scores after action implementation.

KPIs to monitor

Tracking the right metrics confirms whether FMEA actions are delivering the intended reduction in risk. Useful KPIs include:

  • Action completion rate: percentage of FMEA actions closed by their target date.
  • Recurrence rate: frequency of the same failure mode after a corrective action has been implemented.
  • Severity-related incident rate: number of incidents attributable to High AP failure modes per period.
  • FMEA update cycle: time elapsed since the last formal review of each active FMEA.

The maintenance KPIs guide provides a structured approach to selecting and tracking these metrics within a maintenance management framework.

Impact evaluation principles — specifically causal attribution and triangulation — strengthen the verification step. When a failure mode recurrence drops after a mitigation action, triangulating that result with inspection records, sensor data, and operator reports gives a more credible picture of whether the action caused the improvement or whether other factors were at play.

Pro Tip: When setting verification metrics for FMEA actions, apply effect-size thinking: define the minimum meaningful reduction in occurrence or severity-related incidents before you start collecting data. This prevents teams from declaring success on the basis of a single incident-free month when the baseline rate requires a longer observation window to draw a valid conclusion.

Common pitfalls in effects analysis and how to avoid them

Even experienced teams make predictable mistakes in FMEA. The following checklist covers the most consequential errors and the practices that correct them.

Common pitfalls:

  • Overly broad failure modes. “Component fails” is not a failure mode. Each row must describe a specific, observable failure mechanism. Broad entries produce vague effects and unactionable mitigations.
  • Effects written in engineering shorthand. “Loss of function” without specifying whose function and what consequence makes severity scoring arbitrary. Write effects in the language of the person who experiences them.
  • Occurrence ratings based on optimism. Teams frequently rate O=2 or O=3 without consulting failure history. Pull warranty data, maintenance records, or field return rates before the session.
  • Detection ratings that assume controls work perfectly. A visual inspection rated D=2 may be realistic in a controlled laboratory but not on a busy production line. Rate detection as it actually performs, not as it is intended to perform.
  • RPN as the only prioritisation tool. As discussed in Section 5, this can deprioritise high-severity, low-frequency failure modes. Use AP as the primary signal.
  • FMEA treated as a one-time exercise. A static FMEA that is never updated after design changes, field failures, or process modifications provides false assurance.
  • Insufficient cross-functional representation. An FMEA completed by a single engineer or a single department misses failure modes that only become visible from a different vantage point — maintenance, quality, or the customer.

Best practices:

  • Use historical failure data, field returns, and maintenance records to anchor occurrence ratings.
  • Define detection controls precisely: name the method, the frequency, and the acceptance criterion.
  • Update the FMEA within 30 days of any design change, process change, or verified field failure.
  • Assign a named FMEA custodian responsible for scheduling reviews and maintaining the document.
  • Cross-reference FMEA outputs with the control plan and the preventive maintenance schedule to confirm alignment.
  • Use the maintenance auditing guide to verify that detection controls described in the FMEA are actually being executed in the field.

Pro Tip: The most durable FMEAs are those treated as living artefacts within a version-controlled document management system, with a formal review trigger tied to change management. If your organisation has a management of change (MOC) process, make FMEA review a mandatory gate within it.

Standards, templates, and resources for UK practitioners

Must-read references

  • ASQ FMEA resources. The American Society for Quality provides practitioner-level guidance on FMEA methodology, worksheet design, and scoring criteria. Useful as a cross-reference and for teams outside the automotive sector.
  • IfM Cambridge FMEA guidance — Concise, practitioner-focused explanation of FMEA in a design management context. Particularly useful for teams in early-stage design who need a clear framework before adopting the full AIAG–VDA handbook.
  • CMS FMEA guidance. Although written for the US healthcare sector, this document provides a clear, sector-adapted example of FMEA with severity scales and verification steps that translate well to other regulated industries.

Template types to use

  • DFMEA worksheet: columns for item, function, failure mode, effect (local/next-higher/end), S, cause, O, current controls (prevention/detection), D, RPN/AP, recommended action, owner, due date, verification.
  • PFMEA worksheet: same structure, with process step replacing item and product characteristic replacing function.
  • Action-tracking register: a simplified extract of all recommended actions, owners, due dates, and closure evidence — used for progress monitoring between FMEA review sessions.
  • Verification checklist: a structured form confirming that each action has been implemented, the verification metric has been measured, and the FMEA has been updated with revised scores.

Adapting templates for UK regulatory contexts

UK practitioners working under BS EN 60812, the Machinery Directive (retained in UK law post-Brexit as the Supply of Machinery (Safety) Regulations 2008), or sector-specific frameworks such as the Pressure Systems Safety Regulations 2000 should ensure their FMEA severity scales reference the relevant regulatory consequence categories. For example, a severity rating of 10 in a pressure systems context should explicitly reference the potential for a dangerous occurrence under the Reporting of Injuries, Diseases and Dangerous Occurrences Regulations (RIDDOR). This alignment makes the FMEA directly usable as evidence in a safety case or regulatory submission.

The case for pragmatic rigour in effects analysis

There is a persistent tension in FMEA practice between analytical completeness and delivery pressure. Teams in high-volume manufacturing or fast-moving design programmes sometimes treat FMEA as a compliance checkbox — filling in worksheets after the design is frozen, scoring conservatively to avoid triggering actions, and filing the document without a review cycle. The result is an FMEA that satisfies an audit but provides no protection.

The opposite failure is equally common: teams that spend weeks debating whether a severity rating should be 7 or 8, producing a document so detailed that no one reads it and no actions are ever closed. Analytical paralysis is not rigour — it is risk avoidance of a different kind.

The pragmatic position is this: enough rigour to justify the actions you take, and a governance mechanism to close them. That means using real data for occurrence ratings wherever it exists, writing effects in language that makes severity scoring unambiguous, and treating the FMEA as a living document with a named custodian and a formal review trigger. Senior sponsorship matters here. An FMEA whose actions are never resourced or closed is worse than no FMEA, because it creates a documented record of known risks that were not addressed.

For operations managers and reliability engineers working in UK industrial settings, the practical standard is clear: align your FMEA to BS EN 60812, adopt the AIAG–VDA Action Priority approach for prioritisation, and build the action-tracking mechanism into your CMMS or field service management system so that verification is automatic, not optional.

How Fullyops helps you operationalise FMEA actions

Completing an FMEA worksheet is only half the work. The actions it generates need to be tracked, scheduled, verified, and closed — and that process breaks down quickly when it relies on spreadsheets and manual follow-up.

Fullyops gives maintenance and reliability teams a direct path from FMEA output to operational control. Each recommended action maps to a work order or a preventive maintenance task, with an assigned technician, a scheduled date, and a defined verification step. High AP failure modes can be flagged as priority work orders, ensuring they are not displaced by routine tasks. The platform’s operations analytics dashboard tracks action completion rates, recurrence metrics, and severity-related incident trends in real time — giving you the evidence base to confirm that mitigations are working and to update FMEA scores with confidence.

Technician assigning work orders on a dark tablet screen

For teams ready to move from analysis to execution, the resource allocation tutorial on the Fullyops site shows how to assign resources to prioritised actions within the platform. Request a demo to see how FMEA action tracking works in practice.

Sources

FAQ

What is effects analysis in FMEA?

Effects analysis is the step in FMEA where the team identifies and records the consequences of each failure mode at the local, next-higher assembly, and end-user levels. The highest-severity effect is recorded and rated on a 1–10 scale, per ASQ’s FMEA guidance.

What are the five steps of the FMEA process?

The core steps are: identify the process steps or functions; identify failure modes for each; determine the effects of each failure mode; rate severity, occurrence, and detection; then design, implement, and verify corrective actions. The CMS FMEA guidance sets out this sequence explicitly for structured workshop use.

What is the difference between FMEA and root cause analysis?

FMEA is proactive — it analyses potential failures before they occur and prioritises preventive actions. Root cause analysis (RCA) is reactive — it investigates a failure that has already happened to identify its underlying cause. The two methods complement each other: FMEA outputs provide a hypothesis set for RCA, and RCA findings should update the FMEA’s occurrence ratings.

When should an FMEA be conducted?

FMEA is most effective when started early in design or process development, before design freeze or process sign-off. It should also be triggered by significant design or process changes, recurring field failures, new regulatory requirements, or the identification of high-consequence items in a risk register.

Should teams use RPN or Action Priority to prioritise FMEA actions?

The AIAG–VDA FMEA Handbook (2019) introduced Action Priority (AP) to address the known limitations of RPN, particularly its tendency to underweight high-severity, low-frequency failure modes. Use AP as the primary prioritisation signal; treat RPN as a supplementary ranking within the same AP band.

Enhance Your Operations and Maximize Efficiency with FullyOps

  • For Maintenance Teams
  • Ensure smooth operations with automated work order management, real-time tracking, and seamless coordination between teams.
  • For Service Providers
  • Optimize field service efficiency with smart scheduling, resource planning, and mobile-friendly tools for on-the-go management.
  • For Asset Managers
  • Gain full visibility into asset lifecycles, preventive maintenance schedules, and compliance tracking—all in one place.