Writing the Project Initiation Document

OnceOnce you've chosen a topic (see Choosing a Final-Year Project), the next task is turning it into something a supervisor can approve, a marker can assess against, and — most usefully — something you can check your own progress against six months later. That document is the Project Initiation Document (PID). Treat it as a specification, not a formality: vague aims produce vague evaluation chapters, and a marker can only credit what you promised and then demonstrably delivered.

Aim vs Objectives: Keep Them Separate

AA project has exactly one aim — the single sentence answering "what is this project for?" — and several objectives, the concrete, checkable things you'll do to get there. Conflating them is the most common structural fault in a PID.

Making Objectives SMART

EachEach objective should survive being checked against all five SMART criteria. If it can't, it isn't ready to go in the document yet — narrow it until it can.

Present as a Numbered Hierarchy

ProseProse objectives are easy to write and hard to reference later — in supervision meetings, in your own evaluation chapter, in an examiner's annotations. A numbered hierarchy solves this: every deliverable and every metric gets a stable identifier you can point to from anywhere else in the document.

A1   Aim
     "To determine whether a lightweight caching layer can make
      X practical on resource-constrained devices."

O1   Objective: Design and implement a cache eviction strategy tuned for X.
     Metric: strategy documented; passes correctness test suite (O1.T).
     Depends on: none — this is the entry point.

O2   Objective: Benchmark the new strategy against two established
     strategies under representative workloads.
     Metric: benchmark harness produces latency/throughput/hit-rate
     for all three strategies across ≥3 workload profiles.
     Depends on: O1 (needs a working strategy to benchmark).

O3   Objective: Identify the workload conditions under which the new
     strategy wins or loses.
     Metric: written analysis with quantified crossover points,
     backed by O2's data.
     Depends on: O2 (needs benchmark data to analyse).

O4   Objective: Evaluate practical deployability on a representative
     constrained device.
     Metric: strategy runs within a defined memory/CPU budget on
     target hardware; deviation from simulated results reported.
     Depends on: O1; independent of O3 — can run in parallel.

D1   Deliverable: Working implementation of the strategy (→ satisfies O1)
D2   Deliverable: Benchmark harness and raw results (→ satisfies O2)
D3   Deliverable: Written analysis chapter (→ satisfies O3)
D4   Deliverable: Deployment report on target hardware (→ satisfies O4)
D5   Deliverable: Final report (synthesises D1–D4 against A1)

Notice the pattern: every objective (On) carries a metric, and every deliverable (Dn) points back at the objective it satisfies. The prefixes matter here as much as the numbers — a bare "2.1" collides with report section 2.1 the moment you cite the PID from inside the report itself, whereas "O1" is unambiguous wherever it appears. That back-reference is what makes the evaluation chapter easy to write later — you're not inventing evidence retroactively, you're filling in cells in a table you already built. This is the same left-to-right traceability described for report chapters in The Report as the Front-End; the PID is where that traceability starts.

Dependencies Between Deliverables

TheThe "Depends on" lines above aren't decoration — they determine your critical path. Draw them out explicitly once the hierarchy is stable:

The solid path O1 → O2 → O3 → D5 is the critical path; O4 has slack and can slip without delaying the project, as long as it finishes before D5.

A dependency graph this small does two useful things. It tells you which objective to start first (whatever has no incoming arrows), and it tells you where a delay actually costs you time versus where it's absorbable. An objective with no dependents and slack in the schedule is exactly where you should look first if you need to cut scope under time pressure — see Risk Management & Mitigation for the general version of this trade-off, and The Unstuck Ladder if you're already behind and need to decide what to descope.

From Objectives to Work Items

TheThe PID operates at the grain of objectives and deliverables — the grain a marker reads. Your actual week-to-week work happens at a finer grain: tasks, tickets, commits. The mapping between the two should be traceable in both directions.

Keep the granularity asymmetric on purpose: the PID stays stable across the whole project (renegotiate it deliberately if it changes — don't let it drift silently), while your ticket board can churn weekly as you discover what each objective actually requires. If a ticket doesn't trace back to a numbered objective, ask whether it belongs in this project at all, or whether it's scope creep of the kind Choosing a Final-Year Project warns against.

A Minimal Checklist

• One aim, one sentence, no "and" hiding a second aim inside it.
• 3–6 objectives, each SMART, each numbered.
• Every objective carries at least one explicit metric.
• Deliverables numbered and each mapped back to the objective it satisfies.
• Dependencies between deliverables drawn out, critical path identified.
• A rough schedule against your own term dates, not just "objective order."
• The whole document short enough that you'll actually re-read it at each milestone — that re-reading, not the initial drafting, is where a PID earns its keep.

OnceOnce objectives and deliverables are numbered, the next step is breaking them down into day-to-day work and tracking it — see Issue Tracking: CSGitLab and GitHub.