Design FMEA vs Process FMEA: A Practical Guide for Engineers
If you sit on the design side, you have probably been handed an FMEA template and told to "fill in the failure modes" — without a clear line between what your design analysis owns and what the manufacturing team owns. The result is duplicated work, gaps where nobody analyzes the real risk, and an FMEA that auditors flag because the scope is muddled.
Design FMEA (DFMEA) and Process FMEA (PFMEA) answer two different questions about two different things. Confusing them produces weak analyses on both sides. This guide draws the line clearly: what each one analyzes, who owns it, how the inputs differ, and how to make the handoff between them work.
Build your FMEA on a real failure record, not assumptions. WhyTrace Plus structures your incident and field-failure history so design and process teams analyze the failure modes that actually occur — not just the ones they imagine. See how WhyTrace Plus supports FMEA →
Design FMEA vs Process FMEA: The Core Distinction
Design FMEA analyzes the risk that a product's design will fail to meet its intended function. Process FMEA analyzes the risk that a manufacturing or assembly process will fail to produce a conforming product. One examines the thing you are building; the other examines how you build it.
The distinction matters because the two analyses have different owners, different inputs, and different corrective actions. A DFMEA failure like "shaft fractures under rated torque" points to a design change — material, geometry, or specification. A PFMEA failure like "shaft installed without retaining clip" points to a process change — fixturing, error-proofing, or inspection. Treating both as the same exercise produces an FMEA that recommends process fixes for design defects and vice versa.
| Dimension | Design FMEA (DFMEA) | Process FMEA (PFMEA) |
|---|---|---|
| Object of analysis | The product design / function | The manufacturing or assembly process |
| Core question | Can this design fail to do its job? | Can this process fail to make it right? |
| Primary owner | Design / development engineering | Manufacturing / quality engineering |
| Typical failure mode | Cracks, deforms, leaks, signal loss | Wrong part, missing step, out of tolerance |
| Typical cause | Wrong material, undersized feature, tolerance stack | Operator error, tool wear, fixture misalignment |
| Typical control | Design verification, simulation, DV testing | Mistake-proofing, SPC, inspection, control plan |
| Started when | Concept / design phase | Process planning, before PPAP |
Under the harmonized AIAG & VDA FMEA Handbook (the current automotive reference as of 2026), both analyses share the same structured 7-Step Approach, but they are populated from opposite ends of the product lifecycle. The shared method does not erase the difference in scope — it standardizes how you document each one.
What Design FMEA Owns: Function, Not Fabrication
Design FMEA examines whether the product, as designed, can fail to deliver its required functions under expected and foreseeable conditions. It assumes the part will be manufactured exactly to print and asks whether the print itself is sufficient.
This framing is the single most useful discipline for a DFMEA. When you analyze a failure mode, you hold manufacturing constant. You are not asking "what if the operator gets it wrong" — that belongs to the PFMEA. You are asking "if every dimension is perfectly to specification, can this design still fail?"
Design FMEA inputs and failure modes include:
- Functional requirements — the specifications, performance targets, and interface requirements the design must satisfy.
- Failure modes of function — loss of function (it does not work), partial function, intermittent function, degraded function over time, and unintended function.
- Design causes — undersized features, incorrect material selection, tolerance stack-up, inadequate thermal or fatigue margin, missing requirement.
- Design controls — engineering analysis, simulation (FEA/CFD), design reviews, and design verification (DV) testing.
A worked example: in a DFMEA for a hydraulic fitting, a failure mode is "seal fails to maintain pressure at rated temperature." The cause is a design cause — the elastomer durometer specified does not hold its set across the operating range. The corrective action is a design change: re-specify the seal material or revise the groove geometry. No amount of process control fixes a design that is wrong on paper.
The boundary trap most engineers fall into: writing process causes into the DFMEA. "Seal nicked during assembly" is a real risk, but it is a process failure mode and belongs in the PFMEA. Keeping that line clean is what makes both documents auditable and the corrective actions correctly addressed.
What Process FMEA Owns: The Path From Print to Part
Process FMEA examines whether the manufacturing and assembly process can fail to produce a part that conforms to the design. It assumes the design is correct and asks whether the process reliably delivers it.
The PFMEA is structured around process steps. Each operation — receiving, machining, assembly, inspection, packaging — is a row, and you analyze how each step can produce a nonconforming output. The failure modes are stated in process terms.
Process FMEA inputs and failure modes include:
- Process flow — the sequence of operations, derived from the process flow diagram, that transforms raw material into finished product.
- Failure modes of the step — wrong part installed, part missing, incorrect torque, out-of-tolerance dimension, contamination, mislabeled.
- Process causes — operator error, tool or die wear, fixture misalignment, machine drift, incorrect setting, environmental contamination.
- Process controls — error-proofing (poka-yoke), statistical process control (SPC), in-process and end-of-line inspection, and the control plan that ties them together.
The PFMEA feeds directly into the control plan, which is the operational document the shop floor actually runs to. This is a defining feature of Process FMEA: it produces a working manufacturing control, not just a risk register. The AIAG & VDA "Process FMEA: Understanding and Implementing with Control Plans" curriculum explicitly couples the two — the PFMEA identifies the risk, the control plan deploys the countermeasure.
Continuing the hydraulic fitting example: the PFMEA failure mode is "seal omitted during assembly." The cause is a process cause — the assembly fixture allows the housing to be closed without the seal present. The corrective action is a process control: add a presence sensor or a fixture interlock that prevents closure without the seal. The design is fine; the process needs error-proofing.
Try AI-Powered Root Cause Analysis
When a field failure or warranty return lands on your desk, the hardest part is deciding whether it is a design problem or a process problem — because that decision routes the entire corrective action. AI-assisted root cause analysis helps you separate the two by walking the causal chain back from the observed failure to either a design cause or a process cause before you ever open the FMEA.
How DFMEA and PFMEA Connect: The Handoff That Breaks
The link between the two analyses is the point where most FMEA programs lose value. The DFMEA's outputs — its identified failure modes and the characteristics it flags as critical — should become inputs to the PFMEA. When that handoff is informal, the PFMEA misses the design's most important risks.
The mechanism that carries information across the boundary is the special characteristic (also called a critical or significant characteristic). When the DFMEA identifies a feature whose failure has severe consequences — a fatigue-critical weld, a safety-related dimension — that feature is flagged. The PFMEA then must ensure the process reliably controls it, and the control plan must include the corresponding inspection or error-proofing.
A clean flow looks like this:
| Stage | Document | What it produces | Feeds into |
|---|---|---|---|
| 1. Design risk | DFMEA | Failure modes, special characteristics | PFMEA scope |
| 2. Process risk | PFMEA | Process failure modes, controls | Control plan |
| 3. Deployment | Control plan | Inspection, SPC, poka-yoke | Production |
| 4. Field feedback | Incident / warranty data | Real failure modes | Both FMEAs (revision) |
Where this breaks in practice:
- The DFMEA is written once and frozen. Design changes happen but the DFMEA is never revisited, so the PFMEA inherits stale assumptions.
- Special characteristics never cross over. The design team flags a critical feature, but it is communicated in a meeting and never lands in the PFMEA or control plan.
- Field failures are not fed back. A warranty return that points to a design margin problem gets logged as a process defect, the DFMEA is never updated, and the same failure recurs.
The fourth row of the table — field feedback — is the one engineers most often neglect. An FMEA built only on what the team imagined at design time decays quickly. The failure modes that actually occur in the field are the highest-value inputs to revising both analyses, and they require a structured failure record to capture them.
Close the loop from field failure back to FMEA. WhyTrace Plus links each field failure and warranty return to its root cause, so you can tell whether the next FMEA revision needs a design change or a process control — and prove the correction worked. Request a WhyTrace Plus demo →
Severity, Occurrence, Detection, and Action Priority
Both FMEAs rate each failure mode on three dimensions — Severity, Occurrence, and Detection — but the harmonized AIAG & VDA method now uses Action Priority (AP) rather than the older Risk Priority Number (RPN) to decide what gets worked first.
The shift matters for engineers because RPN — the simple product of S × O × D — treated a 5×5×5 (=125) the same as a 1×5×25 (=125), even though a high-severity failure deserves attention regardless of how the math lands. Action Priority tables map combinations of S, O, and D to High, Medium, or Low priority, with severity weighted so that dangerous failures are never deprioritized by a low occurrence score.
| Element | What it rates in DFMEA | What it rates in PFMEA |
|---|---|---|
| Severity (S) | Consequence of the design failure to the user/system | Consequence of the nonconformity downstream |
| Occurrence (O) | Likelihood the design cause produces the failure | Likelihood the process cause occurs |
| Detection (D) | Ability of design controls to detect before release | Ability of process controls to detect before shipment |
| Output | Action Priority (H / M / L) | Action Priority (H / M / L) |
Practical guidance for rating consistently:
- Severity is a property of the effect, not the cause. It does not change between design and process FMEA for the same end effect — a fractured shaft is equally severe whether the cause is a design margin or an installation error.
- Detection is the most over-rated element. Teams optimistically assume their controls catch failures. A detection control that depends on a human noticing something deserves a poor (high) detection rating.
- Drive Occurrence and Detection down, not the score. The goal of an action is to reduce the real likelihood or improve real detection, not to lower a number to clear a threshold.
For a side-by-side look at how FMEA compares to other structured methods you may reach for — fault tree, 5 Whys, fishbone — see the framework comparison guide, which maps each method to the failure situations it handles best.
Common Mistakes Engineers Make in Both FMEAs
The recurring FMEA failures are predictable enough to list, and most of them trace back to a blurred boundary between design and process or to treating the FMEA as a compliance document rather than an engineering tool.
- Mixing scopes. Process causes in the DFMEA, design causes in the PFMEA. This is the most common and most damaging error because it sends corrective actions to the wrong team.
- Failure modes written as causes. "Bolt under-torqued" is a cause; the failure mode is "joint loosens." Conflating them collapses the analysis.
- Single-pass FMEAs. Built once for PPAP, never revised. An FMEA that does not absorb field failures and design changes is a historical document, not a live risk control.
- Detection inflation. Rating detection controls more favorably than the evidence supports, which artificially lowers Action Priority and hides real risk.
- No link to the control plan (PFMEA). A PFMEA whose controls never make it into the control plan identifies risk and then does nothing about it.
- Vague actions. "Improve inspection" cannot be verified. Actions must define an observable, closeable outcome — a specific poka-yoke installed, a tolerance tightened, a DV test added.
The thread connecting these mistakes is the same one that connects FMEA to broader corrective action management: identifying a risk is the easy part, and following it through to a verified, effective change is where systems fail. The same discipline that closes a corrective action — named owner, due date, effectiveness verification — applies to closing an FMEA action.
Frequently Asked Questions
Q. Do you need both a DFMEA and a PFMEA?
If your organization both designs and manufactures the product, yes — they cover different risks and neither substitutes for the other. A supplier that only manufactures to a customer's print may produce only a PFMEA, while the design responsibility (and DFMEA) sits with the customer. Where design responsibility is shared, the special characteristics from the DFMEA must still flow into the PFMEA regardless of who owns each document.
Q. Which comes first, DFMEA or PFMEA?
The DFMEA comes first. It starts in the concept and design phase and identifies the design's failure modes and special characteristics. The PFMEA starts during process planning, before PPAP, and uses the DFMEA's outputs — especially the flagged special characteristics — as inputs. Running the PFMEA without a completed DFMEA means the process analysis cannot know which design characteristics are critical to control.
Q. Is RPN still used, or only Action Priority?
The harmonized AIAG & VDA FMEA Handbook replaced RPN with Action Priority (AP) as the recommended method for prioritizing actions. Many organizations still calculate RPN for legacy continuity or because a customer requires it, but AP is the current standard because it weights severity correctly and avoids the false equivalence that RPN's simple multiplication created. If you are starting a new FMEA program, build it on Action Priority.
Q. Where does the control plan fit in?
The control plan is the operational output of the PFMEA. The PFMEA identifies process risks and the controls that mitigate them; the control plan deploys those controls to the shop floor as specific inspections, SPC charts, and error-proofing requirements. A PFMEA without a corresponding control plan stops at analysis and never reaches production.
Q. How often should FMEAs be updated?
Both FMEAs are living documents. Update the DFMEA on any design change. Update the PFMEA on any process change, new equipment, or relocation. Critically, update both whenever field failures, warranty returns, or internal nonconformities reveal failure modes the original analysis missed — this field feedback is the highest-value source of FMEA improvement and the one most often neglected.
Key Takeaways
- Design FMEA analyzes whether the product design can fail to perform its function; Process FMEA analyzes whether the manufacturing process can fail to produce a conforming part. They have different owners, inputs, and corrective actions.
- Keep the boundary clean: design causes belong in the DFMEA, process causes in the PFMEA. Mixing them routes corrective actions to the wrong team.
- The DFMEA comes first and feeds the PFMEA through special characteristics; the PFMEA in turn produces the control plan that the shop floor runs to.
- The harmonized AIAG & VDA method uses Action Priority (AP) instead of RPN, weighting severity so that dangerous failures are never deprioritized by a low occurrence score.
- FMEAs are living documents — the highest-value updates come from feeding real field failures back into both analyses, which requires a structured failure record.
Run your FMEA program on real failure data. WhyTrace Plus captures incidents and field failures, drives root cause analysis to a verified cause, and feeds the result back into your DFMEA and PFMEA — so the next revision fixes the right thing on the right side. Start with WhyTrace Plus →
Related Resources
| Resource | Description | Best For |
|---|---|---|
| RCA Framework Comparison: 5 Whys, Fishbone, FMEA, Fault Tree | Side-by-side comparison of structured analysis methods and when to use each | Engineers choosing the right method for a given failure situation |
| Corrective Action Management: Stop Losing Track of Your CAPA Items | How to drive FMEA and corrective actions to verified closure | Quality engineers connecting FMEA actions to closed-loop CAPA |
| WhyTrace Plus | Incident and failure tracking with AI root cause analysis that feeds your FMEAs | Design and quality teams building FMEAs on real data |