The assessment round gets most of the attention in grants management. There are tools for it, processes for it, and a growing body of practice around scoring rubrics, panel design, and conflict of interest. But the assessment round is, at most, three months of a grant's life. A three-year funded programme that goes through a two-month assessment process still has thirty-four months of post-award relationship left to manage.
That thirty-four months is where most of the difficulty lives.
Post-award management is harder than the assessment round for three reasons. First, it is longer — the obligations extend across months or years rather than weeks. Second, it is less bounded — the assessment round has a clear end date; post-award ends when the last acquittal is signed off, which can slip repeatedly. Third, it is less visible — the assessment round is an event that organisations prepare for; post-award is ongoing background work that competes with the next funding round for attention and loses.
This article covers the operational practice of post-award management: how to design milestones that can actually be assessed, how to handle progress reporting, how to manage multi-year complexity, and what your records need to show when accountability is tested.
A milestone is a point in a grant's lifecycle at which the funder reviews progress and, in many cases, decides whether the next tranche of funding should be released. The quality of that review depends almost entirely on the quality of the milestone design.
Most milestone failures trace back to one of two design errors: milestones that are too vague to assess, or milestones that are spaced arbitrarily rather than aligned to programme logic.
Vague milestones are ones where the grantee's submission cannot be assessed against a clear standard. "Programme underway" is not a milestone. "Delivery of at least three community workshops, with attendance records and a brief report on participant feedback" is a milestone. The difference is not pedantry — it is the difference between a review where the grants officer can determine whether the condition has been met and one where they must make a judgement call that is difficult to document and easy to dispute.
Misaligned milestones are ones whose timing does not match the grantee's operational reality. A Year 1 milestone requiring a final evaluation report in month six of a three-year programme was almost certainly set by someone filling in a template, not someone thinking about what the grantee will actually have produced by then. Milestones that do not align with the natural rhythm of the funded activity produce reporting that is performative rather than substantive — grantees filing documents to satisfy a contractual obligation rather than providing genuine programme intelligence.
Useful milestone design starts from the funded activity, not the contract template. What should the grantee have done, built, or demonstrated at each stage of the programme? What evidence would show that? What is the minimum submission that would give the funder confidence to release the next tranche? Those questions, asked honestly, produce milestones that are both meaningful for the grantee and assessable by the funder.
For most grants programmes, three to five milestones across the life of a grant is sufficient. More than that and reporting becomes an administrative burden that consumes the grantee's capacity without providing proportionally more assurance.
Progress reports serve two purposes that are easy to conflate but important to keep distinct. The first is accountability — documenting that the funded activity is being delivered as agreed. The second is intelligence — giving the funder genuine insight into what is working, what is not, and what the programme is learning.
Most progress report templates are designed for accountability and are poor instruments for intelligence. They ask for expenditure against budget, activities against the work plan, and narrative on any variances. That is the minimum required for accountability, but it tells you little about whether the programme is achieving its intended outcomes or what adjustments might improve it.
The most useful progress reports ask three things clearly: what did you do since the last report, what did that achieve, and what will you do before the next report? The expenditure section follows from that, not the other way around. When grantees start with the financial reporting and work backwards, the narrative becomes a justification of the spend rather than an account of the work.
Timing matters as much as content. Reports requested too frequently produce compliance fatigue — grantees spending more time filing documents than doing the funded work. Reports requested too infrequently allow programmes to drift off-track without early warning. For most medium-complexity grants, a progress report at each milestone (two to four per year) is appropriate. For simple grants with low risk profiles, an annual report may be sufficient. For complex, high-value, or politically sensitive grants, quarterly reporting may be warranted.
Processing is where reporting most commonly becomes a burden on the funder rather than the grantee. When progress reports arrive by email as PDF attachments, each one requires manual handling: downloading, filing, reading, responding, and updating the grants record. Multiplied across an active portfolio of 30 or 40 grants, that is a significant recurring cost. The more structured the submission — a form with defined fields that populates directly into the grants system — the lower the processing cost and the cleaner the record.
There is a gap, in most funded programmes, between what grantees send and what funders actually need to have on record. Understanding that gap before a grant is approved, and closing it through grant agreement design, is one of the most underrated tasks in grants management.
What most grantees send: a narrative report of activities, a high-level summary of expenditure, and perhaps a few photographs or quotes from participants. Submitted late, in a format that varies from grantee to grantee, without any cross-reference to the specific conditions in the grant agreement.
What funders need on record: evidence that each specific condition in the grant agreement was met, attributed to a documented source, reviewed by a named person on a specific date, and approved at the appropriate delegation level. If a condition required an independent evaluation, the record should include the evaluation report, a note on who received it, and a record of whether it satisfied the relevant contract condition.
The gap between these two is not the grantee's fault. If the grant agreement does not specify the evidence required for each milestone, grantees will send what they think is appropriate. If the submission process does not provide structure, the submissions will be unstructured.
Closing the gap requires three things: grant agreements that specify evidence requirements by milestone, submission processes that guide grantees to provide that evidence in a structured format, and review workflows that ensure each evidence item is assessed against the specific condition it is supposed to satisfy — not just filed as received.
This matters most when accountability is tested externally. An OIA request, an audit, or a grantee dispute will not be answered by a folder of PDFs. It will be answered by a structured record that shows: this milestone required this evidence, this evidence was submitted on this date, it was reviewed by this person, and it was approved (or returned for amendment) on this date, at this delegation level. That record is worth building from the start of the grant, not assembling in a hurry when it is needed.
Multi-year grants introduce complexity that single-year grants do not. External circumstances change. The grantee's context changes. What seemed like a reasonable work plan in Year 1 may look different by the end of Year 2.
The question is not whether conditions will change — they will. The question is how you manage change in a way that maintains programme accountability while giving grantees the flexibility to respond to their environment.
Formal variations are amendments to the grant agreement that change a specific condition: the scope of an activity, the budget allocation between line items, the timing of a milestone, or the definition of what evidence satisfies a condition. Every variation should be documented in writing, reviewed against the original grant agreement, and signed off at the appropriate delegation level. The variation record should be held alongside the original grant agreement and should be referenced whenever a subsequent milestone is assessed.
The mistake most organisations make is allowing informal variations — a phone call, an email, an agreement in principle — to substitute for formal documentation. The grants officer who approved the informal change may move on. The successor finds a grant where the current activity does not match the agreement on file and cannot determine why. The audit trail breaks at the point of the undocumented change.
Amended milestones in multi-year grants should be treated with the same rigour as original milestones. If a milestone is deferred, the new date and the reason for deferral should be documented. If a milestone is modified, the original condition and the amended condition should both be visible in the record — not overwritten.
The mechanism that connects milestone approval to payment release is one of the most practically important design decisions in a grants management system. Done well, it ensures that payment cannot proceed until a milestone has been formally approved by an authorised person. Done poorly — or not done at all — it means the payment workflow and the milestone workflow are separate processes that depend on someone manually checking that both have been completed before releasing funds.
A payment release gate is a structural requirement: the payment cannot be processed until the milestone approval is recorded in the system at the required delegation level. This is not merely a procedural rule; it is an enforcement mechanism built into the workflow.
The gate should be specific about what approval is required. A milestone assessed by a programme officer and approved by a programme manager satisfies the gate for a mid-range tranche. A milestone assessed by a programme manager and approved by a director satisfies the gate for a high-value tranche. The delegation thresholds should match your organisation's delegations schedule, and they should be enforced by the system, not remembered by the person processing the payment.
When payment release gates are connected to your finance system, the workflow closes: milestone approved in grants system, payable record created in finance system, payment processed by finance, reconciliation record linked back to grant. No manual step between milestone approval and payment creation. No possibility of releasing a payment against an unapproved milestone because someone forgot to check.
Some grants will not deliver what was agreed. Staff changes, funding shortfalls, scope creep, and organisational difficulties all create situations where a grant is falling behind its contracted milestones. The question is not whether this will happen in your portfolio; it is whether you have a clear process for managing it when it does.
The failure mode to avoid is informal tolerance — a programme officer who knows a grantee is struggling, is managing it through email and phone calls, and is not recording the emerging problem in the grants system. When the problem escalates — a milestone is missed, a payment is withheld, the grantee disputes the assessment — the absence of a documented early-intervention record puts the funder in a difficult position.
Formal variation is appropriate when the programme is still viable but the agreed conditions need to change. The variation process documents the change, provides a clear new baseline, and ensures the revised programme is approved at the appropriate level.
Formal pause is appropriate when delivery has stopped temporarily — due to a key person leaving, a venue closing, an external event — and is expected to resume. A pause should be documented as a formal status, with a written record of the reasons, the expected resumption date, and any conditions on resumption.
Termination is the appropriate response when a grant cannot continue: the grantee is no longer operating, the funded activity has fundamentally changed from what was approved, or the grantee has failed to meet conditions despite formal notice. Termination should follow a documented process, including formal notice to the grantee, a record of unspent funds and whether recovery is required, and a final closure record in the grants system.
For accountability purposes, a terminated grant that has a complete documentation trail — including the early warning signs, the intervention attempts, and the formal termination decision — is in a far stronger position than one where the difficulty was managed informally and the final outcome is unexplained in the record.
If your post-award records were reviewed by an auditor, a parliamentary committee, or a senior executive who was not involved in the programme, what would they be able to determine?
A complete post-award record for a single grant should show:
- The approved grant decision, with the assessment basis and authorisation
- The executed grant agreement, with all conditions specified
- A record of each milestone, including the required evidence, submission date, reviewer, and approval decision
- Documentation of any variations, with dates, reasons, and approvals
- A payment record for each tranche, linked to the milestone that triggered it
- Correspondence or review notes for any period when the grant was at risk
- A final closure or acquittal record
Most organisations can produce most of this information for most grants, most of the time. The problem is that it requires assembly — pulling records from multiple locations, checking email threads, finding shared drive folders, asking programme officers to reconstruct timelines. Assembly takes time, introduces error, and carries risk: the record that cannot be found is the record that looks like it was not created.
The operational case for keeping records in one place, structured consistently, throughout the grant lifecycle is not a technology argument. It is a programme quality argument. Organisations that do this do not scramble when accountability is tested. They respond.
Post-award management is unglamorous work. It does not produce the visible outcomes of a well-run assessment round. But it is the stage at which funded money is either well accounted for or poorly accounted for — and the stage at which your programme's credibility is built or eroded.
Tahua handles milestone tracking, evidence review, and payment release natively, in the same system you use for assessment, without needing a parallel spreadsheet. If you would like to see how that works end to end, book a 30-minute demo.