DFMEA vs PFMEA: How Design and Process FMEA Divide the Work and Where They Have to Line Up
A contract machining shop won a program to make a hydraulic manifold to a customer print. The purchase order flowed down "FMEA per AIAG-VDA." The plant had a solid PFMEA process and built one. At the PPAP review the customer SQE asked for the DFMEA. The quality manager pushed back: the shop does not own the design, so there is no design FMEA to write. The SQE agreed on that point, then asked a different question. Where in your PFMEA do you address the bore diameter that the print marks as a special characteristic, and does your failure effect severity match what the design says that characteristic does when it drifts?
That is the real relationship between a DFMEA and a PFMEA, and it is why treating them as interchangeable gets a submission kicked back. They are two different analyses that meet at a specific handoff. This guide covers what each one analyzes, how the AIAG-VDA seven-step method applies to both, and the severity and characteristic links that a reviewer checks before reading anything else.
The One-Sentence Difference
A DFMEA analyzes how the product design can fail to meet its intended function, and a PFMEA analyzes how the manufacturing process can fail to build the product as designed. The DFMEA asks whether the part is right on paper. The PFMEA asks whether your process can make the paper come true every time. Same seven-step method, same one-to-ten scales for Severity, Occurrence, and Detection, different subject entirely. The DFMEA is owned by design or product engineering and is usually finished before the process exists. The PFMEA is owned by manufacturing and quality and is built against a real process flow. Where they connect is the special characteristic and its severity, which the design side sets and the process side has to carry forward without changing.
If you need the underlying PFMEA mechanics first, our Process FMEA practical guide walks the columns and the AIAG-VDA scoring in detail. This post is about the split between the two FMEAs and the seam where they have to agree.
What Each One Analyzes
The word "failure mode" means something different in each document, and most of the confusion starts there.
In a DFMEA, a failure mode is a way the design fails to deliver a function under its operating conditions. The manifold cracks at rated pressure. The seal groove geometry lets the O-ring extrude. The wall section is too thin to survive thermal cycling. These are properties of the design itself. They would exist even if the part were machined perfectly to print, because the print is what is being questioned. The DFMEA's job is to find those before the design is released, so the fix is a drawing change rather than a field return.
In a PFMEA, a failure mode is a way the process fails to produce the part as the released print specifies. The bore is machined oversize. The wrong material lot is loaded. The deburr operation is skipped. The heat treat runs cold and the case depth comes in short. These assume the design is correct and ask what can go wrong between raw stock and finished part. The PFMEA's job is to find those and put controls in the process before the first production run.
This is why a build-to-print supplier can legitimately have a PFMEA and no DFMEA. The supplier does not own the design, so design failure modes are the customer's responsibility. But the moment the customer flags a characteristic as special or critical, part of the design analysis crosses the fence, and the supplier's PFMEA has to pick it up. More on that seam below.
The Same Seven Steps, Different Structure Trees
The 2019 AIAG-VDA FMEA Handbook put both FMEAs on the same seven-step method: Planning and Preparation, Structure Analysis, Function Analysis, Failure Analysis, Risk Analysis, Optimization, and Results Documentation. The method is shared. What differs is what goes into the structure tree in step two, and that difference cascades through the rest.
A DFMEA structure tree decomposes the product: system, then subsystem, then component. For the manifold that is the hydraulic system, the manifold body and its ports as subsystems, and the individual bores, seal grooves, and threads as components. The focus element is a component, and the analysis looks up to the effect at the system level and down to the design characteristic that drives the failure.
A PFMEA structure tree decomposes the process: the overall process, then each process step or operation, then the work elements inside a step. The work elements are usually organized by the four Ms, which are Man, Machine, Material, and Method or Environment. The focus element is a process step, and the analysis looks up to the effect on the customer and down to the cause in one of the four Ms.
The practical consequence: a DFMEA row reads like "seal groove depth out of design tolerance leads to O-ring extrusion leads to loss of pressure," and a PFMEA row reads like "boring operation produces oversize bore because tool wear compensation was not applied, detected by post-op bore gauge." Different subject, different level of the world. A reviewer who sees process language in a DFMEA or design language in a PFMEA knows the team blurred the two.
Severity, Occurrence, and Detection Are Rated Differently
All three ratings run one to ten in both FMEAs, and the AIAG-VDA method replaced the old Risk Priority Number with Action Priority in both. But what the numbers describe changes with the subject.
| Element | In the DFMEA | In the PFMEA |
|---|---|---|
| Failure mode | Design fails to meet a function | Process fails to build to print |
| Effect | Consequence to system, vehicle, end user | Consequence to next operation, assembly, end user |
| Severity (S) | Severity of the design effect | Severity of the same effect, inherited where the characteristic is shared |
| Cause | Design deficiency (material, geometry, tolerance) | Process cause in one of the four Ms |
| Occurrence (O) | Likelihood the design cause produces the failure | Likelihood the process cause produces the failure, given prevention controls |
| Detection (D) | Ability of design validation to catch it | Ability of process controls to catch it before ship |
| Owner | Design or product engineering | Manufacturing and quality engineering |
| Timing | Before design release | Against a real process flow, before PPAP |
The rule that trips people up is on Severity. Severity is rated on the effect, and process controls cannot lower it. If a bore going oversize causes loss of clamping force, and loss of clamping force is a Severity 8 effect, no amount of inspection changes the 8. Inspection is a detection control, and detection controls only move Detection. Adding a poka-yoke moves Occurrence. Severity stays put until the design or the effect itself changes. This is true in both FMEAs, and it is the reason Severity is the hinge that links them.
The Seam: How Severity and Characteristics Cross From Design to Process
Here is the connection a reviewer checks first, because it is where the two documents either agree or expose that nobody reconciled them.
The DFMEA identifies design critical characteristics, the features whose variation drives a high-severity effect. Those become special characteristics on the drawing, usually carrying a symbol. The PFMEA then has to address the matching process critical characteristics, the process outputs that control those same features. From the PFMEA the special characteristic flows into the Control Plan with its inspection method, then into an MSA study if it is measured, then into a capability study or control chart. AIAG frames the cascade this way:
- Design FMEA identifies design critical characteristics
- Process FMEA addresses the corresponding process critical characteristics
- Control Plan specifies each special characteristic with its symbol and method
- Process flow marks the operations that control those characteristics
- Each one gets a PFMEA failure mode, a Control Plan entry, an MSA study if measured, and a capability study or control chart
When you run a linkage check between the two FMEAs, two distinct problems fall out, and they are not equally serious.
The first is a design characteristic with no process coverage. The DFMEA flagged bore diameter, surface hardness, wall thickness, and weld penetration as characteristics that drive failures, but the PFMEA has no failure mode, and the Control Plan has no entry, for one of them. That is a critical gap. The design said this feature matters, and the process has no plan to control it. A reviewer treats an uncovered special characteristic as an automatic finding.
The second is a process characteristic that does not trace back to any design characteristic. Your PFMEA controls clamp fixture torque, and no line in the DFMEA mentions clamp torque. That is usually fine. It is a process-specific control that the manufacturing method needs but the design never called out. The reviewer notes it and moves on. The asymmetry is the point: a design characteristic with no process coverage is a defect, while a process characteristic with no design parent is normal.
The severity has to survive the crossing intact. If the DFMEA rates the effect of an out-of-tolerance bore at Severity 9, the PFMEA failure effect for a bore machined out of tolerance is also a 9. A team that independently scores the PFMEA and lands on a 6 for the same effect has a mismatch that says the two documents were built in isolation. For build-to-print work where you have no DFMEA, the customer print and its special-characteristic symbols are your design input, and the severity you assign has to be consistent with what those symbols imply.
Who Needs Which, and What PPAP Expects
Whether you owe a DFMEA depends on design responsibility, and PPAP treats the two FMEAs as different elements.
If you are design responsible, you owe both. The DFMEA is part of your design records, and the PFMEA is a submission element in its own right. In the AIAG PPAP framework, the Design FMEA sits with the design record family and the Process FMEA is its own PPAP element, so a reviewer expects to see both and expects the special characteristics to be traceable from one into the other and onward into the Control Plan.
If you are build-to-print, you typically owe the PFMEA and not a full DFMEA, because you do not own the design. What you cannot skip is the special-characteristic handoff. The customer's print and any provided design risk analysis are your design input, and your PFMEA has to cover every characteristic the print marks. Read the customer-specific requirements before you assume a DFMEA is out of scope, because some customers require the supplier to produce or contribute to a DFMEA even on build-to-print work.
Aerospace bends this further. Under AS9145 the design side of the analysis appears as a Design Risk Analysis rather than an AIAG-style DFMEA, and it is an explicit PPAP element even for suppliers who would not produce a DFMEA in the automotive world. If an aerospace customer flows down AS9145, do not assume your automotive habit of skipping design analysis on build-to-print carries over. Our AS9145 field map covers where the aerospace framework diverges from what AIAG-trained teams expect.
For how the Process FMEA fits the full submission alongside the Control Plan and initial process studies, see the PPAP 18 elements checklist.
Four Kickback Patterns
These are the recurring reasons a reviewer sends the FMEA set back, and all four come from the two documents not being reconciled against each other.
Severity mismatch across the two FMEAs. The DFMEA rates an effect a 9 and the PFMEA rates the same effect a 6. Fix by driving the PFMEA severity from the DFMEA severity for every shared effect. Severity is inherited, not re-invented.
A special characteristic the PFMEA never addresses. The print or the DFMEA flags a characteristic, and there is no matching PFMEA failure mode or Control Plan line. This is the critical-gap case above. Fix by walking every special-characteristic symbol on the print into a PFMEA row and a Control Plan entry.
Design language in the PFMEA or process language in the DFMEA. A PFMEA row that says "wall too thin" is analyzing the design, not the process. The process equivalent is "wall thickness under print at operation 20 because the fixture located on the wrong datum." Fix by re-anchoring the failure mode to the correct subject.
One document treated as a draft of the other. Teams sometimes write the PFMEA by copying the DFMEA and swapping words, which produces a PFMEA with no real process causes and no four-M analysis. Fix by building the PFMEA from the process flow, not from the DFMEA, and using the DFMEA only for the severity and characteristic handoff.
A Fifteen-Minute Pre-Submission QA Pass
Before the FMEA set goes into a PPAP, run this. It is the reconciliation a reviewer will run, done first by you.
- Pull the list of special characteristics from the print or the DFMEA. Confirm each one appears as a PFMEA failure mode and a Control Plan line. Any that do not are critical gaps.
- For every shared effect, check that the PFMEA severity equals the DFMEA severity. Flag any that differ.
- Confirm no process controls were used to justify a lower severity anywhere. Severity moves only with the design or the effect.
- Read three PFMEA failure modes at random. Confirm each describes a process failure with a four-M cause, not a design deficiency.
- Confirm each special characteristic that is measured has an MSA study behind its Control Plan method, and an initial capability study or control chart. Our Gauge R&R acceptance criteria and Cpk vs Ppk posts cover what those studies have to show.
- Confirm the Occurrence ratings reference real prevention controls, not aspirations.
- Confirm process characteristics with no design parent are genuinely process-specific and not a design characteristic you dropped.
- Confirm the Control Plan reaction plans match the PFMEA detection controls, so the two documents describe the same response to the same failure. The Control Plan build guide covers the reaction-plan link.
If all eight pass, the FMEA set will survive the part of the review that fails most submissions.
Where QualityEngineer.ai Fits
The reason DFMEA and PFMEA drift apart is that most teams build them in separate spreadsheets and reconcile them by memory the week the PPAP is due. QualityEngineer.ai closes that seam by treating the documents as one connected cascade.
In Build, the special characteristics identified in the design analysis carry forward into the PFMEA and then into the Control Plan as a single lineage, so a characteristic flagged on the design side cannot silently disappear before it reaches a control. Severity set once propagates rather than getting re-typed and re-guessed. When a design revision changes a characteristic, the change surfaces in the linked PFMEA and Control Plan instead of waiting for someone to remember. Blueprint Intelligence pulls the dimensions, tolerances, GD&T, and special-characteristic symbols straight off the drawing, so the characteristic list your FMEAs work from matches the print rather than a hand-retyped table.
When the package is assembled, Package runs the 18-element gap analysis and cross-document validation that checks exactly the seam this post is about: every special characteristic covered, severities consistent, MSA and capability behind each measured feature. Analyze supplies the Gauge R&R and capability math those characteristics need. The engineering judgment stays with your team. The reconciliation that eats a Friday before every submission does not.
Start a 30-day trial, no credit card required, at qualityengineer.ai and run your next DFMEA and PFMEA as one linked set instead of two spreadsheets you reconcile by hand.
Frequently Asked Questions
What is the main difference between DFMEA and PFMEA?
A DFMEA analyzes how a product design can fail to meet its intended function, and a PFMEA analyzes how the manufacturing process can fail to build the product to the released design. The DFMEA questions the drawing and is owned by design engineering before the process exists. The PFMEA assumes the drawing is correct and questions the process, and is owned by manufacturing and quality against a real process flow.
Do you always need both a DFMEA and a PFMEA?
Not always. A design-responsible supplier owes both. A build-to-print supplier that does not own the design typically owes the PFMEA and not a full DFMEA, but still has to address every special characteristic the print marks. Check the customer-specific requirements, because some customers require a supplier DFMEA even on build-to-print work, and aerospace under AS9145 requires a Design Risk Analysis as a PPAP element regardless.
How do the DFMEA and PFMEA severity ratings relate?
Severity is inherited, not re-invented. For an effect that appears in both documents, the PFMEA severity should equal the DFMEA severity, because both rate the same consequence to the customer. Process controls never lower severity. They move Occurrence and Detection. A team that scores the same effect differently in the two FMEAs has a mismatch a reviewer will flag.
What links the DFMEA to the PFMEA?
The special characteristic and its severity. The DFMEA identifies design critical characteristics, which become special characteristics on the drawing. The PFMEA has to address the matching process characteristics, which then flow into the Control Plan, an MSA study if measured, and a capability study or control chart. A design characteristic with no PFMEA coverage is a critical gap. A process characteristic with no design parent, like fixture clamp torque, is usually a legitimate process-specific control.
Does the AIAG-VDA seven-step method apply to both?
Yes. The 2019 AIAG-VDA FMEA Handbook put both FMEAs on the same seven steps and replaced the Risk Priority Number with Action Priority in both. What differs is the structure tree in step two. The DFMEA tree decomposes the product into system, subsystem, and component, while the PFMEA tree decomposes the process into process, step, and four-M work element.
