Resourcing conflicts sit in an uncomfortable middle ground in Australian government IT projects: too operational for most steering committee agendas, yet too consequential to leave unmanaged at the project team level. When a specialist is shared across three programs, or a business area can't free up its subject matter experts during a critical design phase, the damage accumulates quietly for weeks before anyone formally acknowledges the problem.
This article looks at how resourcing conflicts arise on government IT projects, why the standard remedies often don't work, and what agencies are doing differently when they get it right.
Where resourcing conflicts actually start
The most common origin is shared technical staff. An agency might have two enterprise architects, three senior business analysts, or a single database specialist. When two projects need those people at the same time, someone loses. The decision about who gets priority is rarely written down, which means it gets renegotiated informally every sprint.
Business-side resourcing is a separate problem and frequently a worse one. IT projects depend on subject matter experts from the operational business units they're replacing or changing. Those people have day jobs. A team running a welfare payments system upgrade can't easily pull its processing officers into workshops for three months without the business unit director signing off on backfill arrangements, and that sign-off is often the very conversation nobody wants to have at the start of a project.
Vendor resourcing adds another dimension. Government IT contracts typically specify roles and minimum experience levels, but they rarely lock down named individuals. A systems integrator may win the contract with a particular solution architect visible in the bid, then deploy a junior in that role once the ink is dry. Project managers who don't challenge this early often find themselves months in, working with a team that doesn't match the one they were sold.
Why the standard governance tools miss it
Risk registers tend to capture resourcing risk as a generic entry: "key person dependency" or "business resource availability." That phrasing is too abstract to drive action. A risk logged as "SME availability may be constrained during UAT" doesn't tell a project manager who is constrained, by how much, or what the trigger for escalation looks like. Compare this to the more disciplined approach described in how Australian agencies handle IT project risk registers, where a useful risk register names the specific dependency, the probability, and the owner.
Change control processes similarly struggle with resourcing. A staffing substitution on the vendor side, or a business unit withdrawing its SME halfway through design, often doesn't get raised as a formal change. Project managers absorb the impact by adjusting timelines informally, which disguises the real cost until it's too late to recover.
Steering committees see the effects of resourcing conflicts in milestone slippage and cost variance, but they rarely hear about the resourcing decisions that caused them. That gap is partly structural: project managers have a reasonable incentive to resolve issues below the steering committee threshold rather than escalate problems that reflect poorly on the delivery team. The result is that resourcing problems escalate only when they've already become crises.
The shared resource pool problem in practice
Large agencies running multiple concurrent IT programs face a structural version of this. The DTA's platform mandates and the Commonwealth's various whole-of-government initiatives mean that agencies are often running three or four significant programs simultaneously. When those programs all need the same internal security architect to sign off on designs, or the same privacy officer to review data flows, the queue grows invisibly.
Portfolio management offices in federal agencies have tried to address this with resource allocation registers, sometimes called capacity planning matrices, that map named individuals against project demand over a rolling six-month horizon. The idea is sound. The execution is inconsistent, because updating those registers requires project managers to accurately forecast demand, which few can do reliably beyond four to six weeks.
State governments face a version of the same problem but with thinner bench depth. A mid-sized state agency may have no internal redundancy at all for certain roles. When the project relies on a single person knowing how the legacy system works, and that person takes extended leave or leaves the agency, the knowledge loss is unrecoverable. This is one of the starkest illustrations of why legacy system decommissioning projects are so vulnerable: the people who understand the old system well enough to replace it are exactly the ones in highest demand and most likely to leave before the job is done.
Escalation paths that work
The agencies that handle resourcing conflicts most effectively share a few common practices.
- They define resourcing thresholds in the project initiation documentation, specifying what level of availability shortfall triggers a formal escalation rather than leaving it to the project manager's discretion.
- They assign a named executive sponsor to the business-side resource commitment, not just the IT delivery. That sponsor is accountable for ensuring their business unit releases SMEs as agreed.
- They run fortnightly resourcing checkpoints as a standing agenda item at the delivery lead level, separate from the broader project status meeting.
Contracts with vendors need a substitution clause with teeth. A clause that requires the agency's written approval before any named resource is replaced, with a minimum notice period and a competency matching requirement, changes the vendor's calculus. Without it, substitution is frictionless and common.
What procurement can do earlier
Resourcing conflicts on government IT projects are often seeded during procurement, not delivery. Agencies that specify functional requirements in detail but leave resourcing arrangements vague are setting up future contention. A well-structured procurement for a complex project names the roles the vendor must staff, the minimum experience levels, the on-site commitment, and the process for handling substitutions. It also requires the vendor to demonstrate, not just assert, that the proposed individuals are available for the contract duration.
On the agency side, funding a project without also funding the business unit backfill is a reliable route to SME unavailability. Finance teams sometimes treat project funding and operational staffing as separate budget lines with different approval paths. Agencies that have learned to bundle them into a single project business case have fewer resourcing surprises during delivery.
When the conflict is between programs, not within one
The hardest resourcing conflicts to resolve are the ones that cross program boundaries. Two project directors, both with mandates from senior executives, competing for the same three people, neither willing to defer. These conflicts can only be resolved above the project level, which is precisely what portfolio governance is for. In practice, Australian agencies that have strong portfolio offices resolve these faster and with less relationship damage than those relying on project-to-project negotiation.
The mechanism matters. A portfolio office that publishes a priority stack for shared resources, updated at least quarterly and endorsed by the relevant deputy secretary or chief executive, gives project teams something to point to. A portfolio office that produces reports but doesn't hold authority over resource allocation adds process without solving the underlying conflict.
Getting resourcing right is less glamorous than fixing architecture or scope, but it's where Australian government IT projects most often quietly lose ground. The teams that treat it as a governance discipline, not just a logistics task, finish with fewer surprises.