Managing Cross-Team Dependencies: The Mistakes That Cause Most of the Slippage
In a single-team project, the project manager controls most of the factors that determine schedule performance. In a multi-team project -- which describes the vast majority of capital projects, government programme implementations, and large enterprise technology deliveries -- the project manager controls far fewer of them. Cross-team dependencies are where most of the schedule risk lives, and in 2022, with return-to-office transitions creating coordination friction and labour shortages leaving some teams understaffed, the risk is higher than usual.
The following describes the five dependency management mistakes that cause most of the slippage in multi-team projects -- and what to do instead.
The Five Mistakes
Mistake 1: Not mapping dependencies before the schedule baseline is set. Most multi-team project schedules are built team by team, with each team estimating its own work in isolation. Dependencies are added as links in the schedule software after the fact, rather than used to drive the sequence and duration of activities. The result is a schedule that shows dependencies but was not built around them. Critical path analysis on such a schedule is unreliable. Fix: run a dependency mapping session with all team leads before schedule baseline. Identify the ten to twenty most critical inter-team dependencies and verify that the schedule sequence reflects them correctly.
Mistake 2: No single owner for each dependency. A dependency between Team A and Team B is typically owned by neither. Team A assumes Team B will deliver on time because that is what the schedule shows. Team B is managing its own priorities and may not have flagged that the deliverable in question is at risk. Fix: assign each critical dependency a dependency owner -- the person responsible for proactively monitoring the dependency and escalating if it is at risk. The dependency owner is not the project manager; the project manager cannot monitor every dependency on a large programme. The dependency owner is typically a workstream lead or a senior technical contributor.
Mistake 3: Assuming a dependency is resolved once it appears in the schedule. Putting a dependency link in the schedule software does not resolve the dependency. It documents it. Many project teams confuse documentation with management. Fix: create a dependency log separate from the schedule. Each critical dependency should have: the delivering team, the receiving team, the planned handoff date, the current status (on track / at risk / late), the dependency owner, and notes on any open issues.
Mistake 4: Not sharing dependency updates across teams. In a multi-team programme, teams that are not directly connected by a dependency often lack visibility into whether upstream dependencies are tracking on schedule. By the time the delay reaches them, there is no time to adjust. Fix: include a dependency status summary in the weekly programme report -- not just for the programme manager, but distributed to all team leads. Teams should be able to see the status of dependencies that affect them regardless of whether they are the delivering or receiving team.
Mistake 5: No escalation path when a dependency slips. When a dependency slips, it is often managed as a bilateral problem between the two teams directly involved. By the time the issue escalates to the programme level, the impact has compounded. Fix: define the escalation threshold in advance. A dependency that is projected to be more than a defined number of days late (three to five days is typical for a project with weekly milestone cadence) triggers automatic escalation to the programme manager. The programme manager then decides whether to escalate further, resequence, or accept the impact.
XNM supports public-sector and capital-project organisations in building programme-level dependency management frameworks. Reach out to XNM's program & project delivery advisory team to discuss dependency risk on your programme.