KEVOS · Templates & Examples · Project Templates
Product Development Project Schedule Template
A handbook-style reusable project schedule template for manufactured-product development from concept through tooling, testing and optional production release.
Executive summary
The supplied scheduling set supports a reusable new-product development schedule built around four consistently repeated stages—rapid conceptualisation, development, tooling quotation, and tooling/testing—with a production stage present in most completed examples. The blank source template contains 22 named activities across the first four stages. Eleven of fifteen project examples extend the schedule into production, while four end after tooling/testing. This page turns that recurring structure into a reusable project-template framework without treating any sample duration as a universal requirement.
The schedule architecture
Across the anonymised project schedules, the same work breakdown structure appears repeatedly. The structure is valuable because it follows the technical maturity of a manufactured product rather than organising the plan only by department. Early work defines the problem and proves a rough concept; development then converts the idea into a controlled design; tooling quotation prepares the commercial and technical basis for external or internal manufacture; tooling and testing closes the loop through off-tool samples, correction and final approval; production readiness completes the transfer into repeatable supply.
The blank schedule template supplied in the dataset stops at tooling and testing. The project examples show that a production stage is often required in practice. For that reason, KEVOS treats production as an optional fifth stage that should be enabled when the project scope includes production release, purchasing, freight, stock verification or manufacturing handover.
Core work breakdown structure
| Stage | Recurring activities supported by the sources | Primary output |
|---|---|---|
| Rapid conceptualisation | Design brief; rough design or rapid modelling; 3D-printed/physical prototype; initial testing; prototype approval or preliminary business case. | A concept that is sufficiently defined to justify detailed development. |
| Development | Detailed CAD; CNC or equivalent working prototype; cycle/functional testing where required; prototype review; design approval and supplier-selection meeting. | Approved design direction and an agreed path to tooling/supply. |
| Tooling quotation | Technical drawings and BOM; tooling quotation; quotation review; tooling and testing-plan approval meeting. | Approved technical/commercial basis to commit tooling. |
| Tooling & testing | Tooling manufacture; off-tool sample inspection/testing; tooling corrections; final testing and gauges; customer/stakeholder approval; production gate. | Evidence that tooling and product performance are acceptable for release. |
| Production / launch | Final BOMs and kits; quality-control document; ERP setup and order; production; freight where relevant; incoming/stock checking. | Controlled transition into repeat supply or launch. |
How to create a new schedule from the template
- Define the project boundary. Decide whether the schedule ends at technical approval, tooling acceptance, first production, delivered stock or market launch. This determines whether the production/launch stage is required.
- Create the WBS before dates. Keep summary stages separate from executable tasks. The source examples consistently use stage summaries with leaf tasks beneath them, which makes reporting by phase possible.
- Replace generic task names only where needed. Preserve the intent of the template. For example, “Testing OTS” can be renamed to a specific off-tool test, but it should still represent verification of off-tool samples.
- Build predecessor logic. The blank template links most leaf activities sequentially. Do not rely on dates alone; link the approval output of one activity to the start of the next where a genuine dependency exists.
- Add stage gates. The recurring meeting tasks are control points: design/supplier approval, tooling/testing approval and production approval. Define the evidence required at each gate rather than treating the meeting as an administrative appointment.
- Estimate durations from current facts. Use supplier lead times, internal capacity, testing duration and logistics information. Do not copy long or short durations from an old example simply because the task names are similar.
- Set ownership outside the summary task. Assign accountable roles to leaf activities and gate evidence. The sources show role-based attendance in one spreadsheet export, which is more reusable than tying the schedule to individuals.
- Baseline only after the logic is credible. A baseline is meaningful only when scope, activity sequence, lead times and gate assumptions are understood.
Planning fields to maintain
Stage and task hierarchy that supports roll-up reporting.
Links showing what must finish before dependent work starts.
Measured task progress; avoid using summary progress as a substitute for leaf-task updates.
The approval record, test result, drawing pack or commercial decision that permits progression.
Current expected dates driven by logic and remaining duration.
Explicitly identify stalled work rather than leaving an old finish date to imply progress.
Common scheduling mistakes exposed by the examples
- Copying historical elapsed time as a new estimate. Some examples span years because the project was held, paused or waiting for external decisions. Elapsed calendar span is not the same as planned effort.
- Starting downstream phases too early without explaining concurrency. Some source schedules show tooling or production activity overlapping earlier stages. If concurrent engineering is deliberate, make the dependency exception visible and controlled.
- Using zero-duration milestones for work that actually consumes effort. Two examples convert many early tasks to milestones. This is useful only when the actual work is tracked elsewhere and the schedule intentionally records decision points rather than effort.
- Leaving production outside the plan. If BOM release, ERP creation, quality documentation, manufacture, freight or receiving are necessary to achieve the project objective, they belong in the integrated schedule.
- Calling a meeting a gate without evidence. A gate must be tied to acceptance criteria and required records. Otherwise it becomes a date on the calendar rather than a control point.
Related KEVOS templates
How to tailor the master template before baselining
Start by copying the work-breakdown structure, not the historical dates. Confirm the project objective, the physical deliverable, the intended verification evidence and the event that will count as completion. Then decide which of the five stages actually apply. A development that uses an existing tool may not need a tooling-build task; an internally manufactured item may not need freight; and a low-risk change may use a shorter prototype path. Removing non-applicable work is better than leaving zero-value tasks in the plan.
Next, replace each example duration with an estimate supported by the people who will perform or supply the work. Record the estimating basis in the schedule notes where useful—for example, supplier quotation, known machine availability, planned test duration, prototype capacity or logistics assumption. This turns the schedule from a copied template into a traceable project forecast.
Baseline readiness questions
- Does every summary stage end in a meaningful technical or commercial decision rather than an arbitrary date?
- Are supplier, workshop, test and approval dependencies visible instead of hidden inside long task durations?
- Can the team identify the current design/tool/sample configuration at each approval point?
- Are “waiting” periods represented as dependencies or hold states so completed work is not falsely stretched?
- Is the production or launch end-point defined in operational terms—for example, released stock available and checked—rather than simply “production started”?
During execution, update actual progress and forecast dates separately. A task that took longer than planned should retain its actual history while downstream tasks are reforecast. This preserves learning for future estimates and prevents the current plan from becoming a rewritten version of what was originally promised.