When leadership asks how the grants program is doing, the easy answer is a success rate: "we got four of ten." That number is simple, and it can be misleading. It rewards applying only to sure things, and it says nothing about how much money came in or what it took to get it.
This article gives managers and development directors a short set of metrics in three groups, shows how a high success rate can hide a weak result and explains how to report the numbers so they lead to better decisions.
Pipeline metrics: what is coming
Pipeline metrics tell you whether there is enough in the works to meet your goals. They are the earliest signal, because they change months before revenue does.
- Prospects identified. How many opportunities are on your list at each stage?
- Applications submitted. Count by quarter and by funder type.
- Conversion by stage. Of the prospects you researched, how many became applications? Of the applications, how many were funded?
Conversion by stage shows where the funnel leaks. If many qualified prospects never become applications, the problem is capacity or decision-making, not writing. Building a grants calendar and pipeline shows how to set up the stages these numbers depend on.
Outcome metrics: what came in
Outcome metrics show the results.
- Success rate by funder type. Federal, state, foundation and corporate funders behave differently, so a blended rate hides useful detail.
- Dollars awarded. Report the total, and compare it with what you requested.
- Average award size. A rising or falling average tells you whether you are asking for the right amounts.
- Renewals and multi-year commitments. Revenue you can count on in later years is worth more than a one-time award of the same size.
Report dollars awarded and dollars requested together. An organization that receives half of what it asks for each time may be underbudgeting its requests or applying to funders that can't fund the full need.
Efficiency metrics: what it took
Efficiency metrics connect results to effort.
- Hours per application. Ask writers to log time by application, split by drafting, review and administration.
- Dollars awarded per hour. Divide awards by the hours spent, including unsuccessful applications.
- Cost per dollar raised. Multiply hours by a loaded hourly cost, then divide by dollars awarded.
If you charge costs to federal awards, keep this tracking separate from award-funded work. Under 2 CFR 200.460, the costs of preparing proposals for potential federal and non-federal awards normally should be treated as indirect costs. Confirm with your finance team how your organization allocates them.
The success-rate trap
Say a development director runs two strategies on paper. This is a hypothetical, with round numbers to keep the arithmetic clear. The loaded cost is $45 per hour.
| Strategy A: safe bets only | Strategy B: safe bets plus stretch | |
|---|---|---|
| Applications | 4 | 10 |
| Awards | 3 | 5 |
| Success rate | 75% | 50% |
| Dollars awarded | $60,000 | $160,000 |
| Hours spent | 60 | 300 |
| Dollars per hour | $1,000 | about $533 |
| Cost per dollar raised | about $0.045 | about $0.084 |
Strategy A has the better success rate and the better efficiency. Strategy B raised $100,000 more. The extra $100,000 took 240 more hours, or about $417 per hour. Whether that is worth it depends on your needs and your capacity. If the program needs more revenue and you have the time, B is the better choice, even though the headline rate is lower.
The lesson is not that stretch applications are always better. The lesson is that no single number answers the question. Present success rate alongside dollars and hours, so leadership can see the trade.
Know where the numbers come from
Metrics are only as good as their sources. Pull pipeline counts from your tracker, awards from signed award letters or your accounting records, and hours from timesheets or a simple log kept by each writer. Don't reconstruct hours from memory at year end, because estimates drift upward for hard applications and downward for easy ones. Decide who is responsible for each source and update them monthly.
Match your metrics to what funders measure
Federal rules expect you to measure performance, too. Under 2 CFR 200.301, the federal agency must measure the recipient's performance to show achievement of program goals and objectives. Under 2 CFR 200.329, a recipient reporting program performance must relate financial data and project or program accomplishments to the performance goals and objectives of the award. Your funders' reporting requirements will often tell you which program metrics to track from the first day. Reporting and closeout explains what those reports ask for.
Keep grant-operations metrics separate from program outcome metrics. Pipeline and efficiency numbers describe how well the grants function works. Outcome numbers describe what the funded program achieved. Boards and leadership need both, and they answer different questions.
Report the numbers so they lead to decisions
A few habits make the reporting useful:
- Use a fixed period. Report the same 12 months each time, with the same definitions.
- Show trends, not snapshots. One year of data is a start; three years shows a pattern.
- Add one sentence of interpretation per metric. "Conversion from qualified to submitted fell because we took on a large federal application" says more than the number does.
- End with a decision or request. If a metric points to a capacity gap, say so and propose a response. Managing a grant team covers the workload side.
Decide the definitions once. Does "submitted" include letters of inquiry? Does "awarded" include renewals? Write the answers down so the numbers stay comparable from one year to the next.
Your next step
Pick three metrics, one from each group, and report them for the last 12 months. Dollars awarded, hours per application and conversion from qualified to submitted are a good start. Note the definition you used for each one, so later years' numbers are comparable.
When the metrics say an application is worth the effort, SoliContraX can help you get from the notice to a finished application, starting from a draft written from your own files. Start your next application.