Why Not Every Risk Belongs on the Project Manager's Desk
A control can reduce one threat while creating a secondary exposure. This is why every material treatment needs a net-risk review that considers new failure paths, changed human behaviour and dependencies introduced by the response.
This is the fundamental paradox that every project manager must grapple with during the implementation phase: risk is dynamic, interconnected, and sometimes self-generating. New risks emerge mid-project. Existing risks change in probability and impact as conditions shift. And sometimes, the organisation's tolerance for risk itself changes — meaning that a risk previously deemed acceptable suddenly requires urgent attention.
When this happens, the critical question becomes: who needs to know, and who has the authority to act? The answer lies in three interconnected concepts — risk escalation, risk appetite, and the ALARP principle — that together form the governance framework for risk decision-making during project execution.
What Are Risk Escalation, Risk Appetite, and ALARP?
Risk Escalation
Escalation is not an admission of failure — it is a governance mechanism that ensures risks are managed by people with the authority, resources, and organisational perspective to address them effectively. A project manager who escalates a risk appropriately is demonstrating professional judgement; one who fails to escalate is creating organisational exposure.
Risk Appetite
Risk appetite is not a single number — it is a series of boundaries, appropriately authorised by management, that give each level of the organisation clear guidance on the limits of risk they can accept. These boundaries are expressed in the same terms used in risk assessment: likelihood, impact, and exposure.
The ALARP Principle
ALARP originated in UK health and safety law and is deeply embedded in defence, nuclear, oil and gas, and heavy engineering sectors. It recognises that while zero risk is impossible, there is a region between "broadly acceptable" and "intolerable" where the project manager must demonstrate that all reasonable measures have been taken to reduce risk.
How These Concepts Work Together in Practice
The Architecture of Risk Escalation
If a project has been established with good governance, the project manager will know the escalation processes and the specific triggers that will elevate an issue to higher authorities for timely resolution. An escalation process ensures that the next level of management is informed — often within a specific time period — if an issue cannot be resolved at the current level.
The architecture of escalation operates at three tiers:
Tier 1 — Team to Project Manager. Team members escalate risks that exceed their individual authority or capability to manage. The project manager sets clear expectations about what kinds of issues should be escalated and which the team is empowered to handle independently. Typical triggers include: variance greater than a defined percentage (e.g., 5% on a budget line), schedule delays on critical-path activities, quality non-conformances, or safety incidents. Tier 2 — Project Manager to Project Sponsor/Steering Committee. The project manager escalates risks that exceed the project-level tolerance thresholds. These are typically risks with strategic implications: significant budget overruns, major schedule impacts, scope changes that affect the business case, or risks that require resources beyond the project's allocation. Tier 3 — Sponsor/Steering Committee to Executive/Board. Risks with enterprise-level implications — reputational damage, regulatory exposure, portfolio-level resource conflicts, or strategic risks that affect the organisation's competitive position — are escalated to the highest authority level. The traffic-light principle is a widely used mechanism for communicating escalation status. Risks are colour-coded based on their current exposure relative to tolerance thresholds: Green (within tolerance — managed at current level), Amber (approaching tolerance — heightened monitoring, prepare for escalation), Red (exceeding tolerance — escalated to next level for decision).
Understanding Risk Appetite at Multiple Levels
The concept of risk appetite operates at three distinct organisational levels, each with its own tolerance boundaries:
Corporate Risk Appetite is the overall amount of risk judged appropriate for the organisation to tolerate, agreed at board level. This is not a single statement — organisations typically define risk appetite across multiple dimensions: financial risk, reputational risk, safety risk, regulatory risk, and operational risk. The board establishes general boundaries for unacceptable risk and identifies categories that must always be escalated for board-level discussion. Delegated Risk Appetite cascades the corporate risk appetite down through the organisation, defining tolerance boundaries at each management level. The practical effect is that what constitutes a "high" risk at one organisational level will be a "lower" risk to a higher level of management. This delegation both empowers lower levels to manage risks within their authority and provides a clear escalation mechanism when boundaries are exceeded. Project Risk Appetite may differ from the organisation's general risk appetite depending on the nature of the project. The Orange Book identifies three project categories with inherently different risk appetites:
| Project Type | Risk Appetite | Example |
|---|---|---|
| Speculative | High — high risk, potentially high reward | Pilot programmes, R&D ventures, Invest to Save initiatives |
| Standard Development | Moderate — balanced risk-reward profile | IT projects, procurement, construction, engineering development |
| Mission Critical | Low — organisation must be confident of success | Defence capability delivery, safety-critical infrastructure, regulatory compliance |
The level of risk appetite obviously varies: a speculative project is prepared to accept higher levels of risk than a mission-critical one. A project manager must understand which category their project falls into and calibrate their risk management intensity accordingly.
Critical insight: An organisation's risk appetite is not static. The board retains the freedom to vary the amount of risk it is prepared to accept depending on current circumstances. A defence contractor that was comfortable with moderate schedule risk during peacetime may dramatically reduce its risk appetite when an urgent operational capability is required. The project manager must remain attuned to shifts in organisational risk appetite and adjust their monitoring and escalation thresholds accordingly.
Applying ALARP to Project Risk Management
The ALARP principle provides a structured framework for making risk acceptance decisions. It divides the risk spectrum into three regions:
Intolerable Region: Risks in this zone cannot be justified regardless of the potential benefits, except in extraordinary circumstances. The risk must be eliminated or reduced before work can proceed. In safety-critical engineering, this region is defined by regulatory thresholds — for example, a structural failure probability that exceeds the certification limit. ALARP Region: Risks in this zone are tolerable only if further reduction is impracticable or if the cost of additional reduction is grossly disproportionate to the benefit gained. The burden of proof lies with the project to demonstrate that all reasonable measures have been taken. This is where most project risk management decisions are made — balancing the cost and effort of additional mitigation against the residual exposure. Broadly Acceptable Region: Risks in this zone are so low that no further action is needed beyond routine monitoring. The cost of any additional reduction would exceed the benefit, and the residual exposure is negligible.
If this ratio exceeds a defined threshold (i.e., the cost of reduction is grossly disproportionate to the benefit), the risk is deemed ALARP and can be accepted at that level. In UK health and safety practice, the "grossly disproportionate" test sets a deliberately high bar — the cost of reduction must be grossly (not merely) disproportionate to accept the current risk level.
Emerging Risks, Black Swans, and Continuous Improvement
When New Risks Appear Mid-Project
Even the most rigorous risk identification process cannot anticipate every risk that will emerge during project execution. Three categories of new risk can appear mid-project:
Changed Risk Appetite: The organisation's tolerance for risk may shift due to external factors — a change in government policy, a competitor's market move, a shift in public sentiment, or a change in senior leadership. Risks that were previously acceptable may need to be re-evaluated and potentially escalated under the new appetite framework. Environmental Change: The world does not stand still while your project executes. New technologies emerge, supply chains are disrupted, regulatory frameworks change, key personnel leave, and geopolitical conditions shift. Each of these changes can create risks that did not exist when the risk register was first compiled. Unknown Unknowns (Black Swans): The most dangerous category — risks that were not merely unplanned but genuinely unforeseeable. The modern black-swan literature's concept of the Black Swan describes events that are rare, have extreme impact, and are rationalised in hindsight as if they were predictable. The global pandemic, the de-identified multi-hazard infrastructure disaster, and the 2008 financial crisis are all examples. While Black Swans cannot be specifically anticipated, project managers can build organisational resilience — through reserve allocation, flexible response frameworks, and escalation processes — that improves the capacity to respond when the unforeseeable occurs.
Driving Continuous Improvement
Risk management during the implementation phase is not only about protecting the current project — it is about improving the organisation's capacity to manage risk on future projects. Continuous improvement in risk management should be driven by:
Constant environmental change that makes yesterday's assumptions obsolete. Changes in customer and stakeholder perceptions and opinions that redefine what constitutes acceptable risk. New technology that creates both new risks and new mitigation options. New information that refines the understanding of existing risks. Experience accumulated through the monitoring process itself — the most valuable source of improvement data. The competitive imperative to manage risk better than rival organisations. Best practice benchmarks that establish performance standards. And the customer and stakeholder focus that ensures risk management serves its ultimate purpose: delivering value to the people who commissioned the project.
Common Pitfalls
Escalation as failure. When organisational culture treats escalation as an admission of incompetence rather than a governance mechanism, project managers will delay or avoid escalating — allowing manageable risks to grow into crises. The antidote is a no-blame culture that recognises: bad systems produce bad outcomes, not bad people. Undefined tolerance thresholds. If the project has not defined specific, quantified thresholds for escalation at each management level, escalation decisions become subjective and inconsistent. Every project should document clear trigger points — e.g., "5% budget line variance triggers reporting to PM; 10% total variance triggers escalation to sponsor."Static risk appetite. Treating risk appetite as a fixed parameter established at project inception, rather than a dynamic boundary that may shift as organisational circumstances change. Misapplying ALARP. Using ALARP as a justification for accepting risks without genuinely evaluating whether further reduction is practicable. The ALARP test requires positive evidence that all reasonable measures have been considered — not simply an assertion that "we've done enough."Ignoring Black Swans. While specific Black Swan events cannot be predicted, the category of "severe, unforeseen disruption" is entirely predictable. Projects that allocate no reserves and build no flexible response capacity for unknown unknowns are not managing risk — they are gambling.
Key Takeaways
Escalation is governance, not failure. Clear escalation paths with defined triggers ensure that risks are managed by people with appropriate authority and resources. Every project needs documented escalation thresholds at every management level. Risk appetite operates at three levels. Corporate, delegated, and project risk appetites cascade through the organisation, providing a framework of tolerance boundaries that guide decision-making at every level. Risk appetite is dynamic, not fixed. ALARP is the gold standard for risk acceptance. The principle that risk should be reduced to the lowest level that is reasonably practicable — with the burden of proof on the project — provides a rigorous, defensible framework for risk acceptance decisions in safety-critical and regulated industries. New risks are inevitable. Changed risk appetite, environmental shifts, and Black Swan events will generate risks that were not in the original register. The monitoring process must be designed to detect and respond to emerging risks, not just track known ones. Continuous improvement is the ultimate objective. Every monitoring cycle generates insights that, if captured and applied, improve the organisation's risk management maturity. The implementation phase is not just about protecting the current project — it is about building organisational capability for every future project.