A project proposal's job is to convince your supervisor a specific plan is worth approving -- clarity matters more here than in almost any other document you'll write for your project.
Structure
- Title -- specific enough that someone could guess your topic from it alone.
- Background/Introduction -- briefly, why this problem matters.
- Problem Statement -- the specific gap or issue your project addresses, stated in one or two sentences.
- Objectives -- what you aim to achieve, usually as a short numbered list.
- Scope -- what's included and, just as importantly, what's explicitly excluded.
- Proposed Methodology -- your planned approach at a high level (you're not expected to have executed it yet).
- Expected Outcome -- what a completed project will look like or demonstrate.
Why proposals get sent back
By far the most common reason: an unclear or overly broad objective. If a reader can't state, after one read, exactly what problem you're solving and how you'll know you've succeeded, the proposal usually needs another round. Fix this by writing your problem statement and objectives first, and testing them against a simple check -- could a stranger explain your project back to you in one sentence after reading only those two sections?
A useful habit: write the proposal you'll actually follow
A proposal that's realistic about scope and timeframe saves trouble later -- an overly ambitious proposal approved as-is often forces a scope-narrowing conversation with your supervisor months in, which costs more time than getting the scope right at the proposal stage.
Where UniDraft fits in
Many students carry their approved proposal directly into Chapter 1 of the final report -- UniDraft helps structure that transition cleanly, applying your department's required formatting from the proposal stage onward.
