KEVOS · Templates & Examples · Examples
Worked Example: Product Development Project Schedule
A fully anonymised worked example showing how to build a product-development schedule from concept through tooling, testing and production release.
Executive summary
This worked example applies the recurring source schedule to a fictional manufactured component. It deliberately uses generic names. The durations shown are based on the blank source template where that template provides them, and are labelled as source-example values rather than universal lead times. The example shows how to connect concept, development, tooling, testing and production-release logic into one readable plan.
Example project definition
Fictional objective: develop a new mechanical hardware component that requires a designed body, one or more manufactured parts, prototype verification and production tooling. The project ends when first production stock is received and checked.
Planning assumption: the blank source template provides sample dates/durations for stages 1–4. Production tasks are added from the recurring pattern in the completed project examples. The example is instructional; it is not a promise of schedule duration.
Worked WBS and example logic
| WBS | Task | Example duration/source basis | Predecessor / gate logic |
|---|---|---|---|
| 1.1.1 | Design brief | 2 working days — source-template example. | Project start. |
| 1.1.2 | Rough design and rapid prototype | 10 working days — source-template example. | After design brief. |
| 1.1.3 | Prototype approval / preliminary business case | 3 working days — source-template example. | After rapid prototype. |
| 1.2.1 | Detailed CAD, working prototype and initial testing | 20 working days — source-template example. | After concept approval. |
| 1.2.2 | Dedicated cycle/functional test | 30 working days — source-template example. | After working prototype. |
| 1.2.3 | Prototype review | 6 working days — source-template example. | After test evidence. |
| 1.2.4 | Gate 1: design approval and supplier path | 2 working days — source-template example. | After prototype review. |
| 1.3.1 | Technical drawings and BOM | 5 working days — source-template example. | After Gate 1. |
| 1.3.2 | Tooling quotation | 10 working days — source-template example. | After drawing/BOM issue. |
| 1.3.3 | Quotation review | 4 working days — source-template example. | After quote receipt. |
| 1.3.4 | Gate 2: tooling and test-plan approval | 2 working days — source-template example. | After quote review. |
| 1.4.1 | Tooling | 64 working days — source-template example. | After Gate 2. |
| 1.4.2 | Off-tool testing | 10 working days — source-template example. | After first-off-tool samples. |
| 1.4.3 | Tooling corrections | 10 working days — source-template example. | After test disposition. |
| 1.4.4 | Final verification / gauges | 5 working days — source-template example. | After corrections. |
| 1.4.5 | Final approval | 5 working days — source-template example. | After final verification. |
| 1.4.6 | Gate 3: production approval | 2 working days — source-template example. | After approval. |
| 1.5.x | BOM/QC/ERP, production, logistics and stock check | Project-specific — derived from recurring examples. | After or conditionally prepared before Gate 3, with release controlled by the gate. |
Important interpretation of the example
The example also shows that the WBS can remain stable even when durations change. That is the key value of the template: it gives the team a reliable sequence of decisions and technical outputs without pretending that every product has the same lead time.
Example gate evidence
| Gate | Evidence reviewed in this fictional example | Decision |
|---|---|---|
| Gate 1 | Approved design brief, prototype observations, cycle/functional result, open design actions, proposed supplier route. | Proceed to controlled drawings/BOM and quotation. |
| Gate 2 | Drawing/BOM revision, supplier tooling quote, lead-time trigger, first-off-tool sample assumptions, test plan. | Commit tooling and reserve test capacity. |
| Gate 3 | Off-tool results, correction closure, final verification, final approval, BOM/QC/ERP readiness. | Release production/order and complete logistics/stock checks. |
How the test register supports the worked schedule
When the project reaches the dedicated test and off-tool test activities, the detailed request should be entered in the engineering-test register. The schedule carries the forecast dependency; the register holds sample description, test type, instructions, sample readiness, test owner, forecast completion and result summary.
If the register shows “awaiting report”, the schedule test task should remain open when Gate 1 or Gate 3 requires that report. If a test is paused due to fixture or sample problems, the project forecast should be updated to reflect the real restart condition rather than leaving the old finish date in place.
How the workshop register supports the worked schedule
Prototype machining, simple fixtures, sample rework and gauge work may be handled through the workshop task register instead of adding every small shop activity as a Gantt task. The project schedule should include only the workshop work that materially controls a gate or forecast.
For example, if a test cannot start until a test fixture is made, create or maintain the workshop request with materials/drawing/CAD readiness and link the project test activity to its expected completion. If a non-critical cosmetic prototype rework does not affect the gate, it can remain operational work outside the integrated critical path.
Example change scenario
Assume the first off-tool test identifies a geometry issue. The correct response is not to extend “testing” by two weeks and continue. The project should: classify the issue, create/activate a tooling-correction task, identify the revised tool/sample configuration, repeat the affected verification and only then progress to final approval.
If the correction changes the design definition as well as the tool, the technical drawing/BOM configuration may need revision. The schedule therefore reopens the affected dependency rather than treating the correction as an isolated supplier delay. This keeps configuration, evidence and forecast aligned.
Example completion definition
- Final approved configuration is identified.
- Tooling and final verification evidence are accepted.
- BOM and quality-control information are released.
- ERP/order or equivalent production-system setup is complete.
- First production is manufactured and moved through any required logistics.
- Received stock is checked against the expected configuration.
- Outstanding actions that do not block closure are transferred to an owner and due date.
- Project actual dates and major lessons are retained for future estimating.
Related KEVOS templates
How the fictional example changes when reality changes
Assume the first working prototype fails a functional test. Do not simply add ten days to every later task. First classify the cause. If the design must change, reopen the detailed-design activity, create the next prototype/test loop and move Gate 1 because its evidence is not ready. If the test fixture is faulty, correct the fixture and repeat only the affected test. The schedule effect is different even though both situations appear initially as a “failed test”.
Now assume tooling completes on time but the off-tool samples are insufficient for the planned verification. The tooling task can remain complete; add or expose the sample-production dependency and move the off-tool test forecast. This preserves accurate supplier performance history while showing the real project delay. If an external approval is then required, represent the waiting state explicitly instead of stretching the technical verification task across the approval period.
Example close-out learning
- Compare each major stage actual duration with the estimate and capture the main cause of variance.
- Record how many meaningful prototype and tooling-correction loops occurred.
- Identify any support queue—testing, workshop, supplier, approval or logistics—that controlled the finish date.
- Retain the final approved configuration and evidence references with the project record.
- Feed repeatable lessons back into the template as planning prompts, not fixed universal durations.
The worked example should therefore be copied as a logic model, not as a calendar. A future project may complete concept work faster, require two development prototypes, have a much longer tool build or avoid freight entirely. The stable value is the sequence of evidence, decisions and handovers that makes those differences visible and manageable.