Design FMEA vs Process FMEA
Key Takeaways
- Design FMEA (DFMEA) analyzes potential failures of the product or service design functions before production or full deployment.
- Process FMEA (PFMEA) analyzes how manufacturing or service process steps can fail to produce the intended design intent.
- DFMEA focuses on design causes (geometry, materials, software logic); PFMEA focuses on process causes (methods, machines, people, measurement, environment).
- Green Belts use PFMEA more often on DMAIC projects; they contribute to DFMEA when supporting new product or DFSS work.
- Both FMEA types feed control plans, error-proofing, inspection, and monitoring so high residual risks stay controlled after launch.
Design FMEA vs Process FMEA (CSSGB BoK I.C.3 — Apply)
Quick Answer: Design FMEA (DFMEA) finds how a product or service design can fail to meet functional requirements. Process FMEA (PFMEA) finds how process steps can fail to deliver that design intent consistently. Green Belts apply the right FMEA type to the problem, prioritize with RPN, and link actions to error-proofing and control plans.
At the CSSGB Apply level, I.C.3 expects more than definitions. You should choose DFMEA vs PFMEA for a scenario, explain the different failure-mode focus, and connect outputs to process controls.
Design FMEA (DFMEA)
DFMEA (also called Design Failure Mode and Effects Analysis) evaluates the design of a product, component, system, or—in service contexts—the designed offering and its functional architecture. The question is: If we build this design as specified, how might the design itself fail the customer?
Typical DFMEA focus areas:
- Functional requirements and design features
- Interfaces between components or systems
- Material selection, tolerances, and software logic
- Safety, reliability, usability, and maintainability
- Design assumptions that break under noise (temperature, load, user error)
Example (product): A new insulin pen design might have a failure mode “dose delivery inaccurate.” Causes could include spring constant out of design range, scale marking ambiguity, or software rounding logic—not “operator skipped a work instruction.” Those design-rooted causes belong in DFMEA.
Example (service design): A redesigned online claims portal might fail when “customer cannot submit claim.” Design causes could include missing required-field logic, inaccessible mobile layout, or authentication timeout rules that conflict with customer behavior.
DFMEA is most valuable early—concept and detailed design—while change is still cheap. It supports DFSS phases such as Design/Optimize/Verify and reduces the chance that production will inherit unfixable requirements.
Process FMEA (PFMEA)
PFMEA evaluates the process used to manufacture a product or deliver a service. The question is: How can process steps fail to produce the design intent or meet CTQs?
Typical PFMEA focus areas:
- Process steps and work elements (often from a process map or PFMEA boundary diagram)
- Man, machine, method, material, measurement, and environment causes
- Setup, changeover, handling, and transaction steps
- In-process checks and final inspection capability
- Escape paths to the customer or next process
Example: For the same insulin pen, a PFMEA failure mode might be “incorrect spring installed at Station 3.” Causes could include similar-looking springs, no poka-yoke fixture, or training gaps. Effects still reach the customer as dose error, but the mechanism is process, not the spring’s design equation.
Example (transactional): In claims processing, “claim routed to wrong queue” may have process causes such as unclear decision tree, incomplete intake checklist, or system dropdown defaults—classic PFMEA territory once the workflow exists.
Side-by-Side Comparison
| Dimension | DFMEA | PFMEA |
|---|---|---|
| Object of analysis | Product/service design functions | Manufacturing or service process steps |
| Failure mode examples | Feature does not meet function; interface mismatch | Wrong part used; step skipped; data entered incorrectly |
| Typical causes | Design parameters, materials, architecture, software | Methods, equipment, people, measurement, environment |
| When performed | Concept through detailed design (and design changes) | Process development, pilot, and process changes |
| Primary owners | Design/R&D, systems engineers, DFSS teams | Process engineers, operations, quality, Green/Black Belts |
| Key outputs | Design changes, tolerance strategy, design controls | Process controls, error-proofing, inspection, control plan |
A useful exam test: if fixing the issue requires changing the design, think DFMEA. If fixing it requires changing how work is done while the design stays the same, think PFMEA. Complex projects use both—DFMEA first to harden the design, PFMEA to harden production or service delivery.
When Green Belts Use Each
PFMEA is the Green Belt’s everyday FMEA. On DMAIC projects you map the process, identify failure modes at critical steps, score S/O/D, and drive Improve actions that become Control-plan elements: standard work, checklists, sensors, sampling, SPC, and reaction plans.
DFMEA appears when Green Belts support design or DFSS work. You may facilitate sessions, bring VOC/CTQ data, contribute field-failure history, or help score occurrence and detection using warranty and complaint data. Full ownership of product DFMEA often sits with design engineering and Black Belts, but Green Belts must still recognize DFMEA scenarios on the exam and in cross-functional teams.
Apply-level cues in questions:
- New product geometry, bill of materials, or software requirements → DFMEA
- Assembly sequence, call-center script, batch record steps, machine setup → PFMEA
- High RPN on “customer misuse due to unclear interface” during design → design action via DFMEA
- High RPN on “operator installs backward” at a station → process action via PFMEA
Linkage to Controls
FMEA is incomplete without actions and residual controls. Both DFMEA and PFMEA should close the loop:
- Recommended actions reduce severity (redesign effect), occurrence (prevent cause), or detection (find failures earlier).
- Prevention controls (preferred) remove or block causes—poka-yoke, design margins, qualified suppliers, forced sequencing.
- Detection controls catch remaining failures—tests, inspection, automated checks—with clear reaction plans.
- Control plan / quality plan documents what is monitored, how often, by whom, and what to do out of control.
- Lessons learned feed future designs and process FMEAs so the organization does not rediscover the same failure modes.
DFMEA design controls (for example, mandatory design reviews, reliability tests, interface checklists) and PFMEA process controls (for example, torque verification, barcode match, SPC on a critical dimension) work together. If DFMEA leaves residual risk that process controls must catch, PFMEA and the control plan must make that detection reliable—and RPN should reflect the true residual risk after both layers.
Application Checklist for Green Belts
- Choose DFMEA for design functions and PFMEA for process steps; use both on new product introductions.
- Write failure modes as how the function/step fails, not as vague “quality issue.”
- Score S/O/D with the same scale definitions as the rest of the organization.
- Prioritize with RPN and elevate high severity risks even when rare.
- Convert actions into owned tasks and update control plans so residual risk is managed daily—not only in a spreadsheet archive.
Master this distinction and you can apply FMEA correctly whether the project is a DFSS design effort or a DMAIC process improvement.
A team is developing a new medical device. They analyze whether the chosen seal geometry can fail under sterilization heat, independent of the factory assembly steps. Which tool fits best?
On a Green Belt DMAIC project, operators sometimes skip a torque sequence, causing leaks. The design of the fastener is unchanged. Which action set is most appropriate?