Advanced Product Quality Planning was designed to make product launches predictable. The structured, phased approach moves quality engineering upstream — before steel is cut, before tooling is committed — to identify risks early and build controls before they are needed. The goal is a launch where the first production run succeeds because failure modes are already identified, measurement systems are validated, and process capability is confirmed.
In most organisations, that is not what happens. APQP has degraded into a project management framework that produces Gantt charts, milestone trackers, and cross-functional meeting schedules. The phases exist on paper. The gate reviews happen on calendar. The deliverables get checked off. Then the launch fails in exactly the ways APQP was supposed to prevent, because nobody did the substantive engineering work underneath the checkboxes.
The plan becomes the poster. The poster goes on the wall. And the launch goes wrong. Having transitioned ISO 9001 systems and built QA departments across automotive and aerospace plants, I have seen this failure mode repeatedly: organisations that confuse documentation density with engineering rigour. The five phases of APQP are not a paperwork sequence. They are an engineering sequence, and treating them otherwise guarantees the problems recur.
The Requirements Translation Nobody Does
Phase 1 demands understanding what the customer actually needs, which is not always what the drawing specifies. Drawings carry tolerances tighter than function requires. They omit critical characteristics for assembly or end-use. They reference superseded standards. A proper Phase 1 decomposes customer requirements into specific technical and manufacturing objectives, identifies critical-to-quality characteristics (CTQs), and establishes measurable success criteria.
What actually happens is far simpler. Someone copies the customer drawing into the internal system, assigns a part number, and schedules a kick-off meeting. The requirements section of the APQP checklist gets marked complete because the drawing exists in the folder. Nobody has analysed whether the tolerances are achievable, whether the specifications are clear, or whether implicit requirements exist that the drawing fails to capture.
The consequence is severe. The program launches with a set of requirements that nobody has critically examined. The first time anyone asks whether a tolerance is achievable with the current process is during the trial run — months after tooling is committed and the design is frozen. At that point, the question is no longer academic. It is a crisis with a fixed launch date and a customer expecting parts.
Fixing Phase 1 requires a mandatory feasibility review before any tooling is ordered or designs are locked. This review must include the process engineers who will actually build the part, not just the design team. The output is not a signed form. It is a documented list of manufacturing constraints, achievable tolerance ranges based on actual equipment capability, and any characteristics requiring special controls downstream.
Design Reviews That Review Nothing
Phase 2 assesses the design for manufacturability and identifies engineering risks. Design FMEAs are performed. Design reviews challenge assumptions. Verification testing confirms the design works. This is where the engineering substance of the programme is established — or should be.
In practice, the Design FMEA becomes a post-hoc document written after the design is locked. The cross-functional review that was supposed to challenge the design becomes a status update where everyone nods, because the tooling is already on order and the design cannot change. Design verification becomes a exercise of testing a small sample and declaring success, rather than a statistically meaningful evaluation of whether the design meets requirements across the expected variation envelope.
The deliverable gets checked. The risk the deliverable was designed to identify goes undetected. The risk then shows up during production — predictably, inevitably — when the cost of correction is an order of magnitude higher than it would have been during design. The solution is to enforce design freeze gates. No FMEA, no design release. No completed verification plan, no tooling commitment.
Compliance vs Competence in APQP Deliverables
Compliance (what teams do)
- FMEA written after design is locked, filed and forgotten
- Control Plan copies drawing tolerances into a spreadsheet
- Trial run passes with small sample sizes excluding outliers
- Lessons learned document is generic or never written
Competence (what works)
- FMEA drives specific controls: poka-yoke, sensors, training
- Control Plan traces directly to each FMEA failure mode
- Trial run runs at rate with real material and real operators
- Structured post-launch review feeds the next programme
Process Design That Isn't Designed
Phase 3 is where the deepest APQP failures live. This phase is supposed to produce a fully designed manufacturing process: process flow diagrams showing every step, Process FMEAs identifying what could go wrong at each step, Control Plans specifying how each risk will be controlled, and floor plans verifying physical layout supports the intended flow.
What most organisations produce instead is a Process FMEA listing failure modes in generic terms — operator error, machine malfunction — with risk priority numbers nobody acts on. The recommended action column reads monitor during production for every row. A Control Plan copies drawing tolerances into a spreadsheet, adds a column reading inspect at setup, and calls it process control. A Process Flow Diagram shows boxes and arrows but captures nothing about the actual flow of material, information, or decisions on the shop floor.
The Process FMEA should be the intellectual engine of APQP. It should drive specific, actionable controls. This failure mode has an RPN of 240. Here is the mistake-proofing device we are installing. Here is the sensor that will detect this condition. Here is the specific training operators will receive. Instead, it becomes a spreadsheet exercise disconnected from the actual process design, filed in a binder, and ignored.
Start rebuilding here. Gather the process engineers, quality engineers, operators, and maintenance technicians. Walk the process step by step. Ask what could go wrong, what does go wrong, and what happens when it does. Write down the answers. Then design specific controls for the highest-risk failure modes — not generic monitoring statements, but concrete poka-yoke devices, automated inspection, and procedural changes with named owners.
Validation That Validates Nothing
Phase 4 is the moment of truth. The production process runs at rate with real operators, real tooling, and real material. Measurement systems are validated through MSA. Initial process capability is calculated against the Cpk target. The Production Trial Run produces parts evaluated against customer requirements. This is where APQP earns its keep or where its failures become visible.
In organisations where the first three phases were hollow, Phase 4 becomes a scramble. The trial run produces nonconforming parts. The measurement system cannot reliably detect good from bad. The capability study reveals what everyone secretly knew: the process cannot consistently produce conforming parts. At this point the APQP timeline is already behind, the launch date is fixed, and the customer is expecting parts.
Too many organisations choose to ship, sort, and hope. The trial run passes because the sample size excluded outliers. The capability study passes because data was collected over a window too short for normal variation to reveal itself. The PPAP gets submitted. The launch happens. Then real production begins with all the problems APQP was supposed to prevent.
If your trial run passes on the first attempt every time, your trial run isn't rigorous enough to detect real issues.
The fix is straightforward. Give the APQP team the authority to stop when trial run data is bad. If they cannot delay a milestone when the evidence demands it, then the entire validation phase is performative. The trial run exists to find problems. When it finds them, the organisation must have the discipline to fix them before committing to production — not after.
The Resource and Sustainment Gap
APQP was designed for cross-functional teams of experienced engineers with the time and authority to do the work properly. The reality is that APQP gets assigned to a quality engineer who already manages existing production issues full-time. That engineer is expected to produce all five phases of deliverables alongside daily complaint investigations, line support, and supplier escalations.
This is not a recipe for rigorous engineering analysis. It is a recipe for document generation. When the person responsible for the Process FMEA is simultaneously fighting fires on the production floor, the FMEA will be written to satisfy the deliverable — not to identify and mitigate risk. Organisations that do APQP well staff launch teams with dedicated engineers whose only job is the launch.
The APQP Resource and Sustainment Model
- Phase 5: SustainmentStructured post-launch review feeds lessons learned into the next programme
- Phase 4: Validation authorityPower to delay milestones when trial run data demands it
- Phase 3: Engineering rigourProcess FMEA drives specific, actionable controls with named owners
- Phase 2: Design challengeGenuine cross-functional review before tooling commitment
- Phase 1: Dedicated resourcesFull-time launch team with the authority and time to do the work
Phase 5 barely exists in most organisations. The APQP team moves to the next launch. The production team inherits a process they did not design and problems they did not create. The lessons learned document is either never written or composed so generically it adds no value. The next launch begins, and the same mistakes recur because the organisation did not learn. It just launched.
Closing the loop requires a structured review after every launch. Document what problems occurred during production that APQP should have caught. Identify which deliverables existed but failed to predict the risk. Specify what changes in the APQP process for the next launch. Write it down, share it across the engineering organisation, and reference it in the next kick-off meeting.
Rebuilding Prevention into the System
The structural problem underneath hollow APQP is that most organisations have confused compliance with competence. Compliance means the deliverables exist. The FMEAs are in the folder. The Control Plans are signed. The PPAP is submitted on time. An auditor or customer SQE reviews the package and finds it complete because the format is correct and every box is checked.
Competence means the deliverables are correct. The FMEAs reflect actual engineering analysis of actual failure modes with actual controls. The Control Plans specify measurements statistically capable of detecting the variation that matters. The capability studies reflect real process performance over a meaningful production window. Compliance is easy to audit. Competence is hard. So organisations optimise for what gets measured.
Compliance without competence is theatre. It does not prevent defects, reduce variation, or make launches successful. It produces documentation that looks like the work. When your APQP process produces binders full of signed deliverables but your launches still deliver the same scrap rates and customer escapes year after year, the thinking did not happen. Prevention is cheaper than detection, detection is cheaper than field failure, and field failure is cheaper than a recall. APQP sits at the top of that cost waterfall.
Make the Control Plan a living document, not a derived one. Most Control Plans are copy-paste exercises from the drawing. A real Control Plan is the direct output of the FMEA — it specifies, for each identified risk, the control method, the frequency, the responsibility, and the reaction plan. If your Control Plan does not trace directly to your FMEA, it is a spreadsheet, not a control plan. Staff APQP with dedicated resources. The investment is a fraction of what a single failed launch costs in scrap, delays, and customer dissatisfaction.