Managing Cross-Team Dependencies in a RAID Log

## The short answer

To manage cross-team dependencies well, record each one in the **D section of your RAID log** with four things: the **direction** (are you waiting on someone, or are they waiting on you), a **named owner on both sides**, a **committed date**, and the **impact if it slips**. Then actively track and chase them, because dependencies fail silently, the other team is busy with its own priorities and won't necessarily tell you they're slipping. Dependencies are the quiet killer of multi-team delivery, and the RAID log is where you make them visible.

## Why dependencies deserve special attention

Risks and issues are about your own work; dependencies are about the seams *between* teams, and seams are where things break. You can run a flawless project and still miss your date because another team's deliverable arrives late. Unlike a risk you can mitigate yourself, a dependency often requires someone outside your authority to act, which is exactly why it needs explicit tracking and escalation.

## Capture dependencies properly

A weak dependency entry says "waiting on data team". A strong one captures:

- **Direction** — *inbound* (you need something) or *outbound* (someone needs something from you). Both matter; outbound dependencies are often forgotten and then you become the blocker.

- **What exactly** is needed, in concrete terms.

- **Provider and receiver owners** — a named person on each side, not two team names.

- **Needed-by date** and, separately, the **committed date** the other side has agreed. If those two dates differ, that gap is itself a risk.

- **Impact if late** — what in your plan breaks, and when.

- **Status** — not started, in progress, at risk, delivered.

## Map the network early

Many dependencies can be identified at planning time rather than discovered mid-flight. Run a dependency-mapping session with the teams you interface with and ask: what do we need from you, by when, and what do you need from us? Capturing these as outbound and inbound pairs early gives you the lead time to manage them. Late-discovered dependencies are the ones that hurt.

## Distinguish hard from soft dependencies

Not all dependencies are equal:

- **Hard dependency** — you genuinely cannot proceed without it (you can't test before the environment exists).

- **Soft dependency** — preferable but you have options (you'd like the final logo, but a placeholder lets you continue).

Knowing which is which tells you where to spend your chasing energy and where you have slack to absorb a slip.

## Get a real commitment, not a nod

A dependency is only managed when the *providing* side has explicitly agreed to the date and understands the consequence of missing it. A vague "yeah, should be fine" is not a commitment. Confirm it in writing, ideally referencing both teams' RAID logs with a shared dependency ID so the same item appears, consistently, on both sides.

## Track, chase and escalate

Dependencies need active management between reviews:

1. **Flag proximity.** As a committed date approaches, raise the dependency's prominence in your review.

2. **Chase ahead of the deadline**, not on it. Ask for a status while there's still time to react.

3. **Watch for silent slippage.** No news is not good news with cross-team work.

4. **Escalate early** through your sponsor or steering group when a dependency is genuinely at risk. Cross-boundary blockers are precisely what escalation paths exist for, because resolving them often needs authority above the delivery team.

## Don't forget your outbound obligations

It's easy to obsess over what you're waiting for and forget what others are waiting on *from you*. Track outbound dependencies with the same discipline. Being the team that quietly causes someone else's slip damages trust and tends to come back around.

## When a dependency turns into an issue

If a committed date passes without delivery, the dependency has effectively become an **issue**, it's a problem now, not a future uncertainty. Reflect that in the log, escalate accordingly, and update any downstream plans. This transition is one of the clearest examples of why RAID's four categories live together: the same item moves from D to I as reality changes.

At neart.ai we build enterprise-grade delivery and PMO products, and the consistent pattern in successful multi-team delivery is treating dependencies as shared, dated, two-sided commitments, visible to both teams, rather than informal favours.

## Practical takeaway

Log every cross-team dependency with direction, a named owner on each side, a committed date and the impact of a slip. Map them early, chase ahead of deadlines, track your outbound obligations as carefully as your inbound ones, and escalate cross-boundary blockers before, not after, they break your plan.