Beyond the Risk Register: Reading Complexity, Not Just Managing It

https://youtu.be/Sndk67nZggs?si=YN69n4D6nvH--2EE

In complex projects, the most useful signals are the ones a risk register cannot capture—the persistent tensions between roles, disciplines, and priorities that convey how the project is actually changing. Effective risk management remains essential: a risk is an uncertain event you work to prevent or mitigate, and the discipline of identifying, assessing, and treating risk is foundational. INMAA Advisory's approach builds on that foundation and adds a distinctive layer. In complex environments, the register captures what can be named — but complexity also produces conditions that resist naming, and reading those conditions requires a different lens.

This article sets out three shifts that lens involves: from risk to vulnerability, from divided accountability to collective sensemaking, and from managing complexity to sensing it.

Image credit Valentín Betancur

Complex projects are human activity systems, not machines

A complex project is not a machine with clean, separable dependencies. It is a complex adaptive human activity system, a system of suppliers, competitors, government, customers, and subcontractors, all interdependent. The distinction between interdependence and dependence matters. Dependence is linear: one part relies on another, and you can trace the line. Interdependence is mutual and often circular, and it produces behaviour no single part can explain on its own. The sum is bigger than the parts.

This is why complexity resists the reductive habit of breaking a system into pieces, managing each piece, and assuming the whole is thereby managed. In an interdependent system, the behaviour that matters lives in the interactions, not the components. Two forms of complexity are worth separating here. Organised complexity has structure you can model — many parts, but patterned relationships. Disorganised complexity, the territory of genuine VUCA conditions — volatility, uncertainty, complexity, ambiguity.

From risk to vulnerability

Risk, as conventionally practised, is allocatable. You name a threat, assign an owner, attach a treatment, and record it. That property is exactly why risk management integrates so cleanly into process and compliance — and why, under pressure, process can quietly override leadership, decision-making, and accountability. The register becomes something to fall back on rather than a prompt to decide.

Vulnerability behaves differently. It lives in the interdependence between parts of the system, not inside any one of them, and it is often invisible from any single vantage point. A capability that is delivered on budget but will not integrate is not a risk sitting in anyone's register; it is a vulnerability sitting in the space between the parties who each saw only their portion. You cannot allocate accountability for a vulnerability the way you allocate a risk, because seeing it at all requires more than one perspective.

David Hillson's well-known definition — risk is uncertainty that matters — is a useful anchor here, and worth extending. What matters, and to whom, is not given. It depends on the worldview from which the project is being read. Two roles looking at the same program will disagree about what matters precisely because they hold different, legitimate, partial views. That disagreement is not noise to be resolved. It is information.

Accountability cannot be divided

Conventional governance seeks clear roles and explicit decision rights — and in stable conditions, that clarity prevents the ambiguity and conflict common in multi-stakeholder environments. But there is a limit to how far accountability for complexity can be partitioned. Each role in a complex project holds a different worldview: the delivery function sees one reality, the oversight function another, and each view is real and incomplete. Predictability rests on understanding, and understanding always occurs within a given domain or area of concern. Lose the whole-system view and you do not merely miss information — you alter what it is possible to understand at all.

This is where the distinction between multidisciplinary and interdisciplinary work becomes practical rather than academic. Multidisciplinary effort runs disciplines side by side, each in its lane, outputs assembled at the end. Interdisciplinary effort integrates them, so that insight forms in the overlap between fields rather than inside any one of them. Complex project governance needs the second. The vulnerabilities that matter appear between disciplines and between roles, which means the mechanism for surfacing them is not a clearer division of labour but genuine sensemaking — the disciplined act of bringing partial worldviews together.

Accountability, on this view, does not disappear into collective vagueness. It concentrates. It moves from the boxes on a responsibility chart to the quality of the forum where different worldviews actually meet and make sense of what each is seeing. Boundaries determine the scope and scale of our concern — draw them too tightly around a single role and the signal falls outside the frame. The governance task is to set those boundaries deliberately and to build the forum where the partial views converge.

From control to clarity

The instinct in the face of complexity is to reach for more control — more reporting, tighter process, faster closure of open questions. In a complex adaptive system, that instinct often removes the very signals leadership most needs. Persistent tensions between legitimate priorities — control versus flexibility, speed versus assurance, sovereignty versus interoperability — are not failures of governance to be engineered away. They are emergent properties of the system, and they carry diagnostic information about how the project's complexity is shifting. Collapse a tension too early by picking a side, and you lose the early warning it was providing.

The more useful posture is a shift from control to clarity and focus: not an attempt to command the system into predictability, but the pursuit of shared understanding across its worldviews, and the resilience to absorb what cannot be predicted. Resilience here is not a contingency line item. It is the capacity to adapt as conditions change, built into how the project is governed rather than bolted on afterward.

A newer pressure sharpens all of this. As AI systems begin to generate governance signals faster than human forums can process them, the binding constraint shifts. It is no longer detection — organisations increasingly have more signals than they can act on. The constraint becomes the organisation's capacity to make sense of, and decide on, what it is already receiving. Governance that meets on a fixed monthly rhythm cannot govern a picture that changes weekly. Matching the tempo of decision-making to the tempo of the risks — and the vulnerabilities — is fast becoming the practical edge of governance maturity.

Frequently asked questions

What is the difference between a risk and a vulnerability in complex projects?

A risk is an uncertain event that can be named, assigned an owner, and mitigated — it fits within a register. A vulnerability is a structural condition that lives in the interdependence between parts of a system, often invisible from any single vantage point and not allocatable to one role. INMAA treats both as necessary: risk management remains foundational, while vulnerability identification requires collective sensemaking across worldviews.

Why can't accountability for risk simply be divided between roles?

Accountability for named risks can be divided, and should be. But in a complex adaptive human activity system, each role holds a partial worldview, and the vulnerabilities that matter appear in the interactions between roles rather than inside any one of them. Accountability for those cannot be partitioned — it concentrates in the quality of the forum where different perspectives meet and make sense of what each is seeing.

How does INMAA read governance tensions?

INMAA treats a tension as a persistent, paradoxical force — such as control versus flexibility or speed versus assurance — that cannot be permanently resolved and carries information about a project's shifting complexity. Rather than collapsing tensions into the risk register, INMAA reads them as signals for adaptation. Best-practice risk management and tension-informed decision-making work together, not in opposition.

What does "sensing complexity" mean in practice?

It means treating complexity as a condition to be read rather than a problem to be controlled. In practice this involves establishing a project's complexity profile early, watching persistent tensions as leading indicators, setting system boundaries deliberately, and building resilience to absorb what cannot be predicted — rather than relying on modelling tools suited to stable, organised conditions.