KEVOS · Templates & Examples · Project Templates
Rapid Conceptualisation Schedule Template
A reusable rapid-concept schedule covering design brief, rough modelling, prototyping, testing and the preliminary approval gate.
Executive summary
Rapid conceptualisation is the first recurring stage in every anonymised project schedule. The sources consistently break it into a design brief, rapid modelling or rough design, physical prototyping and testing, followed by prototype approval or a preliminary business-case decision. The purpose of this stage is not to finish the design; it is to reduce enough uncertainty to justify detailed development.
What the stage is designed to achieve
The conceptualisation stage converts an opportunity, request or technical problem into a testable product direction. In the supplied schedules it is deliberately short in structure—only three recurring leaf activities—but the elapsed duration varies widely across the examples. That variation matters: it shows that the WBS is stable even when the commercial urgency, technical difficulty, stakeholder response or project hold periods are not.
A good concept stage therefore protects the structure while allowing the estimates to change. The team should be able to explain what question each activity answers and what evidence allows the project to leave the stage.
Three-task concept sequence
| Activity | Questions it should answer | Typical evidence |
|---|---|---|
| Design brief | What problem is being solved? What is in and out of scope? What interfaces or constraints are already known? | Approved brief, marked-up requirements, interface notes, key assumptions. |
| Rapid modelling / rough design | Can the concept physically fit, move, assemble or demonstrate the intended principle? | Rough CAD, 3D print, simple machined mock-up, photos/measurements, concept test notes. |
| Prototype approval / preliminary business case | Is there enough technical and commercial confidence to invest in detailed development? | Concept review decision, actions, estimated next-stage effort, major risk summary. |
Building the design brief
The source schedules name “Design Brief” as the first executable task. They do not prescribe the content of that brief, so the following is KEVOS implementation guidance rather than a source requirement. A useful brief should be compact enough to be reviewed quickly but structured enough to prevent the prototype from becoming an uncontrolled experiment.
- Problem statement: describe the user, manufacturing or reliability issue in observable terms.
- Functional intent: state what the product or component must do without prematurely prescribing the final geometry.
- Interfaces: record mating parts, envelope, fixing, movement, load path, assembly sequence or system dependencies that could invalidate a concept.
- Evidence target: define what the rapid prototype needs to prove—for example fit, motion, access, assembly, basic force response or user interaction.
- Known constraints: material family, process route, existing tooling, supply constraints, cost boundary or timing assumptions, but only where they are genuinely known.
- Open questions: make uncertainty explicit so it can be closed intentionally during rapid modelling.
Prototype with a question, not just a shape
The schedule examples repeatedly combine rapid modelling, 3D printing and testing in one activity. That wording suggests an iterative loop rather than a single “make a model” task. A prototype is useful only when it is linked to a decision. If the question is fit, the prototype needs representative interfaces. If the question is motion, the degrees of freedom and hard stops matter. If the question is assembly, access and fastening sequence matter.
The concept prototype should not be over-engineered. Detailed tolerancing, production finish and fully representative material may be unnecessary if they do not affect the question being tested. Conversely, a low-fidelity prototype is misleading when stiffness, friction, temperature, wear or load path is central to the concept.
Concept review decision rule
| Decision | Use when | Next action |
|---|---|---|
| Proceed | The concept demonstrates the intended principle and no known issue invalidates detailed development. | Authorise detailed CAD, working prototype and planned verification. |
| Proceed with actions | The concept is viable but specific risks or information gaps must be closed during development. | Record owners and deadlines for the open items in the development plan. |
| Rework concept | The idea is promising but the prototype does not yet demonstrate a critical function or interface. | Return to rapid modelling with a defined question. |
| Hold | External commitment, resources or a prerequisite decision is missing. | Set an explicit hold reason and review trigger rather than extending durations indefinitely. |
| Stop | The evidence does not support further investment. | Close the schedule and capture the technical reason for the decision. |
Scheduling guidance
The blank template provides example durations for the brief, rough design/prototype and approval tasks. Those values are examples only. The fifteen project schedules show that conceptualisation can be compressed, extended or interrupted substantially. Use the current work content to estimate each task and treat waiting time separately from engineering effort.
When the concept task is held for stakeholder input, preserve the planned effort but update the forecast and hold reason. This prevents future teams from incorrectly assuming that a long historical concept-stage duration means the engineering work itself required that many months.
Related KEVOS templates
Running the concept stage as a short evidence cycle
The concept stage works best when it produces just enough evidence to support the next investment decision. The recurring source sequence—brief, rough design/rapid prototype, then approval or preliminary business case—can be run as a compact learning loop. At the start, write down the uncertainty that the concept is intended to reduce. Examples include fit, motion, basic strength behaviour, manufacturability, user interaction or commercial viability. The prototype method should then be selected to answer that uncertainty rather than to resemble final production unnecessarily.
At concept review, separate observations from decisions. Record what was physically tested or reviewed, what was learned, what remains uncertain and what decision is requested. If the concept is rejected, retain the reason so a later team does not unknowingly repeat the same path. If it is approved, convert unresolved issues into development tasks or risks rather than pretending the concept has proven everything.
Concept handover pack
- Approved or current design brief and scope boundaries.
- Images, sketches or model references for the selected concept.
- Prototype/test notes with the specific question each activity answered.
- Known limitations and assumptions that remain to be verified during development.
- Preliminary cost, supplier, tooling or business considerations where these influence feasibility.
- A clear approval decision and the actions required before detailed design can begin.
This approach also helps control schedule creep. New ideas discovered during concept work should be screened against the brief. A genuinely better concept may justify changing scope, but the effect on time, cost and downstream work should be visible. The template is therefore both a scheduling tool and a decision record: it keeps rapid experimentation connected to an explicit project objective.