A final year project proposal explains the problem you intend to investigate, why it matters, how you plan to investigate it and whether the work is feasible. Follow your department's required sections, length and review process; a clear plan does not guarantee approval.
Use the proposal to settle the work before committing to the full report. Once your question, plan and required decisions are confirmed, UniDraft helps organise your actual work into an editable project document. Create your UniDraft account to start that document workflow; it does not supply proposal approval or findings for research you have not completed.
The short answer
- Length: use the page or word limit in your confirmed brief. A short concept note and a fuller proposal can require different levels of detail; ask for the relevant template.
- Sections: title, background, problem statement, objectives, scope, methodology, expected outcome. Add a timeline and short reference list.
- Check alignment: the problem, objectives, method and intended output should describe the same investigation.
- Write these first: the problem statement and objectives. Everything else follows from them.
- It is not a commitment to every detail. It is a plan your supervisor can improve, and you can refine it later with permission.
What a proposal is for (and who reads it)
Your proposal is read by your project coordinator, your supervisor, and in some departments a small committee. They are asking four questions. Is the problem real? Is it small enough to finish? Is your approach appropriate? Is this different from what previous students did?
A broad aim such as "improving education in Nigeria" does not yet identify a feasible student investigation. Narrow the question, setting and evidence, then explain what can be completed under the actual time and access constraints. Plain wording helps the reviewer understand the plan; it does not guarantee approval.
It also helps to know what a proposal is not. It is not a draft of your whole project, and you are not expected to have results. If your department has already assigned you a topic or a supervisor, the proposal still matters: it fixes the scope in writing, and that written scope protects you later when the goalposts try to move.
A few departments call this document a "project outline", "concept note" or "research proposal", and some run it alongside a seminar. The names differ; the job is the same. Because departments and even individual supervisors differ, treat what follows as the standard structure and check your department's guideline for the exact headings, page limit and referencing style. The National Universities Commission (NUC) sets minimum academic standards for universities, but the format of a proposal is normally a department-level decision, not a national rule.
The seven sections of a proposal
1. Title
A good title lets a stranger guess your topic. Include what you are studying or building, the subject or population, and where or in what setting. "Improving power supply" says nothing. "Design and Construction of an Automatic Changeover Switch for Hostel Rooms" says what will exist at the end.
Avoid starting with "A study of", "An investigation into" or "The role of" unless your department's style calls for it. Those phrases take up space without telling anyone anything. If you are still choosing a topic, see how to choose a final year project topic or try the free topic generator.
2. Background (or introduction)
Use the length allowed by your confirmed brief. Explain the area, setting and specific issue, narrowing from the wider context to the investigation you can carry out. Include enough checked evidence to explain why the question matters.
Use checked sources to support the background and problem. The amount of evidence depends on the question and your brief. Use recent, checkable sources (journal articles, government or regulator reports, university publications) rather than a blog or a topic-seller's page.
If you struggle to find real papers, the free citation finder can locate them and format them in APA, IEEE or Harvard.
Keep the background focused on establishing the question. Reserve extended comparison of studies for your full literature review, which comes later.
3. Problem statement
The problem statement explains what is wrong, missing, slow, costly or unknown, for whom, and how you know. One or two sentences carry the main claim; a short paragraph may support it with evidence.
A weak problem statement announces a topic ("This project is about staff records"). A strong one names a gap: "The department keeps staff records in paper files, so retrieving one takes several minutes and files are sometimes misplaced. No electronic system is in use." Notice it points to something you can observe or measure, which the objectives can then address. Our guide to writing a problem statement covers this in more detail.
4. Objectives
Objectives state what you will do to address the problem. Use the number needed to cover the agreed scope and any requirement in your brief. Start each with an action verb you can check: design, develop, measure, compare, test, evaluate, determine, survey. Choose verbs whose intended meaning and evidence you can explain; exploratory and interpretive objectives need not be numerical.
Each objective should connect to a suitable method and a place where its actual outcome, including partial or unmet work, can be reported. If you cannot say where an objective will be answered, it is either too vague or unnecessary. Keep one general aim, then break it into specific objectives. If you are also writing research questions or hypotheses, keep them consistent with the objectives; this guide to research questions and objectives shows how.
5. Scope and limitations
Scope says what you will cover and, just as importantly, what you will not. It is the cheapest way to protect yourself. Examples of scope statements: "The study covers 200-level to 400-level students of one faculty in one university", "The system will run on a web browser and will not include payment integration", "Tests will be carried out on a single 5 kVA supply".
Limitations explain constraints on interpretation, including consequences of design choices, measurement, time, funding or access. Naming them now is a sign of maturity, not weakness. Explain how each constraint affects feasibility and interpretation; disclosure does not remove it or predict a panel decision.
6. Proposed methodology
Describe your proposed approach clearly, distinguishing planned work from any genuine preliminary work: how you will collect data or build the system, with what tools, and how you will judge the result. You are not expected to have done it yet, but you must show you have a workable plan.
What "methodology" looks like depends on your field:
| Project type | What to state in the proposal |
|---|---|
| Survey or social science | Population, sample size and how you will select it, instrument (questionnaire or interview guide), analysis method |
| Engineering or hardware | Design approach, components, software or simulation tools, test procedure and what counts as success |
| Software or IT system | Development model (for example waterfall or agile), tools and languages, users, how it will be tested |
| Laboratory or science | Materials, procedure, number of samples or replicates, how results will be measured and analysed |
| Education or health study | Setting, participants, permissions or ethical clearance if required, instrument, analysis method |
If you plan a survey, decide early how many people you need and how you will reach them; see how to calculate a sample size and how to design a questionnaire.
The full version of this section later becomes your methodology chapter.
Add a simple timeline. A table of weeks and tasks is enough, and supervisors like it because it shows you understand the workload. If your department gives fixed dates (proposal defence, first draft, final submission), build your plan backwards from them.
7. Expected outcome
State what will exist at the end. A working prototype with test results? A validated questionnaire and a dataset analysed in SPSS? A recommendation to a specific body? Be concrete, and do not promise findings. "The project will evaluate retrieval time under specified conditions" keeps the outcome open. "The system will reduce retrieval time by 90%" is a result you have not earned yet.
A worked example (illustrative)
Below is the core of a proposal, shortened. It is invented for illustration, so do not copy it; use the shape.
Title: Design and Implementation of a Web-Based Staff Records System for a Departmental Office
Problem statement: The department keeps staff records in paper files. Retrieving a single record can take several minutes, and files are sometimes misplaced or duplicated. No electronic records system is in use, so the office cannot easily answer routine requests from the faculty.
Objectives:
- To identify the record-keeping requirements of the departmental office.
- To design a database and interface for storing and retrieving staff records.
- To implement the system as a web application.
- To test the system with sample records and compare retrieval time against the current paper method.
Scope: One department, staff records only; no payroll, no student records.
Notice how the problem points at something observable (minutes to retrieve a file), and how the last objective gives a way to know the project worked. That link between problem and test is what supervisors look for.
Time and length: how much to write
Confirm whether the assignment asks for a short concept note or a fuller proposal, then use its page or word limit. Include the detail needed to explain the problem, evidence, method and feasibility within that limit. Clear writing does not compensate for a missing required section.
Allocate space by the actual task and marking or review brief. A complex method may need more explanation than a short background, but no fixed percentage is prescribed here. Check that each required section answers its question without using background detail to conceal an incomplete plan.
Why proposals get sent back
Use the following illustrative review comments to check your own draft. They are examples, not measured rejection frequencies or a prediction of your supervisor’s decision.
- Objective too broad. Comment: "Narrow this." Fix: add a place, a population or a build, and a verb you can check.
- Objectives do not match the methodology. Comment: "How will you achieve objective 3?" Fix: for each objective, write one line naming the method that delivers it.
- Topic already done in your department. Comment: "This was done last session." Fix: check local rules and the evidence, then agree a genuinely justified question or change; changing a place name alone does not establish novelty.
- Too big for the time. Comment: "Is this realistic?" Fix: cut scope. Agree a feasible scope that still addresses the question and requirements.
- Problem is not a problem. Comment: "So what?" Fix: show who is affected and give one piece of evidence.
- Copied or recycled text. Comment: about originality. Fix: write in your own words from your own reading, and cite what you use. Do not copy another student's work or misrepresent it as your own; appropriately cited scholarship and permitted methodological sources can inform your plan.
- Formatting ignored. Comment: "Use the department format." Fix: check the template before you write, not after.
Also watch for a subtler trap: you may not be able to get the data or equipment you need. Before you propose a survey of a hospital's patients, or a project needing a machine your department does not own, ask whether you will really have access. Unconfirmed access can make the proposed procedure infeasible.
How to test your draft before submitting
Try the stranger test: give only your problem statement and objectives to a course mate from another department. Ask them to explain your project back in one sentence. If they cannot, identify which wording or missing detail caused confusion and revise it; this exercise does not replace supervisor review.
Then run this checklist.
- The title names the topic, subject and setting.
- The problem statement fits in one or two sentences and points at something observable.
- The objectives cover the agreed scope and any required count, with checkable actions matched to methods.
- Every objective has a matching method and a matching place in the eventual report.
- Scope says what is excluded.
- The methodology names tools, data and how you will judge success.
- A realistic timeline fits the dates your department has given.
- Every citation is a real source you have read, and the referencing style matches the department's.
- Format (font, spacing, margins, cover page) matches the department template. You can check a Word file against a university's rules with the free formatter and read your institution's guide under format guides.
- You have spell-checked in British English and read it aloud once.
Writing a proposal you can actually follow
A realistic proposal saves months. An overly ambitious proposal that gets approved often forces a scope-narrowing conversation with your supervisor halfway through the session, which costs more time than getting the scope right on day one. When in doubt, choose the smaller version that you can finish properly. You can always add an optional extension in a "future work" line.
Keep a copy of the approved version and note any later changes your supervisor agrees to, with dates. If a panel member asks at your defence why your final project differs from the proposal, you will have a clear answer. Speaking of which, see how to prepare for the project defence.
After approval: what to do with the proposal
Approval is the start of the work, not the end of it.
- Turn it into Chapter 1. Adapt the background, problem, objectives and scope to the current study, adding the significance, definitions and chapter outline your department expects. Choose tense according to meaning and your confirmed style instructions; do not describe planned work as completed. See how to write the introduction.
- Plan your writing order. The step-by-step guide to writing a final year project shows a sensible order and a weekly plan.
- Start the literature review early, using the sources you already cited.
- Hold a check-in with your supervisor every two weeks or so, and keep their instructions in writing, because they will matter when it comes to corrections. See managing supervisor corrections.
Make the timeline follow dependencies
A research timeline should show what will be delivered and what must happen first. Edinburgh's research-proposal guidance includes a timetable for research and writing; that is an example of planning practice, not a Nigerian department's required schedule.
Fictional eleven-week illustration, not a prescribed project duration or an estimate of approval time:
| Window | Deliverable | Dependency or check |
|---|---|---|
| Week1 | Focused question and initial source notes | Supervisor discussion and assignment brief |
| Weeks2–3 | Refined method, instrument and necessary permission requests | Check access and approval requirements; actual approval may take longer |
| Weeks4–5 | Planned data collection, if the project needs it | Proceed only after required permissions/approvals and preparation are complete |
| Weeks6–7 | Checked analysis material and documented analysis | Real data and a justified analysis plan |
| Weeks8–9 | Full draft consistent with the work | Chapters must match actual methods/results |
| Weeks10–11 | Reviewed revisions, final checks and submission buffer | Allow for feedback and your real submission deadline |
Reading and drafting can overlap other stages. Required approvals cannot be replaced by a calendar date. If a dependency is delayed, revise the schedule and discuss a smaller feasible scope; do not claim work happened earlier or collect data prematurely to preserve the chart.
For your own plan, add an owner, estimated duration, deadline and actual completion date to each task. Check the longest chain of dependent tasks against the submission date. Preserve agreed changes so you can explain how the final work differed from the proposal.
Turn your timeline into a usable Gantt chart
A Gantt chart places tasks against a time axis. Use the deliverables and dependencies above rather than copying another student's coloured bars. Sheffield's planning guidance discusses milestones and dependencies; its example durations are not requirements for your project.
Start with this original worksheet:
| Deliverable | Must happen first | Your work estimate | Waiting/review time | Planned finish | Actual progress |
|---|---|---|---|---|---|
| Your checkable output | Required input or permission | Hours/days you can justify | Estimate separately; confirm where possible | Your real deadline | Record completed work honestly |
Place each task on the calendar, then inspect the longest dependent sequence. Several hours of work may still require elapsed days if you must wait for access or feedback. Overlap tasks only when their inputs are available. Keep the original plan alongside dated revisions; moving a bar is not evidence that the task finished. If time is insufficient, discuss scope with your supervisor rather than skipping required review.
Build a budget from tasks, quantities and current quotes
Include a budget if your brief requires it or if it helps you check feasibility. List the activity, quantity, unit cost, basis/date of the estimate and whether a resource is already available. Do not invent laboratory fees, participant costs or software prices.
Arbitrary teaching numbers in naira, not current prices, quotes or a recommended spending budget:
| Item | Quantity × illustrative unit cost | Illustrative total |
|---|---|---|
| Permitted local travel | 3 visits × ₦1,500 | ₦4,500 |
| Required printing | 2 copies × ₦1,200 | ₦2,400 |
| Data access | 2 bundles × ₦1,000 | ₦2,000 |
| Total | ₦4,500 + ₦2,400 + ₦2,000 | ₦8,900 |
Replace every number with a justified estimate for your plan. Distinguish an estimated cost from an actual expense, and avoid counting an item twice just because two activities use it. If your institution requires contingency, tax or a particular budget format, use its instructions and show the basis. A borrowed device may have no new cash cost while still needing permission and availability. If the plan cannot be funded, agree a feasible change before committing to the work.
Keep the estimate auditable
Use a consistent unit: a return journey and a one-way fare are different quantities. Check whether the estimate includes required charges. UKRI's costing guidance supports justified costs in its funding context; it does not set undergraduate reimbursement rules in Nigeria.
| Task and resource | Unit | Quantity | Unit estimate | Subtotal | Basis and date | Assumption |
|---|---|---|---|---|---|---|
| Your actual planned need | Trip/page/hour/etc. | Supported count | Current estimate | Quantity × unit estimate | Genuine quote or other basis | What could change? |
Keep available resources and new cash requirements distinguishable. A funding request is not an award, and a completed budget is not a receipt. After spending, retain genuine evidence and record actual amounts separately from estimates. Explain material differences and obtain any required approval; never manufacture quotations, signatures or payments. For proposal defence, practise explaining the largest line and its quantity. At final defence, distinguish the original plan from what the study actually used.
Where UniDraft fits in
UniDraft does not write your proposal for you, and it will not invent a topic, results or sources. What it does is build your final-year project as an editable Word document around your own confirmed topic and real results, applying project/supervisor instructions first, followed by student-confirmed guidelines, department patterns, university baselines and platform defaults. If you have an approved proposal, that is exactly the material to start from.
- It follows a fixed order of precedence: supervisor, then confirmed guidelines, then department pattern, then university baseline.
- You can upload your own results (a .docx with tables and labelled images) and it will place them; it does not run statistics or make up data.
- When your supervisor sends corrections, you supply them, confirm the changes, and a new version is produced. Earlier versions are kept.
Check current pricing and included correction rounds in the document workflow before checkout. It does not guarantee a grade or approval.
Check the decisions behind the proposal
For the evidence plan, check which data source fits, how the required records will be collected, and what review, consent and data-handling steps apply. A proposed procedure is not a claim that collection or approval has already happened.
Before submitting, check three connected decisions: whether the research gap is supported, whether the design can answer the question, and what contribution the study could reasonably make. These worksheets support discussion with your supervisor; they do not establish approval or completed findings.
Sources
- National Universities Commission (NUC): the federal regulator that sets minimum academic standards and accredits university programmes in Nigeria. Proposal format and length are set by individual departments, so confirm with your project coordinator.
