Scheduling and milestones
Sequence work with dependencies and clear decision points.
The idea
A project schedule relates work to time, resources, and dependencies. Milestones mark significant achievements or decisions rather than simply calendar reminders. Estimates need realistic assumptions, and progress should reflect completed outcomes. Changes in one dependent task can affect later work. Review the schedule as the team learns, and distinguish a target date from a reliably achievable commitment.
In practice
A rollout milestone requires tested recovery and trained support staff, not merely reaching the planned release day.
A common misunderstanding
A Gantt chart does not make uncertain estimates accurate or missing dependencies disappear.
Check your understanding
What makes a milestone meaningful?
Think it through: A defined outcome with evidence and an accountable owner, so completion can be objectively assessed.
Distinguish work duration from waiting time
A schedule shows when work can realistically occur, including dependencies and resource constraints. A task may take two hours of engineering but wait several days for approval. Recording only the hands-on duration creates an optimistic picture. Likewise, tasks that could run in parallel may still need sequencing when they depend on the same specialist or test environment.
A milestone marks a meaningful event such as pilot acceptance or readiness for rollout. It is not simply a task with a more impressive name. Give the milestone evidence requirements so the team can tell whether it has been reached. A planned installation date, for example, does not establish that recovery and support arrangements are ready.
A fictional certificate migration
A team plans to replace certificates on several internal services. It needs an inventory, ownership confirmation, staging tests, an approved change window, and verification after replacement. The inventory reveals a dependency on an older client. Instead of keeping the original rollout date by skipping testing, the team moves the affected service into a separate migration step and explains the impact.
This is a scheduling decision grounded in service behavior. The schedule should retain a baseline for comparison while showing the current forecast. Otherwise, quietly changing dates removes the information needed to learn whether estimates or dependencies were misunderstood. Communicate a revised forecast with its reason and the decision it requires.
Trace a small sequence
Draw six activities for enabling stronger administrator authentication. Mark which activities require another to finish and which could overlap. Add a milestone called pilot accepted, then write the evidence needed to pass it. Finally, delay an approval by three days and update the forecast. Notice that some dates move because of dependencies while unrelated preparation can continue.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
UK Government: Project Delivery Functional Standard