Why Your Risk Register Can't See This

Executive Summary

The first article in this series described how a sequence of individually rational decisions can combine to produce a disappointing strategic outcome, without any single decision being at fault. The second introduced Decision Space Analytics as a way of examining that interaction directly — asking not what a decision will produce, but what it does to the decisions still available afterward.

This article addresses a question a careful reader of both should now be asking: doesn't a mature risk management function already catch this? The honest answer is no, not because risk management is poorly practiced, but because it was built to answer a different, equally important question. This article explains why a well-run risk register — fully documented, properly owned, actively monitored — can be doing its job perfectly and still not surface the interactions this series has been describing.

1. A well-run risk register, and a disappointing outcome anyway

Picture a retail bank replacing its core banking platform, eighteen months into the programme. The risk register is, by any reasonable standard, excellent. Every identified risk has an owner. Vendor delivery risk is tracked and mitigated through contractual milestones. Data migration risk has a dedicated workstream. Change-management risk has an adoption plan with named sponsors. None of these risks has materialized in a way the register didn't anticipate.

And yet the programme is behind, and the bank's recently completed acquisition of a smaller regional lender — approved for entirely separate strategic reasons, by a different committee, months earlier — is quietly part of why. Both efforts depend on the same three architects who understand the bank's decades-old core systems well enough to be trusted with either programme's most consequential technical decisions. Neither business case assumed the other would need them at the same time, because at the point each was approved, the other hadn't yet reached the stage where it needed them.

If you asked the risk manager whether this collision was on the register, the honest answer would likely be no — not because it was missed through negligence, but because it isn't the kind of thing a risk register, as conventionally structured, is built to hold. Nothing "went wrong" in the sense the register is designed to track. Both efforts are executing broadly as planned. The problem is that their plans were never evaluated against each other.

2. What a risk register is actually built to do

It's worth being precise about this, because the point of this article is not that risk registers are inadequate — it's that they were designed to answer a specific and valuable question, and this isn't it.

A risk register, at its core, is a structured way of answering: *what could happen that we don't want, how likely is it, how severe would it be, and who is responsible for managing it down?* This is a genuinely important discipline, and mature organizations have invested heavily, and correctly, in doing it well. The best risk functions go further than a flat list — they identify some dependencies between risks, track risk velocity, and increasingly model risk interactions within a single program or domain.

But even a sophisticated risk register is organized around *risks as things that might happen* — discrete, nameable events with a probability and an impact. The core banking programme's data migration risk is a thing that might happen. The acquisition integration's vendor delay risk is a thing that might happen. Neither register entry, however well specified, is built to represent something different: two initiatives, neither one behaving abnormally, whose ordinary and expected resource needs happen to collide. That collision isn't a risk in the register's sense, because nothing unlikely or adverse needs to occur for it to happen. It happens simply because both programs proceed exactly as planned, at the same time, drawing on the same finite thing.

This is the central distinction worth sitting with: a risk register asks what could go wrong. It does not, in its usual form, ask what happens if everything goes right, but two "everything going right" plans were never checked against each other.

3. Why even mature risk practice misses this

There are three specific, structural reasons a well-run risk function doesn't naturally catch this pattern, none of which reflect a failure of the discipline.

**Risk ownership is usually scoped to a single initiative.** The core banking programme's risk owner is responsible for that programme's risks. The acquisition integration has its own risk owner, responsible for its risks. Both are doing their jobs conscientiously. Neither one's mandate extends to asking what the other program is assuming about the same shared resource, because that question falls between their two scopes, not inside either one.

**Risk registers describe uncertainty, not commitment structure.** A register entry typically has a probability attached to it — this might happen, with this likelihood. The resourcing collision described above isn't uncertain in that sense. It is, in a meaningful way, already true the moment both programs are approved with overlapping resource assumptions; it simply hasn't become visible yet. Risk registers are built to track things that may or may not occur. They are less naturally built to track things that are already structurally true but not yet apparent.

**Risk reviews happen on a cadence set by the initiative, not by the interactions between initiatives.** Most governance calendars review each program's risks on its own schedule — monthly steering committees, quarterly portfolio reviews. Few organizations have a standing forum whose explicit purpose is to ask what has changed *between* programs since they were last reviewed together. Without that forum, the interaction has no natural point of entry into any existing process, however well each individual process is run.

None of this is a criticism of risk practitioners. It is closer to the same observation this series opened with: individually sound practices, each doing exactly what they were designed to do, can still leave a gap between them that nobody is explicitly responsible for.

4. A parallel that risk professionals will recognize

There is a useful analogy here to a distinction risk management itself has made progress on in recent decades: the difference between risks that exist independently and risks that are correlated. A mature risk function already knows that two risks, each individually modest, can be jointly severe if they are correlated — if the same underlying driver could cause both to materialize together. This is why sophisticated risk modeling increasingly looks at correlation structures, not just standalone probabilities.

The pattern this series describes is closely related, but sits one level up. It isn't that two *risks* are correlated. It's that two *decisions* — neither one a risk in the register's sense, both simply commitments the organization has made — draw on the same underlying resource, and the interaction between them only becomes visible once both exist. If risk correlation asks "could these two bad things happen together, and for the same reason," the decision-space question asks "do these two good decisions, each proceeding normally, quietly compete for the same thing, and would we have sequenced them differently if we'd seen that in advance?"

Framed this way, the gap this article describes isn't foreign to risk thinking — it's an extension of an instinct risk professionals already have about correlation, applied to decisions and commitments rather than to adverse events.

5. Three ordinary situations where this shows up

The pattern isn't limited to resourcing collisions between two large programs. It recurs, in slightly different form, across the kinds of strategic decisions most large organizations are making continuously.

**Infrastructure investment sequencing.** An organization approves an infrastructure upgrade in one region, and separately approves a cost-optimization initiative that consolidates support functions across regions. Each decision, reviewed alone, is defensible. Together, the consolidation may quietly assume a level of regional infrastructure stability that the upgrade — still mid-implementation — hasn't yet delivered, narrowing the options available to whichever team discovers the gap first.

**Organizational restructuring layered onto an active transformation.** A restructuring is announced partway through a multi-year transformation program, for reasons that have nothing to do with the transformation itself — perhaps cost discipline, perhaps a change in leadership. Neither decision is unreasonable in isolation. But the transformation program's plan assumed a stable organizational structure to execute against, and the restructuring quietly removes some of the flexibility the transformation's own risk register assumed would remain available.

**Digitalization initiatives competing for the same specialist judgment, not just the same specialist people.** It is not only headcount that gets contested. Two initiatives may each require the same small group of people with deep institutional knowledge to make judgment calls about legacy systems — not full-time capacity, but availability at the specific moments each initiative needs a decision made. Neither program's resourcing plan shows a conflict, because neither plan tracks partial, judgment-based availability the way it tracks allocated headcount.

In each case, a competent risk register, reviewed on its own terms, would find nothing to flag. The interaction only becomes visible to someone deliberately looking across initiatives, at the level of decisions and commitments rather than individual risks.

6. A different question, asked alongside the existing one

This is where the perspective introduced in the previous article becomes useful, not as a replacement for risk management, but as a companion question asked at a different level.

Risk management asks: what could go wrong with this initiative, and how do we manage it down? That question remains essential, and nothing in this article suggests otherwise. Decision Space Analytics asks a different question, aimed at a different target: given everything already committed, what does approving this decision do to the range of decisions the organization can still realistically make afterward — regardless of whether anything goes wrong?

The two questions are not in tension. A program can be extremely well risk-managed and still contribute to a narrowing decision space, because the narrowing isn't a risk event — it's an ordinary consequence of commitments accumulating without anyone examining how they interact. Equally, examining the decision space doesn't reduce the need for disciplined risk management within each initiative; it simply adds visibility at the level between initiatives, which risk management was never scoped to cover.

Executives who have sat through a post-mortem where the risk register showed green across the board, and the outcome was still disappointing, will likely recognize this distinction immediately. It isn't that the register was wrong. It's that the register was never asked the question that actually explains what happened.

7. Bringing this into existing practice

Introducing this perspective doesn't require dismantling anything already working. In practice, organizations that begin paying attention to this gap tend to do so by adding one deliberate habit rather than building new infrastructure: periodically asking, across the initiatives currently underway — not within any single one — what commitments each has made that assume uncontested access to something another initiative is also assuming. For a small number of concurrent initiatives, this can be done through structured cross-program discussion, bringing risk owners and program leads into the same room specifically to compare assumptions rather than status.

As the number of concurrent, interacting initiatives grows, this comparison becomes harder to do reliably through discussion alone — for the same reason raised in the previous article: the number of interactions to consider grows faster than the number of initiatives themselves. This is the point at which some organizations find it useful to work through the exercise with structured support.

Cascade Engine is one such tool. It does not replace the risk register, and it is not itself a risk management system. Given a real, current set of strategic decisions, it helps a leadership team and the relevant risk owners map how sequencing, dependencies, and resource assumptions interact across initiatives — surfacing the kind of cross-program collision described in Section 5 before it becomes structural, rather than after a steering committee discovers it. Its purpose is narrow and specific: to give visibility to the question this article has described, not to duplicate the risk management already being done well within each initiative.

Key Takeaways

- A mature, well-run risk register can be doing its job perfectly and still not surface the interactions this series describes — not because risk management is deficient, but because it was designed to answer a different question.

- Risk management asks what could go wrong with an initiative. Decision Space Analytics asks what a decision does to the decisions still available afterward, even if nothing goes wrong.

- Three structural reasons explain the gap: risk ownership is scoped to single initiatives, risk registers track uncertain events rather than already-true commitment structures, and governance cadences rarely include a forum for comparing assumptions across initiatives.

- The pattern is closely related to something risk professionals already understand — correlated risk — but operates one level up, at the level of decisions and commitments rather than adverse events.

- The two questions are complementary, not competing: strong risk management within each initiative and attention to the decision space between initiatives address different, equally real sources of disappointing outcomes.

- Cascade Engine is one practical way of making cross-initiative interactions visible, intended to support existing risk and portfolio practice rather than replace it.