Organisations usually count projects, people and processes. Complexity is often hiding in the connections between them.
A transformation portfolio can look manageable on an executive dashboard and still be structurally overloaded. Fifty initiatives are not necessarily more complex than twenty. The decisive issue is often how many critical relationships cross the boundaries between those initiatives, how tightly coupled they are, and how much coordination each relationship demands.
A new product may depend on engineering, sourcing, regulatory approval, manufacturing, digital systems, sales readiness and customer support. Each function can appear healthy in its own reporting. The risk sits in the interfaces: one late specification alters tooling, procurement and training; one data-model decision changes software, reporting and operating procedures; one shared specialist becomes the bottleneck for several programs at once.
This is why complexity should not be diagnosed from the component list alone.
The Strategic Context
Oehmen and colleagues describe structural complexity as arising from the number and type of elements in a project, program or portfolio system and the number and type of relationships between those elements. Their engineering-systems perspective emphasises that organisational and technological systems are tightly coupled. Team structures, information flows and technical architectures influence one another rather than operating as separate management domains.
The supplied Study Notes translate this into a practical question: how many people and technical interfaces are involved? It is deliberately simple, but it points leaders toward the right unit of analysis.
San Cristóbal's 2017 literature review supports the same direction. Definitions vary, but interdependency repeatedly appears as a core dimension of complexity.
At enterprise level, this changes how leaders should think about scale. Adding one more project may be almost costless if it is genuinely modular. Adding one small dependency to a highly connected platform can create consequences across many initiatives.
The management burden grows through coordination, not merely through count.
What Leaders Commonly Misread
One common error is to equate organisational charts with operating reality. A chart shows reporting lines. It does not show which engineer is the only person who understands a critical interface, which committee must approve a cross-business decision, or which supplier dependency appears in five separate project plans.
Another error is to manage dependencies as a list. Registers can identify important relationships, but they do not necessarily reveal the network pattern. Ten dependencies concentrated around one node can be more dangerous than fifty evenly distributed ones.
A third error is to add communication as the universal remedy. More meetings may increase information flow, but Oehmen's work warns that complex stakeholder involvement also increases transaction cost. Communication is valuable when it connects the right interfaces. Unstructured communication can simply consume capacity.
A fourth error is to assume that standardisation always reduces complexity. Standardisation can simplify interfaces, but it can also create tightly coupled common platforms. A single shared system may reduce local variation while increasing enterprise-wide consequence if it fails or becomes a bottleneck.
The objective is not uniformity. It is intentional architecture.
Reframing the Issue
Structural complexity is an architecture problem before it is a reporting problem.
The executive question is: what must interact, what can be separated, and where does coupling create disproportionate risk or coordination cost?
Network analysis provides one way to make this visible. Oehmen et al. describe matrix-based and graph-based methods that can represent elements and their relationships. Even a basic model can help identify interdependence, decomposability and modularity. More sophisticated forms can map relationships across different domains, for example organisation to process or process to product.
Leaders do not need to become network scientists to use the principle. The strategic value comes from shifting the conversation.
Instead of asking:
- Which projects are red?
- Which functions are overloaded?
- Which milestones are late?
also ask:
- Which decisions connect the most initiatives?
- Which people are acting as hidden integration points?
- Which interfaces are unstable?
- Which components can be made more independent?
- Which common platforms create concentration risk?
Related article: Decision Quality Depends on How the Portfolio Is Seen
Where Complexity Accumulates
Shared scarce capabilities
A specialist, laboratory, legal approval team, data architect or plant shutdown window can sit at the centre of multiple initiatives. Each project may show acceptable resource demand, yet the shared node becomes a queue.
Technical interfaces
Complexity increases when products, systems or processes exchange information, energy, material, decisions or tolerances across boundaries. Poorly defined interfaces create rework because changes propagate beyond the originating team.
Decision interfaces
Some of the most costly dependencies are governance dependencies. If several programs require the same executive forum to resolve issues, decision latency becomes a system constraint.
Organisational interfaces
Handoffs between functions can multiply interpretations, approvals and incentives. The problem may not be that the organisation has too many departments, but that every value flow must repeatedly cross them.
Temporal interfaces
Dependencies also exist in time. One initiative may need another capability to reach a minimum maturity before value can be realised. When sequence is wrong, work accumulates without becoming usable.
Modularity as a Strategic Response
Oehmen and colleagues identify modularity as a major strategy for managing complexity. The core idea is not simply to divide work into smaller pieces. A useful module has sufficiently clear interfaces that it can change with limited unintended consequence elsewhere.
This applies beyond product architecture.
A modular operating process defines what information or service crosses the boundary and reduces unnecessary knowledge of the internal workings. A modular organisation gives a team enough end-to-end responsibility to deliver without constant cross-functional negotiation. A modular portfolio structures initiatives so that experimentation in one area does not destabilise the entire investment system.
Modularity creates option value. Leaders can change, replace, pause or scale one module more easily when interfaces are stable.
But modularity has a condition: the interfaces must be designed deliberately. Splitting an integrated problem into nominal workstreams without clarifying the connections does not reduce complexity. It hides it.
Decision Framework
Use an Interface Criticality Review for major portfolios and transformations.
For each important component, identify:
| Test | Executive question |
|---|---|
| Dependency | What does this component need from others to succeed? |
| Concentration | Which people, systems or decisions are depended on by many components? |
| Coupling | If this changes, how widely could the consequence propagate? |
| Interface maturity | Are inputs, outputs, standards and decision rights stable? |
| Substitutability | Can another capability replace this node if it fails? |
| Modularity | Can this component be changed without extensive redesign elsewhere? |
| Timing | What must be true before this component creates usable value? |
Do not use the review only to identify risk. Use it to redesign the system.
A dependency can be eliminated, buffered, duplicated, sequenced differently, converted to a stable interface or deliberately accepted because the integration produces greater value than independence.
That is an investment decision, not just a project-control activity.
From Strategy to Execution
Immediate action should focus on the highest-value interfaces, not a complete map of everything. Start with critical programs and identify shared capabilities, decision bottlenecks and technical handoffs whose failure could affect multiple initiatives.
Medium-term capability involves building dependency views into portfolio governance. Portfolio reviews should show concentrated dependencies alongside cost, schedule, risk and benefits. Program reviews should make cross-component commitments explicit. Architecture and operating-model decisions should include the cost of coordination, not only local efficiency.
Long-term positioning is about reducing unnecessary coupling. Standardise interfaces where variation adds little value. Create reusable platforms where scale justifies concentration. Preserve alternatives where common dependency would create unacceptable fragility. Design teams around meaningful value flows where this reduces handoffs and conflicting priorities.
The goal is not to eliminate interdependence. Enterprise value often requires integration. The goal is to know which interdependencies are strategic and which are accidental.
Related article: Interdependencies Are Portfolio Risk: Why Project Dashboards Miss the System
Signals to Monitor
Structural complexity is increasing when:
- the same specialist repeatedly appears on critical-path discussions;
- projects are individually green but cross-program milestones continue to slip;
- coordination meetings multiply faster than productive work;
- changes in one system trigger unexpected rework in several others;
- approvals wait for a small number of executive forums;
- teams create local workarounds because common services are too slow;
- resource plans are stable on paper but shared-capability queues keep growing;
- a "small" change requires many functions to agree before anything can move.
These signals indicate that the organisation may be managing components while ignoring architecture.
Questions for the Leadership Team
- Which five interfaces currently create the greatest enterprise coordination cost?
- What single person, supplier, platform or decision forum represents the largest concentration of dependency?
- Which dependencies exist because of strategic integration, and which exist because the operating model is poorly designed?
- Where would modularity create genuine option value?
- Which common platforms reduce duplication but increase concentration risk?
- Are portfolio sequencing decisions based on dependency reality or only on project priority?
- What would stop working if one critical node became unavailable for three months?
Closing Perspective
Complexity is often less visible than workload because it lives between organisational units, systems and decisions.
Leaders who only count projects will miss the network that determines how those projects behave. Leaders who map interfaces can see where capacity is being consumed by coordination, where risk is concentrated and where modularity can create strategic flexibility.
The practical shift is simple but consequential: manage the connections with the same seriousness as the components.
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.