Last updated: 2026-10-06

U
Undergraduate level

Planning, Milestones, and Time

A project plan is a set of dated decisions about what will be finished when, and what will be checked before the next step begins. It is not a chart to be drawn once and filed. Students who keep a plan current tend to notice slippage in the first week of it. Students who draw a plan and then stop using it tend to notice in the final fortnight.milestones: real gates, not just calendar dates

This page covers how to break the work down, how to set milestones that mean something, how to estimate and track time, and how to choose a way of working that suits a project of this size. The scope that a plan delivers is set out in Scope, Feasibility, and Defining Success. The risks that threaten it are covered in Risk Analysis for a Project.

Breaking the Work Down

Start by listing the deliverables the project must produce, not the activities. "Literature review", "prototype of the data pipeline", and "evaluation results with confidence intervals" are deliverables. "Work on the project" is not. Once the deliverables are listed, break each one into pieces that take a few days each, and arrange them as a tree. This is the work breakdown structure, described in Work Breakdown Structure.see the dedicated page for tree-building tips

The tree is useful for two things. It shows which pieces must be finished before others can start, which is the basis of the schedule. It also shows where a single unexpected problem could hold up several deliverables at once. Pieces that feed many others are where planning effort should go.

Sequencing and the Critical Path

Once dependencies are clear, the sequence of dependent tasks that determines the earliest finish date is the critical path. Any delay on it delays the project. Work that is not on the critical path has slack, which is time you can lose without moving the end date. Knowing which work has slack tells you where to spend an unexpected free week.

The method is set out in Critical Path Method and PERT. For a student project the arithmetic is rarely the hard part. The hard part is being honest with yourself about which tasks depend on a supervisor's reply, a dataset, or an assessment deadline in another module. Those are the tasks most likely to sit on your critical path without you noticing.formal name for the arithmetic you skip

The schedule can be shown as a Gantt chart, which makes the timing visible to a supervisor and to you. The chart is described in Gantt Charts.

Milestones That Mean Something

A milestone is a point where a defined deliverable is complete and has been checked. It is not a date on which you intend to have done a lot of work. The difference matters. "End of week 6: literature review" can be checked. "End of week 6: make good progress" cannot.

Set milestones at the points where a wrong direction would be most expensive to discover. For most projects that means:

  • after the question and success criteria are agreed,
  • after the first working version of the core artefact or method,
  • after the first results, before the evaluation is designed in detail,
  • and a final review against the success criteria, with time left to act on it.
Leave slack before the last milestone. A project that reaches its final milestone with no time to act on the review will write up what happened rather than what was intended.

Estimating and Tracking Time

Estimates for student work are usually too optimistic, and the usual error is to leave out the work that is not the main task: setting up the environment, rereading earlier decisions, writing the report as you go, and recovering from mistakes. A practical correction is to estimate each task, then compare the estimate with what it actually took, and use that record for the next estimate. The method and its pitfalls are discussed in Estimating Effort and Time.

Track time against deliverables, not hours. A week in which you spent twenty hours and produced nothing you can check is a warning. A week in which you spent eight hours and completed a milestone is a success. The discovery log described in Project Navigation and the Art of Triangulation is a convenient place to record both.log the guess and the actual side by side

Choosing a Way of Working

Agile methods were designed for teams delivering software to customers, and their ceremonies do not all suit a single student. The useful parts for a project are short iterations, a visible list of remaining work, and a regular review of what has changed. The origins and practices are covered in Agile: Origins and the Manifesto and Scrum, and a flow-based alternative is in Kanban.

A short fixed iteration, such as one or two weeks, with a written goal for each, is often enough. A waterfall-style plan with fixed milestones suits a project whose method is well established and whose data arrives on a known schedule. Most projects are a mix. The question of fit is discussed in Choosing a Methodology.

Reviewing the Plan

Set a fixed weekly time, perhaps fifteen minutes, to compare the plan with what has happened. Move the milestones that have slipped, note why, and check whether the slip has moved the critical path. A plan that is reviewed weekly stays a plan. One that is not reviewed becomes a record of intentions.