KEVOS · Templates & Examples · Checklists
Project Schedule Readiness Review Checklist
A comprehensive readiness checklist for product-development schedules, stage gates, testing, tooling, production handover, holds and support registers.
Executive summary
This checklist consolidates the recurring schedule structure, three decision gates, testing workflow, production handover and portfolio/workshop controls into one readiness review. It is intended for use before baselining a new schedule, before major gates, and when restarting a held project. The checklist is a KEVOS synthesis of the supplied sources; it is not a contractual or regulatory requirement.
A. Schedule definition and WBS
- Project completion objective is explicit: technical approval, tooling acceptance, first production, received stock or another defined endpoint.
- The WBS uses summary stages and executable leaf tasks rather than one flat task list.
- Concept, development, tooling quotation and tooling/testing stages are present when relevant.
- Production/launch is included if BOM release, ERP/order, manufacture, logistics or stock verification are needed to meet the project objective.
- Optional activities such as second prototype, extra sample request or freight are included only when required by the actual scope.
- Historical source-example durations have not been copied as universal planning values.
B. Dependency and gate readiness
- Leaf tasks are linked by real technical or decision dependencies.
- Gate 1 follows sufficient prototype/design evidence and controls progression into drawings/BOM and tooling quotation.
- Gate 2 follows quotation review and controls tooling commitment plus the testing plan.
- Gate 3 follows final verification/approval and controls production release.
- Each gate lists the evidence that must be reviewed and the authority that makes the decision.
- Conditional pass actions remain visible after the gate and are linked to affected downstream tasks.
- Any concurrent engineering is deliberate, with configuration and assumptions documented.
- Milestones are used for events, while duration tasks are retained for work or meaningful waiting time where schedule visibility is required.
C. Concept and development readiness
- Design brief states the problem, intended function, key interfaces and known constraints.
- Rapid prototype has a defined question to answer rather than being built only for appearance.
- Prototype approval/preliminary business-case decision is recorded.
- Detailed CAD configuration is identifiable.
- Working prototype represents the features needed for verification.
- Test requests are raised and linked to the project forecast where they control a gate.
- Prototype review distinguishes product/design issues from fixture, sample or test-method issues.
- Second prototype is added only when evidence shows it is needed.
D. Tooling quotation and tooling/testing readiness
- Technical drawings and BOM are sufficiently defined for the quotation purpose.
- Quotation is based on an identified configuration.
- Quote scope, exclusions, lead-time trigger and sample assumptions are understood.
- Testing plan is ready before tooling commitment where the project requires off-tool verification.
- First-off-tool sample event is distinct from final product/tool acceptance.
- Required sample quantity and test capacity are planned.
- Correction/retest logic is visible.
- Gauge or test-rig needs are recognised before final verification.
- Final approval evidence is complete or conditions are explicitly recorded.
E. Production and handover readiness
- Approved product/tooling configuration is identified.
- BOM and kit information are finalised or under controlled release.
- Quality-control documentation needed for first production is available.
- ERP/item/order data is correct for the approved configuration.
- Production start is controlled by Gate 3 or another authorised release mechanism.
- Freight is included when transit affects the project completion objective.
- Received stock or first production output will be checked before closure.
- Launch tasks are included only if the defined project objective extends beyond stock receipt.
F. Status, holds and recovery
- Leaf-task progress is current and summary progress is not manually masking stale tasks.
- On-hold work has an explicit reason and restart trigger.
- Remaining duration/forecast reflects current information.
- Baseline remains available for variance learning.
- Blocked work awaiting external commitment is not falsely reported as active delivery.
- Projects pending approval/resources are visible in the portfolio rather than hidden inside long task durations.
- Recovery actions preserve gate evidence and configuration control.
G. Support-register integration
| Register | Readiness checks |
|---|---|
| Engineering test register | Test ID; configuration; priority; method/instructions; samples ready; owner; forecast; status; result/report reference; project disposition. |
| Workshop task register | Task; parent project/reference; priority; due date; material/drawing/CAD readiness; assignment; status; actual hours; completion/comment. |
| Portfolio register | Portfolio status; current phase; forecast finish; next gate; blocker; decision required; priority; last/next review; detailed schedule link. |
Review outcome
| Outcome | Use when | Required follow-up |
|---|---|---|
| Ready | Schedule logic, evidence plan and ownership are adequate for the next commitment. | Proceed and record approval/baseline as appropriate. |
| Ready with actions | Minor gaps exist but do not invalidate the next step. | Assign actions, dates and conditions; keep them visible. |
| Not ready | Missing information, evidence or authority makes the commitment unsafe or likely to create rework. | Close gaps before gate/baseline/restart. |
| Hold | A known prerequisite or external decision prevents meaningful progress. | Record reason, owner and restart trigger. |
When to use this checklist
Use it before the initial project baseline to confirm the WBS and logic are credible; before Gate 1, Gate 2 and Gate 3 to confirm evidence is ready; after a significant redesign or test failure to verify the revised plan; and when restarting a project that has been held long enough for old supplier quotes, design assumptions or test plans to become questionable.
The checklist should be tailored to the project. Do not keep an item merely because it appears here if it is genuinely not applicable, and do not assume the checklist replaces technical specifications, contractual requirements, regulatory obligations or organisation-specific approval procedures.
Related KEVOS templates
How to conduct the readiness review
Run the readiness review shortly before baselining and again before any major stage commitment. The reviewer should work from evidence, not from optimistic verbal status. For each checklist item, identify the supporting record or mark the item as not applicable with a reason. Where evidence is missing, classify whether the gap blocks the next stage, can be completed in parallel under controlled risk, or simply requires documentation clean-up.
The output does not need a complicated score. A practical result is a short decision: ready, ready with conditions, or not ready. Conditions should have owners and due dates. A “ready with conditions” decision is appropriate only when the remaining actions do not undermine the basis of the approval; it should not be used to bypass unresolved technical uncertainty that the gate is meant to control.
Evidence pack to retain
- Current schedule revision and the assumptions used for significant durations or external dates.
- Design/configuration reference being approved at the stage.
- Prototype, test, tooling or quality evidence relevant to the gate.
- Open-risk/action list with owners, due dates and disposition.
- Approval decision, conditions and the person/role authorised to make the decision.
- Updated downstream forecast after the decision is applied.
A readiness checklist should improve decision quality, not become a compliance ritual. If the same item repeatedly fails across projects—for example, missing samples, late drawings or unclear supplier scope—treat that pattern as a process-improvement opportunity. Update the upstream workflow or request template so the evidence is created naturally, rather than adding more end-stage checking.