The Promise vs. the Poster
Advanced Product Quality Planning was supposed to be the answer to a
simple question that every manufacturing organization eventually faces:
Why do we keep launching products that aren’t ready?
The promise was elegant. Bring quality engineering upstream — before
the steel is cut, before the tooling is committed, before the first
production run. Build prevention into the launch sequence. Use a
structured, phased approach to identify risks early, plan controls
before they’re needed, and ensure that by the time production begins,
the process is proven, the part is validated, and the team is
confident.
APQP was designed to make product launches boring. Predictable.
Controlled. The kind of launch where the first run goes smoothly because
you’ve already identified the failure modes, validated the measurement
systems, confirmed the process capability, and pressure-tested
everything in trial runs.
That was the promise. Here is the reality in most organizations.
APQP has become a project management framework that produces Gantt
charts, milestone trackers, and cross-functional meeting schedules —
none of which actually prevent the problems they were designed to catch.
The phases exist on paper. The gate reviews happen on calendar. The
deliverables get checked off. And then the launch fails in exactly the
ways APQP was supposed to prevent, because nobody actually did the
substantive work underneath the checkboxes.
The plan is the poster. The poster is on the wall. And the launch is
on fire.
What APQP Actually Is
(When Done Right)
Before dissecting what goes wrong, let’s be clear about what APQP is
supposed to be.
Developed by the automotive industry — specifically the Chrysler,
Ford, GM Supplier Quality Requirements Task Force — APQP is a structured
approach to product launch that consists of five phases:
-
Plan and Define Program — Translate customer
requirements into specific technical and manufacturing objectives. What
is the customer actually asking for? What does success look like in
measurable terms? -
Product Design and Development — Assess the
feasibility of the design. Can this part actually be manufactured? Can
it be measured? What are the engineering risks? This is where Design
FMEA, Design Reviews, and Design Verification Planning happen. -
Process Design and Development — Develop the
manufacturing system that will produce the part consistently. This is
where Process Flow Diagrams, Process FMEA, and Control Plans are born.
The manufacturing process is designed with the same rigor as the product
itself. -
Product and Process Validation — Prove it. Run
the production process at the intended rate, with the intended tooling,
the intended operators, and the intended measurement systems. This is
where the Run at Rate, the Production Trial Run, and PPAP come together.
The question isn’t “can we make a good part?” — it’s “can we make good
parts consistently, at rate, over time?” -
Launch, Assessment, and Continuous Improvement —
Sustain the gains. Monitor performance, close gaps, drive continuous
improvement through the early production period.
Underneath these five phases sit dozens of deliverables: design
FMEAs, process FMEAs, control plans, measurement systems analyses,
initial process capability studies, packaging evaluations, floor plan
layouts, process flow diagrams, and more. Each one is a tool designed to
answer a specific question before that question becomes an expensive
problem on the production floor.
That’s the system. And it works — when people actually do the
work.
How Organizations Hollow It
Out
Here is how APQP degrades in practice, phase by phase.
Phase 1: The
Requirements Translation Nobody Does
The first phase is about understanding what the customer actually
needs. Not what the drawing says — what the customer needs.
These are not always the same thing. Drawings have tolerances that may
be tighter than function requires. Drawings may omit critical
characteristics that matter for assembly or end-use. Drawings may
reference standards that have been revised or superseded.
A proper Phase 1 involves sitting down with the customer’s
requirements, decomposing them into specific technical and manufacturing
objectives, identifying the characteristics that are critical to quality
(CTQ), and establishing the metrics by which success will be
measured.
What actually happens in most organizations: someone copies the
customer drawing into the internal system, assigns a part number, and
schedules a kick-off meeting. The “customer requirements” section of the
APQP deliverable checklist gets marked complete because the drawing
exists in the folder. Nobody has actually analyzed whether the
tolerances are achievable, whether the specifications are clear, or
whether there are implicit requirements that the drawing doesn’t
capture.
The result: the program launches with a set of requirements that
nobody has critically examined, and the first time anyone asks “wait, is
this tolerance actually achievable with our process?” is during the
trial run — eight months and $200,000 of tooling later.
Phase 2: The
Design Review That Reviews Nothing
Phase 2 is where the design is assessed for manufacturability, and
engineering risks are identified and mitigated. Design FMEAs are
performed. Design reviews challenge assumptions. Verification testing
confirms that the design works.
In practice, the Design FMEA becomes a post-hoc document — written
after the design is already locked, not before. 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 can’t change anyway. Design Verification becomes “we tested three
parts and they were fine” rather than a statistically meaningful
evaluation.
The deliverable gets checked. The risk that the deliverable was
supposed to identify goes undetected. And the risk shows up —
predictably, inevitably — during production.
Phase 3: The
Process Design That Isn’t Designed
This is where the deepest APQP failures live.
Phase 3 is supposed to produce a fully designed manufacturing
process: process flow diagrams that show every step, Process FMEAs that
identify what could go wrong at each step, Control Plans that specify
how each risk will be controlled, and floor plans that verify the
physical layout supports the intended flow.
What most organizations actually produce: a Process FMEA that lists
failure modes in generic terms (“operator error,” “machine
malfunction”), assigns risk priority numbers that nobody acts on, and
gets filed in the APQP binder. A Control Plan that copies the drawing
tolerances into a spreadsheet, adds a column that says “inspect at
setup,” and calls it process control. A Process Flow Diagram that shows
boxes and arrows but doesn’t capture 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 specific mistake-proofing device we’re installing. Here
is the specific sensor that will detect this condition. Here is the
specific training that operators will receive.” Instead, it becomes a
spreadsheet exercise where the “recommended action” column says “monitor
during production” for every row, and nobody ever monitors anything.
Phase 4: The
Validation That Validates Nothing
Phase 4 is the moment of truth. The production process runs at rate,
with real operators, real tooling, real material. Measurement systems
are validated. Initial process capability is calculated. The Production
Trial Run produces parts that are evaluated against the customer’s
requirements.
This is where APQP earns its keep — or where its failures become
visible.
In organizations where Phases 1-3 were hollow, Phase 4 becomes a
scramble. The trial run produces parts that don’t meet specification.
The measurement system can’t reliably detect whether parts are good or
bad. The process capability calculation 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. The customer is expecting parts. And the organization faces a
choice: do we stop, identify root causes, and fix the process — or do we
ship, sort, and hope?
Too many organizations choose the second path. The trial run “passes”
because the sample size was small enough that the outliers were
excluded. The capability study “passes” because the data was collected
over such a short period that normal variation hadn’t yet revealed
itself. The PPAP gets submitted. The launch happens. And then the real
production begins — with all the problems that APQP was supposed to
prevent.
Phase 5: The
Sustainment Nobody Sustains
Phase 5 asks the organization to monitor early production
performance, identify gaps between planned and actual performance, and
drive continuous improvement. It’s the phase that acknowledges that no
launch is perfect, and that the first 90 days of production will reveal
issues that no amount of planning could have predicted.
In practice, Phase 5 barely exists. The APQP team has already moved
on to the next launch. The production team has inherited a process they
didn’t design and problems they didn’t create. The “lessons learned”
document that was supposed to capture institutional knowledge for the
next program is either never written or written so generically that it
adds no value.
And then the next launch begins. And the same mistakes are repeated.
Because the organization didn’t learn — it just launched.
The Structural
Problem: Compliance vs. Competence
The deeper issue is that most organizations have confused APQP
compliance with APQP competence.
Compliance means the deliverables exist. The FMEAs are in the folder.
The Control Plans are signed. The milestone dates are met. The PPAP is
submitted on time. An auditor or a customer SQE could review the APQP
package and find it complete.
Competence means the deliverables are correct. The FMEAs
reflect actual engineering analysis of actual failure modes with actual
controls. The Control Plans specify measurements that are statistically
capable of detecting the variation that matters. The capability studies
reflect real process performance over a meaningful production window.
The launch risks have been identified, quantified, and mitigated — not
just listed.
Compliance is easy to audit. Competence is hard to audit. So
organizations optimize for compliance, because compliance is what gets
measured, scored, and reviewed. The customer’s Supplier Quality Engineer
doesn’t have time to evaluate whether your Process FMEA reflects genuine
engineering analysis — they check whether it exists, whether it’s
signed, and whether the format is correct.
But compliance without competence is theater. And theater doesn’t
prevent defects, reduce variation, or make launches successful. It just
produces documentation that looks like you did the work.
The Resource
Problem: APQP as a Part-Time Job
APQP was designed to be performed by a cross-functional team of
experienced engineers with the time, authority, and mandate to do the
work properly. The reality in most organizations is that APQP is
assigned to a quality engineer who already has a full-time job managing
existing production issues, and who is expected to produce all five
phases of deliverables alongside their daily responsibilities.
This is not a recipe for rigorous engineering analysis. It’s a recipe
for document generation. When the person responsible for the Process
FMEA is also responsible for investigating customer complaints,
supporting production lines, and managing supplier issues, the FMEA will
be written to satisfy the deliverable — not to actually identify and
mitigate risk.
Organizations that do APQP well assign dedicated resources. They
staff launch teams with engineers whose only job is the launch. They
give those engineers the authority to delay milestones when the data
warrants it. They invest in the work because they’ve learned — usually
the hard way — that the cost of a bad launch dwarfs the cost of proper
planning.
How to Fix It
If your APQP process has become a documentation exercise, here is how
to rebuild it into what it was designed to be.
Start with the Process FMEA. Not the document — the
activity. Gather the process engineers, the quality engineers, the
operators, and the maintenance technicians. Walk the process step by
step. Ask: what could go wrong here? What does go wrong here? What
happens when it does? Write down the answers. Then — and this is the
step most organizations skip — design specific controls for the
highest-risk failure modes. Not “monitor during production.” Specific
controls: poka-yoke devices, sensors, automated inspection, procedural
changes, training content.
Make the Control Plan a living document, not a derived
document. Most Control Plans are copy-paste exercises from the
drawing. A real Control Plan is the 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 doesn’t
trace directly to your FMEA, it’s not a Control Plan. It’s a
spreadsheet.
Take the trial run seriously. The Production Trial
Run is not a formality. It is the last opportunity to validate the
process before committing to production. If the trial run reveals
problems — and it should, because that’s its purpose — you need the
organizational authority to stop, investigate, and fix. If your trial
run “passes” on the first attempt every time, either your processes are
exceptionally mature or your trial run isn’t rigorous enough to detect
real issues. In my experience, it’s almost always the latter.
Close the loop with lessons learned. After every
launch, hold a structured review. What problems occurred during
production that APQP should have caught? What deliverables existed but
failed to identify the risk? What needs to change in the APQP process
for the next launch? Write it down. Share it. Use it.
Staff it properly. If APQP is a part-time
responsibility squeezed between production support and customer
complaints, it will produce part-time results. Dedicate resources to
launch planning. The investment is a fraction of what a single failed
launch costs.
The Bottom Line
APQP is not a documentation system. It is a prevention system. The
documentation exists to structure and record the prevention work — not
to substitute for it.
When your APQP process produces binders full of FMEAs, Control Plans,
and capability studies, but your launches still produce the same
problems year after year — scrap rates in the first 90 days that exceed
targets, customer escapes that trigger PPAP Level 3 resubmissions,
capacity shortfalls because the process wasn’t validated at the intended
cycle time — your APQP process is broken. Not because the forms aren’t
filled out. Because the thinking didn’t happen.
The five phases of APQP are not a paperwork sequence. They are an
engineering sequence. Each phase asks a question, and each deliverable
is a tool for answering that question. If you can’t answer the question
— if you can’t say with evidence that the design is manufacturable, that
the process is capable, that the controls are effective, and that the
team is ready — then no amount of signed deliverables will save your
launch.
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, with the leverage to prevent everything
downstream. But only if you actually do the work.
Not the paperwork. The work.
Peter Stasko is a Quality Architect with over 25 years of
experience in manufacturing quality management, process improvement, and
product launch strategy. He has led APQP implementation across
automotive, industrial, and consumer products supply chains and has seen
every way the system can fail — and how to fix it.
