Dependency mapping sits at the intersection of scope, schedule, and risk on every Australian government IT project. Done well, it tells a project team which work items, systems, vendors, and teams must deliver before others can begin. Done poorly, it's a diagram produced in the discovery phase, exported to a PDF, and never opened again. The gap between those two outcomes is where most programme delays actually originate.
What dependency mapping is supposed to do
A dependency map is a structured view of relationships. It answers three questions: what relies on what, which of those dependencies sit outside the project team's direct control, and what happens to the critical path if a dependency slips. In practice, Australian agencies use the term loosely. Project management plans filed with the Department of Finance often include a dependency register that lists other in-flight projects, vendor deliverables, and legislative prerequisites. That register is not the same as a living dependency map. A register names things. A map shows how they connect and propagates impact.
The distinction matters because government IT programmes are unusually dependency-dense. A single federal transformation project might depend on: a shared identity platform managed by another agency, a data-sharing agreement still in legal review, a legacy API that another programme is about to retire, and a vendor milestone tied to a separate whole-of-government contract. Each dependency carries its own risk, its own owner, and its own timeline. A list doesn't show you the chain reaction when one of them slips by six weeks.
Where agencies typically go wrong
The most common failure is mapping dependencies once at project initiation and treating the result as final. Government projects run for years. The dependency landscape at month three is genuinely different from the one at month eighteen, as vendors renegotiate, related programmes reset their schedules, and policy context shifts. A dependency map that isn't updated at least quarterly is a historical document, not a planning tool.
The second failure is scope. Most project teams map internal technical dependencies with reasonable care. What they miss are the organisational and cross-agency dependencies that carry the highest risk. If the project needs a sign-off from a steering committee that meets bi-monthly, that's a dependency. If the deployment requires a change to a shared data feed owned by a different agency, that's a dependency with an entirely separate governance chain and no obligation to move at the project's pace. These soft dependencies are routinely absent from formal mapping exercises.
A third failure is accountability. A dependency without a named owner is just an assumption. Australian agencies frequently list dependencies against organisational units rather than individual roles, which means no one is actually responsible for tracking the status of a critical input. When something slips, the question of who should have seen it coming gets diffuse fast. This is closely related to the escalation problems that affect escalation paths on Australian government IT projects, where the absence of clear ownership compounds delays.
The link to risk registers and change control
Dependency mapping connects directly to two other disciplines that agencies often treat as separate workstreams: risk management and change control. An unresolved external dependency is a risk. If it's not reflected in the risk register, the risk register is incomplete. If it's reflected but not tracked against the dependency map, no one can easily answer whether the risk is materialising or not. The two artefacts should reference each other explicitly. They rarely do.
Change control is the other side of the same problem. When a dependency shifts, the project team needs to assess whether the change to an input constitutes a scope change, a schedule impact, or both. Agencies that treat change control as a bureaucratic gate on internal decisions tend to miss the fact that external dependency shifts require the same assessment. Change control discipline in Australian government IT projects tends to be better understood for internal changes than for externally-driven ones, and dependency mapping is where that gap shows up first.
What good practice looks like
Effective dependency mapping in government IT programmes shares a few consistent characteristics.
- Dependencies are categorised by type: technical, organisational, legislative, and vendor. Each type has a different management approach and a different risk profile.
- Each dependency has a named owner, a due date, and a defined handoff criterion. "Agency X provides the API" is not a handoff criterion. "Agency X delivers a tested API endpoint to the agreed specification by 15 March" is.
- The map is reviewed at every programme board meeting, not just at milestone gates. Owners are asked to confirm status, not simply asked whether anything has changed.
- Cross-agency dependencies are escalated to a level where both agencies have representation. A project manager cannot resolve a dependency on another agency's priorities unilaterally.
Some agencies have started using dependency mapping tools integrated with their programme management platforms. The Digital Transformation Agency has published guidance on digital service delivery that touches on inter-agency coordination, though dependency management at the programme level remains largely a matter of local practice rather than mandated method.
The critical path problem
A dependency map only becomes operationally useful when it's connected to the critical path. Most project schedules in Australian government IT are built in tools that support critical path analysis. The problem is that the dependencies fed into those schedules are usually the internal technical ones. External dependencies, the ones that are actually hardest to control, get listed in the risk register and managed separately from the schedule. That separation means the schedule never accurately reflects the true critical path.
The consequence is optimistic milestone reporting until it isn't. A project can appear on track according to its internal schedule while sitting on a dependency that will push delivery by four months. The steering committee sees green. The project manager knows there's a problem. The dependency map, if it were connected to the schedule, would make the problem visible to both at the same time.
This structural disconnect between the dependency register and the schedule tool is the single biggest dependency mapping failure in Australian government IT. It's fixable. It requires discipline about which dependencies go into the schedule as predecessor tasks, and which stay as watch-items in a register. Almost nothing that sits on the critical path should stay in a separate register. If it can stop the project, it belongs in the schedule.
Dependency mapping at programme level
Individual projects within a larger programme introduce another layer. Programme-level dependency mapping asks which projects depend on outputs from other projects in the same portfolio, and what the sequencing implications are. Australian agencies running transformation programmes across multiple workstreams often discover these cross-project dependencies late, when two teams realise they're both assuming the other will deliver a shared component first.
Programme offices that mandate dependency mapping across workstreams, and hold a cross-workstream dependency review monthly, catch these conflicts early enough to resolve them. Those that rely on workstream leads to self-report tend to find out at milestone reviews, which is too late to avoid a delay.
The discipline isn't complicated. It's consistent. A dependency map that's created, owned, reviewed, and connected to the schedule does its job. One that's created once and filed does not.