IATF16949 Practical Application (1) | APQP Five-Stage Deliverables Checklist and Stage Gate Release Criteria

A certain automotive parts company received a nonconformity from a customer's second-party audit last month. The auditor pointed to a customer-designated key characteristic (CC) and asked, "Which row is it in your control plan?" The project team spent twenty minutes flipping through the drawing notes, PFMEA, and trial production control plan before confirming that the characteristic was not in the control plan. However, in the APQP stage review record, the "control plan" column under Gate 3 clearly stated "completed."

The same issue was almost undetectable during the review meeting. The meeting lasted forty minutes, with the first thirty minutes spent checking whether the forms in the folder were complete, and the sign-off columns were all checked. No one asked: Have the key assumptions of this stage been verified by data?

The root cause is not "not doing APQP," but treating the deliverables checklist as a homework checklist: only checking whether "the document exists," not whether "the output of the document can be directly referenced by the next stage." The true purpose of the stage gate (Gate) is to determine whether "the risks of the previous stage have been closed with evidence, allowing entry into the next stage." This article lists the deliverables for each of the five stages in a reusable main table and provides a practical guide for the stage gate review inputs, agenda, record templates, and release criteria—fill in the table, judge by the table, and leave evidence.

1. Main Table of Five-Stage Deliverables: Field Definitions and Filling Discipline

The easiest place for the deliverables list to fail is not in the amount of content, but in the ambiguity of the fields. It is recommended to uniformly write the five columns as follows, and any article's deliverables can fit into these five columns.

Three filling disciplines must be implemented in document reviews:

1. Deliverables must have a document name and version number. If they cannot be written, it means they are still a "task" rather than an "output," and downstream processes cannot reference them.
2. Each deliverable must have a downstream reference. For example, the reference for PFMEA is the control plan preparer; deliverables without a reference (such as some meeting records) should either be trimmed or the reference scenario should be clearly defined (such as customer audit evidence collection).
3. Criteria must be reproducible by a third party. "Control plan completed" is not a valid criterion; "Control plan covers all 12 special characteristics, each with sample size, frequency, and response plan, version number CP-002, and PFMEA version 3" is a valid criterion.

2. Stage One and Stage Two: Planning, Definition, and Design Development

Stage One: Planning and Definition (Gate 1) — Whether Goals and Resources Can Be Accepted

Stage Two: Product Design and Development (Gate 2) — Whether Design Risks Have Been Identified and Closed

3. Stage Three and Stage Four: Process Design, Confirmation, and Approval

Stage Three: Process Design and Development (Gate 3) — Whether Process Risks Are Controlled and Special Characteristics Are Implemented

Stage Four: Product and Process Confirmation (Gate 4) — Whether Quality and Capacity Meet Standards in Batch Production

4. Stage Five: Feedback, Evaluation, and Corrective Actions (No Gate, but Must Have an Exit)

The fifth stage concludes with initial production data, assessing whether "problems can flow back and experiences can be accumulated."

5. Stage Gate Review: Inputs, Agenda, and Record Templates

Pre-Meeting Inputs (Must be in place 3 working days before T): Completion status table of deliverables (including document names and version numbers), closure status table of previous gate conditions, key assumptions and verification evidence of this stage (test data, GR&R, initial process capability), change list of this stage, progress and resource deviation explanations. Projects with incomplete materials will have their gate reviews rescheduled; no "finding files while in the meeting."

Standard 45-Minute Agenda

Stage Gate Review Record Form (Field Template): Gate number and stage name | Review date | Participants (position + signature, including project, quality, technology, production, procurement) | Completion rate of deliverables (completed items/required items, with incomplete item numbers) | Achievement status of key criteria (list numerical values and conclusions for each item) | Unresolved issues (number, level, measures, responsible person, closure deadline) | Release determination (release/conditional release/no release) | Conditional release registration (condition content, closure deadline, verification evidence requirements, responsible person) | Approval signature. One page is enough, but each item must be traceable.

6. Simplified Implementation for Small and Medium Enterprises: What Can Be Trimmed and What Cannot

The list has over thirty items, and small and medium enterprises often give up directly because of this. The correct approach is to trim by risk but hold the line.

Five Non-Trimmable Bottom Lines: Customer-designated requirements and CSR mandatory items; identification and transmission chain of special characteristics (DFMEA → control plan → work instructions → on-site markings); control plan (including special characteristics and response plans) and accompanying work instructions; MSA for special characteristics and initial process capability study for key characteristics; PPAP key elements and stage gate review records.

7. Key Points for Implementation and Common Errors

1. Deliverables written as "work completed". Change to "document name + version number + downstream reference," making the review verifiable.
2. Last-minute document supplementation before the gate. All deliverables are set to "before the gate," but in reality, they are concentrated at the gate. The solution is to back-schedule by relative time and break down deliverables into weekly plans.
3. Gate review only counts documents, not criteria. Clearly specify "only check criteria" in the agenda; the chair should hold the criteria list, not the document list.
4. Conditional release becomes routine. If it happens twice in a row, it indicates issues with resource allocation or early planning, which should be escalated to management review, not continued with "conditional pass."
5. Version linkage breaks. Control plan revisions and work instructions not being synchronized are the most common breakpoints in audits. It is recommended to create a version matrix: the version correspondence between drawings, DFMEA/PFMEA, control plan, work instructions, and inspection instructions. Any change should update the matrix before the document.
6. Gate closure without item closure. Unresolved issues are only marked as "to be followed up later," without a single downstream responsible person. Each unresolved item must be assigned a tracking responsibility position for the next gate.
7. Stage gates misaligned with customer milestones. Use the mapping table in Section 7 to align gate reviews with customer milestones and mark the planned review dates for each gate in the main project plan.
8. Special characteristics only on drawings, not on-site. No matter how well the identification list is done, if there are no symbols in the on-site work instructions and no frequencies in the control plan, it is as if they were not identified.

The value of the deliverables list is not in "completeness," but in "each item being verifiable, referenceable, and traceable." Achieving these three points will transform the stage gate from a document sign-off meeting into a risk control mechanism.

Deliverables must be directly referenceable by the next stage

Knowledge code: 2.1.2

Version: v20261009

Author: QTank QTank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping enterprises continuously improve their quality capabilities.