Grant Proposals: What the Reviewers Are Actually Checking

A funding panel reads a large number of proposals under time pressure, and most will be rejected. The reader is not looking for reasons to fund; they are working through a pile and forming judgements quickly.

That determines what a proposal has to do. For a concrete operational example of how a workplace tool approaches a related coordination problem, see this overview.

Schemes differ enormously in structure, criteria and weighting. Read the call, read the assessment criteria, and where possible read a funded proposal from the same scheme. What follows is general.

The three questions

Whatever the criteria say, most assessment reduces to these.

Is this worth doing? Would the answer matter, to whom, and how much.

Can it be done? Is the design capable of producing the answer, in the time, with the resources.

Can these people do it? Track record, team, environment.

A proposal usually fails on the second or third, and applicants usually spend their effort on the first.

Structural things that decide it early

Read the call and answer it. A proposal that does not fit the scheme is rejected regardless of quality, and this happens constantly. If the call is about early-stage exploratory work and you propose a definitive study, you are in the wrong scheme.

Follow the format exactly. Page limits, font sizes, required sections. Non-compliance is a common desk rejection and it is entirely avoidable.

Write for the panel, not for the specialist. Most panels are mixed. One or two members know your area; the rest are assessing whether your case is coherent. A proposal only your subfield can evaluate loses the votes of everyone else.

Make the first page carry the case. Many readers form a view there and read the rest for confirmation. See the first paragraph.

The sections that decide it

The summary

Read by everyone including panel members who will not read the full case. Frequently written last, in a hurry.

It should contain the question, the approach, the expected outcome and why it matters — in the length allowed, in plain language.

Write it properly and early, then revise it when the proposal is finished.

The objectives

Specific and testable. "To better understand X" is not an objective. "To determine whether X causes Y under conditions Z" is.

Few. Three or four. A proposal with nine objectives reads as unfocused or as underestimating the work.

Each one connected to a work package, so the reader can see how it gets done.

The methods

Where most proposals are weakest, and where experienced reviewers look first.

Enough detail that a reviewer can judge feasibility. What exactly will be done, with what, to whom, analysed how.

Address the obvious threat. Every design has one. Naming it and saying how you handle it is far stronger than hoping the reviewer misses it — they will not.

Say what happens if it does not work. A contingency for the main risk shows the plan has been thought through rather than described.

Justify the sample or scope. If there is a power calculation to be done in your field, do it. "We will collect as much as possible" is not a plan.

The timeline and resources

Realistic, and visibly so. A plan that fits three years of work into two is read as inexperience.

Include the parts people forget: ethics approval, recruitment, data access agreements, the time to write it up.

Justify every cost. Reviewers check whether the budget matches the work. An unexplained line invites a cut, and cuts are made without consulting you.

Do not pad, and do not under-ask. Both are visible. An under-resourced proposal reads as one that will not deliver.

The track record

Show that you can complete things. Outputs from previous funding, in whatever form your field values.

Address gaps honestly. A career break, a change of field, a thin period — a brief factual statement is better than a silence the reader fills themselves. Many schemes have explicit provision for this.

For a team, say who does what, and why this combination.

What reviewers report finding

Vagueness in the methods. The most common substantive criticism.

An unrealistic timeline.

Objectives that do not match the work packages.

No engagement with the obvious risk.

A budget that does not correspond to the plan.

And overclaiming — a proposal promising to transform a field usually reads as a proposal that has not thought about what is achievable.

Practical process

Start earlier than feels necessary. Internal deadlines, costings, institutional approvals and letters of support all take longer than expected.

Get costings from your research office early, because they constrain the plan.

Ask for letters of support in good time, with a draft attached — people write better letters when given something to react to, and faster.

Have someone outside your field read it and tell you what you propose to do. If they cannot say, the panel will not either.

Have someone who has sat on a panel read it. The most valuable single piece of feedback available, and worth asking for.

Leave a week between finishing and submitting. Errors found in that week are errors not found by a reviewer.

When it is rejected

Rejection is the normal outcome. Success rates in many schemes are low enough that strong proposals are rejected routinely.

Read the feedback for what was unclear, not only for what was criticised. Frequently the panel misunderstood something, which is a writing problem you can fix.

Resubmit where the scheme allows, addressing the comments explicitly.

Do not resubmit unchanged, and do not assume a different panel will read it differently.

And check the fit. A proposal rejected twice from one scheme may suit a different one.

See reading a rejection.

The short version

Worth doing, can be done, can these people do it — and proposals usually fail on the second and third.

Read the call and answer the scheme you are actually applying to.

The methods section is where reviewers look first, and vagueness there is the most common criticism.

Name the obvious risk and say how you handle it, rather than hoping it is not noticed.

And have someone who has sat on a panel read it before you submit.

For an independent authoritative reference, consult the EQUATOR Network for reporting guidance for research writing.