The steering committee is the most powerful governance body on any major government IT project, and also one of the most frequently wasted. In Australian agencies, the pattern repeats: a committee is established at project kick-off, packed with senior executives, given a terms-of-reference document, and then handed a rolling pack of traffic-light status reports that consistently show amber turning to green. Nobody escalates anything. Nobody is empowered to stop work. And when the project eventually runs over budget or scope, the committee minutes show no point at which a different decision could have been made.
That is not governance. It is ceremonial oversight.
What steering committees are actually supposed to do
A project steering committee in Australian government IT has one job: make the decisions the project team cannot make on its own. That includes approving scope changes that breach agreed thresholds, resolving cross-agency dependencies, authorising budget drawdowns above delegated limits, and deciding whether a project should be paused, replanned, or killed outright. These are decisions that require authority, not just seniority.
The distinction matters. Seniority gets people into the room. Authority determines whether anything useful happens once they're there. A Deputy Secretary who attends every fortnightly meeting but cannot approve a $2 million budget variation without going back to Finance is a passenger, not a decision-maker. Agencies that build committees around titles rather than delegations create a governance layer that adds reporting burden without adding decision speed.
The Australian Government's Department of Finance assurance review framework is explicit on this point: steering committees must include members with the authority to act, not just observe. Gateway reviews that find a mismatch between committee composition and project risk profile are a red flag the framework takes seriously.
Common structural failures in Australian agencies
Three structural problems appear repeatedly in government IT steering committees across federal and state jurisdictions.
The first is sponsor ambiguity. Many projects list a Senior Responsible Officer and a Project Sponsor as two different people, sometimes from two different agencies. When those two roles disagree, the committee has no mechanism to resolve the conflict quickly. The project team fills the vacuum by making the call themselves, which is precisely the kind of scope decision that should have gone upward. Good governance design names one person with ultimate accountability and gives every other committee member a clear secondary role.
The second problem is meeting frequency mismatched to project risk. A fortnightly committee works fine during a stable build phase. It is catastrophically slow during a go-live period, a vendor dispute, or a security incident. Agencies that don't embed an escalation protocol for out-of-cycle decisions guarantee that time-sensitive issues will either be decided by the wrong person or deferred until the damage is done.
The third is the reporting culture. Steering packs in Australian government IT projects are typically produced by the project team that the committee is meant to be overseeing. This is not a conflict of interest that agencies take seriously enough. Independent assurance, whether from a PMO, an internal audit function, or an external gateway reviewer, should provide at least some of the evidence the committee uses to form its view. Without it, the committee is essentially being asked to evaluate reporting it has no way to verify.
What the terms of reference need to actually say
Most government project terms of reference are copied from a template, lightly edited, and filed. They say the committee "provides strategic oversight" and "endorses project deliverables." Neither phrase means anything in practice.
Effective terms of reference define financial delegation thresholds precisely. They specify what quorum looks like when named members are unavailable, and they name acceptable substitutes rather than leaving it to the project manager to decide on the day. They set out escalation paths for issues that cannot wait for the next scheduled meeting. And they define what a decision record looks like so that committee minutes capture actual decisions, not just agenda items discussed.
This level of specificity feels bureaucratic until the moment it matters. When a vendor misses a critical milestone and the project team needs an immediate call on whether to invoke the contract's default provisions, a committee that has never discussed how it makes out-of-cycle decisions will spend a week arranging a meeting instead of spending an hour making a call. This is the same pattern that drives scope creep in Australian government IT projects: decisions that aren't made quickly enough create momentum in the wrong direction.
The independent assurance question
One of the harder conversations in Australian government IT governance is how much the steering committee should trust the project team's own reporting. The honest answer is: not entirely.
Projects under delivery pressure have a structural incentive to present their status favourably. This is not unique to government, and it is not usually dishonest in intent. Project managers believe in their timelines. Vendor representatives believe in their delivery plans. The optimism bias is real and well-documented. But a steering committee that has no independent data source is entirely dependent on the goodwill and accuracy of the people it is meant to be governing.
Some agencies address this through a dedicated PMO that sits outside the project team and reports directly to the committee. Others use internal audit on a periodic basis. The best practice at federal level increasingly involves the Department of Finance's independent health check mechanism for projects above a certain risk threshold. The point is not to create an adversarial dynamic but to give the committee a second signal when the first one looks too clean.
This connects directly to how agencies handle post-project accountability. Post-implementation reviews in Australian government IT consistently find that steering committees received warning signals they didn't act on, often because those signals were embedded in project reports that framed them as under-control risks rather than active problems requiring a decision.
When the committee should escalate outside itself
The steering committee is not the top of the governance chain. It sits below the agency's investment board or equivalent senior governance body, and for projects with cross-agency scope, it sits below a whole-of-government oversight layer. Knowing when to escalate beyond the committee is one of the most underrated governance skills in Australian public sector IT.
The trigger points that should automatically prompt an escalation are: a forecast cost overrun exceeding 20 percent of the approved budget, a schedule slip that pushes a key milestone beyond the current financial year, a vendor default that the agency cannot resolve through normal contract management, and any security or data incident that affects live services. These thresholds should be written into the terms of reference, not left to the chair's judgement.
Chairs who escalate look like they're admitting failure. Chairs who don't escalate until the problem is public look like they concealed it. The institutional incentive runs in the wrong direction, which is why the thresholds need to be automatic rather than discretionary.
Getting the composition right
The ideal steering committee for a major Australian government IT project is small. Five to seven members is the workable range. Beyond that, the committee becomes a briefing audience rather than a decision-making body.
Core membership typically includes the Senior Responsible Officer, a representative from the agency's finance function with budget delegation authority, a representative from the business area that owns the outcome, and an independent member with no line relationship to the delivery team. That independent member, whether a retired public servant, an industry expert, or a representative from a central agency, is the one most likely to ask the question nobody else will.
Vendor representatives attend specific agenda items but are not committee members. This is a line many agencies blur, particularly when the vendor is a large systems integrator with a strong relationship with the agency's leadership. Letting a vendor attend the full steering meeting rather than just the relevant agenda item creates an audience dynamic that changes what gets said.
Steering committee governance doesn't fix bad projects. A poorly scoped initiative with weak vendor contracts and no change management plan will still fail with excellent governance in place. But it will fail faster, more visibly, and with better documentation of why. That matters in Australian government IT, where the path from delivery failure to public scrutiny is short and the institutional memory of what went wrong shapes procurement and governance decisions for years afterward.