Project Risk and Enterprise Risk

Why This Matters: One Size Does Not Fit All

Many organisations have mature enterprise risk management (ERM) systems — risk registers maintained by corporate risk teams, quarterly board reporting on strategic risks, compliance frameworks audited annually. Yet time and again, projects within those same organisations fail to manage their risks effectively. Cost overruns, schedule blowouts, and scope failures persist despite the presence of sophisticated organisational risk infrastructure.

The reason is deceptively simple: project risk is fundamentally different from organisational risk, and treating projects as merely another category within an enterprise risk framework is a recipe for underperformance. Projects have characteristics that intensify, compress, and add unique dimensions to uncertainty — dimensions that generic ERM processes were never designed to handle.

Understanding this distinction is critical for two reasons. First, it explains why risk management standards designed for ongoing operations (like ISO 31000 in its generic form) need significant adaptation before they can serve project teams effectively. Second, it reveals the unique risk amplifiers inherent in project work that demand specialised tools, techniques, and — most importantly — a risk-aware project culture.

What Makes Project Risk Different?

Project-risk guidance identifies nine characteristics that distinguish project risk from organisational risk. These are not minor variations — they represent fundamental structural differences in the nature of uncertainty that project teams face.

1. Uniqueness

Every project, by definition, creates something that has not existed before. Unlike ongoing operations where risks are repetitive and can be managed through standardised procedures, projects venture into partially or wholly uncharted territory. A manufacturing plant running a production line can draw on years of operational data to predict failure rates, downtime, and quality variances. A project to design and build a new class of offshore patrol vessel has no such luxury — the design is novel, the integration challenges are unique, and the supply chain configuration has never been tested in this exact combination.

This uniqueness means that historical data is inherently limited as a basis for risk estimation. Risk assessments must rely more heavily on expert judgment, analogical reasoning from similar (but never identical) projects, and structured techniques like Delphi and brainstorming.

2. Complexity

Projects typically involve multiple disciplines, technologies, stakeholders, and organisational boundaries. A Tier-1 defence project might simultaneously involve systems engineering, software development, mechanical design, logistics support, regulatory compliance, and international supply chain management. The interactions between these elements generate emergent risks — risks that arise not from any single element but from the interfaces and dependencies between them.

Organisational risk management typically handles risks in functional silos. Project risk management must address cross-functional interdependencies that create cascading failure modes invisible to any single discipline.

3. Assumptions and Constraints

Every project plan is built on a foundation of assumptions — about resource availability, technology maturity, regulatory timelines, stakeholder behaviour, and market conditions. These assumptions are themselves sources of uncertainty. The PMBOK explicitly recognises that assumptions should be evaluated as potential causes of project risk.

Projects also operate within constraints (budget, schedule, scope, quality) that create rigid boundaries. When a risk materialises, the constrained environment limits the response options available. An ongoing operation can often absorb cost overruns across multiple financial periods; a project with a fixed-price contract and a contractual completion date has far less flexibility.

4. People

Projects are staffed by temporary teams assembled for a specific purpose and disbanded upon completion. Team members may not have worked together before, may come from different organisational cultures, and may have competing loyalties to their functional managers versus the project manager. This creates risks around team cohesion, communication effectiveness, knowledge transfer, and individual competency that do not typically exist in stable operational teams.

5. Stakeholders

Projects typically have a broader and more diverse stakeholder landscape than ongoing operations. Sponsors, clients, end users, regulatory authorities, community groups, subcontractors, joint venture partners, and political stakeholders may all have legitimate but conflicting interests in the project's outcomes. Managing these competing expectations is itself a significant source of project risk.

6. Change

Projects exist in a state of progressive elaboration — the plan evolves as more information becomes available. This inherent dynamism means that the risk landscape is continuously shifting. New risks emerge, existing risks change in probability or impact, and previously identified risks may become irrelevant. Enterprise risk management, designed for relatively stable operational environments, typically reviews risks quarterly or annually. Project risk management must be far more agile — with risk reassessments at every phase gate, milestone, and significant decision point.

7. Deliberate Design

This is perhaps the most profound distinction. Project-risk guidance observes that projects are deliberately designed as risk-taking activities. Organisations launch projects specifically to achieve objectives that require venturing beyond the known and predictable. A company does not invest AUD 200 million in developing a new weapons system because the outcome is certain — it does so because the potential reward justifies the deliberate acceptance of uncertainty.

This means that the goal of project risk management is not to eliminate risk — it is to ensure that the risks taken are conscious, informed, and proportionate to the expected rewards. This is a fundamentally different posture from enterprise risk management, which often focuses primarily on risk reduction and compliance.

8. External Environment

Projects are exposed to external environmental factors — political changes, regulatory shifts, market movements, technological disruptions, natural disasters — over which the project team has no control. While organisations face similar external risks, they typically have longer time horizons and more diversified portfolios to absorb external shocks. A single project concentrated on a specific deliverable within a fixed timeframe is far more vulnerable to external disruption.

9. Common Characteristics Amplified

Many of the risks that projects face are the same as those faced by organisations — financial risk, reputational risk, safety risk, compliance risk. But the project context amplifies these common risks through the combination of uniqueness, complexity, constraints, and compressed timescales. A safety incident on an operational facility is serious; a safety incident during construction of a first-of-type facility, with immature procedures and an unfamiliar workforce, carries even greater consequences because the learning curve has not yet flattened.

How It Works: Adapting Risk Management for Projects

Mapping Risk Across the Project Lifecycle

The combination of ISO 31000 and the PMBOK provides complementary coverage across the full project lifecycle. The key is understanding which standard addresses risk at which phase:

This mapping reveals the complementary strengths: ISO 31000 bookends the project lifecycle with strategic context and closure activities that the PMBOK largely omits, while the PMBOK provides the detailed tactical processes for the planning and execution phases where most risk management activity occurs.

Building Risk Into Project Governance

Because project risk is amplified by the factors described above, it requires governance structures that go beyond those of enterprise risk management. Effective project risk governance includes:

Risk ownership at every level: From the project sponsor (accountable for strategic risks) through the project manager (accountable for operational risks) to individual work package managers (accountable for task-level risks). Integrated risk reporting: Risk status should be a standing agenda item at every project review, not a separate reporting stream. The risk register should be a living input to schedule reviews, cost reviews, and technical reviews. Escalation protocols: Clear thresholds that define when a risk must be escalated from the project level to the programme or portfolio level — and ultimately to the organisational executive if it threatens strategic objectives.

The Pitfalls: The Culture Problem

Deliberate Ignorance

Published behavioural research reveals a disturbing finding: in some projects, risk management is conditioned by the deliberate ignorance of project managers. It identified three factors that drive this behaviour: Untopicality: Risk information is perceived as irrelevant to current project priorities. When a project team is focused on meeting an imminent milestone, risks that might materialise months later are deprioritised — even if they could be mitigated now at low cost. Undecidability: Risk information is perceived as too uncertain to act upon. When probability estimates are vague and impact assessments are speculative, project managers may conclude that the information is not actionable and therefore not worth their attention. Utility: Risk information is perceived as having no practical value. If previous risk management exercises produced risk registers that were never consulted and risk responses that were never implemented, project managers learn that the effort produces no return.

The Administrative Trap

Good risk processes do not guarantee good risk management. The standard provides the structure, but structure without genuine intellectual engagement is empty. A project team that mechanically fills in a risk register without challenging its thinking, debating assumptions, or honestly confronting uncomfortable uncertainties is performing risk theatre — not risk management.

Building a Risk-Positive Culture

The antidote to deliberate ignorance is a culture that:

• Rewards honesty about uncertainty rather than penalising the bearer of bad news
• Values early warning over post-event explanation
• Treats risk discussions as strategic conversations rather than administrative obligations
• Holds risk owners accountable for monitoring and responding — not just for registering
• Captures and applies lessons learnt so that risk management demonstrates tangible value across project generations

Key Takeaways

• Project risk is structurally different from organisational risk due to nine amplifying characteristics: uniqueness, complexity, assumptions, people, stakeholders, change, deliberate design, external exposure, and amplified common risks.
• Projects are deliberately designed as risk-taking activities — the goal is not to eliminate risk but to ensure risks are conscious, informed, and proportionate to expected rewards.
• ISO 31000 and the PMBOK complement each other across the project lifecycle — ISO 31000 provides strategic context and closure; the PMBOK provides tactical planning and execution processes.
• Good processes do not guarantee good risk management — Published behavioural research on deliberate ignorance shows that untopicality, undecidability, and perceived lack of utility can reduce risk management to administrative theatre.
• Culture is the critical success factor — a risk-positive culture that rewards honesty, values early warning, and holds risk owners accountable is more important than any specific methodology or tool.

The Broader Risk Environment: Context and the Extended Enterprise

The Orange Book's model places the core risk cycle within two concentric contextual layers:

The Extended Enterprise — the network of partner organisations, sponsored bodies, contractors, and suppliers on which the organisation depends for delivery. No organisation is self-contained, and the risks arising from these interdependencies must be actively managed. The Risk Environment — the broader external context including laws and regulations, the economy, government policy, stakeholder expectations, and corporate governance requirements. These factors generate risks that cannot be directly controlled but must be anticipated and planned for.

In defence contracting, the extended enterprise is particularly significant. A prime contractor assembling a complex weapons system depends on dozens of Tier-2 and Tier-3 suppliers, each with their own risk profiles. A subcontractor's financial instability, quality failure, or capacity constraint becomes the prime's risk — and the Orange Book framework demands that these interdependencies are systematically identified and managed.

What Is Enterprise Risk Management?

Definition

Enterprise Risk Management (ERM) is a broad, integrated approach to risk management that operates across an entire organisation. Rather than managing risks in isolated silos—OH&S here, financial risk there, project risk somewhere else—ERM creates a unified framework where everyone is responsible for recognising and managing risks at their level.

ERM has evolved to address the needs of organisations that want to understand the full spectrum of risks facing complex operations and ensure they are appropriately managed. Risk management professionals created the concept to implement consistent awareness and prevention programs on a company-wide basis.

The Five Pillars of ERM

An effective ERM system:

1. Creates a culture of risk ownership where everyone is responsible for recognising and managing risks, putting "localised knowledge" to work. The people closest to each business unit's activities are best able to identify risks, collect data, and manage controls and treatments.

2. Makes each area manager responsible for documenting and evaluating risk in their area. This pushes risk identification to the people with the deepest operational understanding.

3. Identifies inadequate controls so that action plans can be initiated to resolve problems before they materialise as incidents.

4. Monitors the progress of outstanding action plans, tracks who is responsible, and sets expected timeframes for resolution.

5. Pushes responsibility and control down to the level where risk can be best managed. Managers become empowered to understand the impact of their roles on corporate results.

The Evolution From Siloed to Integrated Risk

The enterprise-risk research report on Enterprise Risk Management documents a fundamental shift in how organisations approach risk: