2. Program initiation and chartering

An airbag development program does not begin when the first CAD model is created; it begins the moment a customer Request for Quotation (RFQ) lands on the program manager's desk. The initiation phase determines whether the program will be profitable, technically feasible, and schedule-realistic. This chapter walks through the four pillars of program initiation: RFQ analysis, Statement of Work (SOW) definition, deliverable structuring, and cross-functional team setup.

1. Customer RFQ Analysis

The RFQ is the customer's formal request for a quotation package. For an airbag system, it typically includes vehicle platform data, target production volumes, timing milestones, regulatory requirements (FMVSS 208, ECE R94/R95, GB 11551), and a preliminary interface specification. The program manager must decompose the RFQ into quantifiable engineering and commercial requirements before any quotation is submitted.

A structured RFQ analysis should extract and validate the following categories:

  • Scope items: Which airbag modules are in scope — driver, passenger, side, curtain, knee, far-side? Is the inflator supplied by the customer or by the Tier 1?
  • Performance targets: Occupant injury criteria (HIC, chest deflection, femur load), deployment timing windows, and out-of-position (OOP) requirements.
  • Interface constraints: Steering wheel geometry, instrument panel chute dimensions, seat frame mounting points, and electrical connector pinouts.
  • Commercial envelope: Annual volume, piece price target, tooling amortization, and payment milestones.
  • Timing: SOP date, prototype build dates, PPAP submission, and validation gate reviews.

A common pitfall is treating the RFQ as a fixed document. In practice, RFQs contain ambiguities — for example, a customer may specify "side airbag for front seats" without clarifying whether it is a thorax-only or thorax-pelvis combination. The program manager should log every ambiguity in a clarification register and issue formal questions to the customer before quotation. This register becomes the basis for assumptions in the quote and prevents scope creep later.

Practical tip: Assign a numerical risk score (1–5) to each RFQ requirement based on technical maturity, supplier readiness, and regulatory uncertainty. Requirements scoring 4 or 5 should trigger a formal risk mitigation plan before quotation sign-off.

2. Statement of Work (SOW) Development

The SOW translates the RFQ into a contractual document that defines what the program will deliver, when, and under what conditions. For an airbag system, the SOW must be specific enough to prevent disputes but flexible enough to accommodate engineering changes.

A well-structured airbag SOW includes:

Section Content Example Entry
Deliverable items Hardware, software, documentation Driver airbag module, PAB module, ECU calibration dataset
Performance requirements Test standards, pass/fail criteria FMVSS 208 frontal rigid barrier, 56 km/h, HIC ≤ 700
Timing milestones Design freeze, tooling kick-off, PPAP Design freeze: 2026-03-15; PPAP: 2027-01-10
Customer responsibilities Data delivery, sample provision, approvals Vehicle CAD data delivery within 10 business days of kick-off
Change management ECR/ECO process, cost impact Any change after design freeze requires customer ECR approval

The SOW should also define the boundary of supply. For example, if the customer provides the inflator, the SOW must state who is responsible for inflator integration testing, who owns the inflator performance data, and how inflator variability is handled in the airbag module validation.

3. Deliverable Structuring and Work Breakdown

Once the SOW is agreed, the program manager decomposes it into a Work Breakdown Structure (WBS). For an airbag program, a typical Level 2 WBS includes:

  1. Program management (schedule, budget, risk, change control)
  2. System engineering (requirements, architecture, DFMEA, interface control)
  3. Module design (bag, inflator, housing, cover, retainer)
  4. Validation and testing (component, sled, vehicle, OOP)
  5. Manufacturing engineering (tooling, process, PPAP)
  6. Quality and reliability (APQP, control plan, MSA)

Each WBS element must have a single accountable owner, a defined deliverable, and a completion criterion. For example, "Module design" is not a deliverable; "Driver airbag module 3D CAD released to customer with DFM sign-off" is.

The deliverable list should be tracked in a deliverable register with columns for deliverable name, owner, due date, status, and acceptance criteria. This register is reviewed at every program gate review.

4. Cross-Functional Team Setup

An airbag program requires a core team with representatives from engineering, manufacturing, quality, purchasing, and program management. The program manager's role is to establish clear roles, responsibilities, and communication channels.

A RACI matrix is the standard tool for this. For a typical airbag program:

Activity Program Manager Design Engineer Manufacturing Engineer Quality Engineer Purchasing
RFQ analysis A C I I C
SOW creation A C C C C
Design freeze A R C C I
Tooling kick-off A C R I C
PPAP submission A C R R I

R = Responsible, A = Accountable, C = Consulted, I = Informed.

The team should also establish a cadence: weekly core team meetings, monthly program reviews with the customer, and gate reviews at defined milestones (e.g., design freeze, tooling release, PPAP). Each meeting should have a fixed agenda: schedule status, open issues, risk updates, and action items.

Warning: A common failure mode is assigning a part-time quality engineer who also supports three other programs. For airbag programs, the quality engineer must be dedicated at least 50% during the design and validation phases, because PPAP and APQP documentation cannot be retrofitted at the end.

5. Integrated View: From RFQ to Team Charter

The following diagram shows how the four initiation pillars connect. The RFQ feeds the SOW, the SOW drives the deliverable structure, and the deliverable structure determines the cross-functional team composition and RACI. Each pillar has a feedback loop: ambiguities in the RFQ become clarifications in the SOW; deliverable gaps trigger WBS updates; team capacity issues force re-negotiation of scope or timing.

Program Initiation Flow: RFQ → SOW → Deliverables → Team Customer RFQ Scope · Performance Interfaces · Timing Commercial terms Statement of Work Deliverables · Standards Milestones · Boundaries Change management Deliverable Structure WBS · Registers Acceptance criteria Gate reviews Cross- Functional Team RACI · Cadence Clarification register Scope / timing re-negotiation Capacity / skill gap feedback Key Initiation Outputs Clarification Register RFQ ambiguities + answers Assumption log Signed SOW Boundary of supply Change management clause Deliverable Register Owner · Due date · Status Acceptance criteria Team Charter RACI matrix Meeting cadence

6. Practical Example: RFQ Ambiguity Resolution

Consider a customer RFQ that specifies a passenger airbag module for a mid-size SUV with a target SOP of Q3 2027. The RFQ states: "PAB must meet FMVSS 208 unbelted requirements at 25 mph." The program manager identifies two ambiguities:

  1. Does "unbelted" include the 5th percentile female occupant, or only the 50th percentile male?
  2. Is the 25 mph test speed for the rigid barrier or the offset deformable barrier?

These ambiguities are logged in the clarification register. The customer responds: "5th percentile female, rigid barrier." The SOW then specifies: "PAB module must meet FMVSS 208 unbelted requirements for both 50th percentile male and 5th percentile female occupants at 25 mph rigid barrier." This level of specificity prevents a costly redesign after the first sled test.

In parallel, the program manager checks whether the customer-provided inflator has sufficient output for the 5th percentile female unbelted case. If the inflator is marginal, the SOW should include a performance contingency: "If inflator output is insufficient, customer will provide an upgraded inflator at no additional cost to the program."

7. Summary

Program initiation is not a paperwork exercise; it is the foundation of program execution. A rigorous RFQ analysis surfaces ambiguities early. A precise SOW prevents scope disputes. A structured deliverable register makes progress measurable. A well-defined cross-functional team with clear RACI and cadence ensures that decisions are made by the right people at the right time. Together, these four pillars transform a customer RFQ into a chartered, executable airbag development program.

← Previous 📖 Contents Next →