4. Preparing for a DRBFM workshop
A DRBFM workshop is only as good as the preparation that precedes it. The Design Review Based on Failure Modes method is deliberately structured around a small, focused team examining a specific design change, and its effectiveness depends on three preparatory pillars: a precisely scoped change definition, a cross-functional team with the right technical authority, and a data package that lets participants reason from evidence rather than opinion. When any of these pillars is weak, the workshop drifts into generic FMEA-style brainstorming, and the sharp focus on the change—the very thing that makes DRBFM efficient—is lost.
Scoping the Change: From "New Airbag" to a Reviewable Boundary
Change scoping is the single most consequential preparation step. A change described as "new passenger airbag module" is unreviewable; a change described as "replacement of the passenger airbag inflator with a dual-stage variant, retaining the existing module housing, cover, and mounting brackets, affecting the PAB ECU calibration and the passenger restraint deployment strategy" gives the team a boundary they can reason about. The scoping output should answer four questions explicitly:
- What physically changes — part numbers, geometry, materials, interfaces, and the level at which the change is introduced (component, subsystem, or vehicle).
- What is explicitly unchanged — the retained baseline, because DRBFM's power comes from concentrating concern on the delta while treating the unchanged context as a known-good reference.
- What the change touches indirectly — calibration, diagnostics, harness routing, trim interfaces, occupant classification interaction, and manufacturing processes.
- What the change is intended to achieve — the requirement or field issue driving it, with quantified targets where they exist (for example, a target OOP out-of-position injury metric, a seatbelt retractor spool-in force target, or a warranty claim reduction goal).
A practical scoping technique is to build a change-boundary statement and a delta list before the workshop, then circulate both for pre-review. The delta list should be granular enough that each line can be assigned to a reviewer. For a seatbelt change, for example, "switch from pyrotechnic pretensioner to motorized retractor" decomposes into: retractor package and mounting, buckle anchor geometry, B-pillar routing and D-ring position, ECU interface and LIN/CAN messaging, crash signal timing, power supply and quiescent current, service and diagnostic procedures, and end-of-line test coverage. Each line becomes a candidate review object in the workshop.
Assembling the Cross-Functional Team
DRBFM works because it forces the people who own different parts of the design to confront the change together. The team should be small enough to stay focused—typically six to ten participants—but must include the functions that can answer the questions the change raises. For airbag and seatbelt changes, the core composition usually includes:
| Role | Contribution to the Review | Typical Preparation Input |
|---|---|---|
| Design engineer (airbag or seatbelt) | Owns the change; presents geometry, interfaces, and design intent | CAD, drawings, interface control documents, design requirements |
| Restraint systems / crash engineer | Deployment strategy, timing, occupant kinematics, OOP considerations | Crash simulation results, sled test data, calibration assumptions |
| Validation / test engineer | Test coverage, pass/fail criteria, correlation between test and analysis | DV/PV plans, test reports, fixture and instrumentation details |
| Manufacturing / process engineer | Assembly sequence, poka-yoke, EOL test, process capability | Process FMEA, control plan, EOL specifications |
| Supplier quality / SQE | Supplier-side change control and incoming inspection | Supplier PPAP status, change notifications, capability data |
| Field quality / service | Field failure history, warranty data, serviceability | Claim data, field return analyses, service bulletins |
| DRBFM facilitator | Guides the method, enforces the change focus, records results | Scoping package, agenda, prior DRBFM records |
Two practical rules improve team performance. First, participants must have decision authority or direct access to the data—sending a delegate who "will check with the responsible engineer" converts the workshop into a correspondence exercise. Second, the facilitator should be method-focused rather than content-focused; a facilitator who argues design details loses control of the process. Where the change crosses organizational boundaries (for example, an OEM integrating a Tier-1 inflator), include the supplier's responsible engineer in the session or secure a written technical position in advance.
Gathering Design, Validation, and Field Data
The data package converts the workshop from opinion exchange into evidence-based review. It should be assembled and distributed at least three to five working days before the session, with a clear index so participants can locate items during discussion. A workable package for an airbag or seatbelt change contains:
- Design data: current and proposed drawings and CAD, interface control documents, the requirement specification with the changed requirements highlighted, and the design verification plan showing which requirements the change affects.
- Validation data: relevant DV/PV test reports for the baseline and, where available, for the changed design; crash and sled test results with instrumentation channels identified; CAE correlation status; and any open test failures with their current disposition.
- Field data: warranty claims and field returns for the baseline part, filtered to the failure modes the change could plausibly affect; customer complaints; service bulletins; and any regulatory or recall history relevant to the change.
- Process data: the current process flow, control plan, EOL test specification, and process capability for the characteristics the change touches.
Data quality matters more than volume. A field data set that mixes all claim types dilutes the signal; the team should pre-filter claims by failure mode and by build period so that the baseline failure profile is visible. Similarly, validation reports should be accompanied by a short correlation note stating whether the test article represented the production-intent design, because a DRBFM conclusion built on a non-representative test article is a latent risk in itself.
Pre-Workshop Review and Agenda Construction
The final preparation step is a short pre-review in which the facilitator and design engineer walk through the scoping package, confirm that each delta line has an owner and supporting data, and draft the agenda. The agenda should allocate time by delta line rather than by function, with the highest-risk deltas first—typically those affecting deployment timing, occupant classification interaction, or safety-critical interfaces. A useful convention is to send participants a one-page "change brief" containing the boundary statement, the delta list, and the three or four questions the workshop must answer. This focuses preparation and shortens the session.
The diagram above summarizes how the three preparation pillars converge. Note that the agenda is ordered by delta line and risk, not by organizational function—this is what keeps the session anchored to the change and prevents the discussion from expanding into a full-system review. When preparation is done well, the workshop itself becomes a focused examination of a bounded set of design deltas, with each participant arriving able to answer the questions their function owns.