These are the questions Compass asks for this practice, and the levels it scores you against.
Capturing what each design element must do — the starting point for identifying how it can fail.
How well documented is the intended function of each design component or sub-assembly?
Level 1 → 5World class at level 4
- Functions are implicit — engineers know what things are for but nothing is written down
- High-level product requirements exist but functions per component are not documented
- A bill of functions exists for major assemblies but is incomplete at the part level
- Every design element in scope has a documented function statement before DFMEA beginsWorld class
- Function documentation is generated automatically from the product boundary diagram; it is version-controlled alongside the design
Identifying for each function the ways the design could fail to perform — the core of DFMEA.
How systematically do you identify potential failure modes for each design function?
Level 1 → 5World class at level 4
- We rely on engineering intuition — no structured failure mode identification
- We review lessons-learned from past products informally
- We use a structured brainstorm per function guided by failure mode categories (fracture, deformation, wear, corrosion, leakage, etc.)
- We use function-failure analysis with a cross-functional team; results are linked to design requirementsWorld class
- Failure mode identification is driven by a combination of function analysis, historic DFMEA data, and customer-environment simulation results
Scoring severity, occurrence, and detection to prioritise which failure modes need corrective action.
How rigorously do you score and prioritise design failure modes?
Level 1 → 5World class at level 4
- No scoring — we address failures based on gut feel about what matters
- We rate severity informally; occurrence and detection are not scored
- We complete S, O, D scoring but scores are not calibrated against a standard scale
- We use AIAG-VDA DFMEA scoring tables; design controls are documented for each failure mode before scoringWorld class
- Scoring is cross-functionally reviewed and benchmarked against historical DFMEA databases; risk priority thresholds trigger mandatory design actions
Converting high-risk DFMEA findings into design changes with owners and due dates — closing the loop before tooling commits.
How do DFMEA findings translate into actual design changes?
Level 1 → 5World class at level 4
- DFMEA findings are noted but rarely drive design changes before launch
- Critical findings are flagged to the design lead but tracked informally
- Recommended actions are logged with owners and tracked to closure in a project register
- All RPN-threshold actions are tracked to verified closure; re-scoring confirms risk reduction before tooling sign-offWorld class
- DFMEA action status is a mandatory gate criterion; no design release proceeds until all threshold RPNs have verified corrective actions and updated scores
