Managing Project Dependencies: When Everything Connects to Everything
A single project with a clear scope, a competent team, and adequate resources is a relatively tractable management challenge. The project manager controls the inputs, monitors the outputs, and has enough situational awareness to intervene when things go wrong. The dependencies that matter are mostly internal -- one task cannot start until another finishes, one team cannot proceed until another delivers -- and they are visible to everyone on the team.
Large programmes are a different problem entirely. When ten, twenty, or fifty projects are running in parallel, the dependencies between them can multiply faster than any single programme manager can track. A delay in a data migration project affects the user acceptance testing of three other projects. A procurement decision that slips three weeks cascades into a resource conflict in four workstreams. A regulatory approval that arrives later than planned forces a replanning exercise that touches half the programme. The result is that the programme's critical path is not a single line -- it is a network, and the most dangerous dependencies are often the ones that no one has mapped.
Types of Dependencies
Project management frameworks distinguish four formal dependency types, each describing a different relationship between activities or deliverables.
Finish-to-Start (FS): the most common dependency type. Activity B cannot start until Activity A finishes. Data must be migrated before user testing can begin; infrastructure must be provisioned before application deployment can proceed. FS dependencies define the forward flow of work in most project schedules.
Start-to-Start (SS): Activity B cannot start until Activity A starts. This dependency type appears where two activities must begin in coordination -- parallel development workstreams that both need to begin at the same time to share early outputs, or communications that must be sent simultaneously with a system cutover.
Finish-to-Finish (FF): Activity B cannot finish until Activity A finishes. Testing cannot be completed until development is complete; final documentation cannot be signed off until the product it documents has been delivered. FF dependencies are common in review and sign-off processes.
Start-to-Finish (SF): Activity B cannot finish until Activity A starts. The least common dependency type, it appears in shift-handover scenarios where a new activity must begin before the old one can be closed out. SF dependencies are sometimes used in just-in-time contexts where an old system must not be decommissioned until its replacement is live.
Hard Dependencies Versus Soft Dependencies
Beyond the formal taxonomy, a more practically important distinction is between hard dependencies and soft dependencies.
Hard dependencies are logically required: the nature of the work means that one activity genuinely cannot proceed until another is complete. You cannot test software that has not been written. You cannot train users on a system that has not been deployed. You cannot obtain planning permission after construction is complete. Hard dependencies are non-negotiable -- no amount of project management creativity can make an activity occur before its logical predecessor.
Soft dependencies are organisational or resource-driven: one activity is dependent on another not because of logical necessity but because of how the organisation has structured the work, who is doing it, or how decisions are made. A project that requires sign-off from a steering committee that meets monthly has a soft dependency on the committee's meeting schedule. A workstream that depends on a specialist who is also allocated to another workstream has a soft dependency on that individual's availability. Two projects that share a testing environment have a soft dependency on the schedule for environment access.
The distinction matters because hard dependencies are fixed and must be respected; soft dependencies are potentially negotiable. A monthly steering committee can be scheduled more frequently for a critical decision. A shared specialist can be dedicated to one workstream for a defined period. A shared testing environment can be time-boxed with explicit allocation rules. Programme managers who treat every dependency as hard and non-negotiable lose degrees of freedom that could, in practice, help them recover from delay.
Mapping and Managing Dependencies
The prerequisite for managing dependencies is making them visible. Three tools are commonly used in combination.
The dependency register is the foundational artefact: a structured log of all known inter-project dependencies, recording the dependency type, the projects involved, the specific deliverable or milestone that creates the dependency, the planned date, the current status, and the owner responsible for monitoring and escalating. A dependency register that is maintained rigorously -- updated when plans change, reviewed regularly, and used actively in programme status conversations -- is significantly more useful than one that is created at programme initiation and never updated.
The dependency heat map visualises the concentration of dependencies across the programme. Projects that are depended upon by many others -- that sit at the centre of the dependency network -- are the highest-risk projects from a programme perspective. A delay in a project that has ten downstream dependencies is fundamentally more dangerous than a delay in a project that has none. The heat map makes this visible and helps the programme manager and PMO prioritise their monitoring and intervention effort.
Regular dependency meetings -- dedicated sessions, separate from general project status reviews, focused specifically on the health of inter-project dependencies -- create a structured forum for project managers to surface emerging dependency risks before they materialise into delays. These meetings work best when they are time-boxed, focused on exceptions and risks rather than status reporting, and attended by the project managers of the most interconnected projects.
The PMO's Role in Cross-Project Dependency Management
In a well-structured programme, the programme management office (PMO) owns dependency management as a cross-cutting function. Individual project managers are responsible for identifying and managing the dependencies their projects have on others and that others have on them. The PMO is responsible for the programme-level view: maintaining the dependency register, facilitating the dependency heat map analysis, running the dependency meetings, and escalating dependency risks that cross the programme's risk threshold to the programme manager or sponsoring body.
The PMO role is particularly important in managing soft dependencies. Individual project managers naturally focus on the dependencies that affect their own project's critical path. The PMO can see across the full programme and identify dependency conflicts that no single project manager has the vantage point to see -- two projects that both depend on the same resource in the same month, or a sequence of dependencies that, while each individually managed, create an aggregate critical path that threatens the programme's overall delivery date.
When a Dependency Is at Risk
Even with good dependency management in place, dependencies will come under pressure. A project that is supplying a dependency will occasionally be delayed; a shared resource will become unavailable; an external factor will disrupt an assumed input. The test of dependency management is not whether these situations arise -- they will -- but whether the programme is positioned to respond before the impact cascades.
When a dependency is at risk, the first step is to assess the downstream impact: which projects are affected, when do they need the dependent output, and how much schedule float exists before the risk becomes a delay. If float exists, the risk can be managed as a dependency risk on the register. If float is exhausted, the situation has become a programme-level issue that requires escalation, replanning, or negotiation of a recovery plan with the affected project managers.
The recovery options for a dependency at risk are limited but important to explore: accelerating the supplying project (additional resources, reduced scope); reconfiguring the dependency (can the receiving project begin with a partial output?); resequencing other work to absorb the delay; or accepting a revised programme milestone and communicating the change to stakeholders with enough lead time for them to plan around it. None of these options is cost-free -- but the cost of late escalation is always higher than the cost of early intervention.
XNM Consulting provides programme management support to complex, multi-project programmes, including dependency mapping, PMO establishment, and cross-project governance. Learn more about our program and project delivery services.