Sign-off gates on Australian government IT projects are widely misunderstood as administrative formalities. They are anything but. A gate review is supposed to answer a binary question: is this project ready to proceed to the next phase? When agencies treat that question as a box-ticking exercise rather than a genuine decision point, the consequences show up months later as blown budgets, missed benefits, and embarrassing Senate estimates hearings.
The problem is structural. Most agencies design their gate frameworks during project initiation, when optimism is high and political pressure to start building is already building. The criteria for passing each gate get written loosely. Nobody specifies who holds the authority to say no. And the steering committee, as discussed in coverage of how Australian agencies handle IT project steering committees, is often configured to hear good news rather than surface hard blockers.
What a sign-off gate is actually supposed to do
A gate is not a progress report. It is a structured decision about whether the conditions for the next phase have been met. That distinction matters enormously in practice. Progress reports tell you what has happened. Gates force a question: given what has happened, should we continue?
The Australian Government's ICT Two-Pass Review model, administered through the Department of Finance's ICT Investment Approval Framework, provides the most visible gate structure at the federal level. Pass 1 gates a business case before detailed design work begins. Pass 2 gates the final business case and procurement strategy before the contract is signed. These two formal gates exist precisely because early-stage decisions are the cheapest ones to reverse.
Below those formal pass reviews, individual project methodologies layer in additional gates: end of discovery, end of alpha, end of beta, and transition to live. Each one should carry a clear set of entry criteria (what must be true before the review can proceed) and exit criteria (what must be demonstrated before approval is granted). Most project plans include these on paper. Most don't enforce them in practice.
Why gates fail in Australian government projects
There are three failure patterns that appear with striking regularity across Commonwealth and state programs.
The first is authority creep. A project board approves the gate in principle, with conditions attached. Those conditions never get formally signed off. The project moves forward on the assumption that the conditions will be met. They aren't, or they're met superficially. By the time the gap surfaces, the project has momentum and political capital invested. Reversing course becomes politically costly even when it's technically warranted.
The second is the missing no. Gate reviews in government settings operate under implicit pressure to approve. Vendors have contracted delivery timelines. Ministers have announced launch dates. Saying no at a gate review means someone owns the delay. That ownership is uncomfortable, so conditions get softened, concerns get logged rather than resolved, and the project proceeds. This pattern is particularly acute at the transition-to-live gate, where agencies sign off on systems that aren't operationally ready because the alternative is acknowledging the project is behind.
The third failure pattern is documentation substituted for decision-making. Agencies generate extensive gate review documentation: completion reports, risk assessments, test evidence packages. The documentation is thorough. But the actual gate meeting spends 40 minutes on slide decks and 5 minutes on whether approval should be granted. Nobody challenges the evidence. The decision is made before the room convenes.
What effective gate governance looks like
Agencies that run gates well share a few consistent practices.
They separate the review from the decision. The gate review is a working session where project evidence is scrutinised. The gate decision happens afterwards, with a clear decision record that names the approving authority, captures any conditions, and sets a date by which those conditions must be resolved and confirmed. The two steps are distinct. One produces findings; the other produces accountability.
They define non-negotiable exit criteria at project initiation, not at gate time. A project that hasn't defined what "done" means for its alpha phase at the start of discovery will have trouble agreeing on it under delivery pressure six months later. Criteria written under pressure are criteria written to pass.
They assign a single named decision-maker for each gate, rather than diffusing authority across a committee. Committees produce consensus. Consensus produces conditional approvals with soft conditions. One named accountable officer produces a decision. This is consistent with how mature agencies approach their broader IT project escalation paths: clear authority chains matter at every decision point, not just during crises.
They also build in an independent assurance function for high-value gates. The Digital Transformation Agency's Gateway Review process provides this at the federal level for projects above certain investment thresholds. A Gateway Review brings an independent team to examine the project at a critical decision point and provide a confidence rating and recommendations. Importantly, Gateway Reviewers have no stake in the project proceeding. That independence is the point.
The transition-to-live gate is the hardest one to hold
Of all the gate types, transition to live generates the most pressure and the most failures. By the time a project reaches production-readiness assessment, a significant investment has been made, vendor contracts are active, and the business sponsor wants to announce something. The temptation to approve an early launch and fix remaining issues in production is almost irresistible.
The ANAO has identified this pattern in multiple performance audits over the past decade. Systems go live before user acceptance testing is complete. Operational support arrangements haven't been finalised. Data migration has partial integrity issues that haven't been fully resolved. None of these blockers are individually catastrophic, so each one gets rationalised. Together, they combine to produce a launch that requires emergency remediation in the first weeks of operation.
Effective transition-to-live gates enforce a short, specific checklist: production infrastructure is provisioned and load-tested; the support team is trained and rostered; rollback procedures have been rehearsed, not just documented; a hypercare period with defined escalation contacts is confirmed; and any known defects above the agreed severity threshold have been resolved. That checklist doesn't need to be long. It needs to be binary and non-negotiable.
Structuring gate criteria teams can actually use
Good gate criteria have three properties. They are observable: you can point to an artefact, a test result, or a signed document that proves they're met. They are objective: a reasonable person examining the same evidence would reach the same conclusion. And they have a single owner: one person is responsible for confirming that each criterion has been met before the gate convenes.
Criteria written in the passive voice ("stakeholder engagement has been completed") are usually neither observable nor owned. Criteria written with an active owner and a specific output ("the business owner has signed the user acceptance test completion report, version 2.1, dated no earlier than two weeks before the gate") are both. The difference between those two phrasings is the difference between a gate that holds and one that doesn't.
Sign-off gates won't save a project that is fundamentally misconceived. But a project that is broadly sound will fail to deliver its value if the gates don't hold. The accountability that a genuine gate review creates is not bureaucratic overhead. It is the mechanism by which Australian government agencies protect public investment and avoid the pattern of delivering systems that need to be rebuilt within three years of launch.