How to Choose Your Final Year Project Topic
Topic choice is the single decision that most determines whether your FYP finishes. Here is a process for making it deliberately instead of by enthusiasm.
Choose an FYP topic by scoring your candidates on feasibility rather than interest alone. The topic you can finish is one where you already have the data, you can name the hardest component, you can measure success with a number, and a supervisor is genuinely engaged. Interest fades around week six, so build the choice on constraints that do not.
Every semester, a predictable group of projects stalls. They are not the least ambitious ones. They are the ones where a decision was never really made, so the student drifted for six weeks before discovering the data did not exist.
This is a process for deciding properly. It takes an afternoon and it saves a semester.
The four constraints that decide everything
Enthusiasm is real but it decays. Constraints do not. Score every candidate topic against these four, and let the scores start the conversation rather than end it.
One: data or inputs you have today
Not data you could request. Not data a hospital might share. Data sitting on your laptop or in a public repository you have already downloaded. If access depends on another person's reply, it is a risk, and risks in semester one become cancellations in semester two.
Two: a named hard component
Every good project has one piece that is genuinely difficult. A face recognition pipeline. A scheduling algorithm. A latency budget. If you cannot name it, you do not yet understand your own project, and you will discover the hard part at the worst possible time.
Three: a measurable outcome
Something you can put in a results chapter as a number. Accuracy, latency, throughput, error rate, or the result of a small user study. Projects that can only demonstrate features are much harder to defend because there is nothing to evaluate.
Four: an engaged supervisor
This is the constraint students underrate most. A supervisor who finds your topic interesting will read your drafts, suggest papers, and open doors to data. One who does not will sign your forms. That difference shows up in your final grade.
Bring three candidates, not one. Presenting three shows you have done the work and it gives them something to react to. If they push back hard on one, that is useful information, and it costs you nothing because you have two others ready.
Scoring your shortlist
Give each candidate a score out of five on all four constraints. Twenty is the maximum. Be honest rather than generous, because the score is for you.
| Constraint | Score 1 | Score 5 |
|---|---|---|
| Data access | Depends on someone replying | Already downloaded |
| Hard component | Cannot name it | Identified and understood |
| Measurable result | Feature demo only | Clear numeric metric |
| Supervisor interest | Indifferent | Actively engaged |
A topic scoring 18 or above is a green light. Between 13 and 17 needs one weakness fixed before you start, usually data access. Below 13, pick something else regardless of how much you like the idea.
Four warning signs
These appear in almost every project that stalls. Treat each one as a prompt to stop and reconsider.
The feature list is longer than a page. Long lists are a sign that the student is describing an app rather than a project. Two or three core features plus one hard component is a finished FYP.
The word platform, without a specific user. Building a platform for everyone means building for no one, and it makes evaluation impossible. Name the user. First year students in one department. One hospital ward. One campus.
You cannot explain it to a non specialist in one minute. If it takes ten minutes and three diagrams before the idea makes sense, the scope is not clear in your own head yet.
It depends on a single unreleased technology. If the project only works once a specific API or device ships, you have made your graduation conditional on someone else's roadmap.
A topic that is new but unmeasurable is worse than a topic that is familiar but well evaluated. Committees reward rigour far more often than they reward novelty.
After you have chosen
A chosen topic is not yet a project. The next step is writing it down in a form your supervisor can critique, which is what the proposal is for. Keep the scope you just agreed, and resist the urge to expand it the moment you start writing.
One more thing worth doing early: look at how previous students in your department scoped similar work. The MyUni showcase has real examples across attendance systems, recommendation engines, and detection tools. Seeing a finished version of a similar idea is the fastest way to calibrate your own scope.
Frequently asked questions
Should I choose my own FYP topic or take one from my supervisor?+
Take the supervisor's suggestion when they offer a specific one. A supervisor who proposes a topic already knows the data exists, has seen similar projects, and will stay engaged. Choosing your own is fine when it is genuinely your idea and you can still find an interested supervisor. The worst outcome is neither: your own idea plus a supervisor who is indifferent.
How do I know if my FYP scope is too big?+
If your feature list would take a professional team six months, it is too big for two semesters of part time work. A reliable test is to write the list, then cut it in half twice. What remains after two cuts is usually the right scope.
What should I do if two students want the same topic?+
Split it into two distinct problems rather than two halves of one system. Two students building a frontend and a backend for the same app gives neither a complete project. Two students building a recommender and an evaluation framework for the same domain gives both something to defend.
Is it a problem if my FYP topic has been done before?+
Only if you repeat it exactly. Nearly every topic has been attempted. What matters is that your version has a specific constraint, dataset, or deployment target that makes it yours. Reusing a direction with a new dataset and an honest evaluation is normal academic practice.
Start your project on MyUni
Browse notes from Operating Systems, Machine Learning, Computer Vision and more, or publish your own work to the project showcase so the next batch can learn from it.