How to Scope an FYP Project You Can Finish
The practical way to turn an interesting topic into a final year project with a clear boundary, a testable result, and enough room to finish well.
Scope an FYP around one user problem, one difficult technical decision, and one measurable outcome. Build the risky part first, define a small version that works without optional features, and treat every extra idea as a later extension until the core result is proven.
Most FYPs become unfinishable when a topic is mistaken for a project. “AI for education” is a topic. “A revision planner that predicts which lecture concepts a student should revisit next” is a project because it names a user, a decision, and a result.
Start with one problem
Write one sentence that states who has the problem, what slows them down, and what changes if your project works. If the sentence needs “and” more than once, it probably contains more than one project.
Choose a measurable outcome
Decide how you will show progress before writing features. A campus queue system might reduce waiting time. A classifier might improve on a simple baseline. A study tool might help users complete a revision task faster. The metric can be small, but it must be honest.
Find the real hard part
Every credible project has one component that is uncertain: collecting usable data, handling a real-time constraint, ranking results, or making a model work on limited hardware. Identify it early and build a rough prototype of that component first.
Spend two weeks proving the hardest dependency exists. Do not begin with authentication, colours, or a dashboard. If the hard part cannot work in a rough form, changing the scope early is a success.
Define the minimum demonstrable version
Your first version should complete one end-to-end workflow for one user. Keep a second list called “extensions” for mobile apps, extra roles, dashboards, integrations, and features that sound good but do not prove the core claim.
Once the core version works, compare it with a baseline and document its limits. That is the difference between a feature demo and an academic project you can defend.
Use examples without copying them
Review finished work in the MyUni FYP Showcase to understand scope, technologies, and evaluation choices. If you are still comparing directions, start with FYP Ideas. Use examples to improve your planning, not to reproduce someone else’s finished application. You should be able to explain every decision in your own system.
Frequently asked questions
How big should an FYP project be?+
It should solve one clear user problem with one genuinely difficult component and a small working version you can demonstrate early. Features that do not support that result belong on a later roadmap, not in the first submission.
What is the fastest way to test whether an FYP is feasible?+
Build the riskiest technical component first. If you need a dataset, a device, an external API, or a difficult model, test that dependency before designing the dashboard or login flow.
How do I make an FYP easier to defend in a viva?+
Define a measurable claim before building: an accuracy target, time saved, response time, error rate, or user task completion result. A result with a baseline is easier to defend than a long feature list.
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.