Portfolio failure often begins in the interfaces between initiatives, where no single project owns the whole risk.
A portfolio can contain many green projects and still be heading towards failure.
The reason is interdependence.
Projects share people, technology platforms, suppliers, data, operating environments, regulatory approvals and transition windows. A decision in one initiative changes assumptions in another. A delay in a foundational program can reduce the value of several downstream investments.
Project dashboards are designed to show the condition of individual commitments. They do not automatically show how the commitments behave as a system.
The supplied EY portfolio-management framework explicitly includes interdependencies inside the executive decision framework and places portfolio risk review as the link between portfolio choices and project/program execution.
The Strategic Context
Interdependency creates non-linear risk.
If Project A is two months late and Project B is independent, the enterprise consequence may be limited to A.
If B depends on A, the delay propagates.
If several initiatives depend on the same platform, supplier or regulatory approval, a single failure can affect a large portion of the portfolio.
This is risk concentration.
The more transformation an organisation undertakes, the more important the interfaces become.
What Leaders Commonly Misread
The first mistake is treating dependencies as schedule links only. Dependencies also concern decisions, capabilities, data quality, operating readiness, policy and resource availability.
The second is assuming each dependency has one owner. Often each side owns part of the interface and no one owns the combined outcome.
The third is focusing on current status instead of structural exposure. A shared dependency can be "green" today while still representing a large concentration of future risk.
The fourth is allowing portfolios to grow without reconsidering the dependency network. Every new initiative changes the system.
Reframing the Issue
Interdependency should be governed as portfolio architecture.
Leaders need to understand:
- what initiatives enable others;
- what resources are shared;
- where one decision can propagate widely;
- where benefits depend on multiple components;
- where simultaneous implementation creates operational conflict.
This is systems thinking applied to the investment portfolio.
Related article: Program Management Is the Benefits Layer Between Strategy and Projects
Three Dependency Types Leaders Should See
Enabling dependencies
One initiative creates a capability another requires.
Examples include a data platform preceding analytics, infrastructure preceding service migration, or regulatory approval preceding market launch.
Resource dependencies
Several initiatives need the same scarce capability.
The projects may be technically independent but compete inside the organisation.
Outcome dependencies
The benefit of one investment depends on another change being realised.
A technology investment may depend on process redesign. A plant expansion may depend on supply-chain capacity. A new product may depend on sales and service capability.
These dependencies are strategically important because failure can destroy benefit without causing the project output itself to fail.
Dependency Risk Grows as the Portfolio Scales
The number of interfaces grows faster than the number of initiatives. Two independent projects may require little coordination. Ten major initiatives sharing platforms, people and operating windows can create a network whose behaviour is difficult to infer from individual plans.
A hypothetical infrastructure program illustrates the issue. A new facility may depend on utility upgrades, regulatory approvals, access works, technology commissioning and workforce mobilisation. Each component can have its own competent manager and acceptable schedule. If the utility upgrade slips, however, several later activities may become simultaneously constrained. The enterprise risk is the propagated effect, not the original delay.
There is also a strategic dependency that conventional schedules can miss. An organisation might invest in a new customer platform expecting a separate data-modernisation initiative to improve information quality. If the data program is reduced or deferred, the customer project may still deliver its technical output but with materially weaker benefits. The portfolio decision should therefore reconsider the value case rather than treat the dependency only as a delivery issue.
Leaders should be particularly cautious where dependencies cross governance boundaries. Interfaces between two projects owned by different executives can become negotiation problems with no natural owner. Portfolio governance needs enough authority to resolve those conflicts before local optimisation damages the wider outcome.
Decision Framework
Create a dependency review around four questions.
Criticality: If this dependency fails, how much portfolio value is affected?
Concentration: How many initiatives rely on the same dependency?
Ownership: Who has authority to resolve conflicts across the interface?
Alternative: Is there a workaround, sequencing change or architectural redesign that reduces exposure?
High-criticality, high-concentration dependencies deserve executive attention even before they show red status.
A dependency map should therefore be used for decisions, not merely documentation.
From Strategy to Execution
Immediately, ask each major program to identify the dependencies that can materially affect other initiatives, not only its internal schedule.
In the medium term, establish portfolio-level views of shared platforms, suppliers, scarce resources and transition windows.
Longer term, use architecture and sequencing decisions to reduce concentration. Sometimes the best portfolio-risk treatment is not additional contingency but redesigning the dependency itself.
Related article: Risk Belongs in Portfolio Decisions Before Projects Fail
Signals to Monitor
Watch for recurring cross-project escalations; one supplier appearing across many critical initiatives; multiple projects depending on the same small specialist team; benefits delayed by work outside the project boundary; and repeated surprises caused by assumptions that were known in another part of the portfolio.
Another warning sign is when dependency registers exist but have no effect on funding or sequencing.
Questions for the Leadership Team
- Which single dependency could disrupt the largest share of our portfolio?
- Where have we concentrated risk unintentionally?
- Which benefits depend on initiatives governed by different executives?
- Who owns cross-project interfaces when priorities conflict?
- What dependencies could be designed out rather than merely monitored?
- Do new project approvals consider the dependency load they add to the existing system?
Closing Perspective
A portfolio is not a bag of projects. It is a network of commitments operating inside one enterprise system.
The weakest risks are often visible inside project boundaries. The most dangerous can sit between them.
Leaders who govern only project status see components. Portfolio leadership must also see the connections.
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.