Workforce planning on Australian government IT projects is where optimism collides with reality. Agencies regularly begin procurement and scoping with an incomplete picture of who will actually deliver the work, whether that means permanent staff, contractors, or a mix of both. The result is predictable: skill gaps surface mid-delivery, key roles sit vacant during critical phases, and project timelines stretch in ways that budget reforecasting can't fix.
This piece covers how workforce planning is supposed to work on these projects, where it breaks down, and what distinguishes agencies that get it right from those that don't.
Why workforce planning is harder than it looks for government IT
The Australian Public Service operates under constraints that private sector IT teams don't face. Australian Public Service Commission policies govern classification levels, remuneration bands, and engagement conditions for permanent staff. Those rules sit alongside separate frameworks for labour hire and ICT contractors, which typically flow through whole-of-government panels. Neither system is built for speed.
By the time an agency identifies a workforce gap, drafts a position description, clears classification approval, opens a recruitment process, and receives a start date from a hire, months have passed. On a project with an 18-month delivery window, losing three months to a single role is significant. Losing them across four or five roles is a crisis.
The contractor market complicates this further. Specialist skills in areas like cloud architecture, cybersecurity, and digital service design are in high demand across both government and the private sector. Agencies competing for those contractors face commercial rates that often exceed their internal salary ceilings, which pushes them toward standing offer arrangements that carry their own lead times and compliance requirements.
The planning stage: where the gaps begin
Workforce planning on government IT projects typically gets the least attention during discovery. Agencies focus heavily on requirements, procurement strategy, and vendor selection. Resourcing often gets treated as something to sort out after scope is settled. That sequencing creates a structural problem.
By the time a project enters delivery, the workforce picture has usually been defined by one of two approaches: a staffing model inherited from the business case, or a contractor roster assembled quickly after vendor engagement begins. Neither is reliable. Business cases are written months or years before delivery starts, and the skills they assume are available are often no longer available in the market at those rates. Contractor rosters assembled under time pressure produce teams that weren't designed together and may lack complementary skills.
Good workforce planning at the discovery stage involves several concrete steps. Agencies need to map required skills against current APS capability before assuming roles can be filled internally. They need to assess contractor market availability, not just rate card feasibility. And they need to plan for workforce transitions across project phases, because the skills needed to build a system differ from those needed to operate it. This connects directly to how agencies handle IT project knowledge transfer, which is itself dependent on having the right people ready to receive that knowledge at the right time.
Role design and skills matching
One of the more persistent problems in government IT workforce planning is role design. Position descriptions written for APS classification purposes often don't map cleanly onto the technical roles a project actually needs. A "Senior IT Officer Grade 2" might describe someone expected to perform the work of a principal cloud architect, a solution designer, or a business analyst, depending on which agency is writing the PD.
This ambiguity creates downstream problems. Candidates self-select inappropriately. Hiring managers evaluate applications against different mental models of what the role requires. And once someone is placed, mismatches between their capabilities and project needs emerge slowly, after probation periods and panel decisions have already closed off simple remedies.
Some agencies have moved toward capability frameworks that map technical roles to specific competencies rather than classification-level descriptors. The Digital Transformation Agency has published workforce capability guidance for digital roles, but uptake across Commonwealth agencies is inconsistent. State government agencies operate their own HR frameworks, which vary considerably in technical specificity.
Contractor engagement: what goes wrong and when
Contractor engagement is where the most acute resourcing problems tend to occur. Agencies use contractors for legitimate reasons: specialist skills not available in-house, flexible engagement for fixed-term projects, and speed of onboarding compared to ongoing recruitment. But the contractor model introduces vulnerabilities that workforce planning needs to account for explicitly.
Key-person dependency is the most common. A project builds critical knowledge in two or three contractors, and when those contractors leave, that knowledge leaves with them. Agencies that treat contractors as interchangeable units, bringing in replacements at the same rate code without assessing knowledge transfer, compound the problem. The gap between what a departing contractor knows and what the replacement can absorb in the first two weeks is almost always larger than the project plan assumes.
Retention is another pressure point. Government IT contractors work on notice periods that can be as short as two weeks. A private sector client offering a better rate or a more interesting project can pull a key contractor mid-sprint, mid-integration, or in the fortnight before a go-live. Workforce planning that doesn't account for attrition risk, and build in succession depth for critical roles, is fragile by design.
Onboarding friction compounds all of this. The time it takes to grant system access, security clearances, and facility entry to new contractors on government projects is significant. Detailed coverage of this problem is available in the analysis of contractor onboarding on Australian government IT projects, which found that agencies routinely absorb two to four weeks of unproductive time before a new contractor can contribute meaningfully.
Permanent staff: capability uplift and rotation
A well-structured government IT project should build permanent APS capability, not just deliver a system. That means embedding permanent staff in delivery teams, not parking them in governance roles while contractors do the technical work. The distinction matters for two reasons.
First, permanent staff who participate in delivery understand the system they're inheriting. They ask the right questions of the vendor, spot assumptions that don't match operational reality, and carry contextual knowledge into the maintenance phase. Contractors who deliver and leave take that context with them.
Second, the APS has a genuine interest in building technical skills that don't require constant contractor spend to maintain. Projects that structure permanent staff as active participants rather than passive overseers make a contribution to that goal. Those that don't tend to produce agencies that are perpetually dependent on the same vendors or individual contractors to operate what they built.
Capability uplift planning is most effective when it's tied to a specific workforce outcome: a named permanent officer who can perform a defined technical function by project close. Vague commitments to "skills transfer" that aren't attached to individuals and competencies rarely materialise.
Cross-agency and shared workforce arrangements
Several Commonwealth and state agencies have experimented with shared workforce pools for IT delivery, drawing on secondments, cross-agency placements, and shared service arrangements. Results are mixed.
Secondments can work well when they're genuinely voluntary, when the secondee's home agency commits to backfilling the role, and when the receiving project has a clear onboarding plan. When secondees are pushed into projects to fill a gap rather than because they have the right skills, the arrangement benefits no one. The secondee spends months working outside their competency. The project carries a resource that isn't contributing at the required level. And the home agency loses a productive staff member without getting meaningful capability in return.
Shared service centres for common IT functions, such as service desk, desktop support, and infrastructure operations, have a stronger track record when the scope is well-defined and the SLA framework is clear. Where they struggle is in supporting project delivery work, which requires contextual knowledge and flexibility that a shared model finds difficult to provide.
What separates effective workforce planning from the rest
Across Australian government IT projects that handle workforce planning well, a few practices consistently appear.
- Workforce mapping starts at discovery, before vendor selection, and identifies specific skill gaps against current agency capability.
- Critical roles are defined by competency, not just classification, and have succession cover identified before the project enters delivery.
- Contractor attrition risk is treated as a standard project risk, with mitigation plans for key-person dependencies.
- Permanent staff participate in technical delivery, not just governance, with named capability outcomes tied to individual officers.
- Workforce planning is reviewed at each project phase gate, not set once at initiation and forgotten.
None of these practices are particularly complex. Most agencies know they matter. The gap is between knowing and doing, and it widens whenever projects are under time pressure to start delivery. Workforce planning is rarely the reason a project is delayed at initiation, so it gets deferred. It's almost always part of the reason a project struggles in the middle, when it's much harder to fix.