DFMEA vs PFMEA: Key Differences and When to Use Each
Most engineers know there are different types of FMEA. Fewer know exactly where one ends and the other begins — or how they are supposed to connect to each other.
The confusion is understandable. Both DFMEA and PFMEA use the same basic framework: identify failure modes, assess severity and likelihood, document controls, prioritise action. The difference is in what they are analysing and who is responsible for running them.
Getting this distinction right matters because using the wrong type of FMEA for a given problem means either missing failure modes or doing redundant work. This guide explains both types clearly, when to use each, and how they fit together in a product development programme.
The Core Distinction
DFMEA (Design FMEA) analyses the product design. It asks: how can this component or assembly fail to perform its intended function, and what are the consequences?
PFMEA (Process FMEA) analyses the manufacturing or assembly process. It asks: what can go wrong during production, and what effect does that have on part quality and product performance?
The boundary between them is the design intent. DFMEA assumes the manufacturing process produces the part to print — it is not concerned with how the part is made, only with whether the design itself is adequate. PFMEA assumes the design is correct and asks whether the process can reliably produce it.
In practice this means:
- A shaft that fractures under normal operating torque is a design failure — it belongs in the DFMEA
- A shaft that fractures because a heat treat step was missed in production is a process failure — it belongs in the PFMEA
- A housing bore that is out of tolerance because the drawing spec is too tight for the machining process is a design problem (the tolerance is not achievable) — DFMEA, flagged as a design input issue
- A housing bore that is out of tolerance because the CNC programme has an error is a process problem — PFMEA
Design FMEA (DFMEA)
What it covers
DFMEA analyses the product design at the component and subsystem level. The scope includes:
- Component failure modes (fracture, deformation, wear, corrosion, fatigue, leakage, binding, electrical failure)
- Interface failures between components (misalignment, interference, insufficient clearance)
- System-level effects of component failures
- Design decisions that influence reliability: material selection, geometry, tolerances, surface finish specifications, fastener choices
Who runs it
DFMEA is owned by the design engineering team. It should involve people with knowledge of the design intent, the use environment, relevant failure modes for the materials and geometries involved, and field experience from similar products. Quality engineering typically participates as a facilitator and reviewer.
When to run it
DFMEA should begin during concept development, when design decisions are still fluid and changes are cheap. The first pass is done at a high level with limited detail. It is then iterated as the design matures — updated at each major design milestone and whenever a design change affects a previously analysed failure mode.
The critical mistake is waiting until the design is finalised before starting the DFMEA. By that point, many design decisions that influence reliability are locked in, and changing them requires significant engineering effort.
Inputs
- Design requirements and specifications
- Interface requirements and boundary conditions
- Use environment (temperature, humidity, load cycles, duty cycle)
- Customer usage profiles (including misuse scenarios)
- Warranty and field data from similar products
- Lessons learned from previous programmes
Outputs
- Ranked list of failure modes by risk priority number (RPN)
- Actions assigned to reduce severity, occurrence, or detection
- Design decisions documented with rationale
- Basis for test plan development (what to test and why)
Process FMEA (PFMEA)
What it covers
PFMEA analyses each step in the manufacturing or assembly process. The scope includes:
- Process step failures (wrong operation, incorrect sequence, incomplete operation)
- Parameter variation (temperature out of range, torque incorrect, dimensions out of tolerance)
- Material handling and contamination issues
- Human factors (errors of omission, errors of commission, labelling confusion)
- Tooling and equipment failures
- Measurement system adequacy
Who runs it
PFMEA is owned by manufacturing or process engineering, typically with involvement from quality, production, and the design team. Design engineering needs to participate because some process failures reveal design vulnerabilities — a part that is easily assembled incorrectly may need a design change (poka-yoke feature) rather than just a process control.
When to run it
PFMEA should begin during process planning, when the manufacturing process is being defined. This is typically during the advanced product quality planning (APQP) phase in automotive, or during design for manufacturing (DFM) reviews in other industries.
Like the DFMEA, it should be iterated as the process is refined and updated whenever a process change affects a previously analysed step.
Inputs
- Process flow diagram (every process step documented)
- Control plan requirements
- Design FMEA outputs (the DFMEA failure modes that can be caused or worsened by the process)
- Similar product process history and lessons learned
- Regulatory and customer-specific requirements
Outputs
- Ranked list of process failure modes by RPN
- Control plan: the ongoing controls that prevent or detect each failure mode in production
- Inspection and test requirements
- Operator instructions for critical process steps
- Statistical process control (SPC) requirements for critical parameters
How DFMEA and PFMEA Connect
DFMEA and PFMEA are not independent documents. They are linked, and the outputs of one feed the inputs of the other.
DFMEA outputs that feed PFMEA
The DFMEA identifies which design characteristics are critical to function — tight tolerances, specific surface finishes, heat treat requirements, assembly orientations. These become the process characteristics that the PFMEA must ensure the manufacturing process can reliably achieve.
If the DFMEA identifies that a shaft fracture is the critical failure mode and the cause is insufficient fillet radius, the PFMEA needs to address how to ensure the fillet radius is produced correctly and inspected before the shaft ships.
PFMEA outputs that feed DFMEA revision
The PFMEA can reveal design issues. If a process step is difficult to control — for example, an assembly that is easy to assemble backwards, or a tolerance that is not achievable with the available process capability — this is a design input problem. The finding should be fed back to the design team to consider a design change that either makes the process more robust or relaxes the specification to match process capability.
This feedback loop between DFMEA and PFMEA is where significant reliability improvements often come from in mature development programmes.
DFMEA vs PFMEA: Side by Side
| | DFMEA | PFMEA | |---|---|---| | Analyses | Product design | Manufacturing process | | Failure modes | How the design fails to perform its function | How the process fails to produce the design correctly | | Owner | Design engineering | Manufacturing / process engineering | | Timing | Concept through design release | Process planning through production launch | | Inputs | Design requirements, use environment, field data | Process flow, control plan requirements, DFMEA outputs | | Outputs | Design actions, test plan basis | Control plan, inspection requirements, operator instructions | | Assumptions | Process produces the part to print | Design is correct | | Severity | Effect on the end user or system | Effect on the next operation or end product |
System FMEA: When You Need Both
For complex products — particularly in automotive, aerospace, and medical devices — a System FMEA or Functional Safety analysis precedes both DFMEA and PFMEA. System FMEA analyses how subsystem failures cascade and interact at the system level, before the design of individual components is defined.
The hierarchy is:
- System FMEA — subsystem interactions and cascading failures
- DFMEA — individual component and assembly design
- PFMEA — manufacturing and assembly process for each component
In smaller product development programmes, the System FMEA is often abbreviated or folded into the DFMEA. This is a practical compromise, but it increases the risk of missing interface failures between subsystems.
The Maintenance Problem Applies to Both
The same maintenance problem that affects DFMEA also affects PFMEA. When the design changes, the DFMEA needs to be updated. When the process changes, the PFMEA needs to be updated. In practice, both documents drift behind reality as development progresses under schedule pressure.
The consequence in DFMEA is an analysis that does not reflect the design that ships. The consequence in PFMEA is a control plan that does not reflect the process that runs. Both create audit risk and, more importantly, genuine quality risk.
The solution is the same in both cases: make updating the analysis fast enough that it actually happens. That means either disciplined review gates built into the programme schedule, or tooling that reduces the time required to update the analysis.
ForgePilot has an FMEA generation tool that works for both DFMEA and PFMEA. You describe your design inputs or process steps, and the tool produces structured failure mode analysis you can review, modify, and keep current — rather than rebuilding from a blank spreadsheet every time the design or process changes.
Summary
DFMEA and PFMEA address different questions. DFMEA asks whether the design is adequate. PFMEA asks whether the process can reliably produce the design.
They are not interchangeable, and running one does not substitute for the other. In a complete product development programme, both are necessary — and both need to be maintained through the life of the programme.
Start DFMEA early, during concept development. Start PFMEA when the manufacturing process is being defined. Link them explicitly — use DFMEA outputs to identify critical characteristics for the PFMEA, and use PFMEA findings to flag design issues back to the design team.
And update both whenever the design or process changes. That is the part that is hardest to do consistently — and the part that matters most.