Use APQP gates to expose launch risk early

Use APQP gates to expose launch risk early

APQP links product and process development to evidence-based launch decisions. Translate customer needs into a plan with connected responsibilities, timing and deliverables. Use gates to expose unresolved risks, dependencies and changes rather than to celebrate document completion. Evidence from design, process development, suppliers and validation must fit the actual scope. Carry decisions and lessons forward so an approved change does not leave downstream records obsolete. The current public AIAG materials distinguish APQP third edition from the standalone Control Plan first edition. Customer adoption and requirements still need checking. This teaching map demonstrates decision discipline, not a complete mandated gate list or automatic launch authorization.

Follow the method

1. Needs + scope
2. Connected plan
3. Evidence gate
4. Resolve risk
5. Carry learning

Make the three open launch risks visible at the gate

Fictional case: a new component launch has three open actions: measurement validation, supplier validation and a station reaction drill. Planner Tessa has a green schedule because most tasks are complete. The core lesson retains these three gaps. The team must decide what evidence is missing and who can authorize the next step.

Follow the method

1. Measurement
2. Supplier
3. Reaction
4. Overall

Ninety-seven percent complete can still be unready

Use a launch evidence gate to expose dependencies and unresolved risk, with accountable decisions instead of a task-completion percentage.

Fictional case: a new component launch has three open actions: measurement validation, supplier validation and a station reaction drill. Planner Tessa has a green schedule because most tasks are complete. The core lesson retains these three gaps. The team must decide what evidence is missing and who can authorize the next step.

Role: Cross-functional launch leader with engineering, supplier quality and operations

Normal condition

Customer needs, design/process development, validation and operational controls are connected through clear deliverables and evidence-based decisions.

The gap

The team treats a high completion percentage as approval to launch, despite unresolved evidence needed to interpret product results and respond to abnormalities.

• AIAG published APQP 3 and standalone Control Plan 1 in 2024; applicability and adoption remain customer-specific.
• The three example actions are not a complete prescribed gate checklist.

1. Restate the launch decision

   Tessa names the product/revision, intended production conditions and the specific decision the gate must support. She confirms customer requirements and the applicable planning method.

   Why: A gate without scope can be passed using evidence from a different revision or trial condition. A date is not an acceptance criterion.

   Evidence: The gate agenda states the decision, scope and approval roles.

2. Map the evidence dependencies

   She links measurement validation to interpretation of process trials, supplier validation to representative inputs, and reaction-drill results to the control plan and work instructions.

   Why: Open tasks differ in consequence. Dependencies reveal why an apparently small incomplete action can undermine several downstream conclusions.

   Evidence: The evidence map identifies which claims depend on each unresolved action.

3. Inspect the actual deliverables

   Each owner brings traceable records, their limitations and outstanding findings. Tessa distinguishes a scheduled study from a completed reviewed result and a document upload from accepted evidence.

   Why: Administrative completion can hide a missing technical result. The gate must examine what the evidence establishes, not whether a file exists.

   Evidence: Three action rows contain evidence status and remaining questions.

4. Assign accountable decisions

   The authorized team determines whether the applicable criteria are met, what restrictions or additional work are required, and who owns closure. Tessa does not invent a customer deviation or presume silence means approval.

   Why: A conditional decision must have actual authority and explicit conditions. It cannot be manufactured from an optimistic progress score.

   Evidence: The record names decision owner, scope, conditions and next review.

5. Carry changes into operating controls

   Validated changes flow into PFMEA, control plan, instructions, supplier controls and handover as applicable. The team verifies that the receiving operation can use them.

   Why: A launch gate is connected to continuing control, not a ceremony that ends at shipment. Lessons and unresolved risks must reach the people doing the work.

   Evidence: The handover identifies controlled revisions and receiving owners.

The design changes after validation

A late revision changes a controlled characteristic after the trial evidence was accepted.

Assess which evidence and controls the revision affects, reopen those dependencies and obtain the required review before using the old acceptance for the new scope.

Prior evidence may remain useful, but applicability must be justified. Relabelling an old report with the new revision would break provenance.

A change-impact record identifies reused evidence, necessary revalidation and authority.

Run a practice session

Materials

• Three action cards
• Dependency map
• Blank gate record

1. Name the decision · 5 minutes

   What exactly would this gate authorize?

2. Map dependencies · 8 minutes

   Which claims rely on the measurement action?

3. Work the changed launch · 10 minutes

   Why can one gap matter more than two closures?

4. Debrief handover · 5 minutes

   Who receives the controlled changes?

Debrief

• Ask for actual evidence rather than a status color.
• Do not let the exercise imply a universal customer gate or waiver.

Write a one-paragraph gate recommendation with scope, evidence, remaining risk and decision owner.

Transfer into the work

Owner: Launch leader and receiving process owners

Record: Gate evidence, decision conditions and controlled handover

Review: At defined gates and material changes

Evidence: Applicable evidence and verified operational readiness

Reopen affected dependencies and escalate unresolved authority rather than using completion percentage as release permission.