Cross-project dependencies are required handoffs between projects. Managing them means identifying specific commitments, agreeing on owners and dates, and resolving risks before milestones slip.
A dependency only helps a program when it names a supplier, a receiver, a deliverable and a date. This guide covers the definition, the types, a discovery process, the fields a register needs, and how to run reviews and handle delays.
- A cross-project dependency is a handoff one project needs from another, such as an output, a decision, capacity or an event.
- Name a supplier owner and a receiver owner for every entry, and write the deliverable so both sides can test it.
- Keep baseline and forecast dates apart, and separate delivered from closed so status never turns green early.
- Review by exception: critical handoffs, newly at-risk items, open decisions and stale confirmations.
- When a handoff slips, find the affected downstream work first, then choose between partial delivery, resequencing and reduced scope.
What is a cross-project dependency?
A cross-project dependency exists when one project needs an output, decision, capacity, or event from another project before it can complete its own work. The relationship should identify a supplier and a receiver. For example, a customer onboarding project may depend on an identity platform upgrade before its end-to-end testing can begin. The supplier's the platform team, while the receiver's the onboarding team. The commitment isn't a vague promise that IT will help. It's a testable interface delivered by a date that supports a specific milestone. Program managers need to see these handoffs across project boundaries, because a locally successful team can still miss the overall program outcome when a critical upstream contribution arrives late.
Why do cross-project dependencies matter?
Cross-project dependencies matter because delays propagate through connected schedules. A small infrastructure delay might block a launch, customer migration, or regulatory checkpoint. Yet not every late handoff delays the final outcome. Some receiving activities have schedule float, parallel tasks, or temporary alternatives. The program manager has to distinguish a relationship that is merely inconvenient from one that constrains a committed milestone. This requires understanding the downstream sequence, the receiving team's actual need-by date, and the cost of waiting. A shared dependency register makes these relationships visible to people who'd otherwise see only their own delivery boards. Its purpose is better decisions. It isn't there to produce a large inventory of arrows.
What types of cross-project dependencies exist?
Schedule dependencies link the start or finish of work across projects. Technical dependencies include interfaces, infrastructure, shared data models, and system compatibility. Resource dependencies arise when projects compete for the same specialists, test environments, or equipment. Governance dependencies include security approval, procurement decisions, legal review, and executive signoff. External dependencies involve suppliers, customers, and regulators beyond direct program control. Categorization is useful because the response differs. A shared specialist conflict may need resequencing. An API handoff may need contract tests and mock data. A legal approval may need an earlier review cycle. Calling all of these scheduling problems hides the action each one needs.
The table below pairs each type with a typical example and the response that usually fits it.
| Dependency type | Typical example | Usual response |
|---|---|---|
| Schedule | Project B can't start testing until project A finishes its build | Agree a need-by date and track a confirmed forecast |
| Technical | A shared data model or API that several projects consume | Contract tests, mock data and versioned interfaces |
| Resource | Two projects need the same specialist or test environment | Resequence work or reserve capacity in advance |
| Governance | Security approval, legal review or procurement decision | Book the review early and define what evidence it needs |
| External | A supplier delivery, customer sign-off or regulator decision | Name an internal owner and agree a fallback plan |
How do cross-project dependencies differ from risks, issues and assumptions?
A dependency's a required relationship between two pieces of work. A risk is an uncertain event that could affect that relationship. An issue is a risk that has already happened, and an assumption is something the plan treats as true without proof. One handoff can touch all four: the dependency is the agreed handoff, the risk is a late delivery, the issue is the delivery that didn't arrive, and the assumption is that the supplier's team has capacity.
Keeping the terms apart avoids a common failure, where a register mixes everything into one list and nobody can tell which rows need a delivery commitment and which need a mitigation. Many programs record dependencies, risks, assumptions and issues together in a RAID log, then link each at-risk handoff to its risk entry. The dependency register stays focused on the commitments between teams.
How do you find cross-project dependencies?
You find cross-project dependencies by beginning with major outcomes and working backward. For every release, cutover, migration, or business milestone, ask which deliverables must be accepted first. Identify who supplies each deliverable and which project receives it. Review architecture diagrams, delivery plans, procurement calendars, resource allocations, and decision logs. Invite both suppliers and receivers to validate the handoffs together, and ask them what they're assuming. Ask what happens if the contribution arrives late and whether an alternative exists. Don't assume a kickoff workshop discovers everything. New dependencies emerge when designs change, vendors respond, or teams discover constraints. Make dependency identification part of change reviews, planning updates, and milestone readiness checks, so it isn't a one-off workshop. Encourage early disclosure of uncertain relationships. Teams who don't feel safe saying "I'm not sure we can deliver" will say it only when it's too late.
What belongs in a dependency register?
A useful register contains a stable ID, source project, receiving project, supplier owner, receiver owner, concrete deliverable, acceptance criteria, baseline need-by date, latest forecast, status, downstream impact, mitigation, next action, and last confirmation date. A link to evidence can make review faster. Keep baseline and forecast dates separate so changes remain visible; it's the only way to see drift. A strong entry might say that the identity platform team must deliver a tested token validation endpoint for onboarding integration tests. A weak entry just says onboarding depends on IT, which is plainly too vague to act on. The strong version's verifiable and negotiable. Both parties can agree what delivered means and when the receiver will accept it, and nobody's left guessing. The weak version creates ambiguity that you'll often find too late.
Which status definitions keep a register honest?
Use a small set of status labels with explicit meanings. Proposed means the supplier hasn't accepted the commitment. Agreed means both owners confirm the deliverable and timing. At risk means the forecast or confidence has deteriorated. Blocked means downstream work is currently constrained. Delivered means evidence has been supplied, while closed means the receiving team has accepted the result. Separating delivered from closed prevents premature green reporting, since what the supplier calls done isn't always what the receiver can use. Record when a status was last confirmed and by whom. A green label that hasn't been reviewed for weeks isn't reliable evidence. Teams should update forecast changes as soon as they're known, rather than saving surprises for a steering committee meeting, because they're easier to fix early.
How do you map cross-project dependencies?
A dependency matrix places projects on rows and columns to reveal relationships between teams. It can show which projects depend on many suppliers and which shared platforms serve several downstream initiatives. A network diagram uses arrows between milestones and is helpful for understanding sequence and the direction of impact. A timeline overlay shows handoffs alongside committed dates, making upcoming conflicts easier to spot. Choose the representation that supports the decision you're making. Executives may want a compact view of critical exceptions, and they'll rarely read a full network. Delivery leads may need a detailed milestone network, because that's where they'll spot sequencing conflicts. Every visual link should correspond to an actual register entry with an owner. Otherwise the diagram becomes a decorative artifact that's disconnected from execution.
If you want a worked method for the diagram itself, the guide to project dependency mapping walks through a small example. When the network is dense and a grid reads better than arrows, use the project dependency matrix template.
How do you decide which dependencies are critical?
Assess each dependency by its downstream consequence, schedule flexibility, and confidence in the forecast. A missed regulatory approval may require immediate escalation. A late optional report with available float usually won't need it. Review whether the handoff sits on a critical path and whether useful work can continue in parallel, since that's what decides how urgent it is. Confidence should reflect evidence such as completed tests, unresolved design decisions, capacity, and external approvals. Avoid invented probabilities or precise-looking scores that data doesn't support. Teams can use internally defined impact and urgency categories, but they shouldn't leave what each category means undocumented. The aim's to focus scarce attention on handoffs most likely to change important outcomes. Reassess when scope, dates, or assumptions change.
Who owns a cross-project dependency?
A cross-project dependency needs two operational owners. The supplier owns producing the agreed output, and the receiver owns confirming it's usable. The program manager owns visibility, coordination, and escalation across the portfolio. Sponsors own tradeoffs involving funding, scope, or strategic commitments outside team authority. The supplier should provide a forecast supported by evidence. The receiver should specify acceptance conditions up front and respond promptly when the output arrives, so the supplier isn't waiting on feedback. If either side changes the agreement, both project schedules must be updated. Escalation should request a decision. It shouldn't simply circulate a red status. A clear question with options and consequences works better than a vague warning that another team's late.
How often should you review cross-project dependencies?
Run exception-based reviews rather than reading every register row aloud. Before the meeting, ask owners to update forecasts and evidence. During the meeting, focus on upcoming critical handoffs, newly at-risk items, unresolved decisions, and blockers. Ask what's changed since the previous confirmation. Ask suppliers what supports their forecast and receivers whether the proposed deliverable still meets their needs. Close with a named action owner, deadline, and escalation path for every open exception, so nothing ends the meeting without someone who's responsible. Healthy dependencies still deserve an occasional check, particularly when confirmation dates are stale, because a row that looks fine isn't always fine. A short weekly review may suit a fast-moving program, while other portfolios may need a different rhythm. Match cadence to decision speed.
What should you do when a dependency slips?
When a dependency slips, establish the revised forecast and identify exactly which downstream activities are affected. Separate immediate containment from longer-term correction. Explore partial deliverables, mock interfaces, synthetic data, temporary manual controls, resequencing, or a reduced-scope release where appropriate. Evaluate each alternative for cost, risk, and feasibility, and of course write down what you chose and why. Then replan the affected milestones and communicate changes to commitment owners. Preserve the original baseline in the change history so forecast drift stays visible. That's how you'll see patterns later. Don't automatically blame the supplier. A handoff may fail because acceptance criteria weren't clear, requirements changed, or shared capacity was never reserved. Root-cause review should improve the coordination system rather than punish disclosure.
What does a dependency register entry look like?
A dependency register entry uses one row per specific handoff. An illustrative entry is DEP-021, with Data Migration as the supplier project and Analytics Launch as the receiver. The deliverable is a reconciled sample dataset. Acceptance requires the analytics lead to approve row-level checks. The need-by date comes from the agreed release plan. The latest forecast is under review, status is at risk, and the mitigation is synthetic test data. The next action is confirming sample coverage at the integration meeting.
This example is hypothetical, but it shows how a precise commitment differs from a broad statement that analytics needs data, which is what you'll often see in early registers. In a spreadsheet, filter by owner, status, receiving milestone and upcoming due dates, and avoid unnecessary complexity at the start.
Cross-project dependency register
One row per handoff. Replace the fictional rows with your own commitments and keep the IDs stable.
| ID | Supplier project | Receiver project | Supplier owner | Receiver owner | Deliverable | Acceptance criteria | Need-by (baseline) | Forecast | Status | Mitigation | Next action |
|---|---|---|---|---|---|---|---|---|---|---|---|
| DEP-021 | Data Migration | Analytics Launch | Migration lead | Analytics lead | Reconciled sample dataset | Analytics lead approves row-level checks | Per release plan | Under review | At risk | Synthetic test data | Confirm sample coverage at integration meeting |
| DEP-022 | Identity Platform | Customer Onboarding | Platform lead | Onboarding lead | Tested token validation endpoint | Integration tests pass in the shared test environment | Per release plan | Confirmed | Agreed | Mock endpoint for early tests | Share contract tests with the onboarding team |
| DEP-023 | Security Review | Customer Onboarding | Security lead | Onboarding lead | Written approval of the data flow | Approval recorded with open findings listed | Per release plan | Not yet agreed | Proposed | Book an earlier review slot | Ask the supplier to accept the commitment |
- A supplier owner and a receiver owner are named.
- The deliverable is specific enough to test.
- Acceptance criteria are written down.
- Baseline and forecast dates are recorded separately.
- The status was confirmed recently, and the register shows by whom.
- A mitigation exists for every at-risk or blocked item.
How do you measure dependency management?
Measure the share of important dependencies with both owners assigned, the share with acceptance criteria, the age of unconfirmed forecasts, and the number of missed handoffs that caused downstream milestone changes. Look at how early risks were raised before the need-by date. An early warning's more useful than a dashboard that turns red after the launch has failed. Don't use these metrics to punish teams for reporting problems. That creates an incentive to keep risky dependencies green, which defeats the point. Review recurring causes such as unclear intake, late design decisions, or shared specialist conflicts. Combine numbers with conversations about whether your escalations produce timely decisions and whether the register helps teams deliver.
What mistakes undermine dependency management?
Dependency management goes wrong when entries are vague. Avoid entries without a deliverable, acceptance test, or date. Avoid treating a forecast as a guarantee. Avoid assigning only one owner when a handoff needs a supplier and receiver. Avoid closing a dependency before the receiving team accepts the output. Avoid maps that are refreshed only for executive presentations. Avoid tracking so many low-impact relationships that the critical ones disappear in the noise. Above all, don't mistake documentation for coordination, because the two are easy to confuse. The register supports an agreement between teams, but it can't negotiate scope, resolve competing priorities, or validate technical readiness by itself. When a handoff becomes uncertain, the owners must discuss the options and document a clear decision. Nobody else can do it for them.
Where does software help with cross-project dependencies?
Software helps with cross-project dependencies, but a spreadsheet's enough to start, and a shared register with clear owners beats an expensive tool with vague entries. Software starts to help when projects live in different trackers, because the handoffs then sit in boards that no single person reads. That's the gap a register in one spreadsheet can't close on its own.
For programs that span Jira and Asana, a layer that reads both can keep each team's task status where each one lives and still show the handoffs between them. It should flag changed dates and missing owners without becoming a second place to maintain every task. It can't decide whether a delivery is acceptable. The receiving team still makes that call, and the sponsor still approves trade-offs.
Getting started
Select one upcoming portfolio milestone and identify the upstream contributions required for success. Bring the supplier and receiver owners together, since they're the people who'll honor the agreement. Define each deliverable, acceptance test, need-by date, forecast, and next review. Publish a small register that every participating team can open. Agree on simple status definitions and escalation triggers. During delivery reviews, focus on exceptions and decisions instead of reading the entire list. After the milestone, examine which dependencies were discovered late and what would have surfaced them earlier. Expand the process gradually as the portfolio grows, and don't add fields nobody uses. You don't need a complex platform to start, and you shouldn't wait for one. Specific commitments, current forecasts, two-sided ownership, and timely decisions create the foundation.
Frequently asked questions about cross-project dependencies
The questions below cover how dependencies differ from risks, which ones deserve attention and who keeps the shared view current.
Is a dependency the same as a risk?
No. A dependency's a required relationship between two pieces of work. Uncertainty about that relationship creates a risk, and a missed handoff becomes an active issue.
Must every dependency be on the critical path?
No. Some handoffs have float or alternatives, so they aren't all urgent. Prioritize the ones that materially affect committed outcomes.
Who maintains the shared view?
The program manager or coordinator maintains visibility, while supplier and receiver owners confirm the commitments they've made.
What is the difference between a supplier and a receiver?
The supplier project produces the output, decision or capacity. The receiver project needs it before it can finish its own work, and it's the one that decides if the result's usable. Each side needs a named owner.
How many dependencies should a register track?
Track the handoffs that can change a committed milestone. A register with every minor relationship hides the few that matter.
Related guides cover the surrounding documents: the program roadmap template for milestone alignment, the project dependency mapping guide for diagrams and the program management framework for governance around them.
Leave a Reply