APQP: When Your Advanced Product Quality Planning Becomes an Expensive Checklist Nobody Follows — and the Launches You Planned Rigorously Still Failed on the Production Floor

Blog

The Promise That Sold Itself

Advanced Product Quality Planning — APQP — is supposed to be the
framework that prevents launching products into chaos. Developed by the
automotive industry (the Big Three, back when that meant something),
formalized under the AIAG umbrella, and adopted globally as the gold
standard for new product introduction. The idea is deceptively simple:
plan quality in before you build the first part, not after you’ve
shipped ten thousand defective ones.

The manual itself is a masterpiece of structured thinking. Five
phases. Twenty-three elements. Control plans, failure mode analyses,
measurement system studies, process flow diagrams, preliminary process
capability, production part approval. Every box checked is a risk
eliminated. Every gate passed is a failure prevented. APQP is, on paper,
the most rational thing your organization can do before launching a new
product.

And yet.

Walk into any manufacturing plant running APQP and you’ll find the
same pattern. The binder is thick. The spreadsheets are populated. The
signatures are collected. The launch still goes sideways. Scrap spikes
in week one. Customer complaints arrive in week three. The team that
wrote the control plan cannot explain what the control plan actually
controls. The FMEA was copy-pasted from the last project. The PPAP was
approved on parts that were made on a Tuesday by the one setup
technician who no longer works there.

The planning was elaborate. The failure was inevitable. This is the
story of how that happens — and what to do about it.

Phase
1: Plan and Define — Where the Scope Gets Everything Wrong

Phase 1 is where APQP asks you to define the program. What are we
making? For whom? What are the requirements? What’s the timeline? Who’s
involved?

This sounds straightforward. It is not.

The most common failure in Phase 1 isn’t missing requirements — it’s
collecting too many of the wrong ones. Engineering receives the
customer’s specification and transcribes it verbatim into the APQP
documentation. Every dimension, every tolerance, every note on the
drawing becomes a “requirement” without any triage. Critical
characteristics are supposed to be identified — the few dimensions that
actually drive fit, form, and function — but in practice, organizations
either mark everything as critical (which means nothing is) or mark
nothing as critical (which means nobody knows what to focus on).

Meanwhile, the real requirements — the ones the customer will
actually judge you on — are nowhere in the documentation. The customer’s
unspoken expectation that parts arrive clean. The assembly sequence that
creates a tolerance stack nobody modeled. The shipping conditions that
warp the part in transit. These are the requirements that kill launches,
and they’re absent from the APQP binder because nobody thought to ask
the right questions.

Timeline planning in Phase 1 deserves its own indictment. APQP asks
for realistic timing, but organizations work backwards from the
customer’s required ship date and compress every phase to fit. Phase 1
gets two weeks. Phase 2 gets three. Phase 3 gets whatever’s left. The
timeline isn’t a plan — it’s a wish list printed on a Gantt chart.
Everyone signs it. Nobody believes it. The launch date doesn’t move, so
the planning becomes performative.

Phase
2: Product Design and Development — Where the FMEA Becomes Fiction

Phase 2 is where the design comes together. Prototypes are built.
Design FMEAs are conducted. Design verification testing happens.
Theoretically, this is where you catch design problems before they
become manufacturing problems.

The Design FMEA is the centerpiece of Phase 2, and it is almost
universally done wrong. Teams sit in conference rooms and fill out
spreadsheets. Severity. Occurrence. Detection. Risk Priority Numbers.
The exercise feels rigorous because there are numbers involved, but the
numbers are fiction.

Occurrence ratings are guesses. Nobody has data on how often a
brand-new design feature will fail — it’s brand new. Detection ratings
are aspirational. The team writes “statistical process control” as the
detection method for a process that doesn’t exist yet, run by operators
who haven’t been hired, on equipment that hasn’t been purchased. The RPN
comes out to a nice, moderate number, and the team moves on.

The most dangerous Design FMEA is the one that looks complete. Every
failure mode has an entry. Every column is filled. The recommended
actions are documented. What’s missing is the substance: the honest,
uncomfortable conversation about what could actually go wrong. The
failure mode everyone knows about but won’t say out loud because the
design is already locked. The material substitution that purchasing made
to save twelve cents per part. The tolerance that looks fine on the CAD
model but can’t be achieved on the actual machine.

Design verification testing in Phase 2 has its own pathology. Tests
are designed to pass, not to fail. Sample sizes are too small. Test
conditions are idealized. The prototype was made on a tool that will
never be used in production, by a technician who will never touch the
production line. When the tests pass, everyone is relieved. When the
production parts fail six months later, everyone is surprised. They
should not be.

Phase
3: Process Design and Development — Where the Process Becomes Someone
Else’s Problem

Phase 3 transitions from design to manufacturing. Process flow
diagrams. Process FMEAs. Control plans. This is where the baton is
supposed to pass from engineering to manufacturing, and it is where the
baton is most frequently dropped.

The Process FMEA suffers from the same maladies as the Design FMEA,
with an added twist: the people filling it out are often not the people
who will run the process. Engineers write the Process FMEA based on
their understanding of how the process should work. Operators run the
process based on their understanding of how it actually works. The gap
between these two understandings is where every production problem
lives.

Control plans are the practical output of Phase 3, and they are the
most misunderstood document in the entire APQP framework. A control plan
is supposed to be a living document that tells operators and inspectors
exactly what to check, how to check it, and what to do when something
goes wrong. In practice, it’s a static document written at launch, filed
in a binder, and referenced only when the auditor shows up.

The control plan lists every dimension on the drawing with an
inspection frequency of “first article, last article, and every fiftieth
piece” regardless of whether the dimension is critical or cosmetic.
Operators are expected to perform hundreds of measurements per shift on
a document nobody has reviewed since launch day. The inevitable result:
operators measure what they can measure quickly, skip what they can’t,
and record values that look reasonable. The control plan isn’t
controlling anything — it’s generating paperwork.

Process flow diagrams in Phase 3 are similarly optimistic. They show
the process as it was designed — material flows here, operation happens
there, inspection occurs at this point. What they don’t show is the
rework loop that developed in week two. The overflow area where parts
wait for inspection. The alternate routing that was created when Machine
3 went down and never changed back. The real process diverges from the
documented process within days of launch, and nobody updates the flow
diagram because nobody told them they should.

Phase
4: Product and Process Validation — Where the PPAP Becomes a
Performance

Phase 4 is validation. Production trial runs. Measurement system
analysis. Preliminary process capability studies. Production Part
Approval Process (PPAP) submission. This is the phase where you’re
supposed to prove that your process can consistently produce parts that
meet requirements.

The PPAP is the culmination of APQP, and it is the most ritualized
quality exercise in manufacturing. You submit eighteen (or more,
depending on your customer) specific elements to demonstrate that you
understand your process and can control it. The customer reviews your
submission and grants approval.

Here’s what actually happens.

The production trial run that generates your PPAP samples is a
special event. The best operator is selected. The freshest material is
used. The machine is cleaned and calibrated. Environmental conditions
are ideal. Every parameter is monitored and adjusted in real time. The
parts that come off this run are beautiful. They represent the absolute
best your process can produce under the best possible circumstances.

This is not your production process. This is a performance.

The capability studies submitted with the PPAP are based on these
optimal parts. The Cpk values are impressive. The customer approves the
submission. Then production starts, and reality sets in. Different
operator. Different material lot. Machine drift. Tool wear.
Environmental variation. The process that produced Cpk 1.67 during the
trial run produces Cpk 0.89 on a typical Tuesday. The PPAP said you were
capable. The production floor says otherwise.

Measurement system analysis — another Phase 4 requirement — is
typically done once, by the quality engineers, under controlled
conditions, and then filed away. The operators who actually take the
measurements on the production floor use different techniques, apply
different force, interpret the gauges differently. The MSA said the
measurement system was acceptable. The reality is that it’s barely
adequate, and nobody checks because the MSA was already submitted.

Phase
5: Feedback, Assessment, and Corrective Action — Where the Lessons Are
Never Learned

Phase 5 is the closing loop. Continuous improvement. Lessons learned.
Best practices shared across the organization.

This phase exists on paper. In practice, it’s a graveyard.

The post-launch review meeting is scheduled. It happens late or not
at all, because everyone has moved to the next project. When it does
happen, the tone is retrospective but not honest. “What went well” gets
forty minutes. “What went wrong” gets ten. Action items are documented
and assigned to people who are already overcommitted. The action items
from the previous project’s Phase 5 review are still open.

Best practices are documented in a database that nobody reads.
Lessons learned are filed in a folder that nobody searches. The same
mistakes repeat across projects with depressing regularity — the same
tolerance stack issue, the same material qualification gap, the same
supplier quality surprise. Each time, it’s treated as novel. Each time,
someone writes it down. Each time, it happens again.

The most valuable output of Phase 5 — the honest assessment of what
your APQP process actually caught versus what it missed — is the output
that organizations are least willing to produce. It requires admitting
that the control plan didn’t catch the critical defect. That the FMEA
didn’t identify the failure mode that shut down the line for three days.
That the PPAP parts were manufactured under conditions that bore no
resemblance to production. Honest Phase 5 reviews would force
organizations to confront the gap between their documented quality
system and their actual quality system. Most organizations would rather
not look.

What APQP Should Actually
Look Like

APQP is not broken. The framework is sound. What’s broken is how
organizations execute it.

A functioning APQP process looks different from the checkbox exercise
most organizations run:

Phase 1 should produce a short list, not a long one.
Five to seven critical characteristics, not fifty. Requirements triaged
by risk and impact, not transcribed wholesale from the drawing.
Timelines built from experience, not compressed from wishful
thinking.

Phase 2 should produce honest failures, not validated
designs.
The best Design FMEA sessions are the uncomfortable
ones — where someone says “this feature has never worked in any
application I’ve seen” and the team has to confront it. Prototype
testing should push the design to failure, not demonstrate that it
passes.

Phase 3 should be owned by manufacturing, not
engineering.
The people who will run the process should write
the Process FMEA and the control plan. If they can’t, you haven’t
trained them enough to launch. The control plan should fit on one page
per operation and list only what matters.

Phase 4 should reflect reality, not aspiration. Run
your production trial on a normal shift with a normal operator using
normal material. If the capability isn’t good enough under normal
conditions, you have a process problem, not a submission problem. Fix
the process, don’t optimize the trial.

Phase 5 should produce changes, not documents. If
the review doesn’t result in at least three concrete modifications to
your APQP template or your launch process, you weren’t honest enough.
File the lessons in the database if you want, but more importantly,
change the template so the mistake can’t happen again.

The Uncomfortable Truth

APQP fails not because the framework is flawed but because
organizations use it as a substitute for thinking. The checklist creates
an illusion of rigor. The filled-out forms create an illusion of
completeness. The signatures create an illusion of accountability.
Underneath all that paperwork, the same problems recur because the
framework was executed without the substance it demands.

The organizations that get APQP right are the ones that treat it as a
thinking tool, not a documentation requirement. They argue about failure
modes instead of filling in spreadsheets. They challenge their own
designs instead of validating them. They run honest trials instead of
optimized performances. They learn from failures instead of filing
them.

The difference between APQP that prevents launch disasters and APQP
that generates impressive binders is not the framework. It’s the
willingness to use the framework honestly — to say the things that are
uncomfortable, to document the problems that are real, and to fix the
gaps that matter instead of the ones that are easy to address.

Your APQP binder is thick. Your launches still fail. The binder is
not the solution. It’s the evidence that you knew the problems existed
and chose to document them instead of solving them.


Peter Stasko is a Quality Architect with over 25
years of experience in manufacturing quality systems, process
improvement, and launch management. He has led APQP programs across
automotive, electronics, and industrial manufacturing, and has seen
every way a good framework can be turned into expensive theater. He
writes about the gap between what quality systems promise and what they
actually deliver.

Scroll top