Dependency ownership assigns every cross-team dependency to a single named person who is responsible for resolving it, by a date, with a status anyone can check. It is the difference between a portfolio that knows it has 40 dependencies and a portfolio that is clearing them. The register is the inventory. Ownership is the mechanism.
Dependencies are identified when the release plan is drawn in the Focus practice, and they are worked in the Deliver practice, where how long a blocked item waits is one of the numbers Deliver tracks.
How does dependency ownership work?
The part registers often leave out is the owner: one person by name, not a team, not a role, not two people. Around that name, a workable dependency is concrete and dated. "An API that returns a customer's active policies by policy number, in the integration environment" can be chased. "Integration support from the platform team" cannot. The date that matters is when the receiving team needs the thing, not when the providing team expects to have it, and when those two dates differ, the gap is the risk.
A dependency also needs to show when it last moved, because one that has not changed in three weeks is a different problem from one that changed yesterday. And it helps to know, while there is still time, what happens if it slips. Deciding the fallback early is cheaper than deciding it in the release readiness review.
The owner is normally on the receiving side, because the receiving team is the one that suffers if it does not arrive. The owner does not have to build the thing. The owner has to get it agreed, get it dated, and raise it when the date stops looking real.
Why is identifying dependencies only the easy half?
Because identification produces a list and nothing else. Many planning workshops end with a wall of sticky notes, a register with 40 rows, and a shared sense of having done the hard part. Two months later the same 40 rows exist, several have a status of "in discussion", and the release date has not moved.
Nothing in the list causes anyone to act. A row in a register has no calendar entry, no next step, and no consequence for staying open. The work of a dependency is a series of conversations: agreeing what is actually needed, getting it into somebody's plan, and confirming it arrived in a usable state. Conversations need a person who is on the hook for having them.
The second reason is that the list keeps looking healthy while the situation degrades. Statuses stay where someone set them at the workshop, because nobody is obliged to update a row they do not own. The register ages and the portfolio finds out at integration.
Why does putting two owners on a dependency mean neither acts?
Two owners is a common way for a register to look complete and behave as if it is empty. Each name assumes the other is closer to it. Each sees the row with a name on it and reads that as covered. Neither escalates, because escalating implies the other one failed.
The same pattern hides inside plural owners that look reasonable: a team name, a role such as "integration lead", or a pair from each side. The test is whether one person would be asked about this dependency in a stand-up and expected to answer. If the answer is "one of them would know", it has no owner.
If both sides genuinely need to act, split the dependency into two rows with one owner each. One row, one name, one date.
What does good dependency ownership look like?
Rows close. Each dependency has a person who agreed to own it with the other side listening, a date both teams have seen, and an ask specific enough to chase. The register lives where both teams already look, and it is reviewed at the coordination rhythm with two questions for each row: has it moved, and is the date still real.
It is read by age rather than severity. Severity is a judgment call that people revise downward under pressure. Age is a fact, and stale rows are where release dates go, so a row that stops moving gets escalated whether or not anyone feels it is urgent yet.
What does dependency ownership look like in practice?
Say a public sector agency planning a licensing system has 31 dependencies in its register at the end of planning. Every row names a team. Six weeks in, the portfolio lead reads the register by age and finds 19 rows that have not changed status since the workshop.
The fix can take one session. Each row gets a single name from the receiving team, a need-by date taken from the release plan rather than from optimism, and a concrete ask. Nine rows collapse into three once the asks are written precisely, because they were the same request described three ways. Four rows turn out to have no receiving date at all, which means nobody can say when they matter, and two of those are closed as no longer needed.
The remaining rows go to the weekly cross-team session, sorted by age. The useful outcome is not the rows that close. It is that two dependencies on a single identity platform team surface as unschedulable within the quarter, which turns a delivery problem into a portfolio decision about what to cut while there is still time to cut it.
Dependency ownership vs a RAID log: what is the difference?
A RAID log records risks, assumptions, issues, and dependencies for a project so that a project manager can report on them. Dependency ownership is a working practice for one of those four categories, and it is aimed at resolution rather than reporting.
| RAID log | Dependency ownership | |
|---|---|---|
| Purpose | Record and report | Resolve by a date |
| Scope | Risks, assumptions, issues, dependencies | Cross-team dependencies only |
| Owner | Often the project manager for the whole log | One named person per dependency |
| Reviewed | At a status meeting, by exception | At a fixed cadence, by age |
| Test of health | Is the log up to date | Are rows closing |
A RAID log is not the problem. A RAID log where the dependencies section has one owner (the project manager) for 40 rows across six teams is the problem, because that person can report on all 40 and resolve none of them. Keep the log if the organization runs on it, and give each dependency row its own name and date inside it.
Where does this fit in PPM4Agile?
Dependency ownership is one of the Deliver terms in the agile portfolio management terms glossary, and it depends on the release plan from Focus being real enough to name hand-offs. If the register is large and nothing is closing, the underlying problem is often too much parallel work rather than poor follow-up, which is what the WIP limits checklist addresses. If you are not sure which of those it is, a 60-minute Portfolio Clarity Session is a place to start, and it ends with what fits next.