Programme dependency management is the practice of identifying, tracking, and actively managing the relationships between projects where the progress of one depends on the output, resource, or timing of another. Done well, it stops a project with a perfect internal plan from failing anyway, because something it relied on outside its own scope never arrived.
A project can hit every one of its own milestones and still miss its deadline, not because anything inside the project went wrong, but because a dependency it was quietly relying on, a dataset from another team, a decision from a different workstream, a resource shared across two initiatives, showed up late or not at all. This is one of the most common and least visible causes of programme failure, precisely because it never shows up as a fault in the project itself.
This guide covers what programme dependency management involves, the types of dependencies that most commonly cause trouble, how to track them properly, and how Project Director approaches the problem.
What counts as a dependency in a programme?
A dependency exists whenever a project cannot progress, or cannot progress as planned, without something controlled by a different project, team, or external party. Dependencies generally fall into four categories.
Finish-to-start dependencies. Project B cannot begin a specific piece of work until Project A delivers a defined output, such as a data migration project needing a legacy system decommissioned first.
Resource dependencies. Two projects need the same specialist, whether a person or a piece of shared infrastructure, at overlapping points in their timelines, and only one can have priority.
Decision dependencies. A project is waiting on a decision, a budget sign-off, an architecture choice, a vendor selection, that sits outside its own governance and belongs to a different stakeholder or committee.
External dependencies. A project relies on a third party, a supplier, a regulator, or another organisation entirely, whose timeline the PMO has limited or no control over.
The common thread across all four is that the dependency sits outside the project's own delivery team, which is exactly why it tends to be invisible in a standard project status report focused on the team's own tasks and milestones.
Why unmanaged dependencies cause projects to fail for reasons outside their control
A project status report typically tracks internal progress: tasks completed, milestones hit, budget spent. None of that data captures whether the project is waiting on something external, because the wait itself does not show up as a task the team owns.
This is how a project can report green, on schedule, on budget, in scope, right up until the week a dependency fails to land, at which point the project's RAG status drops sharply with what looks like no warning. The warning existed. It just was not being tracked, because dependency risk lives between projects, not inside any one of them, and most reporting structures are built entirely around the inside.
The cost compounds at portfolio level. A programme built from several interdependent projects is only as reliable as its weakest dependency, yet portfolio reporting that only aggregates each project's own RAG status will show every project as healthy right up until the chain actually breaks.
How to build a dependency management process
Map dependencies at the point a project is grouped into a programme, not after work has started. When a project is assigned to a programme, that is the moment to ask what it needs from, or provides to, every other project inside it. Waiting until a dependency becomes urgent means discovering it under pressure rather than planning around it.
Log each dependency with an owner on both sides. A dependency needs two named people: the person waiting on it, and the person responsible for delivering it. A dependency with only one owner tends to be chased by the person waiting and ignored by everyone else.
Give every dependency its own status and date, separate from the project's internal milestones. Track whether the dependency is on track, at risk, or breached, and the date it is due, distinct from the receiving project's own RAG status, so the two signals do not get blended into one and lose their individual meaning.
Review dependencies at the programme level, not just within each project. A Programme Manager, not an individual Project Manager, is usually the right owner for cross-project dependency review, since they are the one person positioned to see both sides of the relationship.
Escalate dependency risk before it becomes dependency failure. A dependency showing early warning signs, a slipping delivery date, a resource conflict emerging, should be escalated as its own risk item, rather than waiting for the receiving project's own status to go red once the dependency has already failed to arrive.
Common mistakes in managing programme dependencies
Treating dependencies as a one-time planning exercise. Dependencies get mapped once, at the start of a programme, and never revisited as scope or timelines shift. A dependency map that is not maintained becomes inaccurate faster than most teams expect.
No visibility across project boundaries. Each Project Manager tracks their own risks and issues, but nobody holds the cross-project view, so a dependency that both sides know about informally never gets logged anywhere either side can be held to.
Confusing a dependency with a generic risk. A dependency is a specific, known relationship between two pieces of work with a defined owner on each side. Logging it as a vague entry in a general risk register, with no clear counterpart owner, tends to mean it gets reviewed as an abstraction rather than actively managed as a relationship.
How Project Director solves this
Most of the failure modes above come down to one structural problem: dependency information lives outside the systems tracking project and programme status, usually in someone's head, a side conversation, or a separate spreadsheet nobody else opens. Project Director addresses this by keeping dependency-relevant context inside the same structure used for everyday portfolio management, rather than treating it as a separate discipline bolted on afterward.
Because Programmes group related projects deliberately, on the basis that they contribute to a shared outcome together, the Programme view is where cross-project relationships are meant to be visible in the first place. A Programme Manager working inside Project Director sees every project inside their programme, its RAG status, timeline, and budget, in one place, which is the same view where a dependency conversation should happen rather than in a document maintained separately from delivery data.
Resource Capacity extends this further for the resource-dependency category specifically. Because it tracks allocation across every active project a team member touches, not just within a single project, a resource conflict between two interdependent projects becomes visible as an over-allocation flag before it turns into a missed handoff date, closing exactly the kind of gap that causes a well-run project to fail for a reason its own status report would never have shown.
And because Objectives and KPIs sit above the Portfolio, Programme, and Project structure, a Programme Manager reviewing dependency risk can also see whether the projects on either side of a dependency are still linked to the same strategic outcome, which is often the fastest way to spot a dependency conflict that reflects a deeper prioritisation problem rather than just a scheduling one.
Frequently asked questions
What is the difference between a dependency and a risk? A risk is a potential event that could affect a project, whether or not another project is involved. A dependency is a specific, known relationship where one project's progress relies on another project, team, or external party delivering something by a certain point. Every unmanaged dependency is a risk, but not every risk is a dependency.
Who should own dependency management in a programme? A Programme Manager typically owns cross-project dependency tracking, since they are positioned to see both sides of a relationship between projects inside their programme. Dependencies that cross programme or portfolio boundaries usually need PMO-level visibility as well.
How often should dependencies be reviewed? Dependencies with an approaching due date should be reviewed at least as often as the receiving project's own status, typically weekly, since a dependency slipping is often the earliest warning sign a project has of a coming schedule risk.
Can dependency management be automated? The tracking and visibility of dependency status can be supported by software, particularly where projects and programmes already exist as structured, linked data. The judgement of which dependencies matter most and how to resolve a conflict between two competing ones still requires a Programme Manager's active involvement.
The practical takeaway
A project's own status report will never tell you the whole story if the biggest risk to its deadline sits outside its own scope. Programme dependency management exists specifically to make that outside risk visible before it becomes a missed date, by giving every cross-project relationship a named owner, a status, and a place to be reviewed alongside the delivery work it affects.
See whether your portfolio still matches your strategy. Start your 14-day free trial, no credit card required.
