A DFMEA (Design Failure Mode and Effects Analysis) is a structured study of how a product's design could fail to perform its function, scored and ranked so the highest-risk failure modes get designed out before any part is built. It works the design on paper, not the factory that makes it.
The value of a DFMEA is not the spreadsheet. It is the set of decisions that come out of it: a wall gets thicker, a tolerance gets tightened, a redundant feature gets added, and a specific test gets written to prove the fix. A DFMEA that ends as a filed document changed nothing. A DFMEA that ends as a rib on a part, a line on the control plan and a test on the verification plan did its job. This guide walks one failure chain end to end and shows where each piece goes next.
What is a DFMEA and how is it different from a PFMEA?
A DFMEA studies the product; a PFMEA studies the process that builds it. The DFMEA asks whether the thing as drawn can fail even when it is manufactured perfectly, given its geometry, material, tolerances, and how its parts interact. The PFMEA asks whether the plant can build that design consistently. They are two halves of the same FMEA discipline, and mixing them up is the most common launch mistake. A latch that is too thin to survive vibration is a design problem the DFMEA owns. A latch that is dimensionally correct on the print but comes out short because a mold ran cold is a process problem the PFMEA owns.
Get the boundary right and the two documents reinforce each other. Get it wrong and design failure modes hide inside the process file where no one with authority to change the drawing will ever read them. For a fuller treatment of the design side as a concept, see our companion piece on the Design FMEA; this article is about doing one.
What are the seven steps of a DFMEA?
The current AIAG-VDA method runs a DFMEA in seven steps, from scoping the analysis to documenting the results. The first three build the model of what the design is supposed to do, the middle two find and rank the risk, and the last two fix the worst of it and record what changed.
- Planning and preparation. Set the scope, the team, the boundary of what is in and out, and the baseline (a similar past design and its known field failures). This is where you decide the DFMEA is about the connector housing, not the wire harness it plugs into.
- Structure analysis. Break the design into its parts and interfaces. The interfaces matter most, because failure modes hide where two components meet.
- Function analysis. Write what each part and interface is supposed to do, in measurable terms. "Retain the mating connector against 15 G vibration for the vehicle life" beats "hold the connector."
- Failure analysis. For each function, list the failure modes (ways it fails to do the function), the effects on the customer, and the causes in the design. This builds the chain in the diagram above.
- Risk analysis. Score severity of the effect, occurrence of the cause, and detection of the current design control, each on a 1 to 10 scale, and read off an Action Priority.
- Optimization. Take action on the high-priority rows: change the design, add a control, or write a justification for why the current state is acceptable. Re-score after the change.
- Results documentation. Record what was decided, what changed, and what is left, and feed it forward to the PFMEA and the verification plan.
How do you score risk and set Action Priority?
You score three things and let a table tell you how urgently to act. Severity rates how bad the effect is on the end user, occurrence rates how likely the cause is, and detection rates how well the current design controls would catch the failure before release. Each is a 1 to 10 rating pulled from the standard scales.
The 2019 handbook replaced the old Risk Priority Number (severity times occurrence times detection) with Action Priority, or AP, which returns a plain High, Medium, or Low. AP fixed a real problem with RPN: a middling RPN could hide a catastrophic failure mode because two low scores dragged the product down. Under AP, any failure mode with a severity of 9 or 10 lands in the High band no matter how rare or how detectable it is, because a safety or regulatory effect deserves attention on its own. High means action is required or you justify why the current state is acceptable. Medium means action should be taken. Low means action could be taken. Priority is about the urgency of action, not a ranking of risk you can average.
The DFMEA rules cited here come from the primary quality bodies:
- Seven-step method and the High/Medium/Low Action Priority are defined in the AIAG & VDA FMEA Handbook, the harmonized automotive reference published in 2019 (AIAG & VDA FMEA Handbook).
- Severity, occurrence, and detection each rate 1 to 10 and FMEA began with the U.S. military in the 1940s before spreading to aerospace and automotive (ASQ, Failure Mode and Effects Analysis).
- Action Priority weights severity first so a severity 9 or 10 failure mode is High regardless of how low its occurrence or detection scores are.
A worked example: a connector latch
Take a plastic connector housing whose latch has to retain a mating connector against vibration for the life of the vehicle. Structure analysis flags the latch-to-mating-connector interface. Function analysis writes the function: retain the mating connector against 15 G vibration with no disconnect. Failure analysis writes the chain from the diagram: failure mode, latch releases under vibration; effect, intermittent signal loss to a control module; cause, latch beam wall thinner than needed for the load.
Now score it. The effect is intermittent loss of a sensor signal, which the vehicle warns on but does not lose control from, so severity is 8. History on the baseline part says a thin-wall latch has released before, so occurrence is 5. The current design control is a vibration test on a design verification build that reliably shows the release, so detection is 4. On the AP tables an S8 with moderate occurrence and moderate detection lands Medium to High, which means the team acts. The fix is a design change: thicken the latch beam and add a support rib, then re-score. Occurrence drops to 2 after analysis confirms the new section survives the load, and the row moves to Low.
How does the DFMEA feed the PFMEA and the verification plan?
This is the step teams skip, and it is where a DFMEA earns its keep. Two threads run out of every finished row. The first thread is manufacturing: any design cause that the factory can influence becomes a line in the PFMEA. If the latch can also come out short because the mold packs low, that is a process failure mode the PFMEA now owns, traceable back to the DFMEA function it threatens.
The second thread is proof. Every high-priority failure mode needs a test that shows the design survives, and those tests become the design verification plan and report, often written as a DVP&R. The vibration test in the example is not a detail; it is the evidence that the thickened latch actually holds. A verification plan built from the DFMEA tests the failures that matter instead of a generic checklist. The table below shows the same failure chain flowing into all three documents.
| Failure chain element | Lives in the DFMEA as | Hands off to |
|---|---|---|
| Function: retain connector vs. vibration | Function statement | Verification plan test requirement |
| Failure mode: latch releases | Failure mode + effect + severity | Verification plan pass/fail criterion |
| Cause: thin latch wall (design) | Cause + occurrence | Design change; re-score |
| Cause: mold packs low (process) | Noted, out of design scope | PFMEA failure mode |
| Control: vibration test | Detection control | DVP&R test method |
What makes a DFMEA fail in practice?
Most weak DFMEAs share the same faults. They start too late, after the design is frozen, when the only honest output is a list of things nobody will change. They score in a conference room from memory instead of from the baseline part's real field history, so occurrence numbers are guesses. They stop at the spreadsheet and never open the PFMEA or the verification plan, so the analysis dies as a document. And they treat detection as a way to lower the priority number rather than as a prompt to prove the design, which is exactly backwards: a good design control is one that would actually catch the failure, not one that reads well.
The fix for all four is discipline about handoffs and honesty about history, which depends on having the history in reach. That is where the shop floor comes in. When a plant logs its defect tracking and field returns in a live system instead of scattered spreadsheets, the next DFMEA team can pull real occurrence evidence in minutes instead of arguing from memory. That is the kind of institutional record Harmony keeps for manufacturers without a rip-and-replace of the tools they already run (see how CLS did it). And when a failure escapes anyway, the same record feeds a proper escape analysis that tells the next design what to watch.
Run the DFMEA early, score it from evidence, act on the High and Medium rows, and push every row to its downstream home. Do that and the analysis stops being paperwork and starts being the reason a part does not come back. See how connected quality data supports it on our features overview.