KEVOS · Templates & Examples · Frameworks
Project Schedule Dependencies and Stage Gates
A practical framework for predecessor logic, three product-development stage gates, milestones and controlled concurrent scheduling.
Executive summary
The project schedules use predecessor links to connect technical tasks and three recurring approval meetings to control movement from design into tooling and then production. This page converts those patterns into a dependency-and-stage-gate framework. It also explains a source variation where two projects use many zero-duration milestones rather than effort-based early tasks.
Dependency logic is the schedule
Dates show when a plan currently forecasts work; dependencies explain why. The blank schedule contains a mostly sequential chain of finish-to-start relationships from design brief through the final production gate. Many project examples preserve that logic, although some historical schedules contain intentional or accidental overlap.
For a reusable template, build logic around technical prerequisites. A task should have a predecessor because the predecessor produces information, a decision, a sample, a tool or another condition needed to begin—not simply because the team usually does the activities in that order.
Core dependency chain
This is the dominant chain supported by the blank template and repeated project examples. Optional branches such as a second prototype, extra sample request, freight or launch should be inserted only when the project requires them.
The three recurring gates
| Gate | Position in source schedules | Decision being controlled | Evidence examples |
|---|---|---|---|
| Gate 1 — design / supplier path | After prototype review and before drawings/BOM for tooling quotation. | Is the design direction mature enough to prepare the manufacturing package and select/confirm the supply path? | Prototype review, controlled design, test evidence, open-action list. |
| Gate 2 — tooling / testing plan | After tooling quotation review and before tooling manufacture. | Is the technical/commercial tooling commitment authorised and is the test approach ready? | Drawing/BOM revision, reviewed quote, lead-time assumptions, test plan, approval record. |
| Gate 3 — production | After final testing/approval and before production release. | Is the product/tooling evidence sufficient to enter controlled production and handover? | Final test results, correction closure, approval, BOM/quality/ERP readiness status. |
Gate criteria should be evidence-based
The source schedules provide gate names but do not provide formal acceptance criteria. Therefore, the criteria above and below are implementation guidance. The key principle is that a gate should reference evidence and decision authority. A meeting duration by itself does not prove the gate has been passed.
A gate can be passed, passed with conditions, held or rejected. If passed with conditions, those actions should remain visible and linked to the relevant downstream work. Do not mark the gate complete and then store material conditions only in meeting minutes that the schedule cannot see.
Milestones versus work tasks
Two source schedules convert many early activities into zero-duration milestones. This can be useful when the actual effort is managed in another system and the project schedule is intended to record only key events. It is not suitable when the schedule must forecast engineering capacity or represent the time consumed by design, testing or quotation work.
Choose the modelling style deliberately. A milestone answers “when did/should this event occur?” A duration task answers “how long does the work or waiting period take?” If a design brief is a milestone, another task or system must still account for the work of creating the brief if resource planning matters.
| Use a milestone when… | Use a duration task when… |
|---|---|
| The event is instantaneous for planning purposes: approval granted, sample received, purchase order released. | The activity consumes measurable working time or waiting time that affects forecast completion. |
| The work is tracked elsewhere and the integrated schedule only needs the event date. | The project schedule is the primary plan for the work. |
| You need a clear reporting checkpoint without inflating the WBS. | You need progress, remaining duration or resource/capacity visibility. |
Handling deliberate concurrency
Several historical schedules show phases or tasks overlapping. Overlap is not automatically wrong; concurrent engineering can reduce elapsed time. The control question is whether the later task has enough stable input to begin without creating unacceptable rework risk.
If tooling quotation begins before all prototype review is complete, identify the quoted revision and the assumptions that may still change. If ERP preparation begins before final approval, separate “prepare item data” from “release order”. This keeps useful parallel work without falsely indicating that the downstream commitment is already authorised.
Dependency quality checks
- Every leaf task that requires a prior deliverable has an explicit predecessor or documented external trigger.
- Summary tasks are not used as substitutes for detailed predecessor logic.
- Approval gates have identifiable inputs and an accountable decision.
- Conditional branches such as second prototype or correction/retest are visible when activated.
- Milestones represent events; effort tasks represent work or meaningful waiting time.
- Concurrency is intentional and the configuration/assumptions under which it is allowed are recorded.
- The final project finish is driven by the actual completion objective, such as approved tooling or verified stock, not by an arbitrary date.
Related KEVOS templates
Building a dependency audit before committing the schedule
A dependency audit is a practical way to test whether a schedule represents real work rather than a sequence of preferred dates. Read each task from left to right and ask what must physically or decisively exist before it can start. For a test, this may be a sample, approved method and available rig. For tooling, it may be design approval and commercial authorisation. For production, it may be an approved configuration and released order. If the answer is missing from the plan, add the predecessor, an external dependency or an explicit assumption.
Then review the stage gates in the opposite direction. Ask what evidence the next stage depends on receiving from the gate. This catches weak gates that merely say “meeting” without a decision. A gate should produce a controlled outcome—proceed, proceed with conditions, hold, rework or stop—and the downstream schedule should respond to that outcome.
Dependency-audit checklist
- No technical activity starts before its required input exists.
- Waiting for a supplier, customer, sample, test resource or approval is visible as a dependency or hold state.
- Milestones represent decisions/events and do not conceal actual effort.
- Gate outputs are recorded and conditional actions have owners and due dates.
- Parallel work is intentional and does not rely on an unapproved configuration without acknowledging the risk.
- The final completion milestone depends on the true operational objective, not merely the last internal task.
Repeat the audit after major changes. A revised design, supplier change, failed test or delayed sample can invalidate relationships that were correct at baseline. Maintaining dependency logic is what allows the schedule to reforecast intelligently instead of requiring manual date editing across dozens of tasks.