Cross-Team Dependency & Risk Playbook for Project Managers

Most delivery slips don't come from the work your team controls. They come from the thing you forgot to ask another team about three weeks ago — the API change that needs legal sign-off, the vendor who can't ship the connector until their Q3 release, the data migration that depends on someone in finance approving a schema change nobody told them about.

Dependencies live in the gaps between people. And those gaps don't show up on your Gantt chart until they're already costing you a week.

This playbook is narrow on purpose. It's not about general risk management or stakeholder politics. It's about one thing: building a working system to find dependencies before they find you, score them so you know which ones actually matter, and push the unresolved ones somewhere they get funded and worked — instead of rotting in a Slack thread.

The specific failure mode we're fixing

Here's the pattern that burns PMs over and over.

You run kickoff. Everyone nods. The plan looks solid. Three sprints in, your lead engineer mentions — almost in passing — that the reporting feature can't ship until the data team exposes a new field. You ask when that's happening. Nobody knows. There's no ticket. There's no owner. There's a vague memory of a conversation from a planning meeting back in March.

Now you're doing archaeology. DMing people, trying to reconstruct who promised what, and the data team lead tells you they're booked solid for six weeks and this was never on their roadmap.

That's not a people problem and it's not bad luck. It's a visibility problem. The dependency existed the whole time — it just never got written down anywhere that forced a decision.

Dependencies tend to fail in three predictable ways:

1. 1
   Invisible handoffs — the dependency was never recorded, so no one owned it until it blocked something.
2. 2
   Orphaned handoffs — it was recorded, but the "owner" was a team name, not a person, so it belonged to nobody.
3. 3
   Unresolved-forever handoffs — everyone knew about it, everyone agreed it mattered, and it still never got scheduled because it wasn't anybody's prioritized work.

Each one needs a slightly different fix.

Step 1: Build a dependency register that people actually fill out

The dependency register is just a structured list of every cross-team or vendor handoff your project relies on. The hard part isn't the table — it's getting people to populate it honestly and keeping it alive.

The mistake most teams make: they treat it as documentation. Something you fill out once at kickoff and never look at again. A dependency register is an operational artifact. It should change every week.

That fallback column is the one people skip and later regret. If a dependency has no fallback, you don't have a plan — you have a hope. Writing "if the vendor connector slips past June 1, we ship with manual CSV import" is what keeps a slip from becoming a scramble.

One practical note on ownership: "the data team" is not an owner. The register should name a human. If that human doesn't know they own it, you don't have a dependency recorded — you have a liability.

“

Message each named owner during the weekly review to confirm they accept ownership rather than relying on asynchronous replies.

The fastest way to validate the register is to message each named owner and ask them to confirm. The ones who say "wait, what?" are your early warnings.

Step 2: Score impact and urgency so you're not treating everything as a fire

Once you have a register, you'll have more dependencies than you can actively chase. On a mid-sized project it's not unusual to have 15–25 live cross-team dependencies at once. You can't escalate all of them — and if you try, people stop taking your escalations seriously.

So you score. Two axes, kept deliberately simple:

1. 1
   Impact — if this slips, how much damage? - 3 (High)

   Blocks a committed milestone or external launch date. - 2 (Medium): Delays internal work but has workarounds. - 1 (Low): Annoying, reschedulable, no milestone risk.

Multiply them. A 3×3 = 9 is a drop-everything dependency. A 1×1 = 1 can sit in the register and get a glance once a week.

1. 1
   Urgency — how soon do we need resolution to stay on track? - 3 (High): Needed within the next two weeks. - 2 (Medium): Needed in 3–6 weeks. - 1 (Low): More than six weeks out.

The part most people miss: urgency decays into impact if you ignore it. A dependency that's six weeks out and scores low urgency today becomes a high-impact fire in week five if nobody started it. Scoring isn't a one-time triage — it's a weekly re-score. The whole point is catching the dependency while it's still a cheap, 3-week fix instead of a 3-day panic.

If you want a deeper version of the urgency-versus-impact logic — including how to keep scoring honest when teams game it to get their stuff prioritized — there's more to dig into there. But for dependency management specifically, the 3×3 is enough to run with.

Step 3: Set SLAs and escalation thresholds before you need them

Step 3: Set SLAs and escalation thresholds before you need them

This is where most dependency systems quietly fail. People surface the dependency, score it, and then nothing happens. It sits at "At risk" for three weeks because there's no rule for when "at risk" becomes "someone with actual authority needs to hear about this."

An SLA here isn't a contractual thing. It's an internal agreement: how long can a dependency sit in a given state before it escalates automatically?

1. 1
   Blocked + impact score ≥ 6

   owner must respond within 1 business day; if no movement in 3 days, escalate to the owning team's manager.

2. 2
   At risk + impact score ≥ 6

   weekly check-in isn't enough — move to a dedicated thread and get a committed date within 5 business days.

3. 3
   Any dependency with Low confidence + High impact

   treat as already escalated. Don't wait for it to go red.

4. 4
   Vendor dependencies

   always add buffer. External partners respond on their cadence, not yours. Teams often assume a vendor turnaround of a couple days when the real contractual SLA is ten business days — that gap has eaten more than a few launch windows.

The threshold that matters most is the one that converts a stuck dependency into escalated work. Decide the trigger in advance and write it down. "If DEP-014 has no committed date by Friday, it goes to the steering sync" is a rule. "We'll keep an eye on it" is not.

Tying escalation to clear thresholds works much better when your broader decision-rights are already mapped — who's allowed to escalate what, and which thresholds unlock budget. If you haven't formalized that, the decision-rights architecture linking funding thresholds to escalation SLAs approach pairs naturally here, because it answers the "who decides and who pays" question that dependency escalations always eventually hit.

Step 4: Run a weekly dependency ritual (15 minutes, not an hour)

A register nobody reviews is a graveyard. The ritual is what keeps it alive. But it has to be short, or it becomes the meeting everyone dreads and silently skips.

1. 1
   Pull the register, sorted by impact score descending. You only talk about the top of the list. Anything scoring 2 or below gets skipped unless someone flags it.
2. 2
   For each high-score dependency, one question

   "Has anything changed since last week?" If the answer is no and the needed-by date is approaching, that's a signal, not a non-event. No change on a dependency that needs change is a problem.

3. 3
   Re-score urgency. Dates move closer. Something that was a 2 last week might be a 3 now.
4. 4
   Check the escalation thresholds. Anything that crossed a threshold gets assigned an action right there — not "we'll follow up."
5. 5
   Identify conversion candidates. Which unresolved dependencies have sat long enough that they need to become real, funded work?

Fifteen minutes. The discipline isn't in the length — it's in refusing to let the meeting drift into status theater. You're not there to hear updates. You're there to catch the dependencies that are about to turn red while there's still time to do something cheap about it.

One pattern worth watching: if the same dependency comes up red three weeks running with no movement, the problem isn't the dependency itself. It's that nobody with authority to resolve it is in the room. That's your cue to escalate the meeting, not just the item.

A quick visual of the ritual helps align participants.

Use the visual as a teaching aid when onboarding participants to the ritual.

Step 5: Convert unresolved dependencies into funded backlog or vendor work

This is what separates a dependency register from a complaint log.

Some dependencies will never resolve through goodwill and follow-up. The other team genuinely can't fit it in. The vendor genuinely needs a contract change. At that point, the dependency needs to stop being an informal ask and become actual scheduled work — either in someone's backlog as a prioritized, funded item, or in a vendor's statement of work.

1. 1
   Fund it into the owning team's backlog — which means it competes for their capacity like any other work, and someone has to decide it's worth displacing something else.
2. 2
   Scope it as vendor work — if an external partner can do it faster, or your internal team genuinely can't, turn it into a defined deliverable with acceptance criteria.
3. 3
   Kill the dependency — change your own design or scope so you no longer need it. This option is underused. Sometimes the cheapest fix is to not need the thing at all.

The decision trigger is straightforward: a dependency that has stayed unresolved past one SLA cycle, with high impact, is no longer a coordination problem. It's a resourcing decision.

The conversation you're forcing is the one people avoid: this costs something, and someone has to pay. Writing it as a funded backlog item makes the cost visible. An informal dependency hides the cost until it detonates.

When this makes sense — and when it doesn't

When this makes sense — and when it doesn't

This full system is overkill for a small, single-team project with two or three external touchpoints. For that, a shared note and a couple of calendar reminders is fine. Don't build a register for a project that doesn't have enough cross-team surface area to justify it.

Where it earns its keep: projects spanning three or more teams, anything involving external vendors, and any program where a single slip cascades into downstream commitments. That's where invisible handoffs do the most damage.

Who should not adopt this as-is: teams that already have strong, high-trust cross-team coordination and reliably surface dependencies in normal planning. If your dependencies already get written down and owned, adding a parallel register just creates duplicate bookkeeping. Fix the gap you actually have, not the one in the template.

A real scenario: the integration that almost missed its launch

A mid-market SaaS company — around 40 people, product and engineering split across three squads — was shipping a new billing integration tied to a partner's platform. The launch date was fixed because it was tied to the partner's marketing push.

The problem surfaced the way it always does: late. During a planning session, an engineer mentioned the integration needed a webhook endpoint the partner hadn't built yet. No ticket on the partner's side. The PM had assumed it was "basically done."

They built a quick dependency register — about nine live dependencies, three involving the external partner. When they scored them, the webhook dependency came out at impact 3, urgency 3. Top of the list. They also found out the partner's real turnaround SLA was around ten business days, not the two or three everyone had assumed.

That gap — scored and visible — was enough to trigger an escalation to both sides' leadership four weeks before launch instead of during launch week. The partner reprioritized the webhook. The internal team built a fallback — a polling workaround — in parallel, in case it still slipped.

It did slip, by about a week. But because the fallback was already scoped and half-built, the launch held. Without the register, that same slip would've been discovered during launch week with no fallback and no runway. The difference wasn't heroics. It was that the dependency got written down and scored early enough to actually act on.

The tooling question (kept honest)

You can run this entire playbook in a spreadsheet and a recurring calendar invite. Plenty of teams do, and it works fine until the register gets big or the project count grows.

Where lightweight workflow and operational tooling starts to earn its place is when you're tracking dependencies across multiple concurrent projects and manual re-scoring becomes its own job. The useful part isn't automation for its own sake — it's having status, owner, and escalation thresholds live in one place so a dependency crossing a threshold actually surfaces instead of waiting for you to notice. If you go the tooling route, keep the same discipline you'd apply to any operational metric: owned fields, clear definitions, someone accountable for data quality. The thinking in instrumentation governance for operational metrics with schema registry and owners applies directly — a dependency register is only as trustworthy as the people keeping it accurate.

And if your dependency system starts leaning on automated reminders or escalation triggers, treat those automations with the same care as any other operational automation — with guardrails and health checks, not fire-and-forget. The patterns in automation risk governance at scale with registry, budgets and health reviews are worth borrowing so your "helpful reminder" system doesn't quietly break and leave you blind.

The one thing to take away

Dependencies blow up delivery not because they're hard to resolve — it's because they're easy to not notice until they're expensive. Every part of this playbook — the register, the scoring, the SLAs, the weekly ritual, the conversion trigger — exists to shorten the distance between "a dependency exists" and "someone is doing something about it."

Start with the register. Name real owners. Score the top items. Set one escalation threshold and actually honor it this week. You don't need the whole system running on day one. You just need the invisible handoffs to become visible — because the ones you can see are the ones you can still save.

Dependencies blow up delivery not because they're hard to resolve — it's because they're easy to not notice until they're expensive. Every part of this playbook — the register, the scoring, the SLAs, the weekly ritual, the conversion trigger — exists to shorten the distance between "a dependency exists" and "someone is doing something about it."

Start with the register. Name real owners. Score the top items. Set one escalation threshold and actually honor it this week. You don't need the whole system running on day one. You just need the invisible handoffs to become visible — because the ones you can see are the ones you can still save.