Project interdependencies are relationships between projects in which the output, resources, timing, budget, or benefits of one project affect another. Interdependencies fall into 6 types: resource, technical, schedule, financial, benefit, and knowledge. Program managers and the project management office (PMO) control them with a dependency matrix, a dependency register, drop-by dates, and a review cadence.
What Are Project Interdependencies?
Project interdependencies are relationships between projects, programs, or portfolio components in which a change in one affects the others. The relationship runs through a deliverable, a shared resource, a date, a budget, or a benefit. Interdependencies appear above the task level.
An interdependency has 6 attributes:
- Source: The project that provides the input.
- Target: The project that receives the input.
- Item: The deliverable, resource, date, budget, or knowledge exchanged.
- Direction: One-way (the target depends on the source) or reciprocal (both depend on each other).
- Drop-by date: The date after which the item becomes a blocker.
- Owner: The person accountable for delivery of the item.
Interdependencies carry portfolio risk. A late source project delays every target project, and the delay compounds as the chain lengthens. Portfolio and program managers manage interdependencies because no single project manager sees the whole network.
How Do Project Interdependencies Differ From Task Dependencies?
A task dependency links 2 activities inside 1 project schedule. A project interdependency links 2 or more projects. Task dependencies belong to the schedule network diagram. Interdependencies belong to program and portfolio governance.
| Attribute | Task Dependency | Project Interdependency |
| Scope | Activities inside 1 project | Between projects, programs, or portfolio components |
| Example | Testing starts after coding finishes | Mobile app testing starts after the data platform project delivers |
| Relationship types | Finish-to-start, start-to-start, finish-to-finish, start-to-finish | Resource, technical, schedule, financial, benefit, knowledge |
| Classification | Mandatory, discretionary, external, internal | Internal or external; one-way or reciprocal |
| Tool | Schedule network diagram, Gantt chart | Dependency matrix, dependency register, portfolio roadmap |
| Owner | Project manager | Program manager, portfolio manager, or PMO |
| Review cadence | Weekly schedule review | Program or portfolio review |
Task dependencies split into mandatory (hard logic), discretionary (preferred logic), external, and internal. Leads and lags adjust the timing between linked activities. The classification of task dependencies is covered in Mandatory vs. Discretionary Dependencies in Project Management: Key Differences Explained.
What Are the Forms of Interdependence Between Projects?
Organizational theory names 3 forms of interdependence: pooled, sequential, and reciprocal. Pooled projects share a common resource. Sequential projects pass outputs one way. Reciprocal projects exchange outputs in both directions. Coordination cost rises from pooled to reciprocal.
James D. Thompson described the 3 forms in his 1967 work on organizations. They apply directly to project portfolios.
| Form | Structure | Project Example | Coordination Method |
| Pooled | Projects draw on 1 shared pool | 3 projects share 4 testers | Resource calendar, allocation rules |
| Sequential | Output of A is input to B | Data platform feeds mobile app | Schedule alignment, interface agreement |
| Reciprocal | A and B exchange outputs repeatedly | Hardware design and firmware development | Joint planning, frequent integration |
A portfolio holds all 3 forms at once. Pooled interdependence is the most common and the easiest to see. Reciprocal interdependence is the hardest to manage, because each project waits on the other.
What Are the Types of Project Interdependencies?
Project interdependencies fall into 6 types: resource, technical, schedule, financial, benefit, and knowledge. Each type has a trigger, a failure signal, and a typical owner. Any type is internal when the source project belongs to the organization and external when a vendor, regulator, or client controls it.
| # | Type | Trigger | Failure Signal | Typical Owner |
| 1 | Resource | Projects share people, equipment, or vendor capacity | A specialist is booked above 100% across projects | Resource manager |
| 2 | Technical | One project needs a deliverable or functionality from another | Interface or data feed unavailable at test | Program manager |
| 3 | Schedule | The timing of one project drives another | Launch dates conflict | Portfolio manager |
| 4 | Financial | Projects draw on 1 budget pool | An overrun in 1 project freezes funding in another | Finance lead |
| 5 | Benefit | One project’s benefit depends on another’s outcome | Benefit target missed when the partner project slips | Benefits owner |
| 6 | Knowledge | One project needs findings, standards, or decisions from another | Rework after a late design decision | PMO |
What Is a Resource Interdependency?
A resource interdependency exists when 2 or more projects need the same people, equipment, facilities, or vendor capacity. It is the most common type. Multitasking across projects slows every project that shares the resource.
A shared architect allocated 60% to Project A and 60% to Project B is over-allocated by 20%. The constraint shows in a resource calendar and in the utilization rate. Resource interdependencies are managed through allocation rules, a shared resource calendar, and project sequencing.
What Is a Technical Interdependency?
A technical interdependency exists when one project needs a deliverable, interface, or functionality that another project produces. The target project cannot test or release without it. Interface control documents and integration testing manage it.
A mobile app that reads customer data from a platform depends on the platform’s application programming interface (API). The failure signal is a missing interface at integration test. The control is an interface agreement with a delivery date and a version.
What Is a Schedule Interdependency?
A schedule interdependency exists when the timing of one project constrains another. The constraint appears as a shared launch window, a shared freeze period, or a required order of releases. It is also called a synchronization dependency.
A retail brand that launches a new loyalty program and a new store system in the same quarter must align both go-live dates. Misaligned dates create customer-facing conflict. Portfolio roadmaps and integrated master schedules manage schedule interdependencies.
What Is a Financial Interdependency?
A financial interdependency exists when projects draw on one budget pool or when one project’s cost affects another’s funding. An overrun in 1 project reduces funds for the others. Portfolio budgeting and reserve policies control it.
A $2 million pool that funds 4 projects leaves $500,000 each. A 20% overrun on 1 project removes $100,000 from the rest. Finance leads track portfolio-level variance, not only project-level variance.
What Is a Benefit Interdependency?
A benefit interdependency exists when the benefit of one project depends on the outcome of another. The benefit arrives only when both projects deliver. Benefits owners track the combined benefit and name the project that gates it.
A grid sensor project and an energy storage program together cut energy cost. The storage savings arrive only after the sensors deliver data. A benefit register links each benefit to the projects that produce it.
What Is a Knowledge Interdependency?
A knowledge interdependency exists when one project needs findings, standards, or decisions that another project produces. The target project reworks its plan when the knowledge arrives late. The PMO manages it through standards, communities of practice, and lessons learned.
A design standard decided in Project A changes the interface in Project B. A late decision causes rework. A shared decision log and a standards owner reduce the delay.
What Are Examples of Project Interdependencies?
Examples span every industry: a data platform feeds a mobile app, a shared engineer serves 2 builds, and a regulatory approval gates a product launch. Each example names a source, a target, an item, and a failure effect.
The figures below are illustrative.
| Industry | Source Project | Target Project | Type | Failure Effect |
| Software | Data platform build | Mobile app | Technical | App testing waits 6 weeks |
| Software | Platform migration | Reporting tool | Resource | 1 architect serves both; 20% schedule slip |
| Manufacturing | New line installation | Product launch | Schedule | Launch moves 3 months |
| Healthcare | Records system rollout | Billing upgrade | Technical | Billing cutover delayed |
| Retail | Store remodel (budget pool) | E-commerce redesign | Financial | Redesign funding cut by 15% |
| Utilities | Grid sensors | Energy storage program | Benefit | Storage savings arrive 9 months later |
| Pharmaceuticals | Clinical trial | Regulatory submission | Schedule | Submission date moves with trial completion |
| Public sector | Identity system | Citizen services portal | Technical | Portal launch waits for identity integration |
What Does an Interdependency Cascade Look Like?
A cascade starts when a source project slips and every dependent project slips in turn. Each dependent project with no float passes the full delay forward. A 3-month slip in 1 source project can move 4 target projects by up to 3 months.
A worked case shows the pattern. Project A (data platform) slips 3 months. Project B (mobile app) needs A’s API for testing and has 0 float, so B slips 3 months. Project C (analytics) needs A’s data and 1 month of float, so C slips 2 months. Project D (website) depends on B for a release, so D slips 3 months. The cost is 3 months of delay in 3 projects plus the benefits those projects delay.
| Project | Depends On | Float | Slip |
| A: Data platform | Source | 0 months | 3 months |
| B: Mobile app | A | 0 months | 3 months |
| C: Analytics | A | 1 month | 2 months |
| D: Website | B | 0 months | 3 months |
Float absorbs delay. A portfolio with float at each handoff stops the cascade at the first buffer.
Why Do Interdependencies Raise Portfolio Risk?
Interdependencies compound delay. Projects in a dependency chain multiply their on-time probabilities. A chain of 5 projects that each finish on time 90% of the time delivers the final project on time 59% of the time.
| Projects in Chain | Probability Each Finishes On Time | Probability Whole Chain On Time |
| 1 | 90% | 90% |
| 2 | 90% | 81% |
| 3 | 90% | 73% |
| 4 | 90% | 66% |
| 5 | 90% | 59% |
The calculation multiplies probabilities and assumes independent projects. In practice, a delay in one project moves its dependents, which enlarges the effect. Interdependencies also hide risk: a project manager who reports “on track” for the project may not know that a source project is late.
How Do You Identify Project Interdependencies?
Identify interdependencies in 5 steps: list deliverables, interview project managers, run a cross-project workshop, review the portfolio roadmap, and check shared resource pools. Each project manager lists what the project needs and what it provides.
- List each project’s inputs and outputs from its scope baseline and work breakdown structure.
- Interview project managers about needs from other projects.
- Run a cross-project workshop where every manager posts needs and offers on a shared wall or board.
- Review the portfolio roadmap for date conflicts and shared launch windows.
- Check resource pools for people booked above 100%.
Start with active projects and add planned projects. A dependency found at initiation costs less to resolve than one found at integration testing. Repeat identification at each phase gate and at every portfolio review.
How Do You Map Project Interdependencies?
Map interdependencies with 4 tools: a dependency matrix, a design structure matrix, a network map, and a dependency register. The matrix shows who depends on whom. The network map shows chains. The register records each link in detail.
| Tool | Shows | Best For | Limit |
| Dependency matrix | Which project depends on which | Portfolios of 5 to 30 projects | Grows large beyond 30 projects |
| Design structure matrix (DSM) | Reciprocal links and clusters | Finding tightly coupled groups | Needs a reordering step |
| Network map | Chains and critical sources | Communication with sponsors | Hard to read when dense |
| Dependency register | Detail per link: item, date, owner | Tracking and control | Does not show the whole picture |
A dependency matrix reads “row depends on column.” The example below uses 4 projects.
| Row depends on… | A: Data Platform | B: Mobile App | C: Analytics | D: Website |
| A: Data Platform | n/a | |||
| B: Mobile App | Technical | n/a | ||
| C: Analytics | Technical | Benefit | n/a | |
| D: Website | Technical | Schedule | n/a |
Column totals rank the projects by how many others rely on them. This count is the fan-out of a project: A has 3 dependents, B has 2, and C and D have 0. Row totals show fan-in, the number of projects a project waits for: D waits for 2, C waits for 2, B waits for 1, and A waits for 0. Project A is the critical source and receives the tightest control. Projects C and D carry the most exposure.
A dependency register records 9 fields per link:
| Field | Example Entry |
| ID | ID-07 |
| Source project | Data Platform |
| Target project | Mobile App |
| Type | Technical |
| Item | Customer data API, version 1 |
| Drop-by date | 15 June |
| Owner | Data platform program manager |
| Impact score | 20 (criticality 5 x likelihood of slip 4) |
| Response | Mitigate: weekly API demo; fallback to mock data |
How Do You Score and Prioritize Interdependencies?
Score each interdependency by criticality multiplied by likelihood of slip, each on a 1 to 5 scale. A score above an agreed threshold, such as 15, goes to the steering committee. Coupling strength and fan-out raise priority.
| Factor | Question | Scale |
| Criticality | How much does the target suffer if the item is late? | 1 (minor) to 5 (blocks release) |
| Likelihood of slip | How likely is the source to miss the date? | 1 (very unlikely) to 5 (very likely) |
| Fan-out | How many projects depend on the source? | Count |
| Coupling | How tightly are the projects bound? | Loose (alternatives exist) or tight (no alternative) |
| Lead time | How long until the drop-by date? | Weeks |
| Score | Priority | Action |
| 1 to 7 | Low | Monitor at monthly review |
| 8 to 14 | Medium | Assign an owner; weekly check |
| 15 to 25 | High | Escalate; plan a response |
Fan-out adds weight. A source with 3 dependents and a score of 12 outranks a source with 1 dependent and a score of 12.
How Do You Manage Project Interdependencies?
Manage interdependencies in 7 steps: register them, assign owners, set drop-by dates, score impact, plan responses, review at a fixed cadence, and escalate through governance. Each step produces a record in the register.
- Register every interdependency in the dependency register.
- Assign 1 owner to each link.
- Set a drop-by date after which the item becomes a blocker.
- Score impact as criticality multiplied by likelihood of slip.
- Plan a response: eliminate, decouple, buffer, re-sequence, pool, or accept.
- Review the register at each program or portfolio meeting.
- Escalate scores above the agreed threshold to the steering committee.
Each high-scoring interdependency enters the risk register as a risk with a probability, an impact, an owner, and a response. The portfolio structure that holds these controls is covered in Project vs Program vs Portfolio: Differences, Scope, and Examples.
Which Responses Reduce Interdependency Risk?
Six responses reduce interdependency risk: eliminate the link, decouple the projects, add a buffer, re-sequence the work, pool the resource, or accept the risk. The response matches the type and the score.
| Response | Action | Example | Trade-Off |
| Eliminate | Remove the dependency by changing scope | Build the needed function inside the target project | Duplicates effort |
| Decouple | Insert an interface agreement, a stub, or a mock | Test the app against a mock API until the platform ships | Late integration risk |
| Buffer | Add float before the dependent milestone | Hold 4 weeks between platform delivery and app testing | Longer duration |
| Re-sequence | Change project start dates | Start the target after the source finishes | Delays benefits |
| Pool | Manage the shared resource centrally | One schedule for 4 testers across 3 projects | Allocation conflicts |
| Accept | Record the risk and set a contingency | Hold a 10% reserve | Exposure remains |
Decoupling is the most common response. An interface control document fixes the shape of the exchange, so both projects work in parallel against the agreed interface.
How Do Agile and Scaled Teams Manage Interdependencies?
Agile teams surface interdependencies in planning events and track them on a dependency board. Scaled frameworks run joint planning for many teams at once. Teams visualize dependencies as cards between teams and review them in short cycles.
| Practice | Used By | Purpose |
| Dependency board | Teams in a program | Show needs between teams on 1 board |
| Scrum of Scrums | Multi-team Scrum programs | Coordinate cross-team impediments |
| Program increment planning | Scaled agile programs | Plan dependencies for a set of iterations together |
| Release train | Scaled agile programs | Align releases of dependent teams |
| Integration demos | Technical dependencies | Prove interfaces every iteration |
Short iterations shorten the feedback loop. A dependency that fails in week 2 costs less than one that fails at month 6.
Who Owns Project Interdependencies?
Ownership sits at 4 levels. Project managers own the links their project provides and receives. Program managers own interdependencies among projects in the program. Portfolio managers and the PMO own cross-program links. Resource managers own shared people.
| Level | Owner | Owns | Cadence |
| Project | Project manager | The project’s inputs and outputs | Weekly |
| Program | Program manager | Links among program projects | Bi-weekly |
| Portfolio | Portfolio manager or PMO | Links across programs and shared pools | Monthly |
| Resource | Resource manager | Allocation of shared people | Monthly |
PMBOK Guide 8th Edition groups governance, integration, and portfolio-level coordination in the Governance performance domain. A RACI matrix assigns who is responsible, accountable, consulted, and informed for each link.
How Do You Measure the Health of Interdependencies?
Measure health with 6 indicators: share of links with an owner, share on track by the drop-by date, average slip in days, number of high-score links, fan-out of the top source, and share of links with a response. Review the indicators each month.
| Indicator | Formula | Illustrative Target |
| Links with an owner | Links with an owner / total links | 100% |
| On-track links | Links on track by drop-by date / total links | 90% or higher |
| Average slip | Total slip days / late links | Falling each month |
| High-score links | Links scoring 15 or higher | Falling each quarter |
| Top-source fan-out | Dependents of the largest source | Reported to the steering committee |
| Links with a response | Links with a planned response / links scoring 8 or higher | 100% |
A rising number of high-score links signals that the portfolio has too many tight couplings. The PMO then re-sequences work or decouples projects.
What Mistakes Do Teams Make With Interdependencies?
7 mistakes cause most interdependency failures: finding links late, assigning no owner, setting no drop-by date, tracking only task dependencies, ignoring shared resources, keeping the matrix static, and escalating too late. Each mistake has a direct fix.
| Mistake | Consequence | Fix |
| Finding links at integration test | Late discovery; rework | Identify at initiation and at each phase gate |
| No owner | Nobody chases the item | Assign 1 owner per link |
| No drop-by date | The need becomes a blocker unnoticed | Set a date with lead time |
| Tracking tasks only | Project-level links stay invisible | Keep a program-level register |
| Ignoring shared resources | Hidden over-allocation | Pool resource calendars |
| Static matrix | The map is out of date | Review at each portfolio meeting |
| Late escalation | Delay grows before a decision | Set a score threshold |
FAQs About Project Interdependencies
Is an Interdependency the Same as a Dependency?
No. A dependency is a one-way reliance, such as a task that needs a predecessor. An interdependency links projects and often runs both ways. Both appear in practice, and the terms are not interchangeable.
How Many Types of Project Interdependencies Exist?
Six types are common: resource, technical, schedule, financial, benefit, and knowledge. Sources group them as internal or external. Organizations add types to fit their portfolio, such as regulatory interdependencies.
Who Manages Interdependencies Between Projects?
Program managers manage interdependencies among projects in a program. Portfolio managers and the PMO manage interdependencies across programs. Project managers own the links their project provides and receives.
What Tool Maps Project Interdependencies?
A dependency matrix shows who depends on whom. A network map shows chains. A dependency register records each link. Portfolio management software combines all 3. Most organizations start with a matrix and a register.
How Often Do Teams Review Interdependencies?
Teams review interdependencies at every program meeting, usually every 2 weeks, and at every portfolio review, usually monthly. High-score links are checked weekly until the item is delivered.
How Does Critical Chain Project Management Handle Shared Resources Across Projects?
Critical chain project management (CCPM) staggers project starts around the constraining resource and protects each schedule with buffers. Staggering removes multitasking, which cuts resource interdependency delays across the portfolio.
CCPM treats the scarce resource as the pacing element, then sequences projects to match its capacity. The Critical Chain Project Management (24 PDUs) course from PMI Authorized Training Partner PMTI teaches how to plan multi-project schedules around shared resources.