KEVOS · Templates & Examples · Project Templates
Tooling, Off-Tool Testing and Correction Schedule Template
A handbook schedule template for tooling manufacture, off-tool samples, verification, correction loops, final testing and approval.
Executive summary
Tooling and testing is the longest recurring technical stage in the source project schedules. The stable pattern is tooling manufacture, off-tool sample testing, tooling corrections, final testing and gauges, approval, then a production gate. Some schedules insert an off-tool sample inspection/request step before formal testing. The correct planning model is therefore an iterative acceptance loop, not a single “tool complete” milestone.
The acceptance loop
Recurring tasks and their control intent
| Task | What it controls | Do not mark complete until… |
|---|---|---|
| Tooling | Creation or modification of production-intent tooling. | The agreed tooling output/sample event has occurred. |
| Off-tool sample inspection / testing OTS | Evidence from the first production-intent outputs. | Required samples are available, test/inspection is performed and results are recorded. |
| Tooling corrections | Closure of dimensional, functional, cosmetic or process issues attributable to tooling or design. | Corrective changes are implemented and configuration is identified. |
| Final testing and gauges | Final verification, including any test rig or gauge work needed by the project. | Required evidence is complete enough for approval. |
| Approval | Acceptance of the product/tooling result by the required stakeholder. | The decision and any conditions are recorded. |
| Production meeting / gate | Authorisation to proceed into controlled production activities. | Production-readiness evidence and outstanding risks are reviewed. |
Separate tool completion from product acceptance
A tool can be physically complete while the product is not acceptable. The source schedules make this distinction by placing testing, corrections and final verification after tooling. That is a useful control principle for any manufacturing project: “tool delivered” is not equivalent to “part approved”.
The schedule should therefore carry at least two different events when appropriate: a tooling completion or first-off-tool event, and a product/tool acceptance event. If these are collapsed into one milestone, the forecast loses visibility of the learning and correction cycle that commonly occurs after first samples.
Planning the off-tool sample step
- Configuration: identify which tool revision/cavity/process produced the sample.
- Sample sufficiency: confirm enough samples exist for the planned inspections and tests. One source example explicitly requests more samples before testing.
- Test readiness: verify that the test method, fixture, rig or gauge is ready. A recurring task name in the sources refers to final testing and gauges and also records test-rig problems in some projects.
- Result ownership: define who reviews results and decides whether an issue is tooling, design, material, process, test setup or sample handling.
- Correction logic: link corrections to retest where required rather than simply closing the correction task when the toolmaker reports completion.
Correction-loop decision tree
| Result condition | Schedule response |
|---|---|
| All required evidence acceptable | Proceed to final approval / production gate. |
| Minor issue with no effect on acceptance criteria | Record disposition and proceed only if authorised. |
| Tooling-related nonconformance | Create correction activity, identify affected tool revision, then repeat relevant verification. |
| Design-related issue | Re-open the affected design task and assess whether tooling must also change. |
| Test-rig or gauge problem | Correct the verification method and repeat the affected test; keep product disposition separate from equipment failure. |
| Insufficient samples | Add sample-production/request dependency before the test can restart. |
| External approval pending | Show the approval task as waiting/hold rather than extending completed technical tasks. |
Why this stage dominates the schedule
Across the fifteen individual source projects, the tooling-and-testing summary is consistently present and often substantially longer than the other standard stages. This does not mean a fixed duration should be used. It indicates that tooling build, shipping or transfer, sample availability, laboratory capacity, correction cycles and approval waiting can all accumulate in the same part of the project.
A better schedule separates these drivers where they matter. For example, if a supplier requires a long tool build and a separate freight period before sampling, show those events explicitly. If internal testing capacity is constrained, link the test task to the laboratory/test-register forecast. If correction cycles are uncertain, plan a reasonable task structure but manage the risk through forecast updates rather than hiding it in an oversized generic duration.
Acceptance records to retain
- Tool or sample configuration identifier.
- Off-tool inspection/test request and results.
- Correction action and evidence of implementation.
- Retest result where the correction affects acceptance.
- Gauge or test-rig status where measurement equipment is required.
- Approval decision and any conditional actions.
- Production-gate decision and unresolved risks carried forward.
Related KEVOS templates
Managing the correction loop as controlled learning
First-off-tool results should be reviewed as a structured disposition event. Group each issue by its likely cause and required action: tooling correction, design change, process adjustment, measurement/test-method correction, material investigation or sample replacement. The classification matters because each path has different owners and dependencies. A tooling correction may require supplier work and new samples; a test-method issue may require no tool change at all.
For every correction that can affect acceptance, define the evidence needed after the change. Closing the action because the physical alteration was completed is insufficient; the affected characteristic or function must be reverified where required by the project. Keep the original result, action and retest linked so the final approval reviewer can understand the history without reconstructing it from separate conversations.
Practical correction-register fields
- Issue identifier and affected sample/tool configuration.
- Observed result and evidence reference.
- Disposition category and responsible action owner.
- Target completion and impact on the project forecast.
- New sample or test dependency, if required.
- Retest result and final closure decision.
If several correction cycles occur, the schedule can retain one summary task while the detailed correction register controls individual issues, provided the forecast reflects the remaining work. For a small project, separate correction tasks may be clearer. The objective is not to create administrative volume; it is to ensure the project knows what must change, what must be tested again and what evidence allows the production gate to proceed.
Keeping test evidence aligned with the project schedule
Where the organisation uses a separate test register, use one cross-reference between the schedule task and the test request. The schedule carries the project dependency and forecast; the register carries sample, method, status and result detail. Update the project forecast when the test queue changes, but avoid duplicating every laboratory field in the schedule. This division of control keeps both systems readable while preserving traceability from a delayed or failed test to the affected project gate.