DFMEA vs. PFMEA: Differences, Examples and When to Use Each

DFMEA vs. PFMEA distinguishes two applications of failure mode and effects analysis. Design FMEA evaluates how a product design could fail to perform its intended functions. Process FMEA evaluates how manufacturing or assembly could fail to deliver the specified product. Both identify potential failures, consequences, causes and controls so teams can prioritize preventive action.¹

The distinction matters because the same customer complaint can originate in either place. Improving production consistency will not correct an inadequate product specification. Revising a sound specification will not necessarily prevent a production operation from missing it.

For engineering leaders, the practical task is to establish where the failure originates, assign responsibility for the corrective action and preserve the connection between product requirements and production controls.

DFMEA vs. PFMEA at a Glance

• DFMEA analyzes the design. PFMEA analyzes the process that builds it.
• DFMEA asks whether the specification is adequate. PFMEA asks whether the operation meets it.
• A DFMEA action changes or verifies the design. A PFMEA action changes or verifies the process.
• The same customer complaint can originate in either. Diagnose the source before choosing the corrective action.
• A change that crosses the design and production boundary should reopen both.

The Difference Is the Source of Failure

What is DFMEA?

DFMEA stands for Design Failure Mode and Effects Analysis. It is a structured review of how a product, system, subsystem or component design could fail to perform its intended functions, together with the effects of those failures, their causes, and the design controls that prevent or detect them.²

What is PFMEA?

PFMEA stands for Process Failure Mode and Effects Analysis. It is a structured review of how a manufacturing or assembly process could fail to deliver the specified product, together with the effects of those failures, their causes, and the process controls that prevent or detect them.³

Comparison	DFMEA	PFMEA
Subject of analysis	Product, system, subsystem or component design	Manufacturing or assembly process and its operations
Central concern	Whether the specified design can perform its functions	Whether the process can consistently deliver requirements
Starting information	Functions, requirements, interfaces and intended operating conditions	Process flow, operation requirements and product characteristics
Typical causes examined	Material selection, geometry, tolerances and interface decisions	Methods, equipment, materials, measurement and operating conditions
Evidence sought	Design analysis and verification results	Evidence that process controls prevent or detect nonconformity
Primary improvement direction	Change or verify the design	Change or verify the production process

These differences describe the scope of the analyses; they do not eliminate the need for collaboration between design, manufacturing and quality personnel.²³

When to Use Each Analysis, and When to Reopen Both

Begin FMEA while decisions remain changeable. It is appropriate for new or revised products and processes, new applications of existing designs and investigations that reveal previously unaddressed failure risks.¹

Use DFMEA when changing the product or its operating assumptions. Relevant triggers include a new design, modified components or an existing product exposed to a different environment or duty cycle. An unchanged drawing does not establish that the original risk analysis remains valid in a new application.²

Use PFMEA when developing or changing the production method. New technology, modified operations and relocation of an existing process are reasons to reassess process risk. Begin early enough for findings to influence tooling and process decisions.³

Avoid using departmental ownership as the routing rule. A manufacturing proposal may require a design change; a design revision may create new production risks. Route the decision by its technical consequences.

Published Examples: One Door, Two Different Failure Chains

Published automotive sample reports provide a useful comparison involving corrosion protection inside a vehicle door. These are instructional examples generated in 2017, not independently verified production case studies or evidence of commercial performance.⁴⁵

DFMEA example: the protection specification is inadequate

The design sample identifies corrosion of the lower inner door panel. One potential cause is a specified protective-wax boundary that is too low. The proposed investigation uses accelerated corrosion testing; the sample records a subsequent change to that boundary.⁴

This is a design issue: correctly following the original specification would still leave the protection requirement inadequately addressed.

PFMEA example: the operation does not achieve the specification

The process sample examines manual wax application. Insufficient coverage is linked to the spray head not being inserted far enough. A proposed action adds a physical depth stop to the sprayer.⁵

Here, the process fails to deliver the specified coverage. The corrective action addresses application consistency. Require evidence that the action addresses the identified failure chain, then verify that the corresponding specification or production instruction actually changed. Teams responsible for production controls should be able to point to the revised document, not simply to the completed action.

Separate Failure Mode, Effect and Cause Before Assigning Scores

An FMEA should identify the function, its potential failure, the resulting effects, the causes and the controls. Risk evaluation and assigned actions follow that analysis.⁶

Keep these distinctions explicit. The failure mode is the way the item or operation fails to meet its function or requirement. The effect is the consequence of that failure. The cause is the mechanism or condition that produces the failure.¹

As a review practice, read each row backward from effect to cause. The proposed cause should plausibly produce the stated failure, and that failure should plausibly produce the stated consequence. If the connection requires an explanation that is absent from the record, revise the record.

Also separate unknowns from conclusions. Record an unverified cause as a hypothesis requiring investigation. Do not turn uncertainty into a confident rating merely because the worksheet requires a number.

What Severity, Occurrence and Detection Actually Measure

Three ratings drive every prioritization method, and each answers a different question. Mixing them is the most common source of an indefensible score.

Severity rates how serious the effect would be if the failure occurred, typically from 1 for no noticeable effect to 10 for a safety or regulatory consequence. It measures impact alone. A failure that is rare, or one that inspection would probably catch, does not become less severe for those reasons.¹¹

Occurrence rates how likely the failure is. The important detail is what it attaches to: occurrence is assigned to the cause, not to the failure mode. AIAG, SAE J1739 and VDA all take that position, and the reason becomes obvious in practice. A single failure mode such as a broken cable may arise from corrosion or from fatigue cracking, two causes with very different likelihoods. Rating the mode instead of the cause averages them into a number that describes neither.¹²

Detection rates how effectively the controls currently in place would find the cause or the failure before it reaches the customer, from 1 for a strong, proven control to 10 for no control at all. Rate the controls that exist, not the ones planned for a future phase.¹³

Detection also means different things in each analysis. In a DFMEA it refers to design verification and validation activity such as simulation, prototype testing and design review. In a PFMEA it refers to process controls such as error-proofing, in-process gauging and end-of-line test.¹³

The evaluation criteria behind the numbers are not identical for design and process analyses, and organizations often maintain customized scales. Whatever tables apply, use them consistently across the organization so that technical risks from different FMEAs remain comparable.¹¹

RPN and Action Priority Are Different Prioritization Methods

Traditional risk priority number scoring multiplies severity, occurrence and detection ratings into a single value between 1 and 1,000:

RPN = Severity × Occurrence × Detection⁶

The AIAG–VDA FMEA Handbook introduced in 2019 replaced that calculation with an Action Priority methodology within its harmonized approach. It also introduced revised rating tables and a structured seven-step development process.⁷

Action Priority is not a product. It is a lookup: the severity, occurrence and detection combination is read from a reference table that returns a high, medium or low priority for action, weighting severity most heavily, then occurrence, then detection.⁹ The practical consequence is that a safety-relevant failure cannot be diluted by a low occurrence estimate or an optimistic detection rating.

That change does not mean every FMEA in every industry must use the same method. Establish the governing customer requirements and organizational methodology before choosing the form, rating tables or prioritization rules. Do not combine legacy scores with a newer method without checking their compatibility.⁶⁷

The distinction is particularly relevant when learning from older examples. The door reports above use legacy RPN formats; they illustrate failure logic, not current AIAG–VDA scoring instructions.⁴⁵⁷

Score the identified risk, not the desired outcome

Use the ratings as a record of judgment supported by evidence. For each rating, ask the reviewer to identify the applicable criterion and the information that supports it.

When an action is proposed, specify what must be demonstrated before reassessment. Purchasing equipment, scheduling a test or assigning training should not be treated as proof that the action worked. The FMEA process includes implementing corrective actions and reevaluating risk afterward.⁶

For managerial review, retain the original assessment, the action owner, the evidence reference and the reassessment. This makes disagreements visible and prevents an unexplained score change from standing in for a technical decision.

Both Analyses Share the Same Seven-Step Structure

The harmonized handbook formalized the activities historically involved in FMEA as discrete steps. The same seven-step sequence guides design, process and supplemental monitoring analyses; the scope and ownership change, not the structure.⁹

The handbook also defines a third, supplemental analysis: FMEA-MSR, for monitoring and system response. It evaluates whether a system can maintain a safe state or remain compliant during customer operation, focusing on whether monitoring detects a fault and whether the system response is effective. It is often used alongside a DFMEA rather than in place of one, and it is not intended for every program.¹⁰

For a team deciding between DFMEA and PFMEA, the practical point is that encountering a third analysis in the handbook does not indicate a missing step. It indicates a different question: not whether the design is adequate or whether the process delivers it, but whether the product detects and responds to a fault once it is in service.

What Each Worksheet Contains

The column headings look similar, which is precisely why the two documents get confused. The entries underneath them are not interchangeable.

Worksheet element	DFMEA entry	PFMEA entry
Item analyzed	System, subsystem or component	Process step or operation
Function	Design function and its requirement	Purpose of the operation and the product characteristic it delivers
Failure mode	The way the design fails to meet the function	The way the operation fails to meet the requirement
Effect	Consequence at the next higher level and to the end user	Consequence to downstream operations and to the end user
Cause	Design decision, material, geometry, tolerance or interface	Method, machine, material, operator, measurement or environment
Prevention control	Design standards, analysis and proven practice	Error-proofing, setup control and maintenance
Detection control	Simulation, prototype test and design verification	Inspection, gauging and end-of-line test
Ratings	Severity, occurrence and detection using design criteria	Severity, occurrence and detection using process criteria
Prioritization	RPN or Action Priority, per the governing methodology	RPN or Action Priority, per the governing methodology
Principal output	Design change and verification evidence	Control plan input and revised work instruction

The Two Documents Mirror Each Other

A linked DFMEA and PFMEA are not two independent worksheets that happen to describe the same part. Specific entries in one should correspond to specific entries in the other, and where they do not, one of the two is usually out of date.

Three correspondences are worth checking explicitly during review:¹⁴

• A PFMEA failure mode that produces a product-level effect should appear as a potential cause in the DFMEA. The process failing in that way is one reason the product could fail.
• A DFMEA failure mode produced by the process should appear in the PFMEA as a failure effect. The design consequence is what the process operation risks causing.
• Where both documents describe the same effect, the severity rating should be the same in both. Severity belongs to the effect, and the effect does not change because a different team is analyzing it.

A severity mismatch on a shared effect is a useful audit signal. Either the two descriptions are not actually the same effect, in which case the wording needs correcting, or one document has not been revised since the other changed.

Link DFMEA to PFMEA Through Requirements, Not Copied Rows

The useful connection between DFMEA and PFMEA is traceable product information. Design characteristics inform process requirements, and process-analysis findings inform the control plan.²³⁸

A copied description is not sufficient evidence of that connection. For each important handoff, identify the product requirement by referencing the controlled drawing, specification or requirement identifier, then confirm which process operation delivers it, which control verifies it and what evidence demonstrates the control works. The design assumptions recorded during development are what make that trace reconstructable later.

Bring Decision Authority, Not Just Attendance

FMEA is a team activity that can involve design, manufacturing, reliability, quality and other relevant functions.¹ Attendance alone, however, does not establish who can approve a specification change or commit resources to a process action.

Before the review, name the decision owner for each type of action. Design changes need an authorized design decision; process changes need an accountable implementation owner, and the manufacturing responsibilities for implementation should be assigned by name rather than by department. The facilitator should keep the discussion and documentation consistent while preserving those responsibilities.

Function	DFMEA	PFMEA	Control plan
Design engineering	Typically leads	Provides requirements and clarification	Confirms characteristics
Manufacturing or process engineering	Reviews producibility	Typically leads	Defines the controls
Quality	Challenges evidence	Challenges evidence	Typically maintains
Reliability or test	Supplies verification results	Supplies capability data	Supports measurement method
Supplier	Leads where design-responsible	Leads for its own operations	Maintains its own
Program management	Convenes the decision	Convenes the decision	Tracks release readiness

Treat that allocation as a starting point. Actual ownership is set by the organization, the contract and any customer-specific requirement, and it should be named in the FMEA plan rather than assumed.

Use a short evidence request for unresolved actions. What technical question remains open? Who will resolve it? What result will demonstrate resolution? Which release or operating decision depends on the result?

This approach turns a broad instruction to improve the FMEA into a set of reviewable engineering commitments.

Eight Mistakes That Undermine Both Analyses

1. Routing a change by department instead of by technical consequence. A manufacturing proposal can require a design decision, and a design revision can create process risk.
2. Rating occurrence against the failure mode instead of the cause. One mode with several causes of different likelihood produces a number that describes none of them.
3. Treating a completed action as evidence that risk changed. Buying equipment, booking a test or scheduling training is activity, not demonstrated effect.
4. Copying rows between the two documents. Matching text is not traceability. The link is the requirement identifier, not the sentence.
5. Mixing legacy RPN thresholds with Action Priority. The two methods rank differently and were not designed to be combined.
6. Letting a low occurrence estimate suppress a safety-relevant severity. This is the specific failure that Action Priority was introduced to prevent.
7. Rating detection on controls that are planned rather than in place. Score the control that exists today; record the planned one as an action.
8. Reusing an analysis for a similar product without documenting the differences. A shared part name or shared equipment is not evidence that the risk profile transfers.

Treat the Next Change as a Test of the Analysis

The lasting value of a linked DFMEA and PFMEA is the ability to evaluate the next revision without reconstructing the original reasoning. A future reviewer should be able to identify which requirement changed, which failure assumptions depend on it and which controls need renewed evidence.

Build that traceability into the current release. The next material substitution, equipment change or application change should trigger a focused technical review with identifiable owners and evidence requirements.

Key Terms

• Failure mode. The way an item or operation fails to meet its function or requirement.
• Effect. The consequence of that failure, described at the next higher level and for the end user.
• Cause. The mechanism or condition that produces the failure mode.
• Prevention control. A measure that reduces the likelihood the cause occurs. It influences the occurrence rating.
• Detection control. A measure that identifies the cause or the failure before it escapes. It influences the detection rating.
• Special characteristic. A product or process characteristic that requires additional control because of its effect on safety, regulatory compliance, fit or function.
• Control plan. The document defining the production controls applied to characteristics. It uses PFMEA findings but does not replace the PFMEA.
• RPN. Risk priority number, the legacy product of severity, occurrence and detection, on a scale of 1 to 1,000.
• Action Priority. The AIAG-VDA method that reads a severity, occurrence and detection combination from a reference table and returns high, medium or low priority for action.
• FMEA-MSR. The supplemental analysis for monitoring and system response during customer operation.

Frequently Asked Questions

Which comes first, DFMEA or PFMEA?

The DFMEA normally leads, because process analysis depends on product requirements that the design analysis establishes. In practice the two overlap. Begin PFMEA planning as soon as the process concept is known rather than waiting for a completed DFMEA, particularly where tooling or equipment decisions have long lead times. What should not happen is a PFMEA that assumes requirements the DFMEA has not yet settled.

What is the difference between FMEA and FMECA?

FMECA adds a criticality analysis to the failure mode and effects analysis, producing a ranking of failure modes by their criticality as well as their effects.⁶ The choice between them is normally set by the governing standard or customer requirement rather than by preference.

Can a supplier perform PFMEA without owning the design?

A practical approach is to obtain the product requirements, relevant failure consequences and necessary design clarification from the design authority. Keep process actions within the supplier's authority and route questions about specification adequacy back to the responsible design owner.

Should DFMEA and PFMEA use the same spreadsheet?

They can share a software environment, but preserve separate scopes and traceable links. Similar column headings do not make their functions, causes or controls interchangeable. Select the reporting format required by the applicable methodology.⁶

Can an existing FMEA be reused for a similar product?

Use it as a starting point, then document the differences. Require a review of changed requirements, application conditions, process assumptions and supporting evidence. Do not approve reuse solely because the part name or production equipment appears similar.

Is a PFMEA the same as a control plan?

No. PFMEA evaluates potential process failures and actions; the control plan uses relevant findings to define production controls. The documents should connect, but one does not replace the other.⁸

What is FMEA-MSR, and do we need one?

FMEA-MSR is a supplemental analysis for monitoring and system response during customer operation. It applies to systems that perform active or passive monitoring and response functions, and it is frequently associated with functional-safety work. It is not required for every program, and it supplements rather than replaces a DFMEA.¹⁰

Does a completed FMEA prove the product is safe?

No. FMEA has limitations, including dependence on available knowledge and data.¹ Treat completion as a review milestone. Require the applicable verification, validation and release evidence before accepting the product or process.

What should happen when reviewers disagree about a rating?

Record the disputed criterion, competing interpretations and missing evidence. Assign an owner to resolve the disagreement before the affected decision. Avoid averaging incompatible judgments merely to finish the worksheet.

Sources

1. American Society for Quality, "Failure Mode and Effects Analysis (FMEA)," reviewed November 2024. asq.org
2. Quality-One International, "Design Failure Mode and Effects Analysis (DFMEA)," accessed September 2026. quality-one.com
3. Quality-One International, "Process Failure Mode and Effects Analysis (PFMEA)," accessed September 2026. quality-one.com
4. HBM Prenscia / ReliaSoft, "Sample Automotive Design FMEA (DFMEA)," report generated November 17, 2017. reliasoft.com
5. HBM Prenscia / ReliaSoft, "Sample Automotive Process FMEA (PFMEA)," report generated November 17, 2017. reliasoft.com
6. ReliaSoft / HBK, "Failure Mode and Effect Analysis (FMEA) and Failure Modes, Effects and Criticality Analysis (FMECA)," accessed September 2026. help.reliasoft.com
7. Automotive Industry Action Group, "New AIAG & VDA FMEA Handbook and Trainings Available!", June 13, 2019. blog.aiag.org
8. Automotive Industry Action Group, "AIAG & VDA Process FMEA: Understanding and Implementing with Control Plans," accessed September 2026. aiag.org
9. Quality Digest, "Understanding AIAG-VDA's FMEA Process and Approach," June 18, 2020. qualitydigest.com
10. Quality-One International, "AIAG & VDA FMEA," accessed September 2026. quality-one.com
11. QualityTrainingPortal, "Severity, Occurrence and Detection Ratings," accessed September 2026. qualitytrainingportal.com
12. QMS Learning, "Severity, Occurrence and Detection in FMEA," August 2026. qmslearning.com
13. APiS North America, "FMEA Severity Ranking: 1–10 Scale and Guidance," accessed September 2026. apisnorthamerica.com
14. IQASystem, "DFMEA: Complete Guide to the Design FMEA," accessed September 2026. iqasystem.com