Lessons learned is the governance step that Australian government IT projects treat as optional. Budgets are exhausted, staff move on, and the formal closure report lands months after the system has gone live. By then, the institutional memory that would make the session useful has already scattered across agencies, vendors, and contractors who have moved to other work. The cycle repeats on the next project.
The pattern isn't new. The Australian National Audit Office has flagged knowledge transfer and post-project review weaknesses across multiple audits. Yet the structural conditions that produce the problem persist: fixed-term contracts, project-based funding, and a procurement model that rewards delivery over reflection.
Why the standard approach fails
Most agencies treat lessons learned as a document, not a process. A project manager compiles a register of what went wrong, attaches it to the project closure report, and files it in a shared drive where it will never be read by anyone on a future project. The lessons exist. The learning does not happen.
Three things drive this outcome. First, the timing is wrong. Lessons learned sessions held after go-live, when the pressure has lifted and the team has dispersed, produce vague retrospectives rather than actionable findings. The emotional distance that makes reflection feel safe also erodes specificity. Second, the audience is wrong. Project teams document lessons for other project teams, but the people who most need to hear them, procurement officers, steering committee members, and program managers, rarely engage with the output. Third, accountability is absent. No one is responsible for acting on lessons from a prior project when a new one starts.
This connects directly to how agencies handle governance more broadly. The same structural issues that affect how Australian agencies run IT project steering committees tend to reproduce themselves in the lessons learned process: the committee heard about problems late, captured them in the minutes, and nobody circled back.
What good lessons learned actually looks like
Effective lessons learned in government IT is continuous, not terminal. It runs in three phases: during the project, at transition, and at a structured post-implementation point.
During delivery, the practice is simple. After each major milestone or phase gate, the project team spends 90 minutes on three questions: what did we plan, what happened, and what would we change? The output is a living document, not a one-time report. It updates after each phase. The project director owns it, not the project manager.
At transition, the outgoing team briefs the incoming operations team with a structured handover that includes a summary of the five decisions that most shaped the final product and the five risks that nearly derailed it. This is distinct from technical documentation. It is institutional memory in plain language.
At the post-implementation stage, typically 90 days after go-live, the agency runs a structured review that includes the business sponsor, not just IT. That review feeds directly into the program-level risk register for the next project in the portfolio. This is the link that is almost universally missing.
The role of the gateway review process
The Australian Government's Gateway Review Process, managed by the Department of Finance, provides an external peer review at key stages of a project's lifecycle. Gateway reviews do capture lessons, but they are snapshots in time rather than a continuous feed. Agencies that treat the gateway review as their primary lessons mechanism are relying on a point-in-time assessment to do the work of an ongoing institutional practice. It cannot.
The more useful role for gateway reviews is as a forcing function. A scheduled gate review in three months creates a reason to have documented lessons clearly enough that an external reviewer can assess them. Without that deadline pressure, documentation slips.
The contractor knowledge problem
A specific and underappreciated issue in Australian government IT lessons learned is contractor knowledge. On large transformation programs, the people who understand the system most deeply are often contractors: solution architects, integration specialists, and technical leads on two or three-year contracts. When those contracts end, the lessons go with them.
Agencies that have managed this well do two things. They require contractors to contribute to the living lessons document monthly as a contractual deliverable, not as an optional contribution at project end. They also run structured knowledge-extraction sessions with key contractors in the final 60 days of engagement, before the intellectual capital walks out the door. These sessions are recorded and summarised by a permanent staff member, creating an artefact that belongs to the agency regardless of what happens to the individual.
The same problem appears in how Australian agencies handle post-implementation reviews: by the time the review is formally scheduled, most of the people who could give it substance are gone.
Making lessons findable
A lessons register that lives in a project folder on a SharePoint site that no one outside the project team knows about is not a knowledge asset. It is an artefact. The distinction matters.
Agencies that do this well maintain a cross-project lessons library at the program or portfolio level, not the project level. Lessons are tagged by category: vendor management, requirements definition, change management, security and privacy, integration complexity. When a new project starts, the program office is responsible for presenting the relevant lessons to the new project team in the first month. This is a governance step with a tick-box in the project initiation checklist, not a suggestion.
Some larger agencies have built this into their project management frameworks. The Department of Home Affairs and Services Australia both maintain program-level governance structures that nominally include cross-project learning. The quality of execution varies, but the structural intent is right. Smaller state agencies, particularly those running one or two significant IT programs at a time, often lack a program office to hold the function, and lessons learned falls to whoever is most organised on the project team at the time.
The honest conversation agencies avoid
The most useful lessons from failed or troubled government IT projects are also the most politically sensitive. A frank account of how a vendor under-delivered against a fixed-price contract, or how a ministerial deadline drove the team to ship a system with known defects, is not the kind of content that makes it into a closure report that will be read by the vendor's account manager or tabled in a Senate estimates hearing.
This is real. Agencies know it. The practical response is to create a confidential track in the lessons process, documented for the CIO and agency head rather than for the program file, where the honest account of what happened can be preserved without triggering a political or contractual consequence. Not every agency has the appetite for this, but those that do get disproportionate value from the exercise.
Without a genuine account of what went wrong and why, the lessons register is a performance. It satisfies a compliance requirement and changes nothing.