Escalation is the mechanism that lets an IT project surface a problem to someone with the authority to fix it. On Australian government projects, that mechanism is broken more often than agencies like to admit. Issues sit unresolved at team level for weeks, then arrive at a steering committee as a crisis rather than a manageable risk. The window for an inexpensive fix has usually closed by then.
The core problem isn't that agencies lack governance structures. Most have steering committees, risk registers, and weekly status reports. The problem is that none of those structures tell a project manager at what point a problem stops being theirs to carry and starts being something a senior responsible officer must decide. That ambiguity is where escalations go to die.
What an escalation path actually needs to define
A workable escalation path answers four questions before any project issue arises. First, it defines the trigger: what specific condition, threshold, or event requires escalation rather than local resolution. Second, it names the recipient: not a role in the abstract, but a named person or position with a defined decision-making authority. Third, it sets a timeframe: how quickly must the escalation be acknowledged and resolved. Fourth, it specifies the format: what information must travel with the escalation so the recipient can actually act.
Most government project documentation handles the second point adequately and ignores the other three. The result is escalations that arrive without context, land with someone unsure of their authority to act, and sit unanswered because the timeframe was never specified.
Trigger thresholds deserve particular attention. Common triggers on well-run government projects include: a risk rated high on the project risk register for more than two consecutive reporting cycles, a schedule variance exceeding 10 per cent from the baseline, a cost forecast revision that falls outside the approved budget tolerance, or a dependency on another agency that has been unresolved for more than five business days. Those aren't universal rules, but they share a quality: they're measurable. A project manager knows whether the threshold has been crossed without needing a judgment call.
The three layers where escalations typically stall
On a large federal project, an issue usually has to travel through project manager, program manager, and senior responsible officer before it reaches a minister's office or central agency. Each layer is a potential holding point.
Project managers hold issues because escalating feels like admitting failure. This isn't a personality flaw; it's a structural one. If the culture around a project treats escalation as a sign of weakness rather than a control mechanism, project managers will absorb problems rather than surface them. Agencies that explicitly reward early escalation, and make this expectation clear in project induction, see faster surfacing of issues.
Program managers hold issues because they want to present solutions, not problems. An issue arrives from a project team and the instinct is to attach a recommendation before passing it upward. That's often appropriate. But when the recommendation takes three weeks to develop, the delay compounds the original problem. The right approach is to escalate the issue with an interim holding position, then follow up with a full recommendation within a defined window.
Steering committees hold issues because their meeting rhythm is monthly. A problem that arrives the day after a steering committee meeting waits four weeks for a governance decision. Agencies with well-structured escalation paths don't rely on the standing meeting cycle for high-severity issues. They define an out-of-cycle mechanism: typically a documented process for convening an extraordinary meeting or obtaining a chair's decision without a full committee sitting.
How escalation connects to risk registers
Escalation and risk management are meant to work together, but in practice they're often treated as separate disciplines. The risk register is updated weekly and reviewed by the project team; the escalation path is documented in the project management plan and referenced by nobody until something goes wrong.
The connection should be explicit. Every risk rated high or critical on the register should carry an escalation owner: the person responsible for deciding whether that risk has crossed the threshold for escalation. That owner should be reviewed at each reporting cycle. If a risk has remained high for two consecutive cycles without a mitigation progressing, the escalation owner is accountable for a decision, not just a status update.
This linkage also matters for issues logs. Issues differ from risks in that they've already materialised, which means the urgency is higher and the tolerance for inaction is lower. An issue log entry should carry the same escalation metadata: current owner, escalation threshold, escalation recipient, and next decision date.
The vendor dimension
Government IT projects almost always involve vendors, and vendor-related issues have their own escalation complexity. A contractual dispute, a delivery shortfall, or a vendor refusing to acknowledge a defect can't be resolved by a project manager unilaterally. It needs someone with contract management authority, often from the agency's commercial or legal team, to engage formally.
Most projects define vendor escalation paths in the contract or the project control framework, but those provisions aren't always communicated to the delivery team. Project managers discover during an actual dispute that they weren't the right person to send the formal notice, or that the contract required written escalation within five business days of identifying a breach and that window has passed.
Agencies that handle IT project vendor disputes well brief project teams on the contractual escalation provisions at project kick-off, not when a dispute is already live. They also maintain a single point of contact for vendor escalations, so that a delivery team doesn't inadvertently send conflicting signals to a supplier while the agency's commercial team is running a formal process.
What the Digital Transformation Agency expects
The Digital Transformation Agency has increasingly emphasised assurance mechanisms across the ICT investment lifecycle, and escalation paths fall within that scope. Agencies seeking approval or assurance sign-off on major projects are expected to demonstrate that governance arrangements include a defined mechanism for surfacing issues to decision-makers before they become unmanageable.
That expectation shows up most directly in gateway reviews, where reviewers assess not just the project's current status but the quality of its governance. A gateway reviewer who finds no documented escalation path, or one that hasn't been tested, will flag this as a risk. Agencies that treat escalation as a checkbox rather than a live process tend to find this out at the worst possible time.
What good practice looks like in short
The agencies that handle escalation well share a few specific habits. They document escalation triggers in measurable terms, not subjective ones. They test the escalation path at project initiation, typically through a tabletop exercise, so everyone knows what to do before the pressure is real. They separate escalation from reporting, so that a high-severity issue doesn't wait for the next status report cycle. And they treat an escalation as a governance success, not a project failure, which changes the incentive for the team member who has to initiate it.
None of this is technically complex. The gap between what most Australian government projects document and what they actually practice on escalation is a governance maturity problem, not a resource one. The fix is largely procedural: clearer thresholds, named owners, defined timeframes, and a culture that rewards early warning over late crisis management.