Managing Cross-Project Dependencies: Where Programmes Quietly Fail

## The short answer

The biggest risks in a programme rarely sit inside any single project — they live in the **dependencies between projects**. To manage them, make every cross-project dependency explicit, give it an owner on both the supplying and receiving side, attach a date and a definition of "ready", and review the dependency map as a first-class artefact, not a footnote on a status slide. Programmes fail at the seams, so manage the seams deliberately.

## Why dependencies are so dangerous

Individual projects are usually well managed: a plan, a manager, a backlog. Dependencies fall between two projects, which means they often belong to *neither* manager's plan. Each side assumes the other has it covered. The supplying team thinks they've delivered; the receiving team finds the output isn't actually usable. By the time the gap surfaces, both schedules are already committed and the slip cascades.

This is why a programme can be "green" on every project status and still be heading for trouble — the red is in the connective tissue that nobody's report covers.

## Make every dependency explicit

The foundation of dependency management is a single, shared dependency register or map. For each dependency, capture:

- **What** is being handed over (be specific — "the API" is not enough; "the authenticated API with documented endpoints and a test environment" is).

- **From whom and to whom** — the supplying and receiving project.

- **When** it's needed by the receiver, and when the supplier expects to deliver.

- **Definition of ready** — the receiver's acceptance criteria, agreed in advance.

- **An owner on each side** — two named people, not two project names.

The act of writing this down surfaces mismatches immediately. The most common discovery is that the supplier's planned delivery date is *after* the receiver's needed-by date — a problem far cheaper to solve on a register than mid-delivery.

## Classify dependencies by type and risk

Not all dependencies are equal. A quick classification helps you focus attention:

1. **Hard dependencies** — the receiver genuinely cannot proceed without the input. These need the tightest management.

2. **Soft dependencies** — preferable ordering, but workarounds exist.

3. **External dependencies** — on third parties, vendors or other programmes outside your control. Highest risk, least leverage; manage with buffers and contingency.

4. **Resource dependencies** — two projects needing the same scarce people or environment at the same time.

Resource dependencies are the silent killers. Two projects can each be perfectly planned and still collide because they both assume full access to the same specialist or test environment.

## Sequence to reduce dependency risk

The programme manager's sequencing decisions directly affect how much dependency risk you carry. Where possible:

- Front-load work that *produces* widely needed outputs so receivers aren't waiting.

- Build slack around hard and external dependencies rather than scheduling them back-to-back.

- Identify the longest chain of dependent work — your critical path across projects — and protect it.

- Decouple where you can: a well-defined interface or a temporary stub lets a receiver start before the supplier is fully finished.

## Review dependencies as a standing item

A dependency register only works if it's alive. Make it a standing agenda item in the cross-project delivery forum, and at each review ask:

- Have any delivery or needed-by dates moved?

- Are both owners still in agreement on the definition of ready?

- Has any new dependency emerged as work has progressed?

- Is any external dependency showing early warning signs?

Dependencies are not static. New ones appear constantly as projects refine their plans, and a register reviewed once at kickoff is worthless by month three.

## Warning signs

- Project statuses are green but integration keeps slipping.

- Teams discover dependencies during delivery rather than planning.

- Handovers get rejected because "ready" was never agreed.

- The same scarce resource is committed to two projects simultaneously.

- The dependency map exists but hasn't been updated in weeks.

At neart.ai we build enterprise-grade PMO tooling, and cross-project dependencies are where we see the most value from making the invisible visible — a shared, owned, regularly reviewed view of the seams between projects catches problems while they're still cheap to fix.

## Practical takeaway

Treat the gaps between projects as carefully as the projects themselves. Maintain a living dependency register with two named owners per dependency, an agreed definition of ready, and dates from both sides. Review it every cycle, sequence work to protect the cross-project critical path, and remember: a programme of green projects can still fail at the seams.