APQP Compliance Checklist from OEM Requirements

Hello! Last lesson separated product-design authority from manufacturing process-design responsibility. That distinction matters when you read a customer-specific requirement: the same document may contain duties for every supplier, duties only for design-responsible suppliers, and duties triggered by a particular part or launch condition.

This lesson shows you how to turn an OEM requirement into a traceable APQP compliance checklist. We will use an illustrative, make-to-print automotive textile cover and Ford’s October 2024 customer-specific requirements as the worked example. The method transfers to other customers; the particular Ford obligations do not.

First, identify what kind of requirement you are reading

A customer requirement can arrive through a drawing, a statement of work, a purchasing condition, or a customer-specific requirement (CSR). These sources work together, but they are not interchangeable.

For this lesson, the CSR is the source you will extract from. The drawing and program documents supply facts needed to decide whether each CSR clause applies. For example, a clause concerning a customer-designated critical characteristic cannot be classified confidently until you have checked the current drawing.

The short OEM-matrix example in APQP Full Training: Advanced Product Quality Planning (#coretools), from We Improve Consulting, shows why this is more than making a list of document names.

An auditable checklist preserves that distinction. A row such as “PFMEA — complete” loses the source clause, its trigger, the required acceptance, and the evidence that proves completion.

Extract the obligation before assigning the work

Read each relevant clause as a conditional statement. Identify who must do what, under which circumstances, by when, and with what record or approval. The operative words matter: shall states a requirement; if or for can limit its scope; should does not automatically become an unconditional mandate.

Use these fields when extracting a clause:

Applicability is not completion. “Applies; awaiting customer information” is a useful checklist result. “Not applicable” is defensible only when its trigger has been checked and ruled out. Likewise, “no customer-specific requirement for this section” does not cancel a requirement from the underlying standard, drawing, or another applicable customer document.

Start the Ford example with the program-level obligations. In Ford’s Customer-Specific Requirements (October 2024), read the APQP record-retention passage and the “8.1 Operational planning and control” subsection, then the feasibility provision under “8.2.3.1.3 Organization manufacturing feasibility.”

Suppose the cover is a New Tooled End Item, manufactured using newly installed cutting equipment. The drawing fully defines the product, so the supplier is make-to-print. It does not carry Ford’s inverted-delta designation. Those are scenario facts, not conclusions drawn from the CSR.

Two planning rows now become clear. Schedule A is applicable because this is a New Tooled End Item: even without a notification letter, the supplier must complete it at each program milestone and retain the final version as specified. The new manufacturing equipment triggers the documented initial and final feasibility reviews. The checklist should still record the actual program milestone dates and determine whether a notification letter adds submission instructions; neither a guessed date nor “monthly” by itself captures the full clause.

Follow the requirement into process evidence and approval

The previous lesson established that a make-to-print supplier still designs its manufacturing process. Ford’s CSR makes that boundary concrete: some design-risk information must be obtained from Ford and carried into supplier-created process evidence. Other clauses impose obligations on every relevant launch, while customer acceptance depends on design responsibility or the part’s designation.

Read “8.3.2.1 Design and development planning — supplemental” and its FMEA, special-characteristic, and control-plan provisions on pp. 23–25.

For the example cover, “make-to-print” does not justify writing “DFMEA: N/A” and stopping there. Ford’s provision calls for the supplier to obtain relevant DFMEA information, including potential special characteristics, to develop its PFMEA and identify special characteristics. The supplier documents those characteristics on the Special Characteristics Communication and Agreement Form (SCCAF), including controls at sub-tiers where applicable, and obtains Ford approval. If that information has not arrived, the row is applicable and open, not complete.

Conversely, do not add “Ford acceptance of supplier DFMEA” as an applicable row for this fully customer-defined cover. Ford’s cited DFMEA-acceptance requirement addresses design-responsible organizations. Nor should you mark inverted-delta PFMEA and control-plan acceptance as applicable without the part designation. Record that trigger as checked against the current drawing. Ford also reserves the right to require acceptance for other parts, so a later customer instruction would require reassessment.

Finally, read the product-approval subsection, “8.3.4.4 Product approval process,” on p. 29.

This final passage is a reminder not to mistake the checklist for the submission. The checklist controls whether the applicable evidence and approvals are ready; the PPAP process governs their approval route.

Build a checklist that can support a gate decision

Here is an illustrative extraction for the make-to-print, New Tooled End Item textile cover described above. “Program owner” entries are proposed coordination assignments, not roles prescribed by Ford. Checkpoints must be replaced with dates from the actual program and customer instructions.

Notice what the last two trigger-check rows accomplish. They preserve the source requirement without falsely assigning work. If the drawing is revised to add an inverted-delta designation, or the supplier takes on product-design responsibility, those rows can be reopened and their consequences planned. A checklist that simply deletes “N/A” items has no reliable way to show what was checked.

Before using this example on a real program, verify the controlled CSR revision, the current drawing and designation, the actual statement of work, New Tooled End Item status, notification letter, program timing, and any customer instructions that alter approval expectations. Then check each completed row against its record: document title and revision, part or program identity, approval where required, and the milestone it supports. Marking a document “complete” when customer approval is still pending would give a misleading gate status.

Key takeaways

To extract an APQP obligation, retain its source, trigger, required action, evidence, timing, and approval condition. Apply each clause to verified program facts rather than assuming that every listed deliverable applies equally to every supplier. In the Ford example, make-to-print status changes who authors the DFMEA, but it does not remove the need to obtain design-risk information or develop controlled process evidence.

Your checklist should make unresolved inputs and conditional requirements visible. In the next module, you will use customer requirements and lessons learned to define measurable program objectives and critical-to-quality requirements—the next step in turning compliance obligations into a workable launch plan.