Why Outcomes Are Built, Not Measured
The meeting that keeps happening
Somewhere in a government department, a grant program manager is sitting in a post-round debrief explaining why the grant program didn’t work the way anyone expected.
The applications were inconsistent. The assessment panel couldn’t agree on what “really good” looked like. The minister’s office is asking what the grant program actually achieved, and the data doesn’t answer the question. The guidelines are being reviewed for next round, but nobody is sure what to change because nobody is sure what went wrong.
The room agrees that “lessons learned” should feed into the next round. Someone suggests better reporting templates. Someone else raises the possibility of an outcomes framework. The conversation is earnest and well-intentioned. It is also the same conversation that happened after the last round, and the round before that. I know, because I have been in that room more times than I can count.
The grant program will be tweaked. The guidelines will be updated. The assessment criteria will be adjusted. And the next round will produce approximately the same results, because the thing that actually determines results was never on the table.
That thing is program design. Not guidelines. Not reporting. Not assessment panel training. The structural decisions that determine what the program funds, how it decides, and whether it can produce the outcomes it claims to pursue. Those decisions were either made in a rush before the first round opened, inherited from a predecessor program, or never consciously made at all.
Grant programs behave exactly as they are designed. When they are not deliberately designed, they behave exactly as they did last time. This is not theory. It is what I see in every program that lands on my desk.
This paper argues that the grantmaking sector’s most widely used lifecycle models, the diagrams that guide how programs are planned, delivered, and evaluated, have a structural gap. They describe grant administration thoroughly. They describe program design barely at all. And until that gap is closed, no amount of better reporting, better technology, or better evaluation will reliably produce better outcomes.
What You'll Find Here
Part 1: The Outcomes Conversation We Keep Having
There is broad agreement across Australian government that grant programs should be more outcomes-focused. The Commonwealth Grants Rules and Principles 2024 now explicitly require an outcomes orientation. The Assistant Minister for Treasury has made evaluation a priority. The Treasurer’s wellbeing agenda insists we measure what matters. This is not a fringe position. It is official policy.
And yet the conversation keeps circling the same territory: better measurement, better reporting, better data collection.
The assumption is that if we define outcomes clearly and track them consistently, programs will improve. That assumption is wrong. More precisely, it is incomplete.
If the eligibility rules exclude the cohort most likely to generate the desired outcome, no reporting framework corrects that. If the assessment criteria weight organisational capacity over intervention logic, the strongest projects lose to the most established applicants, and outcomes tracking faithfully documents the result.
If the funding model offers twelve-month competitive grants for a problem that requires three years of developmental investment, evaluation will confirm what the design guaranteed: insufficient time to produce meaningful change.
- The problem is not that government fails to measure outcomes.
- The problem is that government fails to design programs that can produce them.
The standard objections to outcomes-focused grantmaking are attribution and abstraction.
- Attribution: too many external factors influence outcomes for any single program to claim credit.
- Abstraction: outcomes are inherently less concrete and countable than outputs, making them harder to track and easier to contest.
Both objections are legitimate. But both are made worse, sometimes made insurmountable, by programs that were never designed with a clear causal logic connecting what they fund to what they intend to change.
Attribution is hardest when the program cannot explain its own theory of how funding produces outcomes.
Abstraction is worst when the evidence pathways were never built into the program, so by the time evaluation arrives, the only available data is activity counts and expenditure reports.
The difficulty of measuring outcomes is real. But it is not fixed by better measurement. It is reduced by better design, design that builds the causal logic, the evidence architecture, and the evaluation framework into the program before the first dollar goes out the door.
This is not a criticism of the people doing the work. Program managers, grants administrators, and policy officers are operating within structures that compress design into a preliminary step, reward administrative compliance, and treat evaluation as a terminal activity rather than a generative one.
The grants ecosystem produces exactly what it is designed to produce. And the system was designed around administration, not outcomes. The evidence for this is visible in every lifecycle model the sector uses.
Part 2: What Current Grantmaking Lifecycle Models Actually Show
Every major grantmaking body, peak organisation, and grants management platform publishes some version of a grant program lifecycle.
These models serve an important purpose: they give practitioners a shared language for the stages of delivering a grant program. They are useful. They are also incomplete in a way that matters.
Look at any of them closely and you will find the same pattern.
The operational stages (application, assessment, decision, contracting, monitoring, acquittal) are described in detail. Each gets its own stage. Each has defined activities, responsibilities, and outputs. This makes sense. Administration is complex, consequential, and needs to be done well.
But program design is treated differently. In most models, it appears as a single stage, often the first, sometimes sitting in a central hub, labelled something like “Plan and Design” or “Program Design and Planning.” It shares space with administrative setup: configuring grants management systems, establishing record-keeping processes, preparing communications. Goals, governance, eligibility criteria, outcomes frameworks, and assessment logic are compressed into a handful of bullet points alongside database configuration.
This creates a structural distortion. The stage that determines whether the program can achieve its intended outcomes is given the same weight, often less weight, than the stage that involves telling applicants whether their application was successful.
I have yet to meet a program manager who thinks notification is as important as design. But that is what the diagram says.
Consider what “Plan and Design” is actually being asked to contain: problem definition, outcomes, theory of change, eligibility, funding model, application design, assessment logic, decision governance, and evidence collection. That is not one stage. That is the most complex and consequential phase of the entire lifecycle. Compressing it into a label does not make it simpler. It makes it invisible. And when design is invisible, it gets done by default, inherited from the last round, copied from a similar program, or assembled under time pressure in the weeks before applications open.
The lifecycle models are not wrong about what they include. They are wrong about what they leave out. They describe the engine of grant administration in detail and treat the engineering of the vehicle as a preliminary note.
The sector has become very good at improving the plumbing while quietly ignoring the architecture of the building. The pipes are polished. The water still doesn’t go where it needs to.
Part 3: A Complete Grantmaking Lifecycle
A best practice grantmaking lifecycle has three layers, not one.
The design layer is where the grant program is built to produce specific outcomes. This is where the critical decisions are made:
- what problem is being addressed,
- what change the funding is intended to produce,
- who is eligible and why,
- what evidence applicants must provide,
- how applications will be assessed,
- how decisions will be governed,
- what funding model fits the problem, and
- how evidence of outcomes will be collected through delivery.
These decisions are interdependent.
Eligibility rules shape the applicant pool. The applicant pool determines what the assessment framework encounters. The assessment framework determines what gets funded. What gets funded determines what outcomes are achievable.
The design layer is not a checklist. It is a system.
The administration layer is where applications are opened, received, assessed, decided, contracted, monitored, and closed.
This is the layer most current lifecycle models describe well, and it matters. Good administration is essential to fairness, accountability, and public trust. But administration delivers a grant program. It does not determine whether that grant program can succeed.
The learning layer is where grant program-level evaluation generates evidence that feeds directly into the design of the next iteration.
Not project-level reporting. Not financial acquittal. Program-level learning that asks: did the design work? Where did the assumptions hold? Where did they break? What would we change?
This layer exists in most grantmaking lifecycle models as a final stage (“Evaluate and Share” or similar) but it is rarely connected structurally to the next design cycle. It produces reports. It does not reliably produce redesign.
Most current models collapse the design layer into a single step, describe the administration layer in thorough detail, and treat the learning layer as an end point rather than a feedback loop. A best practice lifecycle gives each layer its full weight and recognises that the design layer is where outcomes are determined.
The Design-Led Grant Program Lifecycle
The lifecycle that follows is built on this three-layer structure. It has eight stages. It is a loop, not a line: the final stage feeds directly back into the first. And the design layer, Stages 1, 2, and 3, carries the structural weight that determines whether the remaining stages can produce outcomes.
Design Layer
Stage 1: Define the Problem
- What system-level change is the funding intended to produce?
- What does the evidence say about the nature, scale, and distribution of the problem?
- Who is affected?
- What has already been tried, and what did it achieve?
- What would success look like at the population or system level, not just the project level?
This stage establishes the foundation. Everything that follows (outcomes, eligibility, assessment, evaluation) depends on whether the problem has been defined with enough precision to guide design decisions.
A grant program that begins with a vague problem statement will produce a vague grant program.
Stage 2: Define Outcomes and Evidence
- What measurable outcomes would indicate that the program is contributing to the intended change?
- What evidence is proportionate and feasible to collect?
- What is the theory of change, the logic connecting the funding mechanism to the desired outcomes?
This is not the same as choosing indicators. It is the stage where the program decides what it means by success, how it will know if it is getting there, and what evidence framework makes evaluation possible.
The outcomes defined here must be achievable given the funding model, timeline, and cohort that the program designs in Stage 3. Outcomes and design are interdependent, which is why they sit in the same layer.
Stage 3: Design the Grant Program
This is the stage that most grantmaking lifecycle models compress into a single step. It is the heart of the lifecycle. It contains the structural decisions that determine whether the program can produce the outcomes defined in Stage 2. The sequence matters. Each decision shapes the ones that follow.
Program intent and outcomes. Before any structural decision is made, the program’s objectives, target cohort, and success measures must be made explicit and carried forward from Stage 2 into operational design. This is where the theory of change meets the mechanics of the program. Every design decision that follows should be traceable back to this intent.
Funding model. Grant quantum, duration, payment structure, tranches, co-contribution requirements. A twelve-month competitive grant produces different behaviour than a three-year developmental partnership. The funding model must match the problem’s timeframe, the outcomes’ evidence horizon, and the capacity of the cohort the program is designed to reach.
Eligibility rules. With the funding model established, define who can apply and what projects or activities are in scope. Eligibility is not a filter. It is a design decision that shapes the entire applicant pool and, by extension, the outcomes the program can achieve. Rules must match the program’s objectives and risk appetite. Rules that are vague push judgement calls onto staff. Rules that are precise resolve hard decisions at the design stage, where they can be governed and defended. I have seen programs where three experienced staff members cannot agree on whether the same applicant is eligible. That is not a training problem. That is a design failure.
Proportional evidence pathways. With the cohort and funding model defined, decide what levels of evidence the program needs from applicants and grantees, scaled to grant size and risk. This decision shapes everything downstream: what the application form asks for, what attachments are required, what monitoring looks like, and whether evaluation will have the data it needs. Small grants follow a short evidence pathway. Complex programs provide deeper substantiation. The burden of proof matches the funding risk and the evaluation ambition.
Application design. The application form is not a questionnaire. It is a decision tool. Questions should be structured to elicit exactly what assessors and decision-makers need, aligned to the eligibility rules, assessment criteria, and evidence pathways already established. Data collected at application should serve the entire lifecycle: eligibility screening, assessment, contracting, reporting, and evaluation. Reusable, not redundant.
Assessment system. Criteria, weighting, scoring methodology, calibration processes. The assessment framework should be engineered backwards from program intent: the right applications should score highest by structure, not by luck or assessor skill. Every criterion should exist because a funding decision depends on it. If you cannot explain what a score of 3 means versus a score of 4 without using the word “adequate,” the scoring architecture is not finished.
Decision governance. Who decides, on what basis, with what constraints, and what gets recorded. Specify roles and delegations, approval pathways, briefing formats, and recording of rationales. The governance structure determines whether decisions are consistent, transparent, and defensible under audit, FOI, or public scrutiny.
Guidelines design. The guidelines are the final output of this stage, not the first. They package every design decision above into external-facing documents and internal procedures that are clear, proportionate, aligned with the CGRPs or relevant state framework, and consistent across all touchpoints.
Most grant guidelines are written in policy language that was never translated for the people who actually need to use them. The result is confused applicants, poor-fit applications, and an enquiries line that becomes an unofficial helpdesk.
Guidelines that communicate program design clearly are themselves a design discipline, not an administrative task. You cannot write good guidelines until you have resolved what they need to communicate.
These elements are not independent. They are a system. Change the eligibility rules and the assessment framework encounters a different pool. Change the funding model and the evidence timeline shifts. Change the application design and the assessment criteria may no longer have the inputs they need. Stage 3 is where these interdependencies are resolved, before applications open, before assessors are briefed, before ministers are committed.
Administration Layer
Stage 4: Open and Support Applications
The grant program opens. Applicants are supported to provide the evidence the assessment system needs to make good decisions. Communications are clear about what the grant program is for, whether it is a fit, and what a good application looks like. The goal is not more applications. It is better-aligned applications.
Stage 5: Assess and Decide
Applications are assessed against the criteria designed in Stage 3. Moderation processes ensure consistency across assessors. Decisions are made through the governance structure established in Stage 3. If the design work has been done properly, assessment is execution, not interpretation. Assessors apply program logic rather than substitute their own.
Stage 6: Contract, Fund, and Monitor
Agreements are executed. Funding flows according to the payment structure designed in Stage 3. Milestone and reporting requirements reflect the evidence pathways designed in Stage 3.
Monitoring during delivery is not just compliance checking. It is structured data gathering against the outcomes framework established in Stage 2.
Evidence is collected progressively through existing touchpoints: progress reports, site visits, milestone reviews. Evaluation is built into the workflow, not created as a separate burden after funding decisions are made.
Learning Layer
Stage 7: Evaluate the Grant Program
This is program-level evaluation, not project-level acquittal.
- Did the design produce the intended outcomes?
- Where did the design assumptions hold?
- Where did they break?
- Were the eligibility rules right?
- Did the assessment framework select the right projects?
- Did the funding model give recipients enough time and resources?
- Did the evidence pathways produce data that can actually answer these questions?
Grant program evaluation is only possible if the design layer created the conditions for it.
- If outcomes were never defined precisely, evaluation has nothing to measure.
- If evidence pathways were never built into the delivery stage, the data does not exist.
- If the assessment framework was not engineered to select for outcome potential, there is no basis for asking whether the right projects were funded.
Evaluation does not sit at the end of the lifecycle. It sits at the end of a chain that begins with design.
Stage 8: Redesign
Evaluation findings become the evidence base for the next iteration. The loop returns to Stage 1, but with data.
The problem definition is revisited in light of what the grant program learned. Outcomes and evidence standards are refined. Design decisions in Stage 3 are reconsidered based on what worked and what did not.
This is how good grant programs improve structurally, not just administratively. Not by tweaking guidelines between rounds, but by feeding program-level evidence back into program-level design.
The lifecycle is a loop because grant programs are not one-off events. They are iterated systems. The quality of each iteration depends on whether the learning from the last one reaches the design layer, or stops at the administration layer, where it produces minor adjustments to forms and processes but never questions the underlying structure.
Part 4: Why This Matters Now
Three forces make this shift urgent rather than aspirational.
Fiscal pressure demands design discipline. Australian governments are spending an estimated $125 billion annually on grants. When budgets are constrained and productivity is stagnant, the question is no longer whether programs are administered properly but whether they are producing results. Better administration cannot answer that question. Better design can.
Every dollar spent on a grant program that was not designed to produce outcomes is a dollar that cannot demonstrate value, regardless of how efficiently it was distributed or how thoroughly it was acquitted.
AI is arriving in grantmaking, and it will automate whatever it finds. Artificial intelligence is being applied to grant assessment, application support, reporting analysis, and program monitoring. The enthusiasm is understandable.
The risk is that nobody is asking what the AI is being pointed at. If these tools are built on top of programs that were never properly designed, they will automate the wrong decisions faster.
An AI assessment tool trained on criteria that do not select for outcomes will produce more consistent wrong answers. An AI reporting tool processing data from an evidence framework that was never connected to the program’s theory of change will produce beautifully formatted irrelevance.
The design layer must be right before automation makes sense.
The future of grantmaking is not smarter software. It is smarter program design. Automation does not create judgement. It simply scales whatever judgement you already baked into the program. AI applied to a well-designed program is a force multiplier. AI applied to a poorly designed program is an accelerant.
Public trust depends on demonstrated impact. Citizens and communities increasingly expect to see what their money achieved, not just that it was spent according to the rules. That expectation cannot be met by programs that were designed to be defensible rather than effective.
A grant program that can demonstrate outcomes, that can answer “what actually changed?” with evidence, builds the kind of trust that sustains public investment. A grant program that can only demonstrate compliance builds the kind of scepticism that leads to budget cuts.
What a Design-Led Grantmaker Lifecycle Changes
The shift from an administration-centred grantmaker lifecycle to a design-led grantmaker lifecycle does not mean administration matters less.
It means design is recognised as the stage that determines whether administration, monitoring, and evaluation can produce meaningful results.
In practical terms, this means three things change.
First, design becomes a governed, resourced, and time-protected stage of the lifecycle, not something done in the weeks before applications open by the same team that will administer the program. Design decisions are documented, reviewed, and defensible. They have their own governance, their own deliverables, and their own quality assurance.
Second, administration stages become execution of design decisions rather than substitutes for them. Assessment panels apply criteria that were engineered to select for outcomes, rather than interpreting vague criteria through individual judgement. Reporting requirements collect data that was designed to support evaluation, rather than collecting activity data because no one designed an evidence framework. Contracting reflects a funding model that was chosen for the problem, rather than a standard template applied by default.
Third, evaluation becomes generative rather than terminal. It does not just ask what happened. It asks whether the design worked, and its findings feed directly into the next design cycle. Programs improve because their structures improve, not just because their processes are refined.
This is the difference between a grantmaker lifecycle built around getting money out the door and a grantmaker lifecycle built around producing change with public funds.
The Choice
The grantmaking sector has spent two decades improving administration. Better systems. Better platforms. Better compliance frameworks. Better reporting tools. That work has value. It has made grant programs fairer, more transparent, and more accountable. It should continue.
But somewhere along the way, we started believing that if we administered grants well enough, outcomes would follow. They do not. I have watched beautifully administered grant programs produce nothing of consequence, and scrappy grant programs with strong design logic change lives. Administration is necessary. It is not sufficient.
The grantmaker sector does not suffer from a shortage of dashboards. It suffers from a shortage of design decisions.
A best practice grantmaking lifecycle recognises all three layers and gives each one its proper weight. It starts with the problem, not the application.
It treats grant program design as the most consequential phase, not the most compressed. And it connects evaluation back to design, so that every iteration of a program is built on what the last one learned.
The lifecycle models we use shape how we think about grant programs. If the model centres administration, we optimise administration. If the model centres design, we optimise for outcomes.
Grant programs don’t fail because of poor reporting. They fail because design decisions were made by default rather than by design.
It is time to start with a clean sheet.
Grant programs don’t produce outcomes because we measure them. They produce outcomes because we design them to.
I’m Geoffrey Clow EGA – Expert Grant Program Advisory. I work with government agencies and philanthropic organisations on grant program design, review, and improvement. I bring practical experience from both sides of the grants relationship; as program designers and as assessors who’ve seen thousands of applications and know what works and what doesn’t.
The Better Best Practice Grantmaking Lifecycle was developed to honour the work of my partner in love and business, the late Georgie Bailey, who knew that grant programs succeed or fail long before applications open. Who also believed that grant management should be rigorous, fair, and free of bullshit. In loving memory 1968-2022
For more information: Contact details here
© Geoffrey Clow – Expert Grant Program Advisory (EGA)
2026. This white paper may be shared with attribution.
