Complex Systems, Interdependencies, and Systemic Risk

Introduction

Projects are often governed as if risks were independent events: a delay has a probability, a cost overrun has an impact, and a mitigation is assigned to each item in a risk register. This approach is useful for simple risks but becomes unreliable when projects are embedded in technical, organizational, economic, ecological, and regulatory systems. In such settings, a local disturbance can alter other risks, activate feedback loops, overwhelm controls, and produce consequences that no single risk owner can observe or manage.

Systemic risk is the possibility that interactions within a system, rather than an isolated failure, generate widespread or cascading disruption. It is especially important in major infrastructure, digital transformation, construction, aerospace, energy, health, financial, and supply-chain projects. The project may be only one component of a larger system, while its outcomes depend on suppliers, regulators, users, utilities, data, markets, and institutional decisions.

This chapter develops methods for evaluating causal chains, feedback loops, common-cause failures, risk interactions, cascading impacts, black-swan conditions, and emergent behaviour. It integrates bow-tie analysis, fault-tree analysis, event-tree analysis, influence diagrams, system dynamics, and network analysis. The central managerial principle is that risk must be analysed not only as a list of events, but also as a structure of relationships.

Learning objectives

By the end of this chapter, the reader should be able to:

1. Distinguish complex, complicated, and merely uncertain project environments.
2. Explain systemic risk, interdependence, emergence, feedback, and common-cause failure.
3. Construct and interpret bow-tie, fault-tree, and event-tree models.
4. Represent risk interactions using influence diagrams and networks.
5. Use system-dynamics concepts to identify reinforcing and balancing loops.
6. Analyse cascading impacts and concentration of vulnerability.
7. Evaluate black-swan claims without confusing rarity with unknowability.
8. Design governance and controls that are resilient to interacting risks.

1. From individual risks to complex systems

A complicated system may contain many components but remain sufficiently decomposable: experts can identify parts, model their relationships, and predict outcomes with reasonable confidence. A complex system contains nonlinear interactions, adaptation, delays, feedback, distributed decision-making, and path dependence. In a complex project, changing one element can change the behaviour of other elements and even alter the rules by which the system operates.

A project system can be described through four layers:

A useful distinction is between risk interaction and systemic risk. Risk interaction occurs when one risk changes the probability or impact of another. Systemic risk is broader: interaction produces disruption across a system, often through shared dependencies or loss of control capacity. For example, a supplier delay, labour shortage, and design change may each be manageable alone. Together, they may create schedule compression, rushed testing, quality defects, rework, and further delay.

Interdependence and dependency types

Interdependencies may be:

• Sequential: one activity must occur before another.
• Resource-based: several activities rely on the same people, equipment, budget, or facility.
• Technical: components exchange energy, material, signals, or data.
• Institutional: decisions depend on approvals, contracts, or governance bodies.
• Geographical: assets share a location or hazard exposure.
• Informational: several decisions depend on the same data source or model.
• Financial: cash flow, credit, insurance, or market conditions connect actors.
• Behavioural: participants adapt to incentives and to one another.

A risk register usually records nodes—events, causes, and consequences—but often omits the edges connecting them. Systemic analysis makes these edges explicit.

2. Causal chains, feedback, and emergence

A causal chain is a sequence in which a condition contributes to an event, which produces an outcome and possibly creates further conditions. Chains should not be interpreted as deterministic unless the relationships are known to be necessary. In practice, causal links are usually probabilistic, conditional, and influenced by controls.

Feedback occurs when an output of a system returns as an input. A reinforcing loop amplifies change. A balancing loop counteracts change and tends to move the system toward a target or constraint. Delays can make both types of loop unstable or misleading.

Examples include:

• Schedule delay → overtime and work compression → fatigue → defects → rework → further delay. This is a reinforcing loop.
• Forecast cost increase → management review → scope reduction → lower expenditure. This is a balancing loop, although it may reduce benefits.
• Incident reporting → learning → improved controls → fewer incidents → less reporting. This balancing loop can create a misleading appearance of improvement if reporting declines because trust has been lost.

Figure: A reinforcing feedback loop in which schedule pressure increases the conditions for further delay.

Emergence is a system-level pattern that arises from local interactions and is not obvious from examining one component alone. A safety culture, congestion pattern, market panic, or organizational silence may emerge from many individually rational actions. Emergence does not imply magic or complete unpredictability; it means that explanation must include interactions and system structure.

3. Common-cause failures and latent conditions

A common-cause failure occurs when multiple safeguards, components, or processes fail because of one underlying cause. Examples include a shared power supply disabling redundant servers, one incorrect design assumption affecting several disciplines, or a single contaminated data source driving multiple decisions.

Common-cause failures challenge the assumption of independence. If events A and B are independent, then:

where P denotes probability and A ∩ B means that both events occur. This relationship is applicable only when independence is justified. If a common cause C affects both events, their joint probability is better represented conditionally:

Here ¬C means that C does not occur. The formula follows the law of total probability and shows why multiplying marginal probabilities can understate joint exposure. Conditional dependence may also arise without a single identifiable common cause, for example through shared environmental stress or adaptive behaviour.

Latent conditions are weaknesses embedded in design, procurement, governance, training, culture, or infrastructure. They may remain unnoticed until combined with active failures. A resilient system therefore needs diversity, independence, separation, monitoring, and recovery capacity—not merely duplicated components.

4. Bow-tie analysis: connecting causes, events, and consequences

Bow-tie analysis places a central top event between its causes and consequences. The left side resembles a fault tree: threats lead to the top event, subject to preventive controls. The right side resembles an event tree: the top event may lead to different consequences depending on mitigating controls.

A basic bow-tie contains:

1. Threats or initiating conditions.
2. Preventive barriers.
3. The top event, such as loss of containment or loss of data integrity.
4. Escalation factors that weaken barriers.
5. Recovery or mitigation barriers.
6. Consequences, including safety, schedule, financial, legal, and reputational outcomes.

The method is valuable because it links operational controls to causal logic. However, a barrier should not be treated as a label. Its owner, performance standard, failure mode, test method, and recovery action should be specified. A nominal barrier that is unavailable, bypassed, or dependent on the same failed resource is not an independent protection.

Bow-tie analysis is most useful for a well-defined hazard and top event. It becomes misleading when a complex system is forced into one linear diagram or when feedback and adaptation are omitted. It should therefore be combined with dynamic and network methods.

5. Fault trees and event trees

Fault-tree analysis

A fault tree is a deductive, top-down model. The analyst starts with an undesired top event and decomposes it into causes using logical gates.

For independent basic events A and B, an AND gate occurs only if both occur:

An OR gate occurs if at least one occurs:

The OR expression assumes independence. For rare, independent events, it is often approximated by P(A) + P(B), but the exact expression should be used when probabilities are not very small. In a real system, common causes require explicit modelling rather than blind use of these formulas.

Worked example. Suppose a service outage occurs if both an application failure and an ineffective backup occur. Let their probabilities during a specified period be 0.04 and 0.10, respectively, and assume independence for this illustrative calculation. Then:

The estimated probability is 0.004, or 0.4% for the stated period. If both failures share a power dependency, the independence assumption is not credible and the result may be understated.

Fault trees support minimal cut sets: the smallest combinations of basic events sufficient to cause the top event. Identifying cut sets helps managers find combinations that deserve attention even when individual event probabilities appear modest.

Event-tree analysis

An event tree is an inductive, forward model. It starts with an initiating event and branches according to whether safety, recovery, or governance functions succeed. If the initiating event has probability p and a sequence of conditional branch probabilities q₁, q₂, …, qₙ, the probability of that particular outcome is:

The q values must be conditional on the preceding branch history. Branches should be mutually exclusive and collectively exhaustive for the modelled scenarios. Event trees are particularly useful for analysing consequence severity, emergency response, and recovery pathways.

Fault trees ask, “How can this event occur?” Event trees ask, “What can happen after it starts?” Their combination in a bow-tie supports both prevention and mitigation.

6. Influence diagrams and decision quality

An influence diagram is a directed graphical model containing chance nodes, decision nodes, and value or utility nodes. Arrows represent informational or causal relevance, not necessarily physical causation. The method is useful when managers must choose actions under uncertainty.

For example, a project may include:

• Chance node: supplier financial distress.
• Chance node: delivery delay.
• Decision node: qualify a second supplier.
• Value node: total cost, schedule reliability, and strategic benefit.

The expected value of an action d can be represented as:

where sᵢ are possible states, P(sᵢ | d) is the probability of state sᵢ given decision d, and V(sᵢ,d) is the value of decision d in that state. The formula assumes that the states are adequately defined and that value can be represented on a common scale. In practice, multi-criteria decisions may require explicit weights, utility functions, or qualitative judgement.

Influence diagrams expose a frequent governance error: deciding on an action before identifying what information would change the decision. They can also represent value of information, the benefit of obtaining better information before committing resources. They do not, however, prove causation merely because an arrow is drawn; causal assumptions must be justified by evidence, expertise, or a validated model.

7. System dynamics and nonlinear project behaviour

System dynamics models stocks, flows, feedback loops, delays, and nonlinear relationships. A stock accumulates over time; a flow changes a stock. Examples include completed work, defect backlog, cash reserve, technical debt, and workforce capability.

The general stock relationship is:

Here t₀ is the starting time, t is the observation time, and τ is a dummy time variable. In discrete monthly planning, an approximation is:

The units of stock and the accumulated inflow and outflow must be consistent. System-dynamics models are not automatically forecasts; they are structured representations of assumptions. Their value lies in revealing behaviour over time, testing policies, and identifying unintended consequences.

Consider a defect backlog. If new defects are discovered faster than they are resolved, the backlog grows. A management response that adds inexperienced staff may temporarily increase apparent capacity but also increase error rates, creating a reinforcing loop. A policy of reducing scope may balance workload but transfer risk to operational users. Simulation can compare these policies under different assumptions about delays and learning.

Important modelling disciplines include:

• Define a clear boundary and purpose.
• Separate stocks from flows.
• State time units and decision intervals.
• Represent delays explicitly.
• Test extreme conditions and conservation relationships.
• Conduct sensitivity and scenario analysis.
• Validate behaviour with subject-matter experts and historical patterns.

8. Network analysis and cascading impacts

A risk network represents entities or events as nodes and dependencies as edges. Directed edges may show influence, supply, information, or failure transmission. Weighted edges can represent strength, capacity, or probability of transmission.

Useful network concepts include:

• Degree: number of direct connections. High-degree nodes may be exposed to many pathways.
• Betweenness centrality: extent to which a node lies on shortest paths between others. Such nodes may be bottlenecks or brokers.
• Clustering: tendency of connected nodes to form groups.
• Modularity: presence of relatively separate communities.
• Connectivity and redundancy: availability of alternative paths after a failure.

Centrality is not the same as importance. A low-centrality asset may be safety-critical, while a highly connected node may have strong substitutes. Interpretation requires domain knowledge, direction, timing, and capacity constraints.

A simple cascade model can assign each node a threshold. Node i fails when the weighted pressure from failed neighbours exceeds its tolerance θᵢ:

where wᵢⱼ is the influence of node j on node i and xⱼ indicates whether j has failed or is exerting pressure. This is a modelling rule, not a universal law. It assumes that pressures are additive and that thresholds are meaningful; real systems may include recovery, direction-specific effects, and time dependence.

Network analysis is particularly valuable for supply-chain concentration, shared cloud services, transport corridors, utility dependencies, stakeholder influence, and interface management. It supports targeted interventions such as alternate suppliers, physical separation, interface standards, buffer capacity, and independent monitoring.

9. Black swans, deep uncertainty, and resilience

A black-swan condition is commonly associated with an event that is surprising relative to prevailing expectations, has extreme consequences, and is retrospectively made explainable through narratives. The concept is useful as a warning against overconfidence, but it should not become a label for every unlikely event.

Three distinctions are essential:

1. Known risk: probabilities and outcomes can be estimated with acceptable confidence.
2. Deep uncertainty: analysts know relevant drivers and plausible outcomes but cannot agree on probabilities or models.
3. Unknown unknowns: relevant variables or mechanisms are not recognized in advance.

Risk models may fail through model error, data limitations, changing conditions, strategic behaviour, or feedback from the model itself. A probability estimate with many decimal places does not imply corresponding knowledge.

Under deep uncertainty, robust strategies are often preferable to strategies optimized for one forecast. Robustness may involve modular design, reversible decisions, reserves, diversification, graceful degradation, early-warning indicators, and rapid recovery. Scenario discovery, stress testing, and adaptive pathways are useful because they ask not only “What is most likely?” but also “Under what conditions would this policy fail?”

Resilience has several dimensions:

• Absorptive capacity: withstand disturbance without unacceptable loss.
• Adaptive capacity: adjust operations as conditions change.
• Transformative capacity: redesign the system when the existing configuration is no longer viable.
• Recovery capacity: restore essential functions within an acceptable time.

Resilience should not be used to excuse weak prevention. A system that repeatedly absorbs avoidable harm may be resilient in a narrow sense but poorly governed.

10. Integrated analysis workflow

A practical postgraduate-level workflow is as follows.

Step 1: Define the system and objectives

Specify boundaries, stakeholders, critical functions, time horizon, performance criteria, and unacceptable outcomes. Include external dependencies rather than treating them as background assumptions.

Step 2: Map architecture and dependencies

Create a system map, interface register, supply-chain map, and information-flow map. Identify shared resources, single points of failure, coupling, and recovery constraints.

Step 3: Identify causal mechanisms

Use workshops, incident data, process observation, expert elicitation, and historical evidence. Distinguish causes, conditions, triggers, controls, and consequences.

Step 4: Select complementary models

Use bow-ties for barrier management; fault trees for deductive failure logic; event trees for consequence pathways; influence diagrams for decisions; system dynamics for feedback and time; and network analysis for distributed dependencies.

Step 5: Challenge assumptions

Test independence, stationarity, perfect information, unlimited resources, linearity, and rational behaviour. Search explicitly for common causes and correlated failures.

Step 6: Analyse interventions

Compare prevention, detection, mitigation, transfer, redundancy, diversification, decoupling, monitoring, and recovery options. Consider interactions among controls: a new control can create workload, delay, or a new failure mode.

Step 7: Stress-test and monitor

Use scenarios, sensitivity analysis, tabletop exercises, simulations, and leading indicators. Monitor weak signals such as growing work-in-progress, repeated near misses, supplier financial deterioration, exception approvals, and declining reporting quality.

Step 8: Govern dynamically

Assign model ownership, document assumptions, define escalation thresholds, review changes, and update the system model when architecture, contracts, technology, or external conditions change.

11. Illustrative case: regional hospital digital transformation

Background. A regional hospital introduces an integrated electronic records and medication-management platform. The project depends on a software vendor, a cloud-hosting provider, network connectivity, clinical training, identity management, and regulatory approval.

Problem. The initial risk register treats software defects, connectivity loss, staff resistance, and vendor delay as separate medium-level risks. The steering committee assumes that the cloud provider and the hospital’s local data centre provide independent backup.

Analysis. A dependency network reveals that identity services, network access, and a single data-integration interface are shared by many clinical applications. A fault tree for loss of medication-record availability identifies two apparent alternative paths, but both depend on the same identity directory. This is a common-cause failure. An event tree shows that if an outage occurs during a high-demand period, the consequences depend on whether downtime procedures are available, staff are trained, medication reconciliation is completed, and clinical leaders can authorize workarounds.

A system-dynamics view identifies a reinforcing loop: schedule pressure reduces training time; inadequate training increases support calls and workarounds; workarounds increase data-quality problems; data-quality problems increase testing and rework; rework increases schedule pressure. An influence diagram shows that a decision to go live depends on uncertain information about defect severity, staff readiness, and fallback performance—not merely on the percentage of software tests passed.

Approach and solution. The project team establishes an independent identity service for critical downtime operations, separates selected network paths, pilots the system in one clinical unit, increases realistic simulation training, and defines a staged go-live decision. A clinical safety board—not only the project sponsor—owns acceptance criteria. The team conducts a 48-hour downtime exercise and uses scenario thresholds rather than a single probability estimate.

Outcome. The pilot identifies a medication-interface defect that ordinary functional testing did not expose. The defect is corrected before expansion. The project incurs additional training cost and a short delay but reduces the likelihood of a high-consequence clinical disruption.

Learning points. First, apparent redundancy is not genuine redundancy when alternatives share a dependency. Second, readiness is a system property involving people, procedures, technology, and authority. Third, schedule compression can create a feedback loop that makes the original delay worse. Finally, governance should include operational and safety expertise, not only delivery representatives.

12. Limitations, ethics, and governance

No model captures a complex system completely. Boundaries exclude some causes; data may reflect past conditions; expert judgements may be biased; and diagrams can create false confidence. Quantitative precision must not be confused with validity. Analysts should document assumptions, uncertainty ranges, data provenance, model purpose, and known exclusions.

Ethically, risk analysis must consider who receives benefits and who bears exposure. A project may improve aggregate efficiency while transferring operational or environmental risk to vulnerable communities. Stakeholder participation is therefore not merely a communication exercise. People with experiential knowledge may identify dependencies absent from formal architecture documents.

Governance issues include accountability for cross-boundary risks, escalation of weak signals, protection of incident reporters, segregation of assurance from delivery incentives, and retention of auditable model versions. AI-enabled risk tools can assist with anomaly detection, document analysis, dependency extraction, and scenario generation. They may also reproduce historical bias, infer causal relationships from correlation, conceal uncertainty, or encourage automation bias. AI outputs should be traceable, challengeable, and reviewed by accountable professionals. Sensitive project and personal data require appropriate security, privacy, and access controls.

13. Best-practice principles

1. Model relationships, not only risk-list entries.
2. Treat independence as a hypothesis requiring evidence.
3. Search for shared infrastructure, data, people, suppliers, and assumptions.
4. Combine static logic models with dynamic and network perspectives.
5. Define barrier performance, ownership, testing, and failure response.
6. Analyse time delays, adaptation, and resource constraints.
7. Use scenarios and stress tests when probabilities are disputed.
8. Design for graceful degradation and recovery, not only prevention.
9. Include affected stakeholders and operational experts.
10. Revisit models after changes in architecture, contracts, technology, or context.
11. Separate model uncertainty from natural variability and communicate both.
12. Use governance to convert analysis into decisions, thresholds, and learning.

Chapter Summary

Complex projects generate risk through interactions among technical components, organizations, external institutions, resources, information, and time. Systemic risk differs from an isolated risk because dependencies and feedback can create cascading or emergent outcomes. Common-cause failures invalidate simplistic independence assumptions and can defeat apparently redundant controls.

Bow-tie analysis connects threats, preventive barriers, a top event, mitigating barriers, and consequences. Fault trees reason backward from failure, while event trees reason forward from an initiating event. Influence diagrams support decisions under uncertainty. System dynamics represents stocks, flows, delays, and feedback loops. Network analysis reveals concentration, bottlenecks, alternate paths, and cascade potential. Black-swan and deep-uncertainty conditions require humility, stress testing, adaptive strategies, and resilience rather than false precision.

Effective practice begins by defining system boundaries and critical functions, mapping dependencies, selecting complementary models, testing assumptions, and evaluating interventions. Governance must ensure that models remain connected to operational decisions, ethical responsibilities, stakeholder experience, and continuous learning.

Key Terms

Systemic risk: Risk arising from interactions and dependencies that can disrupt a wider system.

Complex system: A system with interacting, adaptive, nonlinear, and often path-dependent elements.

Interdependence: A relationship in which the state or behaviour of one element affects another.

Causal chain: A sequence of conditions and events connecting causes to consequences.

Feedback loop: A circular causal relationship in which outputs influence future inputs.

Reinforcing loop: A feedback loop that amplifies change.

Balancing loop: A feedback loop that counteracts change or moves a system toward a target.

Emergence: A system-level pattern produced by interactions among local elements.

Common-cause failure: Failure of multiple components or controls due to a shared cause.

Latent condition: A hidden weakness embedded in design, management, culture, or infrastructure.

Bow-tie analysis: A barrier-based method linking threats, a top event, and consequences.

Fault tree: A deductive model that decomposes a top failure into contributing causes.

Event tree: An inductive model that traces possible outcomes after an initiating event.

Influence diagram: A graphical decision model containing chance, decision, and value nodes.

System dynamics: A modelling approach based on stocks, flows, feedback, and delays.

Network analysis: Analysis of nodes and edges representing entities and dependencies.

Cascade: Propagation of disruption from one element through connected elements.

Black swan: A surprising, high-consequence event that challenges prevailing expectations.

Deep uncertainty: A condition in which probabilities, models, or outcomes cannot be confidently agreed.

Resilience: The capacity to absorb, adapt to, recover from, or transform after disruption.

Review Questions

Short Answer Questions

1. What distinguishes systemic risk from an isolated project risk?
2. Explain the difference between a reinforcing and a balancing feedback loop.
3. Why can duplicated controls fail to provide genuine redundancy?
4. What is the principal difference between a fault tree and an event tree?
5. Define emergence in the context of project systems.

Long Answer Questions

1. Explain how a bow-tie model can be integrated with fault-tree and event-tree analysis. Discuss its strengths and limitations.
2. Critically evaluate the assumption of independence in project risk quantification, using common-cause failures as your focus.
3. Describe how system dynamics can reveal the unintended consequences of schedule-recovery actions.
4. Compare influence diagrams and network analysis as tools for managing interdependent project risks.
5. Discuss how governance should respond to black-swan conditions and deep uncertainty.

Analytical / Application Questions

1. A project has two backup systems, but both depend on the same identity-management service. Construct a qualitative fault tree and identify the common-cause failure. Recommend two design or governance responses.
2. A delayed construction project responds with overtime. Fatigue increases defects, and defects create rework. Use causal-loop reasoning to explain the likely behaviour and propose a balancing intervention.
3. For a critical supplier network, identify which data would be needed to assess concentration, alternative paths, and cascade potential. Explain how you would combine network analysis with stress testing.

Multiple Choice Questions with Answers

Question 1

Which feature most directly distinguishes a complex system from a merely complicated system?

A. It contains more than one component

B. It has feedback, adaptation, and nonlinear interactions

C. It can be represented in a project schedule

D. It has documented operating procedures

Correct Answer: B. It has feedback, adaptation, and nonlinear interactions

Question 2

If two events are genuinely independent, which relationship is correct?

A. P(A ∩ B) = P(A) + P(B)

B. P(A ∩ B) = P(A)P(B)

C. P(A ∩ B) = P(A) − P(B)

D. P(A ∩ B) = 1 − P(A)P(B)

Correct Answer: B. P(A ∩ B) = P(A)P(B)

Question 3

What is the principal purpose of the left side of a bow-tie analysis?

A. To identify threats and preventive barriers

B. To calculate project profit

C. To rank stakeholders by authority

D. To describe only recovery outcomes

Correct Answer: A. To identify threats and preventive barriers

Question 4

An event tree primarily answers which question?

A. What causes the top event?

B. What outcomes may follow an initiating event?

C. Which stakeholder owns the budget?

D. How should a work package be sequenced?

Correct Answer: B. What outcomes may follow an initiating event?

Question 5

A shared power supply disables two supposedly redundant servers. This is best classified as:

A. A balancing loop

B. A common-cause failure

C. A value node

D. A minimal benefit case

Correct Answer: B. A common-cause failure

Question 6

In system dynamics, which quantity accumulates over time?

A. A stock

B. A causal arrow

C. A threshold label

D. A decision node

Correct Answer: A. A stock

Question 7

In an influence diagram, a node representing the choice to qualify a second supplier is a:

A. Chance node

B. Decision node

C. Value node

D. Failure node

Correct Answer: B. Decision node

Question 8

A network node with high betweenness centrality may be especially important because it:

A. Always has the highest failure probability

B. Lies on many connecting paths

C. Has no dependencies

D. Must be a safety-critical asset

Correct Answer: B. Lies on many connecting paths

Question 9

Which response is most appropriate under deep uncertainty?

A. Report probabilities to many decimal places

B. Optimize exclusively for one forecast

C. Use stress testing and adaptive, robust strategies

D. Ignore outcomes that lack historical precedent

Correct Answer: C. Use stress testing and adaptive, robust strategies

Question 10

A schedule delay causes overtime, fatigue, defects, rework, and further delay. This pattern is a:

A. Reinforcing feedback loop

B. Balancing feedback loop

C. Mutually exclusive event tree

D. Independent fault pair

Correct Answer: A. Reinforcing feedback loop