---
name: grant-and-funding-proposal-development
description: >
  Builds a funding application written to the call's assessment criteria, with a
  case for support a mixed panel can grade, a feasible work plan and risk
  register, a justified team and budget structure, and impact taken seriously.
  Use for "write a grant application", "funding proposal", "case for support",
  "read the call for me", "pathways to impact", "work plan and milestones",
  "budget justification", "my grant was rejected", "resubmit a funding
  application", "what are my chances".
category: 15 Academic University Research
ref: "15.28"
tier: 3
inherits: [K2, K3, K4, K5]
---

# Grant and Funding Proposal Development

## 1. One-line description

A method for building a funding application from the call's own assessment criteria outward, so that a mixed panel of specialists and non-specialists can find, grade and defend each thing they are required to score, and so that feasibility, team, budget and impact are argued rather than asserted.

## 2. What this skill is used for

**The research problem it solves.** Most funding applications are written as descriptions of a project and assessed as answers to a set of criteria, and the gap between those two things is where the majority of avoidable failures live. Reviewers score against a published scheme, item by item, often under time pressure, and frequently across a mixed panel where the person grading your application is not from your subfield and may not be from your discipline. An application that buries its significance in specialist language, or never states its question in a form a non-specialist can grasp, or leaves feasibility to be inferred from a publication list, loses points the underlying research deserved. A second failure is strategic: applying to a funder whose priorities the project does not serve and dressing it to fit, which experienced reviewers detect quickly and penalise heavily. A third is administrative: a work plan that cannot be delivered in the time, a budget that does not match the plan, a missing data management or ethics section, or a rule in the call that was not read. This skill installs the discipline that prevents all three: read the call first, write to the criteria explicitly, and argue the parts applicants usually assert.

**Where it sits in the research lifecycle.** Usually before a project exists at all, which makes it structurally different from most skills in this library: the work being described has not been done, and the application is a case that it should be. It also recurs at resubmission, and it feeds directly into project design.

**Typical use cases.**
- Building a full application against an open call.
- Deciding whether a project fits a funder's priorities well enough to be worth applying.
- Turning a research idea into a case for support with a defensible aim and objectives.
- Building a work plan, milestone schedule and risk register that a reviewer will believe.
- Justifying a team, and each role in it, rather than listing people.
- Structuring a budget justification so that every line traces to the work plan.
- Writing an impact section that is not an afterthought.
- Rebuilding an application after rejection, using the reviewer comments.

**Who uses it.** Early-career researchers writing their first application, for whom the base rate is most demoralising and least explained; established researchers moving to an unfamiliar funder or scheme; research development and pre-award staff supporting applicants; doctoral researchers applying for fellowships and small awards; applied and practice-based researchers seeking project funding outside a university.

## 3. When to use it

- A call is open and you are deciding whether and what to submit.
- You have an idea and need to turn it into a fundable case.
- You have a draft that describes the project well and does not obviously address the criteria.
- Reviewers on a previous application said the project was interesting but the feasibility, team or impact was weak.
- You are assembling a team and need to justify each role rather than list names.
- You need a work plan and risk register that will survive scrutiny.
- An application was rejected and you are deciding whether and how to resubmit.
- You are advising someone else and want a defensible process rather than a personal habit.

## 4. When NOT to use it

- **The project does not fit the funder's remit, and the fit would have to be manufactured.** This is the single most common reason to stop, and stopping is the right answer. Reviewers assess remit fit routinely and detect retrofitted framing easily: the giveaway is a proposal whose priority alignment appears only in the opening and closing paragraphs and never in the work plan. Where the fit is genuinely partial, say so and argue it; where it is absent, find a different call. See Step 2.
- **The research question is not yet defined well enough to design a study around.** An application is not the place to work out what you are asking. Go to **15.04 Research Proposal Writing** for the problem statement, aim, objectives and scope, and to **01.02 Business Problem to Research Question** where the origin is an applied or organisational problem. Return here once there is a question a method could answer.
- **The claimed contribution is not established.** Where the application rests on the work being genuinely new and that has not been checked against the literature, the reviewers will check it. Establish it first: **15.13 Doctoral Research Positioning and Originality**, or **15.06 Systematic Literature Review** where the state of the evidence is what is in question.
- **The deadline does not permit the work.** A serious application takes weeks, not days, and the parts dropped under time pressure (impact, risk, budget justification, data management) are precisely the ones reviewers score separately. The honest options are the next round, a smaller scheme, or submitting knowing the score is capped by the sections that could not be built. State the trade rather than concealing it. `RESEARCHER DECISION REQUIRED` (K5 §2.7).
- **What is wanted is a case for support to be submitted as the applicant's own unaided writing.** An application is signed by named people accountable for every claim in it, including claims about their own track record. See §12.1.
- **The application requires representations the applicant cannot verify.** Institutional commitments, collaborator agreements, access to facilities or data, letters of support and costings from a finance office are matters of record obtained from the people who own them. Do not draft them speculatively and do not describe an arrangement that has not been agreed (K4 §2.5).
- **The proposal involves human participants, animals, sensitive data or dual-use concerns and the ethical position has not been worked out.** Most calls require an ethics section and most panels read it. This is not a paragraph to write at the end. See **15.09 Ethics Clearance Application** and **13.05 Research Ethics and Consent Design**.
- **The task is reporting on funded work rather than seeking it.** Progress, final and impact reporting are a different genre with a different audience. See **12.03 Research Report Compilation**.

## 5. Required inputs

**Required.**
- **The call document in full**, including the assessment criteria, eligibility rules, scheme aims, budget rules, page limits, required sections and the deadline. Without the criteria, this skill cannot do the thing it exists to do. If the criteria are not published, say so and use the scheme aims as a proxy, marked as an inference.
- **The research idea**, to the level of a question, an aim and a rough approach. Not a topic.
- **The applicant's and team's actual track record**, as fact: outputs, prior projects, skills, access, and any relevant career context. This must come from the people concerned. It is never inferred or embellished (§12.4).

**Optional, and what each one adds.**
- **The funder's published strategy, priorities or previously funded projects.** Converts "does this fit?" from a guess into an assessment, and shows what the funder considers a fundable size and shape of project.
- **Feedback and scores from a previous unsuccessful application.** The single most valuable input at resubmission, and the thing applicants most often decline to re-read (Step 11).
- **Any internal review or pre-award support available**, and its deadline. Internal deadlines usually precede the funder's by weeks and are frequently discovered late.
- **Collaborator and partner commitments**, actual or in negotiation. Determines what may be claimed and which letters of support are realistic.
- **Costing information from the institution's finance function.** Budget rules differ between funders and institutions in ways that cannot be inferred, and a costing built on assumption is rebuilt from scratch later.
- **Existing preliminary or pilot data.** Often the strongest single feasibility argument available, and frequently under-used because applicants regard it as too small to mention.
- **The applicant's career stage and eligibility position.** Some schemes are stage-restricted, and some criteria (particularly track record) are assessed relative to career stage and to career interruptions, which applicants routinely fail to declare when they are entitled to.

## 6. Questions to ask before starting

1. **What are the assessment criteria, and what weight does each carry?** Determines the structure of everything. Default if unpublished: use the scheme aims and the required sections as a proxy, and mark the inference explicitly.
2. **Who assesses this: subject specialists, a mixed panel, a lay panel, or a sequence of these?** Determines the register, how much is assumed, and where the plain-language statement of significance has to sit. Default: assume a mixed panel with at most one subject specialist, which is the safer error.
3. **Does the project genuinely serve this funder's priorities, and can you show it in the work plan rather than only in the framing?** Default: apply the test in Step 2 honestly, and be willing to conclude no.
4. **Is the applicant eligible, and does the project fit the scheme's size, duration and cost envelope?** Cheap to check, expensive to discover late. Default: check eligibility before any writing.
5. **What is the internal deadline, not the funder's?** Default: assume institutional approval and costing need one to three weeks, and work back from that.
6. **What is the single most likely reason a reviewer will decline to fund this?** The most useful question in the process, and it should be answered in the application rather than left for the panel. Default: derive candidates from the risk work in Step 6 and address the top three explicitly.
7. **What happens to the project if this application is unsuccessful?** Determines how much is invested here, whether the work can be staged, and whether a smaller scheme is a better first move. Default: raise it, because most applicants have not considered it and the base rate makes it a live question (Step 12).

## 7. Step-by-step methodology

**Step 1. Read the call completely, and build the criteria map before writing a word.**
Read the whole call, including the parts that look administrative, and extract three lists. The **assessment criteria** with their weights where given, since a criterion carrying a third of the score deserves a third of the effort and usually does not receive it. The **hard rules**: eligibility, budget ceilings and permitted cost categories, duration, page and character limits, required sections, formatting, and anything the call says will cause rejection without assessment. And the **scheme's purpose in its own words**, which is the standard fit will be judged against. Then build the criteria map: one row per criterion, with columns for where it will be addressed, what evidence supports it, and who owns that content. This map is the application's specification. The commonest structural failure in unsuccessful applications is a well-written project description in which a reviewer cannot locate two of the five things they are required to score. *Correct result: a criteria map covering every criterion, and a hard-rules checklist with each item confirmed.*

**Step 2. Test the funder fit honestly, before investing weeks.**
Funders fund their own priorities, not good research generally, and the test is whether the project advances what this funder exists to do. Three questions. Does the project's core purpose serve a stated priority, or does only its framing? Would the funder's account of success be served by the results, including the results you get if the hypothesis fails? Do previously funded projects, where visible, look like this one in scale, shape and ambition? The distinction that matters is between **fitting** and **pretending to fit**. Fitting means the priority is visible in the objectives, the work plan and the impact activities, and removing it would change the project. Pretending means it appears in the first paragraph and the last, and the project would be identical without it. Reviewers detect the second reliably, because they are usually people who care about the priority and can see it is not in the work. Where fit is partial, state which part of the remit the project serves and which it does not, which is stronger than an unconvincing claim to serve all of it. Where fit is absent, stop and find a different call: that is a saving, not a failure. *Correct result: a fit statement naming the specific priorities served, with the objectives and work-plan elements that serve them, or a documented decision not to apply.* `RESEARCHER DECISION REQUIRED` where the fit is judged partial (K5 §2.3).

**Step 3. State the research question so a non-specialist reviewer can grasp why it matters.**
Panels are usually mixed, and even specialist panels contain people from neighbouring fields, so the application must work at two levels at once: a non-specialist must be able to say what is being asked, why it is not already known and why it is worth funding, while a specialist must find the precision that makes it credible. Write the question three times. Once for a specialist, technical framing intact. Once for a colleague in the discipline but outside the subfield, jargon removed and significance stated in the discipline's terms. Once in plain language for an intelligent reader with no background, in two or three sentences saying what is not known, why that matters, and what the project would establish. The plain version usually exposes significance that was assumed rather than argued, which is precisely what the panel will find. Place it early and prominently, because a reviewer who cannot answer "why does this matter" on the first page carries that deficit through every subsequent criterion. Then check two failure modes: significance asserted by adjective ("this critically important problem") rather than argued, and significance that rests on the topic being large rather than on the specific gap being consequential. *Correct result: three versions of the question, with the plain-language version placed early and tested on someone outside the field.*

**Step 4. Build the case for support around the criteria, not around the project's chronology.**
A case for support typically establishes: the problem and its significance, the state of knowledge and the specific gap, the aim and a small number of objectives that would close it, the approach and why it is the right one, why now and why this team, and what will result. The order varies by funder and should follow the call's required structure exactly where one is given. Two disciplines make it work. **Objectives must be objectives**: things that will be achieved and can be seen to have been achieved, not activities. "Conduct interviews" is an activity; "establish how practitioners interpret the standard in three contrasting settings" is an objective. Three to five is the workable number; more than six reads as unfocused however coherent it is. And **every claim about the approach must be argued against the alternative**. Reviewers know the other designs, and an approach presented without a reason reads as a default rather than a choice. Where a method is contested in the field, name the contest and state your position; a reviewer who holds the other position will respect an argued choice and penalise an unacknowledged one. Cross-check the finished case against the criteria map: each criterion should be findable and ideally signposted in a heading or opening sentence, because reviewers scoring against a scheme are grateful for signposting and grateful reviewers score better. *Correct result: a case in which each assessment criterion is locatable, objectives are outcomes rather than activities, and every methodological choice carries its reason.*

**Step 5. Argue feasibility, and use the track record as evidence for it rather than as a credential.**
Feasibility is the criterion applicants most often assume and reviewers most often doubt. The question in a reviewer's mind is not "is this team good" but "will this specific work get done, in this time, with these resources, by these people". Answer it with four kinds of evidence. **Prior delivery**: work of comparable complexity actually completed, which is where the track record belongs, framed as evidence that this kind of thing gets finished rather than as a list of achievements. **Access**: confirmed access to the sites, populations, data, equipment or archives the project needs, the confirmation real (a letter, an agreement, an existing relationship) rather than assumed. **Pilot or preliminary work**: even small, and frequently under-used, because a pilot showing that the recruitment route works or the instrument functions removes the reviewer's largest doubt more efficiently than any assertion. **Realism in the plan**: a schedule accounting for approvals, recruitment lead times, seasonal constraints and analysis, that does not assume everything starts on day one. Where the team lacks something the project needs, name it and show how it is covered, through a collaborator, an advisor or a costed training element; reviewers respond far better to an acknowledged and covered gap than to one they spot themselves. *Correct result: feasibility argued from prior delivery, confirmed access, pilot evidence and a realistic schedule, with any capability gap named and covered.*

**Step 6. Build a work plan, milestones and a risk register that a sceptic would believe.**
The work plan converts the approach into a sequence: work packages with their objectives, activities, durations, dependencies, responsible people and outputs. Two tests distinguish a credible plan from a decorative one. **The dependency test**: does anything start before the thing it depends on has finished, and does the plan account for approvals, recruitment and access outside the team's control? **The slack test**: is every month occupied? A plan with no contingency is not optimistic, it is unfinished, because every project loses time and a reviewer knows it. Milestones are verifiable events rather than periods of activity, spaced so a funder monitoring the project can see whether it is on track. The risk register is where applications are most often thin and most easily improved. List the real risks, not the ritual ones: recruitment shortfall, access withdrawn, a key person leaving, data quality failure, delayed approvals, dependency on an external partner, and the risk that the central hypothesis is wrong. State likelihood and impact honestly, and give a mitigation that is specific and, where possible, already in the plan. The omitted risk is usually the scientific one, and naming it is a strength: an application that says what it will do if the main effect is absent, and shows the project still yields something, is demonstrably better designed than one that assumes success. *Correct result: a work plan that passes the dependency and slack tests, milestones that are verifiable events, and a risk register containing at least one risk the applicant genuinely worries about.*

**Step 7. Justify the team by role, not by reputation.**
Reviewers assess whether the team can do the work, which is a question about capabilities matched to tasks. Build the section as a mapping: for each work package, the capability required, the person or role supplying it, and the evidence that they can. Then state, per named person, what they will actually do and the time committed, since a distinguished name with a nominal allocation reads as decoration and is scored as such. Where staff are to be recruited rather than named, describe the role and profile and say how recruitment fits the schedule, because unnamed posts are a known source of delay and an unaddressed one is a feasibility weakness. Include advisers, collaborators and partners with what each contributes and what has actually been agreed. Where the scheme assesses the applicant's development or independence, address it explicitly rather than leaving the panel to infer it. *Correct result: every work package's capability requirement traced to a person or role, with committed time stated, and no name present without a job.*

**Step 8. Build the budget so that every line traces to the work plan, and justify it structurally.**
The budget is a model of the project and is read as a check on whether the applicant understands their own plan. Structural categories vary by funder and institution, but the logic is constant: staff time by role and duration, consumables and materials, equipment, access and facility charges, participant-related costs, travel the work requires, data management and archiving, dissemination and publication, and whatever overhead or indirect-cost treatment the funder's rules specify. Build it from the work plan rather than from a target total, then read it back the other way: every line attributable to an activity, every activity holding the resource it needs. Both directions catch real errors, and the second catches the more damaging one, a plan the budget cannot deliver. The justification is separate from the arithmetic: for each significant line, say why that resource is needed for that work and why at that scale. Reviewers look for proportionality and evidence that cost was thought about, not for the lowest number; an under-costed application is a feasibility risk, not a virtue, and is frequently scored as one. Obtain figures from whoever owns them (the institution's costing function, suppliers, partners) and never estimate a cost into an application (§12.3). Where the call caps or excludes a category, comply exactly. *Correct result: a budget every line of which maps to a work package, a justification that argues necessity and scale rather than restating the figures, and all figures sourced rather than estimated.*

**Step 9. Write the impact section as a plan, not as an aspiration.**
Impact sections are commonly written last, at speed, in general terms, and are commonly scored separately and substantially. The failure is a section saying results will be disseminated widely and may inform policy and practice, which describes no activity, names no audience and commits to nothing. A serious plan has four components. **Who specifically benefits**, as concretely as the project allows: which practitioners, decision-makers, communities or parts of the field, and what they would be able to do differently. **What has to happen for that to occur**, the pathway, where most of the thinking is: the intermediate steps between a finding and a change, including who must be persuaded and what form the evidence must take for them to use it. **The activities** that make those steps happen, resourced in the budget and scheduled in the work plan, which is the check that the section is real. **How you would know**: indicators proportionate to a research project rather than promises of societal change. Two further points earn credit and are usually omitted. Engagement starting during the project is far more credible than a dissemination phase at the end, because the audiences that matter have to be involved before the findings exist. And academic impact is impact: contribution to the field, to method, to training and to capacity is legitimate and in some schemes primary. Where realistic impact is largely academic, say so rather than manufacturing a societal claim, which reviewers read as overclaiming and which damages the credibility of the rest. *Correct result: named beneficiaries, an articulated pathway, scheduled and costed activities, and proportionate indicators.*

**Step 10. Complete the data management, ethics and governance sections properly, because they are scored.**
These are frequently treated as compliance paperwork and are frequently the difference between two applications with equal science. Data management covers: what data will be generated or used, in what formats and volumes; storage, backup and security during the project; the legal and ethical basis for processing personal data where any is involved; what will be preserved afterwards, where and for how long; what will be shared, with whom and under what conditions, and where sharing is restricted, why; and who is responsible. Ethics covers: the approvals required and the route to them, with realistic timing built into the work plan; consent arrangements; risks to participants and researchers and their mitigation; arrangements for vulnerable groups; and any dual-use, security or cultural sensitivity considerations. Two rules. Restrictions on sharing are legitimate and should be stated with the reason rather than avoided, because an application promising to share data it cannot lawfully share is worse than one explaining the constraint. And approvals take time: a work plan starting fieldwork in month one when approval takes three is an immediate feasibility flag to any reviewer who has run a project. *Correct result: both sections complete and specific, with approval timelines reflected in the work plan and any sharing restriction stated with its reason.*

**Step 11. Where this is a resubmission, use the reviewer comments as the specification.**
Rejected applications usually come with comments, and applicants usually read them once, painfully, then rewrite from instinct. The productive method is the sort used for peer review (**15.26 Peer Review Response**): wait, read again, and separate comments into real defects, misunderstandings that indicate unclear writing, requests you disagree with, and comments reflecting a panel's priorities rather than the application's quality. Then determine what the scheme permits: some calls require a resubmission to state what changed, some prohibit resubmission of the same project entirely, and some treat it as a fresh application with no memory of the last. Comply with whichever applies. Address substantive criticisms in the application itself rather than only in a covering statement, because a new panel may never see the statement. And distinguish two situations that feel identical: an application that scored well and missed the funding line, which usually deserves resubmission with modest strengthening, and one that scored poorly on criteria the project cannot satisfy, which usually needs a different project or funder. *Correct result: a categorised comment list, a resubmission decision with its reason, and every substantive criticism addressed in the body of the application.*

**Step 12. Treat the base rate honestly, and plan around it.**
In most competitive schemes, most applications are unsuccessful. Success rates commonly sit well below half and often far below, which means an unsuccessful application is the modal outcome for good research written up well. Two consequences follow, and stating them is part of doing this properly. The first is interpretive: a rejection is weak evidence about the quality of the project and much stronger evidence about the volume of competition (K3 §3.1), and reading it as a verdict on the researcher is inaccurate and, for early-career applicants, actively harmful. The second is strategic: if the expected outcome of any single application is failure, the unit of planning is a portfolio and a schedule rather than a submission. Practically: identify two or three plausible calls rather than one; stage the work so a smaller award could establish feasibility for a larger one; write reusable components (the significance case, the team description, the data management approach) that can be adapted rather than rewritten; decide in advance what happens to the project if this fails; and protect the time to write the next one rather than absorbing the loss and stopping. None of this is consolation. It is what the base rate actually implies, and applicants who plan this way submit more, improve faster and are funded more often. *Correct result: a stated understanding of the scheme's competitiveness where it is published, a named alternative route for the project, and a decision about what follows an unsuccessful outcome.* `RESEARCHER SIGN-OFF REQUIRED` before submission (K5 §2.8).

## 8. Analytical framework

The application is built on one mapping, and everything is checked against it:

    Assessment criterion → Where it is addressed → What evidence supports it →
    What a reviewer would have to accept → Whether they would

Applied to every criterion in turn, this catches the failures that matter. A criterion with no location is unscored. A criterion addressed by assertion rather than evidence scores at the bottom of its band. A criterion whose evidence requires a reviewer to accept something they have no reason to accept (that access will be granted, that recruitment will hit target, that a partner will engage) is the place a sceptical panel member will push, and it is better to find it yourself.

Beneath that sits the coherence chain, which is what a reviewer traces when deciding whether an application is real:

    Problem → Question → Objectives → Work packages → Milestones →
    Team roles → Budget lines → Impact activities

Every element must connect forward and backward. An objective with no work package is a wish. A work package with no budget line is unfunded. A budget line with no work package is padding. An impact activity with neither time nor money is decoration. Reviewers do not necessarily trace this chain formally, but they notice when it breaks, and the break is usually what they cite when they explain a low score for feasibility.

## 9. Output format

Follow the funder's required structure exactly. The content below maps into it.

**1. Criteria map.**

| Criterion | Weight | Where addressed | Evidence supplied | Owner |
|---|---|---|---|---|

**2. Hard-rules checklist.** Eligibility, limits, required sections, formatting, deadlines (internal and funder), each confirmed.

**3. Fit statement.** The funder priorities the project serves, and the objectives and work-plan elements that serve them. Partial fit stated as partial.

**4. Case for support.** Problem and significance (with the plain-language statement placed early), state of knowledge and gap, aim and objectives, approach with its alternatives addressed, why now and why this team.

**5. Work plan.**

| Work package | Objective served | Activities | Duration and dates | Dependencies | Lead | Outputs |
|---|---|---|---|---|---|---|

**6. Milestones.** Verifiable events with dates.

**7. Risk register.**

| Risk | Likelihood | Impact | Mitigation | Where the mitigation sits in the plan |
|---|---|---|---|---|

**8. Team justification.** Capability required per work package, person or role supplying it, evidence, committed time.

**9. Budget and justification.** Every line mapped to a work package, with a stated reason for the resource and its scale. Figures sourced, not estimated.

**10. Impact plan.** Beneficiaries, pathway, activities (scheduled and costed), indicators.

**11. Data management, ethics and governance.**

**12. Resubmission statement**, where applicable: what changed and why.

**When something is not yet known, the application says so rather than inventing it (K4 §1).** An unconfirmed partner is "in discussion", not "confirmed". A cost not yet obtained from the finance function is marked `[to be costed]` in the draft and obtained before submission, never estimated into place. A track record item is what the person actually did. Preliminary data is described at the scale it exists. An application that overclaims in any of these is a representation by named people to a funder, and the consequences of it being wrong are of a different kind from those of a weak score.

## 10. Quality checks

Run before submission. These sit on top of K4 §8.

1. Has every assessment criterion been located in the application, and would a reviewer find it without searching?
2. Does every criterion carrying significant weight receive proportionate space?
3. Is every hard rule complied with: eligibility, limits, required sections, formatting, deadlines?
4. Can a non-specialist state, from the first page, what is being asked and why it matters?
5. Is the funder fit visible in the objectives and work plan, not only in the framing?
6. Are the objectives outcomes rather than activities, and are there few enough of them?
7. Does every methodological choice carry a reason, including against the obvious alternative?
8. Does the work plan pass the dependency test and the slack test, and do the approval and recruitment timelines match reality?
9. Does the risk register contain at least one risk the applicant actually worries about, including the possibility that the central hypothesis is wrong?
10. Does every named person have a job and a stated time commitment?
11. Does every budget line map to a work package, does every work package have the resources it needs, and are all figures sourced rather than estimated?
12. Does the impact plan name beneficiaries, articulate a pathway, and schedule and cost its activities?
13. Are the data management and ethics sections specific, with any sharing restriction stated and reasoned?
14. Is every claim about track record, access, partnership and institutional support factually true and verifiable by the person making it?
15. Has someone outside the subfield read it and been able to say what it is for?

## 11. Common failure modes

| Failure | How to recognise it | How to prevent it |
|---|---|---|
| **Written to the project, not the criteria** | A good description in which two criteria cannot be located | Build the criteria map first (Step 1) |
| **Manufactured fit** | Priority language in the first and last paragraphs only | Test fit in the objectives and work plan (Step 2) |
| **Significance assumed** | Adjectives doing the work: "critical", "vital", "urgent" | Argue significance in plain language and test it (Step 3) |
| **Objectives that are activities** | Objectives beginning "conduct", "collect", "review" | Objectives are outcomes, and there are few (Step 4) |
| **Method chosen without argument** | An approach stated and never defended | Argue against the obvious alternative (Step 4) |
| **Track record as credential** | A list of achievements with no link to the work | Use it as evidence that this kind of work gets delivered (Step 5) |
| **The fully occupied plan** | Every month allocated, no contingency | Apply the slack test (Step 6) |
| **Ritual risk register** | Generic risks with generic mitigations | Include the risk you actually worry about, including scientific failure (Step 6) |
| **Decorative team members** | Distinguished names with nominal time | Every name has a job and a committed time (Step 7) |
| **Budget that does not match the plan** | An activity with no resource, or a line with no activity | Build from the plan, then read it back (Step 8) |
| **Under-costing to look cheap** | A budget that could not deliver the plan | Proportionality, not minimisation (Step 8) |
| **Impact as aspiration** | "Findings will be widely disseminated" | Beneficiaries, pathway, costed activities, indicators (Step 9) |
| **Approvals not in the schedule** | Fieldwork starts in month one | Build approval timelines into the plan (Step 10) |
| **Resubmission by instinct** | The old comments were read once and never revisited | Sort the comments and address them in the body (Step 11) |
| **AI-invented specifics** | A confident cost, success rate, funder priority or collaborator commitment nobody supplied | Nothing enters the application unsourced (§12.3, §12.5) |
| **AI-inflated track record** | Achievements phrased more impressively than the facts support | Track record is fact, supplied by the person (§12.4) |
| **Rejection read as verdict** | The applicant stops applying | State the base rate and plan a portfolio (Step 12) |

## 12. AI guardrails

Skill-specific. The universal prohibitions in K4 apply in full and are not repeated.

1. **Academic integrity is the binding constraint on everything in this skill.** These skills assist a researcher's thinking, structure and rigour. They do not produce work to be submitted as the researcher's own unaided output. The user must comply with the policies of their institution and of the venue they are submitting to, including any requirement to declare AI assistance. Many publishers now require disclosure of AI use in manuscript preparation and prohibit it entirely in peer review. The skill never writes a passage for submission as though the author wrote it; it interrogates, structures, critiques and teaches. Funders are increasingly explicit about AI use in applications, and some prohibit or require declaration of it; check the call and the institution's rules and comply. Note also the reciprocal obligation: a researcher reviewing someone else's application holds it in confidence exactly as a manuscript reviewer does, and must not enter it into an AI system where the funder's policy prohibits it (see **15.26 Peer Review Response**, Section 2).

2. **Never state a fact about a funder, a scheme or a call from model knowledge.** Priorities, eligibility rules, criteria, weightings, cost rules, page limits, deadlines and success rates change between rounds. Every such statement comes from the call document supplied in this project, or it is marked as unverified with a note to check. Never name funders or schemes speculatively.

3. **Never invent a number.** This includes costs, salaries, overhead rates, participant payments, equipment prices, success rates, sample sizes, and any figure in the budget. Costs come from the institution's costing function or from a real quotation. Where a figure is not yet available, write `[to be costed]` and say who must supply it.

4. **Never embellish a track record, and never infer one.** Publications, grants held, roles, access, collaborations and career history are matters of fact supplied by the people concerned. Do not upgrade a contribution, do not describe a relationship as a partnership without agreement, and do not generate a list of the applicant's outputs. An application is a representation by named people, and a false statement in one is a serious matter (K4 §2.5).

5. **Never describe a commitment that has not been made.** Institutional support, collaborator involvement, data or site access, facility time, and letters of support are agreed with the people who own them or they are described accurately as unconfirmed. "In discussion" is a legitimate and often perfectly acceptable status; "confirmed" when it is not is a misrepresentation.

6. **Never manufacture fit with a funder's priorities.** Where the project does not serve the remit, say so. Generating priority-aligned framing for a project that does not serve the priority is the specific failure this rule prohibits, it is detectable, and it damages the applicant's standing with a funder they will apply to again.

7. **Never overclaim impact.** Do not promise societal, policy or economic outcomes a research project cannot deliver, and do not attach indicators the project could not evidence. Where impact is primarily academic, say so; that is a legitimate answer in most schemes and a stronger one than an implausible claim (K3 §3.5).

8. **Do not assume a discipline, country, funding system or career stage.** Scheme structures, cost rules, overhead treatment, the meaning and weight of impact, what counts as track record, career-stage definitions and eligibility conventions differ profoundly between countries, funders and fields. Where a convention matters and is unknown, ask, or state the assumption at the point it bites and mark it unverified.

9. **Do not present an estimate of success probability.** Where a scheme publishes a success rate, cite it; where it does not, say it is not published. An invented probability is both unfounded and, at the point a researcher is deciding whether to invest three weeks, actively harmful.

## 13. Best-practice principles

- **Read the call twice before writing once.** The criteria, the hard rules and the scheme's own statement of purpose are the whole specification, and most of the avoidable failures are in there.
- **Write to the criteria and signpost them.** A reviewer scoring against a scheme will thank you for making each criterion findable, and gratitude shows up in scores.
- **Weight your effort by the weighting.** Applicants routinely spend most of their time on the section they enjoy and least on the section carrying a third of the marks.
- **The plain-language version is not a simplification, it is a test.** If the significance survives being stated plainly, it is real; if it evaporates, the panel would have found that too.
- **Objectives are things achieved, not things done, and the method is argued against the alternative the reviewer is thinking of.** They are thinking of one.
- **Feasibility is the criterion applicants assume and reviewers doubt.** Evidence it: prior delivery, confirmed access, pilot data, a realistic schedule that puts approvals where they actually fall.
- **A plan with no slack is not ambitious, it is unfinished.**
- **Name the risk you actually worry about, including that the hypothesis is wrong.** It is the strongest signal of a real project in the whole application.
- **Every name needs a job; every budget line needs an activity; every impact claim needs a scheduled, costed action.** Under-costing is a feasibility risk, not a virtue.
- **Impact starts during the project, not after it.** Audiences that matter have to be involved before the findings exist.
- **Get someone outside your subfield to read it and tell you what it is for.** If they cannot, the panel will not either.
- **Most applications fail, and that is a base rate rather than a verdict.** Plan a portfolio, reuse components, protect the time for the next one, and decide in advance what happens to the project if this one does not land.

## 14. Worked example

Generic fictional scenario, academic and NGO partnership (applied social research).

**INPUT**

A researcher, three years into a first academic post, plans a three-year project on how community organisations adapt national guidance on flood preparedness to local conditions. A call is open from a funder whose stated priorities are climate resilience and community-led adaptation. The researcher has a completed doctorate on a related topic, one small internal grant delivered, a working relationship with two community organisations, and no experience of a project of this size. Twelve weeks to the deadline.

**PROCESS**

*Step 1.* Five criteria: significance and fit to the scheme's priorities (30%), research quality and approach (25%), feasibility and delivery (20%), team and capability (10%), pathways to impact (15%). The criteria map immediately exposes a misallocation: the draft outline devotes most of its length to the approach, which carries a quarter of the marks, one paragraph to impact, which carries 15%, and two sentences to feasibility, which carries 20%. Reallocated. The hard rules turn up a 36-month duration cap, a required named partner organisation, and an internal costing deadline three weeks before the funder's.

*Step 2.* Community-led adaptation is not a framing here: the core question is about local adaptation of guidance, and the partner organisations are co-designing the fieldwork. The priority is in the objectives and removing it would change the project. Fit is genuine and is stated with the objectives that serve it. Climate resilience is served indirectly, and this is stated as partial rather than claimed whole.

*Step 3.* The plain-language version exposes a real weakness: the draft's significance rested on flooding being important, which is true and is not an argument for this project. Rewritten to argue the specific gap, that national guidance is evaluated on whether it is issued rather than on how it is locally interpreted, so the failure point is invisible to the bodies that could fix it. That version goes on the first page.

*Steps 5 and 6.* Feasibility is the weakest criterion and gets the most rework. Prior delivery is thin, so the small internal grant is presented as delivery at its actual scale and the other three legs are strengthened. Access is confirmed in writing with both organisations. A three-site pilot from the previous year, dismissed by the researcher as too small to mention, becomes the centrepiece, because it shows the recruitment route works and the protocol functions. The plan is rebuilt with approvals in months one to four, recruitment one to three, and no fieldwork before month five, removing the schedule's largest implausibility.

*The judgement call.* The researcher wants to name a senior professor as co-investigator at 5% time with no defined role, to strengthen the team criterion. That is the decorative-name failure and would be read as one. The alternative is a co-investigator with a defined work package (comparative analysis across sites) at meaningful time, plus a costed advisory group including the professor in a role honest about what it is. The second is chosen: it scores better and it is true. Flagged as a researcher decision, because it involves a professional relationship the skill cannot weigh.

*Step 8.* The budget is built from the plan and read back. Reading back catches two errors: the partner's co-design time is in the plan and not the budget, and a transcription cost covers more interviews than the plan specifies. Both fixed. All figures come from the costing function and the partners; none is estimated.

*Step 9.* Impact becomes a plan. Beneficiaries: the two partner organisations and their network, the local authority emergency planning function, and the national body issuing the guidance. Pathway: that body acts only on evidence its review cycle can absorb, so the output must reach it during a consultation window in year three, now a scheduled milestone. Activities: three practitioner workshops, a short practice-facing output and participation in the consultation, all scheduled and costed. Indicators framed as engagement and uptake rather than reduced flood damage.

*Step 12.* The scheme publishes a success rate below one in five. A smaller second call is identified as a fallback that would fund the first work package alone and establish feasibility for a later full application, and an unsuccessful outcome triggers that route rather than a pause.

**OUTPUT**

An application in which each of the five criteria is signposted and proportionately resourced, a significance argument that survives plain language, a feasibility case built on a pilot the applicant had underrated, a work plan whose schedule accounts for approvals, a team section in which every name has a job, a budget every line of which maps to an activity, an impact plan timed to an external decision window, and a documented fallback if the application does not succeed.

`RESEARCHER SIGN-OFF REQUIRED` on the whole submission, and on every statement about partners, access and institutional support (K5 §2.8).

## 15. Advanced usage

**Building a reusable component library.** Applicants who submit regularly should maintain adaptable components: the significance argument for their problem area, team and capability descriptions, the data management approach, standard risk entries with real mitigations, and impact pathways for recurring audiences. This is not boilerplate reuse, since each component is still tailored to the call's criteria. It is the difference between writing a fourth application in three weeks and writing it in eight.

**Staging a research programme across schemes.** Where the ambition exceeds what one scheme funds, design the sequence: a small award establishing feasibility and generating pilot data, a mid-scale project delivering the core work, and a larger application whose feasibility case is built on delivered work rather than assertion. This converts the base-rate problem into a ladder and turns each unsuccessful application into a stronger next one. Pairs with **15.17 Longitudinal and Multi-Study Design**.

**Writing for a two-stage scheme.** Where an outline precedes a full application, it is assessed on fit and significance far more than on method, and the commonest error is submitting a compressed full application. Write the outline to the outline's criteria and hold the methodological detail for the stage that asks for it.

**Reading an unsuccessful outcome accurately.** Distinguish three cases from the feedback: scored well and missed the line (resubmit with modest strengthening); scored poorly on a criterion that can be fixed (rebuild that section); scored poorly on fit or significance (different funder, or rethink the question). Applicants reliably read all three as the third and stop, or as the first and resubmit unchanged. Both errors are expensive.

**Where the standard approach does not fit.** Fellowships assess the person as much as the project, and the career narrative becomes a scored component with its own logic. Consortium applications add coordination, partner agreements and governance as substantial sections, and the work plan becomes a cross-institutional negotiation with its own timeline. Practice-based and applied schemes may weight outputs and engagement over method. Some schemes assess anonymously, which changes how track record can be presented. In every case, return to Step 1: the criteria are the specification, and they are what varies.

## 16. Skill chain

**Recommended previous skills:**
- **15.04 Research Proposal Writing.** Hands over the problem statement, aim, objectives, method and scope, which this skill re-argues against a funder's criteria rather than an academic reader's.
- **15.13 Doctoral Research Positioning and Originality.** Hands over the originality claim and its defence, which underpins the significance criterion.
- **15.06 Systematic Literature Review** or **10.01 Literature Review and Desk Research.** Hands over the evidence for the gap, which is what makes the significance argument checkable.

**Recommended next skills:**
- **15.09 Ethics Clearance Application.** Takes the ethics section into the institutional approval process, on the timeline the work plan assumes.
- **01.04 Research Method Selection** and the design track. Take the funded approach into detailed study design.
- **15.24 Journal Article Development** and **15.27 Conference Abstract and Presentation.** Take the outputs the impact plan commits to.

**Runs well alongside:**
- **15.26 Peer Review Response**, whose comment-sorting method applies directly to funder feedback at resubmission, and whose confidentiality rules apply to reviewing others' applications.
- **13.05 Research Ethics and Consent Design**, for the ethics and governance sections.
- **13.06 AI Research Governance**, for the AI use declarations funders increasingly require.
- **14.03 Research Repository and Knowledge Curation**, for the reusable component library in Section 15.

---
A Yazi Supplied Skill and resource.