KEVOS · Templates & Examples · Project Templates
Development and Prototype Testing Schedule Template
A detailed project schedule template for CAD development, working prototypes, verification testing, iteration and design approval.
Executive summary
The development stage in the supplied schedules consistently converts an approved concept into a detailed design and a working prototype. The recurring pattern is detailed CAD plus CNC or equivalent prototyping, testing, prototype review and a formal design/supplier-selection gate. Some examples include a second prototype loop; the blank template also includes a dedicated cycle-test activity before prototype review.
Development-stage purpose
Detailed development is where geometry, interfaces and manufacturing intent become controlled enough to support tooling and supplier commitment. The source schedules place this stage after prototype approval and before technical drawings/BOM and tooling quotation. That sequence is important: the project should not seek final tooling commitment while the product definition is still being fundamentally explored.
The stage is best viewed as a controlled learning loop. The design is detailed, a representative prototype is produced, verification reveals gaps, the design is reviewed, and the project either loops through another prototype or proceeds to a gate.
Recurring schedule pattern
| Task | Schedule intent | Exit evidence |
|---|---|---|
| Detailed CAD + working prototype + testing | Combine design maturation with a representative physical test article. | Controlled model/revision, prototype build record, test observations. |
| Dedicated cycle testing (blank template variant) | Run a longer verification activity before stakeholder review. | Test status/results and any resulting corrective actions. |
| Prototype review | Assess fit, function, failure modes, manufacturability and unresolved deviations. | Review decision and action list. |
| Second prototype (where required) | Close material issues found in the first iteration. | Updated design and verification of corrected features. |
| CAD approval and supplier selection gate | Freeze enough definition to prepare drawings/BOM and obtain tooling quotation. | Approval record, selected supply route or authorised quotation process. |
How to decide whether a second prototype is needed
Three source examples explicitly show a second-prototype activity or second-prototype approval. Most examples do not. This means a second prototype should be treated as a conditional branch, not a mandatory fixed task for every project.
| Condition after first prototype | Recommended schedule response |
|---|---|
| No material design change required | Proceed to the design/supplier gate after the planned review. |
| Minor corrections that can be verified analytically or through local rework | Record corrective actions and decide whether full prototype repetition is necessary. |
| Geometry, load path, interface or functional behaviour changes materially | Insert a second prototype and verification task before the gate. |
| The prototype failed because the test method or fixture was inadequate | Correct the verification method and repeat the relevant test; do not redesign the product solely to fit a faulty test. |
| External requirement changes | Re-open the affected design decisions and update the WBS if the scope change is substantial. |
Link the test register to the schedule
The supplied engineering-test workbook contains separate fields for test status, priority, test type, sample availability, test details, start/forecast/completion dates and results. This is useful because a project schedule should not try to hold every test detail inside a single task name. Instead, the schedule can carry a task such as “cycle testing” while the test register holds the method, samples, result summary and laboratory workflow.
For schedule control, the key integration fields are the test request identifier, current test status, sample readiness, forecast completion and result disposition. The schedule activity should not be marked complete merely because a sample was delivered; completion should align to receipt and review of the evidence required by the project gate.
Design-development readiness checklist
- The concept-stage approval decision is recorded and open actions have owners.
- The detailed model has a controlled revision or otherwise identifiable configuration.
- Prototype manufacturing method is appropriate to the design question being tested.
- Test samples represent the intended configuration closely enough for the stated verification purpose.
- Required test requests are raised and their dependencies are linked to the development forecast.
- Prototype review records distinguish design failures from test-rig, sample or setup problems.
- Supplier-selection assumptions are documented before the gate.
- A second-prototype branch is added only when the evidence requires it.
- The gate decision clearly states whether the design is ready for drawings, BOM and tooling quotation.
Example dependency logic
The bracketed tasks are conditional. In a scheduling tool, use logic that reflects the actual technical dependency rather than forcing every project through identical dates. If testing can start on an early prototype while another detail is still being refined, document that concurrency and the configuration under test.
Related KEVOS templates
Controlling prototype iterations without losing configuration history
Prototype work becomes difficult to schedule when several physical versions exist but the plan uses one generic “prototype” task. Give each meaningful iteration a simple configuration identity and link its test result to that identity. The configuration may be a drawing revision, model revision, build number or another locally controlled reference. The important point is that a failed test can be traced to the exact design that was tested.
When a second prototype is required, add it as a deliberate loop rather than silently extending the first task. State the problem that triggered the iteration, the change made and the evidence required to close it. This keeps the development forecast readable and shows management why an extra cycle is necessary. Conversely, do not create a second build simply because a previous project had one; if the first working prototype provides adequate evidence, proceed to the design/supplier gate.
Development review agenda
- Confirm the latest model/drawing configuration and list material or process assumptions.
- Review test evidence against the intended function, not merely whether the prototype “worked”.
- Classify issues as design, prototype-manufacturing, test-method, material, interface or requirement problems.
- Decide which issues must close before Gate 1 and which can be controlled as later actions.
- Confirm whether technical drawings and BOM preparation can start or whether another design loop is required.
The schedule should also make test-resource constraints visible. If a test rig, workshop job, sample quantity or external resource is required, link that dependency before the test task. A prototype sitting in a queue is not technical progress. Separating readiness from test execution improves forecast accuracy and makes support-resource bottlenecks visible early.
Handover into drawing and BOM release
Before development is declared complete, reconcile the physical prototype with the design record that will be used downstream. Prototype parts are often hand-fitted, modified or manufactured by a temporary process. Note any deviation that must not be copied into production, confirm the intended material and interfaces, and ensure the drawing/BOM package reflects the approved design rather than the accident of how the prototype was made. This short reconciliation protects tooling quotation from being based on an ambiguous prototype.