FMEA (DFMEA + PFMEA)

What You Actually Need to Know

1) What FMEA Is

FMEA (Failure Mode and Effects Analysis) is a structured way to predict failures before they happen, prioritize the biggest risks, and define specific actions to reduce those risks. It is used to prevent defects, safety incidents, downtime, warranty costs, and launch failures.

FMEA answers three questions:

  • How can it fail? (failure modes)

  • What happens if it fails? (effects)

  • Why would it fail, and how would we stop or detect it? (causes + controls)

FMEA is not “quality paperwork.” Done well, it becomes the backbone of your control strategy and launch readiness.

2) DFMEA vs PFMEA vs Process Flow vs Control Plan (No Confusion)

DFMEA (Design FMEA)

Focus: risk in the design (the product definition).

  • Typical scope: interfaces, tolerances, materials, loads, fatigue, sealing, thermal, software logic, misuse, environmental exposure

  • Best time: early design, updated through design freeze and change cycles

  • Typical outputs: design changes, special characteristics, validation plans, key tolerances, critical interfaces

PFMEA (Process FMEA)

Focus: risk in the manufacturing/assembly process.

  • Typical scope: each process step, machine settings, fixturing, torque strategy, heat treatment, cleaning, contamination control, handling damage, measurement method

  • Best time: during process design, before tooling lock and pilot builds

  • Typical outputs: error-proofing, inspection strategy, reaction plans, control plan, operator instructions

Process Flow Diagram

The “map” of process steps. PFMEA is built from it. If the flow is wrong, PFMEA is wrong.

Control Plan

The “operational contract” of how the process is controlled. It must be derived from PFMEA, not written independently.

A healthy chain looks like this:
Requirements → DFMEA → Special characteristics → Process flow → PFMEA → Control plan → Work instructions + checks → Evidence (MSA, capability, audits)

3) The Anatomy of an FMEA Row (What Each Column Really Means)

Most FMEAs have these elements (wording varies by template/tool):

(A) Item / Function / Requirement

What must the design feature or process step accomplish?
Good: “Seal interface prevents leakage at 2 bar across -20°C to 120°C.”
Bad: “Seal works.”

(B) Failure Mode

How does it fail to meet the function? Use specific language.
Examples:

  • “Leaks above allowable rate”

  • “Cracks under cyclic load”

  • “Incorrect torque applied”

  • “Hole position out of tolerance”

  • “Sensor output stuck high”

(C) Effects of Failure

What happens downstream (customer, vehicle/system, safety, compliance, scrap, rework, downtime)?
Effects should be observable consequences, not just “fails.”

(D) Severity (S)

How bad is the worst credible effect?
Severity typically stays fixed unless you change the design concept or system-level protection.

(E) Causes / Mechanisms

Why would the failure mode happen?

  • DFMEA cause examples: wrong material spec, insufficient fillet radius, tolerance stack-up too tight, resonance at operating RPM

  • PFMEA cause examples: worn tool, fixture mislocation, wrong program version, operator skips step, contamination, wrong gage method

(F) Occurrence (O)

How likely is the cause/mechanism to happen?
This should be based on data where possible (history, capability, scrap rates), not opinions.

(G) Current Prevention Controls

Controls that prevent the cause from happening:

  • DFMEA: robust design margins, derating, design standards, simulation rules

  • PFMEA: poka-yoke, controlled settings, automated parameter checks, interlocks

(H) Current Detection Controls

Controls that detect the failure before it ships:

  • in-process checks, end-of-line tests, vision inspection, torque-angle monitoring, leak tests

(I) Detection (D)

How likely the current detection controls will detect the failure before escape.
High D score = poor detectability.

(J) Risk Evaluation (RPN or Action Priority)

Old-school: RPN = S × O × D
Modern: Action Priority (AP) or equivalent logic that stops teams from hiding behind math.

(K) Recommended Actions + Owner + Due Date + Status

Actions must change reality: design change, poka-yoke, improved test method, tighter setup control, better gage, better reaction plan.

(L) “After Action” Re-rating

Show the effect of improvements on Occurrence and/or Detection. Severity rarely improves unless you change the concept.

4) RPN vs Action Priority (And What People Get Wrong)

RPN (Severity × Occurrence × Detection)

Pros: simple, familiar
Cons: dangerous if used blindly:

  • A high-severity risk can have a “moderate” RPN and be ignored

  • Different S/O/D combinations can produce the same RPN but represent very different risk

Action Priority (AP) / Risk Ranking

Modern approaches prioritize action based on severity-first logic:

  • High severity triggers action even if occurrence is low

  • Emphasizes prevention and robust controls rather than “just inspect more”

Practical rule:

  • If severity is high, you either design it out, add strong prevention, or create near-certain detection with clear reaction plans.

5) What “Good” DFMEA Looks Like (In Real Engineering Terms)

Strong DFMEA characteristics

  • Starts from clear requirements, not generic “functions”

  • Includes interfaces: mating parts, sealing surfaces, connectors, software/hardware boundaries

  • Explicitly considers:

    • tolerance stack-up and variation sensitivity

    • material properties and environmental aging

    • misuse / abuse / abnormal conditions

    • manufacturing variation limits

  • Uses real evidence:

    • simulation outputs, design margins, test results, prior warranty

  • Produces outputs people use:

    • special characteristics, test plans, design changes, key drawings notes

Typical DFMEA improvements that actually reduce risk

  • Increase design margin (thickness, fillet radius, stronger material)

  • Make design less sensitive to variation (self-locating features, datums)

  • Reduce complexity (fewer parts, fewer interfaces)

  • Improve robustness to environment (corrosion protection, sealing strategy)

  • Clarify specifications so manufacturing can consistently hit them

6) What “Good” PFMEA Looks Like (And How It Drives the Shop Floor)

Strong PFMEA characteristics

  • Built directly from a process flow with correct step boundaries

  • Failure modes are specific to each step:

    • “Wrong component installed”

    • “Press force too low/high”

    • “Burr remains after machining”

    • “Heat treatment cycle incorrect”

    • “Contamination introduced during assembly”

  • Controls are realistic and executable:

    • poka-yoke > inspection

    • automated monitoring > manual checks for critical steps

    • measurement method validated (MSA)

  • Every critical characteristic has:

    • measurement method + frequency

    • reaction plan (what to do if out-of-control)

    • containment / escalation path

PFMEA must align with the control plan

If PFMEA says a risk is controlled, the control plan must show:

  • what is measured/monitored

  • how often

  • how it’s recorded

  • what happens when it fails (reaction plan)

7) Prevention vs Detection (The Core Philosophy)

Teams often “fix” FMEA by adding more inspection. That’s expensive and often ineffective.

Best practice hierarchy:

  1. Eliminate the cause (design change or process redesign)

  2. Prevent the cause (poka-yoke, interlocks, controlled parameters)

  3. Detect reliably (automated checks with proven capability)

  4. Manual inspection (last resort for high-risk items)

If you rely on detection, ensure:

  • detection method is capable (MSA)

  • criteria are objective

  • reaction plan is enforced

8) Special Characteristics (Critical / Significant / Key)

Different customers use different labels, but the concept is the same:

  • Some characteristics deserve extra control due to safety, regulation, function, or critical fit/performance.

Where they come from:

  • Requirements and DFMEA analysis
    Where they must end up:

  • Drawings/specifications → PFMEA → Control Plan → Work instructions → validation evidence

A “special characteristic” that doesn’t change the control plan is meaningless.

9) FMEA and Change Management

FMEA must be updated whenever any of these change:

  • design requirements/specs

  • geometry/tolerances/materials

  • manufacturing steps, equipment, tooling, programs

  • suppliers or supplier processes

  • inspection methods, gages, test limits

  • field issues or internal failures

The practical mechanism:

  • change request triggers an “FMEA impact review”

  • impacted rows updated

  • validation needs reassessed (what must be re-tested)

10) How to Use Data (So FMEA Isn’t Opinion-Based)

Use real inputs where possible:

  • warranty claims / returns

  • scrap and rework Pareto

  • process capability (Cpk/Ppk)

  • SPC signals (out-of-control points, trends)

  • test failures / DVP results

  • audit findings

  • supplier defect rates

Translate data into:

  • realistic occurrence scoring

  • targeted actions at the real causes

  • updated detection scoring when you prove detection capability

11) FMEA Facilitation: Who, How, and How Often

Who should be in the room

  • DFMEA: design, test/validation, manufacturing, supplier quality, service/field (if relevant)

  • PFMEA: process engineering, manufacturing, quality, maintenance, metrology, supplier quality

How sessions should run

  • Start with requirements and process flow

  • Work step-by-step, avoid skipping “boring” steps (that’s where escapes happen)

  • Keep actions specific, owned, and time-bound

  • Review “top risks” every meeting and force closure

Frequency

  • Early development: frequent updates as design/process evolves

  • Pre-launch: intense updates during pilot builds

  • Post-launch: periodic review plus immediate updates for any major issue/change

12) Typical Audit Findings (And How to Avoid Them)

Common problems:

  • DFMEA and PFMEA not linked (no traceability)

  • Control plan doesn’t reflect PFMEA risks

  • Actions open for months with no closure evidence

  • Detection controls listed but not validated (no MSA, unclear criteria)

  • “Generic” failure modes and causes

Avoidance:

  • maintain traceability (requirement → DFMEA → PFMEA → control plan)

  • require evidence links for key controls (MSA, capability, test reports)

  • enforce phase gates: no gate pass with critical actions open

13) Practical Mini-Checklist: What to Look for in a “Good” FMEA

  • Failure modes are specific and testable

  • Causes are real mechanisms, not vague statements

  • Controls are feasible and owned by a process/design owner

  • High severity items have strong prevention/detection and clear reaction plans

  • PFMEA and Control Plan match line-by-line for critical risks

  • Document is living: updated with changes and real issues

14) FAQs People Research About FMEA

Is FMEA mandatory?
Often yes in automotive and many supplier contracts; practically, it’s required to pass customer audits and launch gates.

Should severity be reduced?
Rarely. Severity usually reflects the effect on the customer/system. You mainly reduce occurrence and improve detection unless you redesign the concept.

Is adding inspection a valid action?
Sometimes, but it’s usually a weaker action than prevention. If you add detection, validate it and define reaction plans.

How detailed should an FMEA be?
Detailed enough that controls and actions are unambiguous and traceable. If two engineers interpret a row differently, it’s too vague.

15) Summary

  • DFMEA controls design risk; PFMEA controls manufacturing risk.

  • Both must connect to the control plan and real validation evidence.

  • The value of FMEA is not the scoring; it’s the actions and controls that prevent escapes.