The Complete Guide to Grant Evaluation, From Proposal to Final Report

Grant evaluation works best as a feedback loop that runs through the whole award

Grant evaluation works best as a feedback loop that runs from the proposal to the final report, with findings reaching the project team throughout the award. Many grant-funded evaluations begin because a solicitation asks for one, and that requirement is real: the evaluation has to meet it. But compliance should never be its only purpose. At its best, an evaluation helps a project understand what's working, what isn't, what the team is learning, and what it should do next.

We think of evaluation as a cycle. The program produces data, the data leads to learning, learning leads to action, and action leads back to a better program. That cycle should repeat throughout the life of a project. A grant's calendar gives it natural points to turn: the proposal, the weeks after the award notice, each budget year, each annual report, and the end of the grant.

The two NSF figures are one example of a funder's calendar, and your own funder's may differ.

What carries across funders is that each stage asks something different of the evaluation, and each depends on the one before it.

A plan designed with the proposal is easier to start after the award. Findings shared during the year make the annual report easier to write. An honest record of how the program ran is what makes the final results possible to interpret. The sections below walk those stages in order and link to the pages that answer each question in detail.

Between the award notice and the kickoff meeting, your institution's steps decide when the evaluation can start

Between the award notice and the kickoff meeting, the steps that decide when a grant evaluation can start are mostly your institution's, and most of them can begin before the award starts. That's why your evaluator should hear from you as soon as the notice arrives, not on the grant's start date.

The evaluation can't begin until the agreement is signed, and the institutional steps around it are the ones most likely to delay the start. In the order they usually come:

• 1
  Sign the agreement

  The evaluator sends it, and your institution finds who is authorized to sign and whether legal or contracts review is needed.

• 2
  Set the evaluator up as a vendor

  Your procurement or accounts payable office registers the evaluator, usually with forms the evaluator provides.

• 3
  Arrange payment

  Often a purchase order against the award budget, with invoicing instructions from your finance office.

• 4
  Name the project team

  The principal investigator (PI), any co-PIs, the project coordinator, and your contacts for finance, procurement, and the IRB.

• 5
  Review IRB requirements and data agreements

  Your institution's IRB process, and any data use, data sharing, or confidentiality agreement needed before the evaluator receives participant or institutional data.

• 6
  Hold the kickoff meeting

  The team agrees on goals and timeline, roles, how you'll communicate, the evaluation activities and data collection, and the IRB plan.

Every institution's procedures are different, so ask each office what it needs.

After the kickoff, the evaluation moves into a regular schedule set out in the scope of work. Grantibly typically meets with project teams quarterly for about an hour, with email in between and reports timed to the funder's calendar, though we can meet more or less often depending on the project.

When to get your evaluator involved once your project is funded has the detail on each step, and what the evaluation process looks like from kickoff to final report describes the work phase by phase.

During the grant, formative evaluation shares findings while the project team can still change the program

During the grant, formative evaluation gathers information while the program runs and shares findings with the project team while there's still time to make changes. Funders often ask for formative and summative evaluation together, because each does what the other can't.

NSF's ATE solicitation is one example of how a funder describes the pair: it says the evaluator's primary role is to inform the project team's decisions about changes to the project as it's carried out, and that at the end of the project the evaluator should provide a summative evaluation.

Formative findings only help if they arrive in time, so they belong in project meetings and planning conversations as well as in formal reports. At Grantibly, they reach the team through regular meetings and shorter summaries between those reports.

What the evaluation collects during the grant follows from its questions: the information that answers your evaluation questions and meets your funder's reporting requirements. More data isn't necessarily better, because every added survey or measure creates work for participants, project staff, and the evaluator.

Often the funder doesn't require a type of data but rather wants an answer to a question. Start with what already exists, such as participation and attendance records, institutional data, applications, and surveys you already run, and collect only what's missing.

Each evaluation question decides the method. Numbers show patterns and change, and interviews or focus groups help explain why.

The pages on the difference between formative and summative evaluation and what data you need to collect go further into each.

A grant's final evaluation report shows what the project accomplished and what it learned

A grant's final evaluation report shows what the project accomplished, what changed for the students or participants it served, and what the team learned, and it's where the summative evaluation does most of its work. NSF's ATE solicitation, as one example, asks the evaluator to provide a summative evaluation at the end of the project identifying key accomplishments, their impacts, and lessons learned.

NSF also requires a final annual project report and a project outcomes report for the general public no later than 120 days after the grant expires.

A final report is easier to write, and easier to trust, when it isn't the first time anyone has looked closely at the program. Positive outcomes don't automatically show what produced them, and outcomes that fall short don't automatically mean the idea was ineffective. The record built across the grant, of how the program ran, what changed, and why, is what lets the final report explain its results.

The questions a final report answers are worth asking from the start. These are among the ones we want project teams to be asking:

• Instead of "Did the program work?" Ask what worked, for whom, under what conditions, and what evidence supports that conclusion.
• Instead of "How many people participated?" Ask who participated, who didn't, what they experienced, and what changed as a result.
• Instead of "How do we show the funder that we're successful?" Ask what you're genuinely learning about your progress toward the outcomes you promised.

An honest final report can also help with what comes next. It shows that the team thinks critically about the work and uses resources responsibly, which can count in future proposals, though no one can promise it will lead to new funding. Turning program data into a report your funder reads covers making any report readable and used.

What grant evaluation from proposal to final report comes down to

Grant evaluation from proposal to final report comes down to one practice repeated at every stage: gather the information the project needs, share it while the team can still use it, and act on what it shows. The evaluator designs that work with you in the proposal, your institution's steps get it started, formative findings carry it through each year, and the final report draws it together.

Meeting the funder's requirement matters, and an evaluation built this way meets it. It also gives the project team a steady account of what's working, what isn't, and what to change while the grant is still running.

Evaluation is most valuable when it's integrated into the work.