grant-writing

name: grant-writing description: > Write or revise research grant applications using Parker Derrington's case-for-support framework. Use when drafting a new application, revising a draft, peer-reviewing your own work, or responding to referees. Covers structure, key sentences, importance proposition, summary, style, and rejection. disable-model-invocation: true user-invocable: true

Grant Writing

Adapted from Parker Derrington's catalogue (https://parkerderrington.com/catalogue/). Apply when drafting a new application, revising a draft, peer-reviewing your own work, or responding to referees.

1. Mindset

• Target reader is a committee member skimming under time pressure (panels review ~72 applications in ~6 hours).
• Most readers will not read everything. The document must work at every depth: full read, skim, summary only.
• The reader defines what is "important", not the writer. Importance is set by the funder's mission and the reviewer's lens.
• If the reader misunderstands, the writer failed. Take responsibility for clarity; do not blame readers.

2. The magic formula: a 10-sentence Statement of Case

The introduction is exactly ten sentences in this order:

1. Opening sentence. Catches non-experts with a big-picture statement, builds credibility with specific methodological detail, and stands alone as a summary of the whole case.
2. Importance statement. Why the topic matters to this funder.
3. Aim 1 sentence. Sub-project aim + why it matters.
4. Aim 2 sentence. Sub-project aim + why it matters.
5. Aim 3 sentence. Sub-project aim + why it matters.
6. Project overview sentence. What the overall project will do.
7. Component 1 sentence. Matches Aim 1 word-for-word.
8. Component 2 sentence. Matches Aim 2 word-for-word.
9. Component 3 sentence. Matches Aim 3 word-for-word.
10. Conclusion / dissemination sentence. What the project achieves and how it is shared.

Critical rule. Sentences 7–9 use identical language to sentences 3–5. Do not paraphrase. The reader matches them by sight; synonyms break the match.

3. Key sentence skeletons

Use these templates verbatim, then fill in the brackets. Treat them as scaffolding before writing prose.

Key 1  (summary):       "This project will [progress toward solving big problem]
                         by [specific description of what it will do]
                         [assertion that project is novel]
                         [claim to ownership]."

Key 2  (importance):    "The [big important problem] is [statement of importance];
                         [statement that project outcome contributes to solving it]."

Keys 3–5 (aims):        "We need to [know | establish | develop]
                         [what the sub-project discovers]."

Key 6  (project):       "The proposed project will [general research activity]
                         to [specific research outcome]
                         in order to [partial progress toward solving the problem]."

Keys 7–9 (sub-projects): "We will [relevant research activity]
                          in order to discover
                          [the thing needed from the corresponding Aim sentence]."

Key 10 (dissemination): Tailor to whether importance is practical or theoretical.
                        Practical → who uses results, how, when.
                        Theoretical → which field advances, which next questions open.

Build the framework with key sentences first. Only write prose once all ten lock together.

4. Three-layer document structure

Order rule. The Background addresses outcomes in the same order as the project description in Methodology. Mismatched order is the most common structural sin.

5. The importance proposition

If the application does not make the importance proposition, nothing else matters: it does not get funded.

• Reader perspective sets importance, not writer assertion.
• Each funder has distinctive priorities; align outcomes to them explicitly.
• Direct outcomes (knowledge, health, economic, societal benefit) → establish in the Background.
• Indirect outcomes (training, career development, capacity-building) → address in the application form fields.
• Cite evidence of importance. Assertion alone fails.
• Follow the form's instructions exactly, however bizarre.

Funder-fit checklist. For each direct outcome, list:

1. Which sentence establishes its importance.
2. Which citations support it.
3. Which funder priority it meets.

6. The summary: committee feelgood

The designated committee member must present your application in ~5 minutes. Make their job effortless.

The summary should answer, in order:

1. The problem and the approach to solving it.
2. Why the problem matters.
3. The specific research aims.
4. How the research meets those aims.
5. Applications of the results.

The Introduction must mirror the summary. The full Case for Support fleshes the same skeleton out with evidence. A reader who only reads the summary, only reads the Introduction, or reads the whole thing should come away with the same picture.

7. Style rules

Sins of omission (accidental)

Sins of commission (deliberate)

8. Five-minute self-review checklist

Run this before sending the draft to anyone.

If any check fails, fix the framework before touching prose.

9. Responding to referees

Principles

• Assume good intent. Whether or not it is true, it improves your response.
• Reader-failure is writer-failure. Misunderstanding means unclear writing, not stupid reviewers.
• Express gratitude. The less you feel it, the more fulsome it should be. Committees grade your response.

Structure

1. Paraphrase and map. Restate each comment, then explicitly explain what you changed (or why not). Executive-summary style.
2. Emphasise improvements. Highlight how feedback strengthened the project. The less you actually changed, the more emphatically you should describe the gains.
3. Be concise. Committees are time-pressed.
4. Decline gracefully when needed. If feedback is unreasonable or uniformly lukewarm, polite refusal beats forced compliance. Better not to respond at all than to respond with bad grace.

10. Dealing with rejection

• Most material is salvageable for the next call. Treat the draft as inventory.
• A rejection reflects committee context (panel mix, fit, timing) as much as the idea. Do not over-update on a single outcome.
• Decide quickly whether to resubmit, redirect to a different funder, or shelve. Do not let the application become never-ending.

11. Workflow

• Framework before prose. Lock the ten key sentences before drafting any paragraphs.
• Write fast. Aim for ~2 weeks end-to-end. Long timelines drift and lose energy.
• Apply often. Volume + framework reuse beats single-application perfectionism.
• Avoid the never-ending application trap. Set a submission date and ship.