APQP Planner

What this tool does

CM8-292 plans a product launch across the five phases of advanced product quality planning. Each row is one deliverable: which phase it belongs to, what kind of thing it is, who owns it, when it is planned to start and finish, when it actually finished, what state it is in, and whether it is a gate — a deliverable the phase cannot close without.

From that it produces the phase progress bars, a Gantt of the whole programme with gates drawn as diamonds, a slippage ranking, and a gate table that answers the only question a launch review really asks: can this phase close, and if not, what is holding it. One file can hold several programmes, and everything runs inside this single file — no account, no upload, no network request of any kind.

What quality planning is for

Advanced product quality planning is a structured way of planning a launch so that the evidence of quality is built during development rather than reconstructed afterwards. It began in automotive supply chains and spread into aerospace, medical devices and general contract manufacturing because the problem it solves is universal: a team designs a part, orders tooling, makes some samples, and only then discovers that nobody wrote down what the customer asked for, that the gauge cannot see the tolerance, and that the approval pack is due in a fortnight.

The framework's answer is to name the deliverables up front, put them in phases, give each an owner and a date, and refuse to move on until the ones that matter are done. That is all this planner is: the value is not in the phase names but in a plan that exists before the work rather than a report written after it.

The five phases

Phase 1 — plan and define. What is being built and for whom. Volumes, build dates, the customer's own requirement list, special characteristics, design goals, the team and the timing plan. This phase produces agreement, and it is cheap. Everything wrong here gets expensive later.

Phase 2 — product design and development. The design itself: drawings and models, the design FMEA, design reviews, prototypes and their test results, the preliminary bill of process, and the first list of equipment and gauges the part will need. It ends with a released drawing that everything downstream is raised against.

Phase 3 — process design and development. How the part will be made: the process flow, the process FMEA, the pre-launch control plan, packaging, tooling and equipment, gauges and their studies, operator instructions and training. This is the largest phase and the one that slips.

Phase 4 — product and process validation. Proving it works at production conditions: the significant production run, run at rate, measurement system studies, initial process capability studies and the production part approval submission. This phase turns intent into evidence.

Phase 5 — feedback, assessment and corrective action. After launch: reduced variation, improved delivery and service, and the lessons that go into the next programme.

Gate deliverables

A gate deliverable is one the phase cannot close without. Tick it sparingly — the handful that genuinely stop the programme, not everything anyone considers important. If every row is a gate, the gate column tells you nothing and the review meeting goes back to arguing from memory.

The reason to be strict is that a phase closed over an incomplete gate does not remove the work — it moves it downstream, into a phase that has its own work and less time. The classic version is closing phase 3 with the tooling trial outstanding: phase 4 then starts with no parts, run at rate cannot happen, the approval submission has no dimensional results behind it, and the launch date protected on paper arrives with nothing behind it. The gate table here is deliberately blunt: yes or no, with the earliest outstanding date beside it.

Timing, and where launches slip

The honest observation from most launches is that phase 3 is where the time goes. Phases 1 and 2 are largely paperwork and engineering judgement, and a determined team can compress them. Phase 3 contains the things with lead times nobody controls: tooling, gauges, fixtures, equipment installation, and the training that cannot start until the method settles. A four-week slip at the tool maker is four weeks, and no amount of programme management converts it into two.

This is why slippage is measured two ways. A completed deliverable is measured from planned finish to actual finish, so you can see how the plan behaved. An unfinished deliverable past its date is measured to today, so the bar grows every day it is left — the honest picture, because an overdue item does not stop costing time while it is overdue. When something slips, move the dates behind it rather than letting the plan quietly become fiction.

The outputs

Most of what quality planning produces is not produced by the plan — it is produced by the work, and the plan insists it happens on time. The FMEA Worksheet produces the design and process FMEA deliverables. The Control Plan Builder produces the pre-launch and production control plans, and should agree with the FMEA line by line. Gauge R&R produces the measurement system studies that phase 4 depends on. The PPAP Submission Checklist assembles the approval pack — and if the phases have been run properly, that submission is an assembly job rather than a scramble, because every element already exists as a completed deliverable here. That is the argument for the whole framework: the pack is the same evidence either way, and the only question is whether it was created while the work was fresh or reconstructed afterwards.

Run at rate

Run at rate is the phase 4 deliverable people most often water down, so it is worth being precise. It is a production run on production tooling, in the production cell, at the production cycle time, with production operators, for long enough to be real — commonly a shift, or a quantity agreed with the customer.

What it demonstrates is not that good parts can be made; a skilled engineer with unlimited time can make good parts on almost anything. It demonstrates that the process can make good parts at the rate the schedule assumes, with the people who will run it, including changeovers, material handling and gauging. A trial run by the engineering team at half speed proves the parts and nothing about the process — and where the run is short, the capability studies behind it inherit that weakness.

Phase 5, the phase everyone skips

Phase 5 has no customer date attached to it, which is exactly why it evaporates. The team disperses onto the next programme the week after launch, and the knowledge of what went wrong — the tool maker who slipped, the gauge that could not see the tolerance, the requirement discovered in month four — goes with them. The next programme then repeats it. The counter is to book phase 5 as deliverables with owners and dates, at the start, and to make the lessons review a gate. It costs a day.

The spreadsheet workflow

Launch plans usually start life in a spreadsheet, and the toolbar keeps that route open.

• Spreadsheet template saves a CSV whose headings are exactly this tool's column names, with a guidance row showing what each column expects — the date format, and the accepted values for the phase, deliverable type and status lists.
• Keep a master copy with the phase, deliverable, type and gate columns filled in: that is your standard deliverable list. Copy it for each programme, add owners and dates, and delete the guidance row before saving. Keep the file as CSV.
• Import spreadsheet reads it back. Columns are matched by heading, so their order does not matter and extra columns are ignored. Rows missing a required column, or failing a validation check — a blocked deliverable with no risk note — are skipped and reported by row number.

The file is read by this page in your browser: nothing is uploaded, and importing adds to what is already here rather than replacing it.

The formulas

Phase completion counts rows, not effort: five small documents and one tooling programme give a phase of six deliverables in which the tooling is one sixth. That is why the gate flag exists — it is the weighting the percentage cannot carry. Read the gate column first and the percentage second.

FAQ

Our customer uses different phase names. Most do. Map yours onto the five here — the sequence plan, design, process, validate, feedback is common to nearly every variant. The customer's own requirement governs what the phases are called and what they must contain.

How many deliverables should a programme have? Enough that nothing important is unowned, few enough that the plan is read. Two hundred rows becomes a document nobody opens.

What is the difference between at risk and blocked? At risk means it can still make its date if something is done; blocked means it cannot, and the date is already wrong. Both demand a risk note, because "at risk" without a cause is a feeling rather than a status.

Why does a complete deliverable need an actual finish date? Because without it there is no slippage history, and slippage history is what makes the next programme's plan realistic instead of optimistic.

Saving your work

Deliverables, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the plan for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo. A launch plan names customers, dates and suppliers who are late — treat exports as confidential.

Accuracy & disclaimer

This tool records what you enter and summarises it faithfully. It cannot open a document, visit a tool maker, or tell whether a deliverable marked complete is any good. Phase completion counts ticks in this file, and a phase shown green with an unbuilt tool behind it is a reporting problem, not a launch on schedule.

Which deliverables are required, which are gates, what the phases are called and what evidence a customer will accept differ by customer and by industry, and the customer's own requirement always governs. Nothing here is certification, compliance sign-off or engineering advice.