How to choose and plan your final-year project (and keep it yours)

Your final-year project (FYP) is usually the largest piece of work in a Computer Science, Software Engineering or IT degree, and the one employers ask about. Most projects that go badly do so for the same reasons: the idea was too big, the technology was new to everyone, or the planning started too late. All three are decided in the first few weeks.

Five tests for an FYP idea

Before you fall in love with an idea, put it through these five questions. If it fails two or more, change it or cut it down.

1. Does it solve a real problem for a real user? "A system for students" is vague. "Helping a department's students swap lab slots without emailing the coordinator" is a project. A real user gives you requirements, test cases and a strong viva answer.
2. Can your group build it in the time you have? Count the weeks, subtract exams and holidays, and be honest about everyone's skills.
3. Is the data available? Machine learning projects fail more often on data than on code. If you need a dataset, find it, open it and check its licence before you propose.
4. Is there something for you to work out? Your department will expect more than forms on top of a database: an algorithm, an integration, an evaluation, a design decision you can defend.
5. Will your supervisor support it? Read your department's guidelines and past project titles, and discuss the idea early. A supervisor who understands the area can help you far more.

Cut it to a size you can finish

Write your idea as a list of features, then sort them into three groups:

• Must have: the smallest version that solves the problem from start to finish. This is what you commit to in your proposal.
• Should have: features that make it clearly better. Plan them, but treat them as the second half of the year.
• Nice to have: everything else. Write them down as future work for your report, and leave them there.

A complete, tested "must have" version is worth more than an ambitious system that half works on demo day.

Choose technology you can explain

Pick a stack where at least one person in the group already knows the main language, and where good documentation exists. Every choice needs a reason you can give in your viva: "we used PostgreSQL because our data is relational and we need transactions" is an answer; "it was popular" is not. If the project needs a technique that is new to you, such as a data structure or algorithm you have not used, plan time to learn it properly before you build on it.

What a proposal usually contains

Always follow your department's template. Most proposals cover the same ground:

1. Problem statement: who has the problem and why it matters
2. Objectives: three to five measurable goals
3. Scope: what is included, and what is explicitly not
4. Related work: existing solutions and how yours differs, with references
5. Proposed approach: architecture, main components and technology
6. Evaluation: how you will show that it works (tests, users, metrics)
7. Timeline: milestones with dates, and who does what
8. Risks: what could go wrong, and your plan if it does

A two-semester plan

Departments differ, so match this to your own deadlines. The principle is the same everywhere: design early, build in small working steps, and leave real time for testing and the report.

• Semester 1, first weeks: choose the idea, research related work, agree it with your supervisor.
• Semester 1, middle: requirements, the proposal, and the main design: architecture, database and diagrams.
• Semester 1, end: a small working prototype of the riskiest part, to prove the idea can work.
• Semester 2, first half: build the "must have" version feature by feature, with tests as you go.
• Semester 2, second half: "should have" features only if you are on schedule; then testing, evaluation and fixing.
• Final weeks: finish the report, rehearse the demo, and prepare for viva questions.

Use version control (for example Git) from the first day, with every member committing their own work. It protects you from lost files, and it is a clear record of who did what.

Keep it yours: academic integrity

Buying a project, or having someone else write your code or report, is academic misconduct at every university, and examiners are good at spotting it, often in the viva. It also leaves you without the skills and the story an employer will ask about. Getting help is different, and it is normal: asking your supervisor, learning from tutorials, getting your design reviewed, or working with a mentor who explains and asks questions while you do the work.

• Read your university's rules on collaboration, outside help and AI tools, and follow them. If you are unsure, ask your supervisor.
• Cite every source, library and dataset you use, including code you adapted.
• Make sure every group member can explain every part of the system.

How a mentor can help

Our FYP mentoring supports you from idea to viva: refining and scoping the idea, reviewing your architecture and database design, debugging sessions with you at the keyboard, feedback on your report, and practice viva questions. We guide and supervise; you build it. We never write code, reports or any graded work for you.