Two projects can face the same external event and experience completely different outcomes because risk is what may happen, while vulnerability is what allows the event to become damaging.
A supplier can fail. A market can contract. A regulatory requirement can change. A key engineer can leave. Cybersecurity controls can be breached. A construction approval can be delayed.
These are familiar project risks.
Yet the event itself does not determine the outcome. One organisation has a second qualified supplier, modular architecture, cross-trained staff and financial contingency. Another has a single dependency, undocumented knowledge, no fallback design and a business case that tolerates almost no delay.
The external event may be identical. The vulnerability is not.
The Strategic Context
The supplied feasibility material from Mesly distinguishes contextual risks from internal “points of vulnerability”. The author's terminology and quantitative model are distinctive and should be attributed rather than adopted as universal doctrine, but the conceptual distinction is powerful.
Risk management often concentrates on identifying events and estimating probability and impact. That is useful, but it can leave leadership with a long register of things that might happen without revealing why the system is fragile.
Systems thinking shifts the question.
Instead of asking only “What can go wrong?”, leaders also ask:
“What is it about our design, organisation, dependencies or capability that would allow that event to cause disproportionate harm?”
This is a resilience question.
What Leaders Commonly Misread
The first mistake is to treat vulnerability as another word for high risk. They are related but not identical. A low-probability event can be strategically serious when vulnerability is extreme. A frequent disruption can be manageable where resilience is strong.
The second is to focus only on threats outside the project. Internal design choices create exposure: single-source suppliers, concentrated expertise, tightly coupled processes, unrealistic schedules, inflexible contracts and over-optimistic benefit assumptions.
The third is to assume that contingency money is resilience. Financial reserve helps only if money can actually solve the failure mode. A missing regulatory approval, obsolete technology architecture or unavailable specialist skill may not be recoverable merely by spending more.
The fourth is to catalogue risk without redesigning the system. If a risk remains material because the project is structurally vulnerable, the response should often change the architecture rather than update the register.
Reframing the Issue
A practical relationship is:
Risk event × vulnerability × exposure = potential consequence
This is not presented as a mathematical formula from the supplied sources; it is an ERANORTH decision model for thinking about causal structure.
Risk describes uncertainty in the environment.
Vulnerability describes susceptibility inside the system.
Exposure describes how much value, safety, service, reputation or strategic capacity is placed in the path of the failure.
Resilience is the system's ability to absorb, adapt and recover.
This framing changes the focus from prediction to design. Leaders do not need to predict every external event if they reduce the number of ways a single event can become catastrophic.
Vulnerability Often Hides in Interfaces
Complex systems fail at interfaces more often than executive dashboards reveal.
A manufacturing line may contain individually reliable machines but remain vulnerable where upstream variation causes downstream starvation, where one manual inspection becomes the bottleneck, or where spare parts for a critical control component have long lead times.
A digital program may have strong individual applications but weak identity management, inconsistent data definitions or brittle integrations.
A transformation program may have well-managed projects but weak dependencies between technology deployment, process redesign, training and policy change.
The risk register may show “integration delay”. The vulnerability is the architecture that made integration a single point of failure.
Organisational Vulnerability Matters as Much as Technical Vulnerability
The supplied feasibility material also points to people, power, communication, control, management support and competence as areas where projects can become vulnerable.
This is important because organisations often design redundancy into machines while leaving human systems dangerously concentrated.
Examples include:
- only one engineer understands a critical legacy system;
- the project depends on one sponsor's political support;
- decisions require several committees with no clear escalation path;
- operational acceptance depends on one manager who was not involved in design;
- benefits require workforce behaviour change but no benefit owner has authority over the affected process;
- supplier knowledge is not transferred to internal staff.
These weaknesses may not create immediate failure. They create sensitivity to otherwise manageable events.
Vulnerability Can Be Created by Success
One useful insight in the supplied feasibility material is that unexpectedly high demand can itself expose weaknesses. Success can overload capacity, service processes, infrastructure or governance.
A digital service that attracts far more users than forecast may fail under load. A new product may create quality problems because the supply chain cannot scale. A public event may become unsafe because turnout exceeds planning assumptions.
This is strategically important. Leaders should not test only downside scenarios. They should ask whether the system can absorb upside variance as well.
Resilience is not merely protection against bad outcomes. It is the ability to remain functional when reality differs materially from the plan.
Decision Framework
A vulnerability review can work through six layers.
| Layer | Diagnostic question | Typical vulnerability |
|---|---|---|
| Strategy | What assumption would remove the rationale for investment? | Single demand forecast, one regulatory interpretation |
| Design | What component or interface has no practical substitute? | Single point of failure, tightly coupled architecture |
| Supply | Which external dependency is difficult to replace? | Sole supplier, scarce material, proprietary support |
| People | Where is capability concentrated? | Key-person dependency, inadequate cross-training |
| Governance | What decision cannot be made quickly when conditions change? | Ambiguous authority, slow escalation, sponsor dependence |
| Operations | What would prevent recovery after disruption? | No spare capacity, weak maintenance, no fallback process |
For each vulnerability, leaders should decide whether to remove it, reduce it, transfer part of it, create redundancy, create recovery capability, or consciously accept it.
The important point is that the treatment acts on the system, not merely the probability estimate.
From Strategy to Execution
Immediately, take the top ten material risks in a project and ask a second question beside each one: what internal condition makes this event dangerous? This simple exercise often produces more actionable responses than adding further detail to probability scoring.
In the medium term, introduce design reviews focused on resilience. Engineering, operations, commercial, cyber, workforce and governance perspectives should examine single points of failure and recovery capability before major commitments.
Over the longer term, portfolio leaders should identify shared vulnerabilities across projects. Ten projects may look diversified while all depend on the same specialist team, cloud provider, contractor, regulatory approval path or supplier geography. That is portfolio risk concentration hidden beneath project-level reporting.
Related article: Feasibility Is a Search for Failure Before It Is a Case for Approval
Related article: The Hidden Portfolio Cost of Treating Every Good Project as a Priority
Signals to Monitor
Watch for repeated risk acceptance without structural treatment, growing dependence on a small number of specialists or suppliers, contingency plans that have never been tested, and projects whose recovery strategies assume the same resources that would be unavailable during the disruption.
Other warnings include increasingly tight schedule tolerance, elimination of spare capacity solely to improve efficiency, and benefit cases whose value collapses under modest deviations from the central forecast.
Questions for the Leadership Team
- Which external event could hurt us most because of an internal weakness we already know about?
- Where do we have single points of failure in technology, suppliers, people or decision rights?
- Which vulnerabilities are shared across multiple projects or business units?
- Can our contingency plans actually operate under the conditions in which they would be needed?
- Where has efficiency removed too much resilience?
- What happens if demand is materially higher—not lower—than forecast?
Closing Perspective
Risk cannot be eliminated from ambitious investment. Vulnerability can often be designed down.
The strongest project is not the one with the shortest risk register. It is the one whose architecture, people, governance and operating model prevent ordinary uncertainty from becoming extraordinary damage. Leaders who separate risk from vulnerability move from predicting threats to building systems capable of surviving them.