What supervisors look for
Supervisors and panels usually check four things: is the problem clear and worth studying, are the objectives specific and achievable, does the method fit the objectives, and can you finish within the time and resources you have.
They also look for signs that you have read around the topic, that you can explain the idea in plain terms and that the scope is realistic for one student. Check your faculty's proposal template for page limits and required headings.
Background and problem statement
Start broad and narrow down. The background explains the context and why the topic matters, using a few recent sources or data. The problem statement then says exactly what is wrong, missing or unknown.
A useful pattern is: context, what is known, what is not known or not working, and what your project will address. Avoid vague claims like "many people have problems with..."; state who, where and how big, with evidence.
Objectives and scope
Objectives say what you will do, using action verbs such as "to examine", "to develop", "to compare". Keep them to three or four and make sure each can be measured or evaluated.
Scope sets boundaries: the population, location, time period, variables or system features you will cover, and what you will not cover. A clear scope shows your supervisor that the project is manageable.
Literature snapshot
Include a short review of three to five key studies or existing systems that relate to your topic. Summarise what they found or did, then point out what they leave unanswered, which is your gap.
This is not the full literature review, just enough to show your project is grounded and original. Cite properly using the style your faculty requires.
Methodology and timeline
Describe how you will meet each objective. For a survey: design, sample, instrument and analysis. For a system: development approach, tools, requirements and testing. Name the software and techniques you will use, and justify them briefly.
Add a timeline, such as a Gantt chart or table, with realistic milestones for the semester or year. Link tasks to deadlines, and leave time for revisions and writing.
A worked outline you can adapt
Here is a section-by-section structure for a typical IT or business FYP proposal. Replace the example topic with your own, and follow your faculty template if it differs.
- Title. Specific and testable, for example "Factors affecting student adoption of mobile banking apps in [your city or university]".
- Background (about one page). The context, the trend or gap in practice, and why it matters in Malaysia.
- Problem statement (one or two paragraphs). What is not known or not working, supported by one or two credible sources.
- Research questions and objectives. Two to four of each, numbered, with each objective matching one question.
- Scope and limitations. Who, where, when and what is excluded, so the project stays finishable.
- Literature snapshot. Three to five key studies and the gap they leave.
- Method. Design, sample, instrument or system approach, and how you will analyse the data or test the system.
- Timeline. Milestones by week or month, ending with the report and presentation dates.
- References. In the style your faculty requires.
Length, tone and format
Proposal length varies widely between faculties, from a short form of a few pages to a full document with a literature section, so confirm the page or word limit before you write. Keep the tone formal but plain: short sentences, one idea per paragraph and no unexplained jargon. Number your objectives, label every table and figure, and use the heading styles from your faculty template so the document is easy to scan. Finally, read the proposal aloud once. Sentences that are hard to say are usually hard to read, and a panel member skimming ten proposals will notice.
Check that every part lines up
The most common structural problem is a mismatch between sections. Test your draft with this chain: the problem statement leads to the research questions, each question has an objective, each objective has a method step, and each method step has a place on the timeline. If any link is missing, your supervisor will notice. A simple table with four columns (problem, objective, method, timeline) is a quick way to check, and it can go in your appendix.
Using your supervisor's feedback
Book a short meeting once you have a one-page outline, not a finished document. Bring your title, problem statement and objectives, and ask two questions: is this scope realistic for the time we have, and does the method fit the objectives? Write down the answers, change the draft, and send a revised version before the deadline so your supervisor can see how you responded. Panels tend to respond well to students who show they have acted on guidance.
Common reasons proposals are rejected
Proposals often fail because:
- The topic is too broad or unclear.
- Objectives do not match the problem statement.
- The method cannot answer the objectives.
- The scope is unrealistic for the time or resources.
- There is little evidence of reading.
- The idea is not original or has already been done without a new angle.
- The writing is unclear or has many errors.
Ask your supervisor for early feedback and revise before the formal submission.
Checklist
Before submitting, check that:
- The title is specific and matches the content.
- The problem statement is supported by evidence.
- Objectives are clear and aligned with the method.
- The scope is realistic.
- The timeline is achievable.
- References are cited and listed correctly.
- The format follows the faculty template.
- Your supervisor has seen a draft.