How to Write a Final Year Project Proposal
A proposal is not a description of everything you might build. It is an argument that this project is worth approving, and that you can finish it.
An FYP proposal needs six sections: problem statement, objectives, literature review, methodology, evaluation plan, and timeline. Supervisors read the methodology and evaluation first, because those two sections show whether the project is completable and assessable. Write them before the introduction, keep the whole document between six and twelve pages, and make sure every objective has a matching test.
Students usually write proposals in the wrong order. They start with an introduction describing the problem in broad terms, add a feature list, and finish with a vague sentence about testing. The result reads well and says very little.
Write it in the other order. Start with how you will prove the project worked, because everything else exists to make that evaluation possible.
Write the sections in this order
This is not the order they appear in. It is the order you should write them, because each section constrains the one before it.
First: evaluation. How will you know it works? Name the metric, the test set, and the comparison. Until this exists, you cannot write a methodology, because you do not know what you are building toward.
Second: methodology. What are you actually going to build and in what order? This follows from your evaluation. If you must measure latency, the architecture is constrained. If you must measure accuracy on a labelled set, the data pipeline is constrained.
Third: objectives. Now you can write objectives as testable statements, because each one maps to something in your evaluation.
Fourth: literature review. Only now can you position the work accurately, because you know what you are claiming.
Fifth: problem statement. The introduction is easier to write last, because you finally know the boundaries of the problem.
Sixth: timeline. Now that the scope is fixed, dates mean something.
What belongs in each section
Problem statement
Two paragraphs. What is the situation now, what specifically is wrong with it, and why does it matter. Avoid starting with the state of the industry. Start with the concrete problem your user has. If you cannot describe a person experiencing this problem, it is not a problem statement.
Objectives
Three to five objectives, each one starting with a verb and each one testable. Compare these two.
| Untestable | Testable |
|---|---|
| Build a smart attendance system | Recognise enrolled students from a single lecture hall camera with a false reject rate under ten percent |
| Improve paper recommendations | Outperform a popularity baseline on precision at ten using a held out citation set |
If an objective has no matching test in your evaluation section, either delete the objective or add the test. Examiners look for this alignment specifically, and missing it is the most common structural weakness in student proposals.
Literature review
Six to twelve sources for a proposal is enough if you use them properly. Organise by approach rather than by paper. What have people tried, where does each approach break down, and what gap does your project fill. A list of summaries with no comparison reads as padding and supervisors recognise it immediately.
Methodology
The core of the proposal. Describe the system in enough detail that a reader could criticise your approach. Include the data sources and how you will obtain them, the architecture at a component level, the tools and frameworks, and the order you will build things.
Be specific about the hard part. If your project depends on a face recognition pipeline, say which model family you will start with and what you will do if accuracy is too low. Naming the fallback is what convinces a supervisor you have thought past week one.
Evaluation plan
The metric, the dataset, and the baseline. Three things. If you cannot name a baseline, you cannot show improvement, so choose something simple: a popularity ranking, a majority class predictor, or the current manual process. Simple baselines are perfectly acceptable and often more convincing than a weak competing model.
Timeline
Milestones by month, covering development, evaluation, and writing. Two errors are common. The first is allocating no time for data collection, which is usually the slowest step. The second is leaving no buffer, which means any delay eats your evaluation period.
A proposal that promises eight features and a full deployment will be judged against all eight. A proposal that promises three, delivers three, and evaluates them properly scores better every time. Promise less and over deliver, never the reverse.
Before you submit
Read the proposal once asking only one question: for every claim I make, is there something later in the document that proves it? Where the answer is no, either add the proof or remove the claim.
Then check the practical items. Does every objective have a test? Does every test name a metric? Does the timeline include writing? Is every cited source actually read? Those four questions catch most of what supervisors mark down.
Once the proposal is approved, the document becomes your contract with yourself. Keep referring back to the evaluation section during development, because it is easy to drift into building features that nothing in your plan measures.
Frequently asked questions
How long should a final year project proposal be?+
Between six and twelve pages is typical, excluding references. Length is not what gets it approved. A focused eight page proposal that names the dataset and the evaluation method will beat a twenty page one that lists features. Follow your department's template if it specifies a limit.
What is the most important section of an FYP proposal?+
The methodology and evaluation section. Supervisors approve proposals they believe can be completed and assessed. A clear statement of what you will build, how you will test it, and how you will know it worked is what turns a topic into an approved project. Everything else is context for that.
Should I include a timeline in my FYP proposal?+
Yes, and it should be honest rather than optimistic. Give each major milestone a date and include time for data collection and writing, not just development. A realistic timeline signals that you understand the project. An optimistic one signals that you have not started yet.
Do I need a literature review in an FYP proposal?+
You need enough of one to prove nobody has solved your exact problem the same way. Six to twelve well chosen sources is usually enough for a proposal, covering what exists, what it misses, and what your project does differently. Save the exhaustive review for the final report.
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.