How to Write a Research Proposal

A proposal asks someone to approve or fund research that has not been done yet. Here are the parts it needs, the order to write them in, and the checks to run before you send it.

A research proposal is read by people deciding whether to say yes: a supervisor, an admissions or thesis committee, a funding panel. They read many, quickly, and they look for three things: a question worth answering, a plan that can answer it, and an author who can carry the plan out. This guide covers the parts of a proposal, the order that makes them easier to write, and the problems that cost proposals the most. The rules of your department or funder come first: where they set sections, word counts or page limits, follow them. To check your draft once it is written, use the research proposal checklist.

Thesis proposal and grant proposal compared

Thesis or PhD proposalGrant or fellowship proposal
Who decidesA supervisor, a department or a committeeA funder's reviewers or panel
What it asks forApproval or admissionMoney, sometimes with approval
Rules set byYour department's guidelinesThe call, its annexes and the funder's guide
BudgetRarelyAlmost always
Work planA timeline for one personOften work packages, deliverables and milestones
Judged onThe question, the fit with the literature, feasibility for one studentThe funder's published criteria
01

Two kinds of proposal

Most advice mixes two documents. A thesis or PhD proposal asks a department or a supervisor to approve a project: it is judged on the question, the fit with the literature and whether the plan is realistic for one student in the time available. A grant or fellowship proposal asks a funder for money: it is judged against the funder's published criteria, and it adds a budget, often a work plan in packages, and a case for impact. The parts overlap; the weight given to each does not.

02

The parts of a proposal

Names vary, and your guidelines decide which parts are required. Most proposals contain the following:

Title
what the project is about, in words a reviewer outside your subfield understands.
Summary or abstract
the question, the approach and the expected result, in a paragraph. Many readers decide here.
Background and gap
what is known, what is not, and why the gap matters. Not a full literature review: only what the question needs.
Research questions, aims or objectives
the one part every other part has to answer to.
Methods or approach
how each question will be answered, with the data, the sample, the analysis and the risks.
Timeline or work plan
when each piece of work happens, often with milestones, and in grants with work packages and deliverables.
Resources and budget
what the work needs, and in grants what it costs.
Expected outcomes and impact
what will exist at the end, and who will use it.
References
the sources cited in the text, in one consistent style.
03

The order to write them in

Not the order they appear in. Write the aims first, because every other part depends on them. Then the methods, one block per aim. Then the timeline and the budget, built from the methods rather than from a guess. Then the background, which now only needs to justify the question you have fixed. Write the summary and the title last, when you know what the proposal says. A summary written first is the part most likely to describe a project you no longer propose.

04

Aims the rest of the proposal can answer

Most structural problems start with the aims. A few rules hold across funders and departments:

Each aim says what you will find out or produce, not what you will study.
Each aim can be answered by the methods you describe, with the resources you ask for.
The aims do not depend on each other so tightly that one failed result stops the project, or the proposal says what happens if it does.
The aims use the same wording and numbering everywhere
summary, aims section, methods, timeline, budget justification.
05

Methods, timeline and budget that agree

Reviewers cross-check. A method that needs a year of data collection in a timeline that gives it three months, a sample of 200 in the methods and 150 in the work plan, a post in the budget that no task uses: each one tells a reviewer the plan was not read as a whole. These errors are hard to see in your own draft because each section is correct on its own. Read the proposal once only for numbers and dates, with the timeline open next to it.

06

Mistakes reviewers notice

These are the problems that come up again and again in advice from funders, supervisors and research offices:

The question arrives late
two pages of background before the reader learns what you will do.
Too many aims for the time or the money.
Methods described in general terms ("qualitative analysis", "machine learning") with no detail on the data or the procedure.
No word on risks or alternatives when a step may fail.
Terms, acronyms and aims used two ways in different sections.
A budget or timeline that does not match the plan.
Typos on the first page, which a reader takes as a sign of how the work will be done.
Ignoring the guidelines
a missing required section or a page over the limit can end the review before anyone reads the science.
07

Before you send it

Check the guidelines item by item, then read the proposal in passes, each for one kind of problem: the argument, then consistency between sections, then language and typos. The research proposal checklist lists the passes. Give the draft to someone in your field, who can judge the question and the methods, and to someone outside it, who will tell you where they got lost. The Grant Proposal Review ($50, paid once) reads the whole proposal and reports language, structure, typos, and aims, methods, dates and budget figures that contradict each other. It does not judge your idea and does not predict funding or approval.

Frequently asked questions

As long as your guidelines say, and no longer. Departments and funders set word counts or page limits that differ widely, so there is no general answer. If none is given, ask your supervisor or the programme contact rather than guessing.