Post-implementation reviews (PIRs) are supposed to answer a simple question: did the project deliver what it promised? In Australian government IT, that question is harder to answer than it sounds. Projects run over budget, change scope mid-delivery, or produce a system that works technically but fails operationally. A well-run PIR captures that gap. A poorly run one produces a document nobody reads.
The Digital Transformation Agency's guidance on project governance nominates PIRs as a required step for significant ICT investments, and most state government frameworks echo that position. But requiring a review and conducting a useful one are very different things. The gap between the two is where lessons get lost.
What a PIR is actually supposed to do
A post-implementation review is not an audit. It isn't a chance to apportion blame or defend decisions already made. The functional purpose is narrower: compare actual outcomes against the business case, identify variance, and extract lessons that can improve future projects.
In practice, Australian agencies structure PIRs around four core questions. Did the system meet its functional requirements? Did it deliver the expected benefits within the expected timeframe? Did costs land within approved budgets? And did users and stakeholders receive what the business case described?
Those four questions sound mechanical, but each one requires careful framing. Benefit realisation, in particular, trips up a lot of agencies. Benefits specified in a business case are often written to secure approval rather than to enable later measurement. Vague claims like "improved service delivery" or "efficiency gains" can't be verified three years after go-live without baseline data, and that data is rarely collected systematically before a project begins.
When reviews actually happen
Timing is the first structural problem. Most frameworks recommend conducting a PIR six to twelve months after a system goes live. That window is long enough for operational issues to surface but short enough that users are still adjusting and some benefits haven't had time to materialise. Teams that conduct reviews at three months are measuring the wrong thing. Teams that wait two years are writing history, not lessons.
The second problem is resourcing. PIRs are usually assigned to whoever is left after the project team dissolves. In federal agencies, that often means a small group within the sponsoring business unit, sometimes with support from a central PMO. But the people with the deepest knowledge of what went wrong, particularly vendors and contractors, are no longer on the project by then. Their institutional memory walks out with them.
State governments handle this differently. Victoria's Department of Government Services, for example, has centralised gateway review functions that include mandatory PIRs for projects above a capital expenditure threshold. Queensland follows a similar model through its Project Assurance Framework. NSW uses independent review panels for major ICT investments, drawing on the NSW Audit Office's work as an external check. These structures don't eliminate weak PIRs, but they reduce the chance that a review is written purely by the people who ran the project.
What good benefit realisation measurement looks like
Benefits management is the hardest part of a PIR to get right. Most agencies track three types of benefit: financial (cost avoidance, reduced headcount, lower transaction costs), quantitative non-financial (processing times, error rates, call volumes), and qualitative (user satisfaction, staff capability, policy compliance). Each type requires different measurement approaches and different data sources.
The agencies that get this right do three things consistently. First, they define benefits in measurable terms inside the business case, not after approval. Second, they assign a named benefit owner for each claimed benefit, not a team or a branch, a specific person. Third, they collect baseline data before deployment so post-go-live comparisons are meaningful.
Services Australia's transformation program has demonstrated this at scale. The shift from paper-based processing to digital claim pathways produced measurable reductions in average handling times for a range of welfare payments, and the agency was able to demonstrate that because it tracked baseline handling times before the digital channel launched. That kind of discipline is rarer than it should be across Australian government ICT.
For a broader view of how measurement works across the digital service lifecycle, the approaches used in Australian agency digital service performance measurement provide useful context on the frameworks agencies apply before and after deployment.
Common failure modes in Australian government PIRs
Several patterns recur in PIRs that produce little actionable output.
Review as compliance tick. The PIR is written to satisfy a governance requirement rather than to produce insight. It documents what happened, confirms the project is closed, and files the report. No recommendations. No follow-up owners. No commitment to act on findings before the next project of the same type begins.
Scope drift not accounted for. Many government IT projects change significantly between business case approval and delivery. If the PIR compares outcomes against the original business case without acknowledging approved scope changes, the variance analysis is meaningless. A project that delivered everything in its final scope statement may still look like a failure against an outdated baseline.
Vendor self-assessment. In projects where a single systems integrator or platform vendor held most of the delivery responsibility, PIRs sometimes rely heavily on the vendor's own reporting. That's a structural conflict. The vendor has an obvious interest in presenting outcomes favourably, particularly if there are ongoing support contracts at stake. Independent validation of vendor-reported metrics is a basic control that agencies often skip.
No lessons register. A review that produces lessons but doesn't route them into a live lessons register accomplishes almost nothing. The Australian National Audit Office has noted in multiple performance audits that agencies frequently conduct reviews but fail to use findings to inform subsequent projects. The same mistakes repeat because the institutional memory from PIRs isn't accessible to project teams that start work twelve months later.
The role of the ANAO and parliamentary scrutiny
The Australian National Audit Office provides a secondary layer of accountability that PIRs alone can't replicate. ANAO performance audits of major ICT projects examine whether agencies followed their own governance frameworks, whether reported benefits were actually realised, and whether value for money was achieved. These audits are public, which creates an accountability mechanism that internal PIRs don't have.
Recent ANAO work on large-scale government ICT has been pointed. Reports have identified cases where agencies claimed benefit realisation without supporting evidence, where PIRs were completed late or not at all, and where governance frameworks existed on paper but weren't applied consistently. Parliamentary committee inquiries into specific project failures have drawn on this work to press secretaries and agency heads for explanations.
That scrutiny has a real effect. Agencies that have faced public ANAO findings about project governance tend to improve their PIR processes in the subsequent cycle, at least temporarily. The problem is that the improvement often doesn't outlast the attention. When a new major project starts, the lessons from the previous PIR are frequently invisible to the incoming team.
What procurement design means for PIR quality
One structural lever agencies rarely use is procurement design. Contracts for major ICT projects can require vendors to support the PIR process, including providing performance data, participating in lessons-learned workshops, and holding baseline measurements throughout delivery. This is distinct from the vendor self-assessment problem described above. It places contractual obligations on vendors to support an independent review process rather than substitute for one.
How Australian agencies handle vendor obligations more broadly connects directly to this point. The constraints that shape vendor lock-in in government cloud contracts often also limit the agency's ability to extract post-implementation data from a vendor platform, which is a further reason to address data access and reporting rights explicitly in the original contract.
Agencies that build PIR obligations into procurement from the start are also better positioned on legacy transition. When a system eventually needs replacing, the post-implementation record tells the next project team what the current system actually does, not just what it was designed to do. That distinction matters more than most people expect at the start of a migration.
The path to more useful reviews
Better PIRs don't require new frameworks. The frameworks exist. The gap is in execution, and execution depends on two things: leadership that treats the review as genuinely useful rather than procedurally required, and institutional structures that ensure findings reach the people who need them.
Centralised lessons registers, mandatory PIR clauses in major ICT contracts, independent reviewers for projects above a fixed cost threshold, and defined benefit owners named before a project starts: none of these are novel ideas. The agencies that manage IT project scope creep well tend to share one trait: they treat the feedback loop between projects as part of the delivery model, not an administrative afterthought.
The review doesn't end when the report is filed. It ends when the next project team can point to a specific decision they made differently because of what an earlier review found. Until that connection is traceable, the PIR process is producing paperwork, not improvement.