Resources
Grant programs succeed or fail long before they reach delivery. Outcomes are shaped by how policy intent is interpreted, encoded, and explained at the program design stage. This section brings together resources that examine those early decisions and their systemic effects.
DELIVERABLES
These are just some the concrete outputs clients receive when they engage me. Each deliverable addresses a specific structural problem in grant programs and is designed to be practical, defensible, and usable.
What Does a Grant Application Design Spec Actually Look Like?
The question this answers What is the technical deliverable that turns application design into something a platform team can build? What the problem
Why do small orgs give up before they finish your application?
The question this answers How do you design a grant application form that scales evidence requirements to project size and risk? What the problem
Would your grant decisions stand up to a probity complaint?
The question this answers How do we make sure decision-makers act appropriately and can prove it? What the problem looks like without probity
Are your grant program integrity controls mapped to real risks?
The question this answers Which controls address which risks, and who’s responsible? What the problem looks like without a control framework mapped to identified
Do You Actually Understand Your Grant Program’s Fraud Risks?
The question this answers: Where are the vulnerabilities in our grant program, and how likely is someone to exploit them? What the problem
Are Your Panel Processes Protecting the Program Or Exposing It?
The question this answers: How do we run the panel so decisions are fair and defensible? What the problem looks like without panel
Do Your Assessment Scores Mean What You Think They Mean?
The question this answers: What does a “3 out of 5” assessment score actually mean? What the problem looks like without rating scales
Does Your Assessment Framework Pick the Right Applications?
The question this answers How do we make sure the right grant applications get funded? What the problem looks like without assessment criteria
Why do you keep asking applicants for the same information?
The question this answers How do you design a grant program so data is collected once and used everywhere? What the problem looks
Case Studies
Short, practical pieces focused on where grant program design goes wrong in practice, and how to fix it early. These articles are written for people working inside grant programs who need clarity, not theory. They draw on real assessment, delivery, and review experience to surface problems that are usually only acknowledged once a program is already in trouble.
What changes when you write grant guidelines for applicants, not policy?
Policy tells you why.Guidelines tell people how. Most grant programs confuse the two A Case Study by Geoffrey Clow | Expert Grant Program Advisory Why
AI-Augmented Grantmaking: A Case Study
What happens when a funder asks what AI is actually for, before turning it on? A Case Study by Geoffrey Clow | Expert Grant Program
Designing Grant Programs for Outcomes and Systems: A Case Study
What happens when a funder stops counting outputs and starts measuring change? A Case Study by Geoffrey Clow | Expert Grant Program Advisory The Dirty
White Papers
Longer, technical analysis for senior policy teams, grant program leads, and decision-makers responsible for setting direction. These papers examine structural design choices, integrity risks, efficiency failures, and recurring issues that tend to surface during audits, reviews, or external scrutiny. They are intended to support internal decision-making, reform work, and defensible program design.
Grant Standardisation Done Right
The reason is almost never discussed: most grant standardisation starts at the wrong end of the grant program. It starts at the form, the workflow, the reporting template. These are downstream consequences of design decisions that were made, or not made, much earlier.
Grant program standardisation amplifies what is already in the design. If the design is clear, standardisation makes clarity consistent. If the design is ambiguous, standardisation makes ambiguity consistent. A cleaner form does not fix a confused grant program. It just gives the confusion better stationery.
This white paper makes the case for a different sequence: design first, then standardise.
The AI Assesssor Is the Wrong Idea
The grant sector built AI tools that process applications. It should have built tools that improve decisions. Those are not the same thing, and the difference is where most of the money, time, and genuine potential in AI for grantmaking is currently being lost.
The tools on offer operate almost entirely at the application layer: eligibility checking, document summarisation, preliminary scoring. This is first-generation thinking. It solves a workflow problem while leaving the integrity, equity, and intelligence problems in grantmaking completely untouched.
This white paper argues that the AI assessor is not the destination. It is a distraction. The real opportunity lies across five distinct layers of the grantmaking system, and almost no current product addresses more than the first. This paper names all five, and gives you the questions to put to a vendor before you sign anything.
The Better Best Practice Grantmaking Lifecycle
Somewhere in a government department, a grant program manager is sitting in a post-round debrief explaining why the grant program did not work the way anyone expected. The applications were inconsistent. The assessment panel could not agree on what good looked like. The minister’s office is asking what the program actually achieved, and the data does not answer the question.
The room agrees that lessons learned should feed into the next round. It is also the same conversation that happened after the last round, and the round before that.
Grant programs behave exactly as they are designed. When they are not deliberately designed, they behave exactly as they did last time.
This white paper argues that the sector’s lifecycle models describe administration in detail and treat design as a preliminary note. That is the gap this paper closes.