By the last day, everyone who touched the application has read their own part so many times that they can't see it anymore. The final read is the one chance to look at the whole package with fresh eyes, and the temptation is to spend it improving sentences.
Don't. The final read has a narrower job: find anything that will cost you points or make the application ineligible. This article gives you a short list of what to check, how to test that your numbers agree, what to let go and how to record the sign-off.
Why compliance comes first
Some funders do not review applications that fail their instructions. NIH states that noncompliant applications may be withdrawn from the review and funding consideration process, and its checks cover font, type size, page limits and margins. NIH's compliance policy gives examples that include biosketches that don't follow the required format and inappropriate material pushing a section over its page limit.
NSF is similar. Its Proposal & Award Policies & Procedures Guide says NSF "will not accept or will return without review proposals that are not consistent with these instructions," and that its Research.gov system checks proposals for compliance before submission. The guide also strongly recommends that proposers do their own administrative review before submitting.
Funders differ in how strictly they enforce their instructions, and you rarely know in advance how yours will. A missed requirement is also one of the few problems you can fully prevent. Your notice is the authority here, so read the notice again with the finished draft next to it.
Check the requirements, item by item
Use the notice, not your memory. For each item, find it in the notice and find it in your package:
- Eligibility and funder name. The applicant's legal name, the funder's name and the program name are correct everywhere, including the headers carried over from a previous application.
- Page, word and character limits. Check the limits for each section, not only the total. Check font, size, margins and spacing if the notice sets them.
- Required sections in the required order, with the headings the funder uses.
- Required forms and attachments. Count them. Every form signed or completed, every letter attached, every attachment opening and in the right file type.
- Budget rules. Indirect costs follow the rate the notice allows, caps are respected, and cost share or match is shown where required.
- Scoring criteria. Take each review criterion and find the paragraph that answers it. If you can't, that's the gap to fix.
- Dates, deadlines and period of performance. They agree with the notice and with each other.
For a reviewer, the criteria are the rubric. A section that is well written but answers the wrong question scores poorly, and a missing section can score nothing. Decoding the scoring criteria shows how to turn them into a checklist.
Test your numbers across the whole package
Numbers fail quietly. The narrative says one thing, the budget another and the form a third, and each author was sure theirs was right.
Make a one-page list of every number that appears in more than one place, and compare them:
- Number of people served
- Number of staff, positions and full-time equivalents
- Total request, annual request and cost share
- Project start and end dates
- Counts of sessions, sites or deliverables
Here is a hypothetical example. Say a food bank's narrative promises meals for 250 households, its logic model says 240 and the budget divides $150,000 across 250. A reviewer who notices the mismatch has a reason to doubt the rest. The fix is to pick the correct number, update every place it appears and recheck the per-household cost: $150,000 divided by 250 is $600.
Do the arithmetic yourself, too. Add up the budget columns, the budget narrative and the total on the federal form. Budgets that tell a story explains how the pieces should connect.
Read it twice, in two different ways
One read won't catch both kinds of problem.
- Read as the reviewer. Print it or view it as a PDF, as it will be submitted, not in the editing view. Read straight through, with the scoring criteria beside you. Mark each place you get lost or can't find an answer.
- Read as a checker. Go through the list above, ticking items off. Check hyperlinks, names of people and partners, and any reference to another document.
If the people who wrote the application are tired, ask someone who didn't. A colleague who hasn't seen the draft will notice what the authors can't.
What to let go
At this stage, every change risks a new error. Leave these alone:
- A word you'd have chosen differently
- A paragraph you'd like to rewrite from scratch
- A stylistic preference that doesn't affect compliance, scoring or accuracy
- New ideas, however good
If a fix is needed, make the smallest change that solves the problem, then recheck anything that depends on it. A change to the budget total, for example, touches the narrative, the forms and the summary.
Keep a list of improvements you'd like to make later. They are material for the next application.
Sign-off and records
Decide before the read who gives the final approval to submit. It should be a named person, not "the team." That person should see the final package, not a summary.
Record the sign-off in an email or on the checklist, with the date and time. Note which version of the package was approved, then submit exactly that version. If anything changes after approval, the approver sees it again.
Your next step
Build a one-page final-read checklist from the notice for your next application: the requirements above, the numbers that must match and the name of the person who signs off. Use it on your next submission, then add anything that surprised you.
SoliContraX can help by listing what the notice asked for that your draft doesn't yet answer, so the gaps are visible before the last read. A person still reads the whole package and signs off. Start your next application.