A research team submits a twenty-page proposal in which the literature review fills eight pages and carefully surveys every theoretical school. The aims appear on page nine. The review comes back with three lines that matter: “The specific question is unclear. It is unclear why this team is best placed. It is unclear how the results will be used.” All of that information was in the proposal. It was simply scattered where the reviewer never had time to find it.
A grant proposal is not a journal article written in the future tense. It is a credible promise: this team will answer this question, in this way, within this time, for this amount of money, and the result will matter to someone.
Read the call like a contract
Before writing a word, read the call and the assessment guidance closely. Underline three things:
- Criteria and weightings. If societal impact carries a third of the marks, it cannot be a single paragraph.
- Eligibility. Who may lead, limits on submissions per person, which costs are ineligible.
- Format. Page limits, font size, mandatory sections. Many funders reject non-compliant proposals without reading them.
Then look at previously funded projects, which many funders publish. They reveal the scale, style and type of question the funder actually backs, which is not always what the call text suggests.
The first page: question, gap, aims
Whether the funder calls it a summary, specific aims or project overview, the first page should do five things in this order:
- The problem (two or three sentences): why it matters and to whom.
- The gap (two or three sentences): what is not yet known or possible, stated plainly.
- The overall aim (one sentence).
- Two or three specific objectives, one sentence each with the main approach.
- Expected outcomes and impact (two or three sentences): what will be different afterwards.
Test it by giving the page to a colleague outside your field for two minutes, then asking them to tell you what the project does. If they can't, rewrite the first page, not the rest.
Objectives: independent but connected
A classic weakness is an objective 2 that depends entirely on objective 1 succeeding. If the first fails, the whole project collapses, and experienced reviewers spot it at once. Design each objective to produce something valuable even if another runs into trouble, and state your fallback.
Methods: detailed enough to trust, concise enough to read
| Element | What reviewers look for | Common weakness |
|---|---|---|
| Study design | Fits the question, with comparison groups where needed | A vague “mixed methods” label |
| Sample and data | A justified sample size and feasible data sources | No explanation of how participants will be reached |
| Analysis | Methods matched to each objective | Listing software instead of methods |
| Risks | Identified, with contingencies | Omitted entirely |
| Ethics | Approval process and data protection | “Ethical approval will be sought” and nothing more |
Pilot data is the strongest weapon in this section, even when modest. A small table from a thirty-person pilot persuades more than pages of argument that the method will work.
Timeline and deliverables
Use a quarterly Gantt chart and tie each objective to milestones and concrete outputs: datasets, papers, policy briefs, software, training sessions. Don't promise too many papers; reviewers know how long a good paper takes from data to publication.
Budget: every line needs a “because”
The budget justification is where good proposals lose marks needlessly. Every cost should link to an activity in the methods. “Laptops: 2” invites questions; “laptops for two field assistants collecting data in twelve villages, running offline data-entry software” does not. A budget that is too low is also a warning sign, suggesting the team hasn't costed the work properly.
The team: why you
The team section is not a list of achievements. For each member, one or two sentences should say which objective they lead and what experience shows they can deliver. If the team lacks a skill, statistics for instance, bring in a collaborator with a letter of support rather than hoping the reviewer won't notice.
Try this: an eight-week process
- Week 1: read the call, criteria and funded projects. Contact the programme officer if scope is unclear.
- Week 2: write the first page. Only the first page. Revise until a colleague from another field understands it.
- Weeks 3–4: methods, timeline, risks.
- Week 5: budget and justification, working with your research office.
- Week 6: background, team, impact.
- Week 7: mock review: ask two people to score it against the funder's actual criteria.
- Week 8: revise, check formatting, and submit at least two days early, since portals often slow down near the deadline.
When you are rejected
Most proposals are rejected at first submission, including those from very experienced researchers. The reviews are an asset. Sort each comment into “fixable”, “needs clearer explanation” and “reasoned disagreement”. If the funder allows resubmission, many require a response to reviewers; answer every point politely and specifically, including those you disagree with.
Something to do now: take your most recent proposal, submitted or not, reread only the first page, and answer three questions: what the project does, why this team, and what will change afterwards. Any answer that requires turning the page marks the first thing to rewrite.
Câu hỏi thường gặp
What are the main sections of a research grant proposal?
Typically a summary or specific aims, background and gap, methods, timeline, risks, a justified budget, team expertise and impact. Always follow the structure the funder specifies.
How can I make my grant proposal stand out to reviewers?
Make the first page exceptionally clear on the problem, gap, specific aims and impact. Include pilot data where possible, and map every section to the funder's scoring criteria.
How do I write a budget justification?
Link every cost to a specific activity in your methods and explain why it is needed. Avoid under-budgeting, which suggests the team has not costed the work realistically.
Should I resubmit a rejected grant proposal?
Yes, if the funder allows it. Use the reviewers' comments to improve the proposal, and respond to each comment specifically and courteously.
How long does it take to write a grant proposal?
For a mid-sized proposal, six to eight weeks is realistic alongside other duties. Build in time for internal review before submission.
