Choosing a Final-Year Project
The hardest part of a final-year project is often the part that happens before any code exists: picking one. Students who struggle here usually aren't short of ideas — they're short of a way to compare the ideas they already have. This page offers a heuristic for that comparison, and a way of thinking about scope so the project you pick is one you can actually finish.
Start From Genuine Interest, Then Interrogate It
Pick something you're interested in" is common advice and also incomplete — interest alone doesn't survive eight months of debugging. Use interest as the starting filter, then stress-test the shortlist against the questions below before committing.
Six Questions to Ask of Any Candidate Topic
| Question | What it's really testing |
|---|---|
| Does it interest you enough to survive month six? | Motivation is a resource you spend, not a constant. A topic that's merely acceptable in week one is often abandoned in spirit by week twenty, even if the repository keeps moving. |
| What benefit does it bring, and to whom? | "Interesting to me" and "useful to someone" are different properties. A project with a clear beneficiary — a user, a research question, a practical gap — gives you a north star when design decisions get ambiguous. |
| Does it match a possible supervisor's interests? | A supervisor who is already curious about your domain will give sharper feedback, faster, than one indulging a topic outside their expertise. Read staff research pages before you fix on an idea, not after. |
| Does it showcase your skillset in the CS domain? | The project is also a portfolio piece. A topic that only exercises one narrow skill (however well) tells an examiner or future employer less than one that demonstrates range: design, implementation, evaluation, communication. |
| Is it topical and timely, or stale? | A well-scoped contribution to a live area ages better than a competent retread of a solved problem — but see the caution below before chasing this too hard. |
| Is it trendy for a reason, or just trendy? | Novelty is not the same as merit. Choosing a hot topic because it's hot, with no specific question you want it to answer, produces a project that's fashionable and empty. Choose it because the fashionable area happens to contain a real, answerable question. |
The Old-Problem / Trendy-Topic Trap, Both Directions
Two failure modes sit at opposite ends of the same axis, and both are common enough to name directly:
- Tackling an old, solved problem with no new angle. Reimplementing a well-known algorithm or system with nothing added — no new constraint, no new evaluation, no new context — gives an examiner little to assess beyond whether you can follow a tutorial. If the problem is old, your contribution needs to be new: a different context, a rigorous comparison, an application nobody has tried.
- Chasing a trend with no specific question. "I'll do something with [current buzzword]" is not a project, it's a vibe. If you can't state, in one sentence, what you want to find out or build and why it matters, the trendiness of the surrounding field won't rescue the write-up.
The productive middle ground is a genuine question — even a modest one — situated in an area you understand well enough to defend your choices. See Risk Management & Mitigation for how to reason about the risk profile of a topic once you've shortlisted it.
A Decision Heuristic
Work through candidates in this order — each stage is a filter, not a scoring system, so a topic that fails a stage is out regardless of how well it does on the others:
question/benefit in
one sentence?"} C -- "No" --> C1["Not yet ready — narrow it first"] C -- "Yes" --> D{"Fits a plausible
supervisor's expertise?"} D -- "No" --> D1["Find a different angle,
or a different supervisor"] D -- "Yes" --> E{"Old problem: genuinely new angle?
Trendy problem: a real question,
not just the label?"} E -- "No" --> E1["Reframe or discard"] E -- "Yes" --> F{"Showcases range —
design + build + evaluation?"} F -- "No" --> F1["Broaden the scope"] F -- "Yes" --> G{"Scoped to what one
person can finish and
defend in the time available?"} G -- "No" --> G1["Cut scope — see below"] G -- "Yes" --> H["Proceed — write it up as a
Project Initiation Document"]
Sizing the Project: Domain and Scale
Once a topic survives the filter above, the remaining risk is almost always scope, not idea quality. Two axes matter:
| Axis | Under-scoped | Well-scoped | Over-scoped |
|---|---|---|---|
| Domain breadth | Trivial — a working prototype exists as a library call | One clear system with a defined boundary and a small number of deliberately excluded extensions | "And also" creeping in every planning conversation — the boundary keeps moving outward |
| Technical depth | No decision in the project required real engineering judgement | A handful of genuinely hard problems, each traceable to a design decision you can defend | Every subsystem is a research problem in its own right; nothing has time to be finished properly |
A useful test: can you describe, today, the thing that will not be in the final system? If every version of the description is "everything, eventually," the scope isn't fixed yet, and it should be before you commit real time.
The Hourglass Cycle: Broaden, Then Narrow, Repeat
Scoping is rarely a single decision — it's a rhythm. Each pass through the search space has the shape of an hourglass: you deliberately widen out ("and also...", "what about...", "there's a related approach that...") to make sure you're not narrowing prematurely onto the first idea you had, then you deliberately squeeze back down to a single committed thread before the widening turns into scope creep. Do this once and you've made one good decision. Do it two or three times, each cycle narrower than the last, and you've triangulated your way to a topic you actually understand — see Project Navigation & Triangulation for the same widen/fix pattern applied to staying oriented once the project is under way.
(explore adjacent approaches,
related literature)"] N1["Narrow
(pick the most promising thread,
discard the rest deliberately)"] B2["Broaden again
(within the narrowed thread —
smaller search space this time)"] N2["Narrow again
(commit to a scope for this phase)"] Q{"Time and velocity allow
another cycle?"} F["Fix scope.
Write the Project Initiation Document"] S["Initial idea"] S --> B1 B1 --> N1 N1 --> B2 B2 --> N2 N2 --> Q Q -- "Yes, plenty of runway" --> B1 Q -- "No — deadline pressure,
or this cycle changed little" --> F
Two things govern how many cycles are worth running:
- Duration. A one-term project can typically afford one full cycle and the start of a second before it needs to fix scope; a full-year project can usually justify two or three, provided each one is visibly narrower than the last rather than re-litigating the same breadth.
- Velocity. If a broaden/narrow cycle changes almost nothing — you widen, look around, and narrow straight back to where you started — that's a signal you've converged and further cycling just spends time. If a cycle keeps turning up genuinely new candidate directions, you haven't converged yet and another pass is worth the time, even under some deadline pressure.
The failure mode to watch for is a cycle that only ever broadens. If "and also" keeps adding branches and nothing gets deliberately discarded at the narrow end, you're not triangulating — you're accumulating scope, and the over-scoped column in the sizing table above is where that ends up. The hourglass only works if the waist actually narrows each time.
Where This Leads
A chosen topic is not yet a project — it becomes one once it has aims, objectives, and criteria you can be marked against. See Writing the Project Initiation Document for how to turn the topic this page helped you choose into a structured specification, and The Report as the Front-End for why that specification should be written before the code, not reconstructed after it.