Build a project timeline around dependencies, not just dates
Plan an academic project using prerequisites, elapsed time and milestones, with an original fictional dependency ledger.
About 5 min read · Allow extra time for the practical checks
Start with the required outputs and deadline, identify what each task needs before it can proceed, and then test whether the work fits the time available. A calendar filled with attractive dates is not a feasible plan if one missing decision prevents several later tasks from starting.
Use your programme’s actual requirements and any agreed project scope. This guide concerns planning and revising a small academic project’s schedule; it does not authorise research activity, determine an approval process or prescribe a standard dissertation duration.
Name the outputs before placing the dates
Write down the things you need to produce and what would count as each being ready for its next use. “Work on project” is difficult to schedule because it hides several different jobs. A checked reading collection, a draft comparison and a revised report can each need different inputs and completion checks.
If the output itself is still too broad, use the capstone scope guide first. A schedule helps you arrange agreed work; it cannot make an oversized project feasible merely by allocating fewer days to it.
Break larger outputs into tasks small enough to estimate and monitor. Include checking, discussion, revision and final submission preparation as appropriate. Do not assume that drafting the final section means the whole submission is ready.
Identify what must happen first
Memorial University of Newfoundland’s research project scheduling guidance connects task sequence with dependencies, external constraints and milestones. Use that principle to distinguish a necessary prerequisite from a convenient preferred order.
Ask what information, material or decision each task requires. Does a comparison need the complete set of documents? Does final revision depend on an agreed interpretation of feedback? Which tasks could proceed while you wait, and which would create avoidable rework if started too early?
Record uncertain prerequisites explicitly. A requested meeting is not a completed decision, and anticipated access is not confirmed access. Follow the applicable rules where permissions or approvals are required; a date in your plan does not grant them.
Test one fictional dependency chain
The project, documents and review arrangements below are entirely invented teaching material. They do not describe an actual institution, approval or commitment.
Imagine a small project comparing the information on two fictional exhibition catalogues. The agreed output is a comparison report. The writer has one catalogue and is waiting for the second. A tutor has agreed to discuss a draft comparison, but no meeting time has been confirmed.
| Fictional task | What it needs | What the writer can honestly plan |
|---|---|---|
| Record the first catalogue’s relevant details | The available catalogue and agreed comparison criteria | Begin this task now and mark the second catalogue as outstanding |
| Complete the two-catalogue comparison | Both catalogues checked against the same criteria | Keep completion conditional on obtaining and checking the second catalogue |
| Discuss the draft interpretation | A usable comparison and a confirmed discussion arrangement | Ask about availability without treating a proposed slot as guaranteed |
| Revise and prepare the report | Checked comparison, relevant feedback and submission requirements | Protect time for revision and final checks after the necessary inputs arrive |
The second catalogue’s delay affects the comparison and may affect the discussion. It need not prevent every useful action: the writer could check the first catalogue, organise notes and prepare a question about the missing material. Those tasks must remain distinct from claiming that the comparison is complete.
If the second catalogue cannot be obtained in time, the writer needs a scope discussion. Silently replacing the agreed comparison with a one-catalogue description would change the task. A smaller alternative requires whatever agreement the actual course or project demands.
Estimate effort and elapsed time separately
A task might require a short period of your work but depend on someone else’s availability over several days. Record both the work you need to do and the waiting that affects when the next task can start. Avoid treating an external response time as something you control.
The University of Exeter’s project time-planning guidance recommends breaking tasks down, estimating duration, allowing contingency and working back from the submission date. Use your own requirements and capacity rather than copying its illustrative durations or dates.
Place necessary tasks against the actual deadline and check clashes with other commitments. Leave room for uncertainty in proportion to the work. A contingency allowance is not proof that a delay will be manageable; it makes the assumption visible so you can reassess it.
Use milestones that show a change in readiness
A milestone should tell you something useful about progress, such as having a checked comparison ready for discussion. “Spend a week reading” describes elapsed time without establishing what material is ready. Choose completion checks that support the next decision or task.
A table, calendar or Gantt chart can display the plan. Use a format you can maintain; specialised software is not required. Keep the dependencies visible alongside dates so that a shifted task does not leave an apparently unchanged but impossible schedule.
Revise the plan when an assumption changes
When an input is late, check the tasks depending on it before moving every date by the same amount. Identify what can still proceed, what now needs a decision and whether the final output remains feasible. Keep a brief note of important changes and why you made them.
Take unresolved consequences to the appropriate supervisor or project contact while there is still time to decide. Use a focused supervision note to explain the completed work, dependency and decision needed. Report the actual state of the project; do not mark a milestone complete because its planned date has arrived.
