IT project handover to operations is the step that Australian government agencies most consistently underinvest in. A system goes live, the project team celebrates, and then within six months the operations team is struggling with documentation nobody can find, runbooks that don't match what was actually deployed, and support requests that fall into a gap between vendor SLAs and internal capability. The handover was a box-tick, not a transition.
This is a structural problem, not a personnel one. Most government IT projects are funded and governed as delivery exercises. The moment go-live is reached, budget authority shifts, the project sponsor moves on, and the integrators start rolling off. What's left is a production system that the operations team didn't design, barely tested, and now owns entirely.
Why handover fails in the public sector
Government project structures create predictable handover failures. Projects are time-boxed. Operations is ongoing. Those two funding models sit in different parts of the budget, are measured differently, and are staffed by people who often don't meet formally until the final few weeks before go-live.
Vendors have little incentive to invest in handover documentation beyond what their contract specifies. Contracts written early in procurement rarely capture the operational knowledge that accumulates during build and test. If the statement of work says "provide a runbook," the vendor will provide a runbook. Whether that runbook reflects how the system actually runs in the agency's environment is a different question entirely.
The result is that operations teams inherit what project teams built without inheriting the knowledge of why it was built that way. The architectural decisions, the workarounds, the integration quirks discovered during UAT: these live in Confluence pages, email threads, and the heads of contractors who are no longer engaged. A poorly managed lessons learned process compounds this: the knowledge stays inside the project and never reaches the people who will run the system day-to-day.
What good handover documentation actually contains
Agencies that handle handover well treat it as a knowledge transfer program, not a document drop. The distinction matters because documentation without context is nearly useless when something breaks at 2am.
Useful handover packages cover six areas. First, a system overview written for someone who wasn't on the project: architecture diagrams, data flows, and integration points described plainly. Second, operational runbooks that cover routine tasks and known failure scenarios, tested by operations staff before go-live. Third, a contact directory that goes beyond vendor support lines to include named engineers, account managers, and escalation paths. Fourth, a known issues register that captures every workaround applied during build and test, with the reason it exists. Fifth, monitoring and alerting configuration documented well enough that a new team member can interpret an alert without tribal knowledge. Sixth, a schedule of upcoming dependencies: certificate renewals, licence expiries, planned infrastructure changes from connected agencies.
Most agencies produce something in categories one and five. The rest gets skipped or deferred. The known issues register is almost never completed because project teams don't want to hand over a document that makes the system look fragile.
The role of shadow operations periods
Shadow operations, sometimes called parallel running or hyper-care, is the practice of having the project team support the system in production while the operations team takes over gradually. Done well, it's the most effective knowledge transfer mechanism available. Done poorly, it extends the project team's engagement without actually transferring any knowledge.
Poor shadow operations look like this: the project team keeps resolving incidents, the operations team watches, and after four weeks the project team leaves. The operations team has seen the system run but hasn't diagnosed anything. The next incident is the first one they own.
Good shadow operations require a deliberate inversion. Operations staff take first call. The project team provides context, not resolution. Every incident becomes a teaching exercise. This requires the project sponsor to protect time and budget for this period, which is where most programs fail. The pressure to close the project and release resources is intense, and shadow operations is typically the first casualty.
Governance gaps between project close and steady state
Government IT projects often close formally before the system reaches genuine steady state. The project board is dissolved, the steering committee stops meeting, and the project manager files the final report. The system is technically in production but it's still unstable, still receiving minor configuration changes, and still relying on vendor support for things that should be internal capability.
This gap creates a governance vacuum. Change requests come in but there's no clear authority to approve them. Incidents escalate but there's no escalation path into anyone who understands the system's design intent. The operations team starts making decisions without the context to make them well.
Agencies that handle this well extend formal governance past go-live. A post-go-live review board, meeting monthly for at least six months, keeps decision-making authority alive while the system stabilises. It doesn't need to be heavy: a one-hour meeting with the right people is enough. The key is that someone with design authority is still available for consequential decisions. This connects directly to how agencies structure their IT project steering committees: the agencies that maintain committee involvement through the early operational period consistently report fewer critical incidents in the first year.
Vendor obligations after go-live
The handover period is also where vendor contract provisions get tested. Most government IT contracts include a warranty or defect liability period after go-live, typically 90 days. What agencies often discover is that the warranty covers defects in delivered functionality, not gaps in operational knowledge. The vendor isn't obligated to train operations staff, answer questions about undocumented behaviour, or respond to integration issues that emerged after acceptance.
Procurement teams that anticipate this write explicit knowledge transfer obligations into contracts. These include: a minimum number of knowledge transfer sessions with operations staff, sign-off from the operations team lead before the project is accepted, and a defined period of on-call support from named vendor engineers after go-live. Without these clauses, the vendor's post-go-live obligation is limited to fixing bugs in what they delivered. With them, the contract creates accountability for the transition itself.
The vendor disputes that arise most often in government IT during this phase centre on precisely this ambiguity: the agency believes the vendor is responsible for the operational gap; the vendor believes its contractual obligations ended at acceptance.
Training as a handover gap
Operations staff training is the most underfunded part of any handover plan. Project budgets include training as a line item but it's usually allocated for end-user training, not operational training. The people who will manage the system in production often receive the same training as the people who will use it. Those are not the same thing.
Operational training needs to cover failure modes, not features. An operations staff member needs to know what happens when the integration with the external identity provider drops, not how to create a new user account. Training that focuses on standard workflows is useful for end users. It leaves operations teams unprepared for the incidents they'll actually face.
The fix is straightforward but requires deliberate budget allocation: fund a separate operational training stream, run it in the pre-go-live environment, and base it on realistic incident scenarios rather than feature demonstrations. Agencies that build this into their project budgets at planning stage treat it as non-negotiable. Agencies that defer it to "post go-live when we have time" rarely get to it.
What mature agencies do differently
Agencies with a track record of successful handovers share a few practices. They bring operations staff into the project at the build phase, not the testing phase. They treat handover as a milestone with acceptance criteria, not a date on a plan. They fund a transition period explicitly, separate from both the project budget and the steady-state operations budget. And they measure operational readiness before go-live, not after.
Operational readiness assessments typically cover: can the operations team deploy a patch without vendor involvement, can they restore from backup within the target RTO, can they interpret monitoring dashboards and respond to alerts, and do they know who to call when the system behaves unexpectedly? If the answer to any of these is no at go-live, the handover isn't complete. The system may be live. The transition isn't done.
Readiness criteria of this kind also give project sponsors a defensible basis for delaying go-live when handover preparations are behind schedule. Without them, the pressure to hit the go-live date overwhelms operational concerns every time.