In the complex programs I've run, the hardest delivery problems weren't technical. They were organizational.
The dependency blocking your sprint sits with a different vendor. The team that has to resolve it reports to a different company. The schedule that governs their work was set by someone in a different part of the organization. Your authority over their timeline is approximately zero.
This is the multi-vendor dependency problem, and in my experience it's the leading cause of schedule slip that can't be traced to a technical failure.
Why standard PM tools fail here
Standard program management tools are built for environments where the program manager has authority over the resources that determine the schedule. A Gantt chart that shows a dependency doesn't give you the ability to accelerate the vendor on the other end of it. An escalation path that runs through your own management may not connect to the authority structure that governs the blocking vendor at all.
The tools that work for managing your own delivery don't work for managing delivery you don't control. Used on cross-vendor dependencies, they produce the same output — a plan that shows the dependency, a flag when it slips, a report to leadership that an external factor affected the schedule — without actually moving the dependency.
What moves cross-vendor dependencies
Cross-vendor dependencies move through relationships, shared documentation, and escalation paths established before the dependency became a blocker.
The relationship. The program manager who knows the lead on the blocking vendor — their priorities, their constraints, their decision process — has more leverage than the one sending formal requests up a chain. This isn't back-channel communication that bypasses governance. It's the situational awareness that lets formal requests be targeted, timed, and framed in terms the receiving team can act on.
The shared documentation. Dependencies documented in both programs' planning artifacts — the interface agreement, the shared master schedule, the joint risk register — have formal visibility that creates mutual accountability. Dependencies that exist only in one program's plan have visibility only where the program manager already has authority.
The escalation path. Every cross-vendor dependency needs a documented escalation path that rises above the vendor level to the shared authority with oversight of both. This path is established at program kickoff, not when the dependency becomes critical. When it does become critical, the path is used immediately — not as a last resort after direct outreach has failed.
The planning decision that changes everything
In the programs I've seen, the multi-vendor dependency problem is a planning failure before it's a delivery failure. The dependency existed at the start. The planning that should have established joint documentation, shared schedule visibility, and an escalation path didn't happen — either because the integration complexity wasn't recognized, or because building that structure requires coordination work nobody's budget explicitly funds.
The programs I've seen manage cross-vendor delivery well made one decision at the start that the others didn't: they mapped every external dependency to the vendor and the authority structure that controls it, and built the documentation and escalation infrastructure before they needed it.
The dependency that surfaces mid-program as a blocker was visible at the start as a risk. The difference between a managed risk and a blocker is whether the infrastructure to manage it was built before it materialized.
The bottom line
The PM who manages cross-vendor dependencies well isn't the one with the most formal authority. It's the one who built the most situational awareness across the boundaries of that authority — who knows what the adjacent vendor is working on, what their constraints are, and what conditions would let the dependency accelerate.
That awareness doesn't come from status meetings. It comes from relationships established early, maintained consistently, and activated specifically when the dependency needs to move.
Cybaris Consulting advises programs on delivery architecture and cross-vendor integration — the planning infrastructure that makes multi-vendor delivery manageable. Start a conversation at cybarisconsulting.com.