Why Most Organisations Get Risk Management Effort Wrong
Here is a problem that plagues project-based organisations across every sector. A AUD 2 million routine maintenance shutdown on a manufacturing line receives the same 47-page risk management plan as a AUD 200 million new-build defence platform integration. The result is predictable: the small project team drowns in administrative overhead, while the mega-project team treats risk management as a checkbox exercise because the tools feel generic and disconnected from their actual challenges.
The solution is scalable risk management — a framework that calibrates the depth, rigour, and resource intensity of risk management activities to the size, complexity, and strategic importance of each project. This is not about doing less risk management on smaller projects. It is about doing the right amount of risk management on every project, ensuring that effort produces genuine insight rather than bureaucratic waste.
This article examines how scalable risk management works in practice, drawing on the public infrastructure agency three-tiered model — one of the most thoroughly documented scalable PRM implementations in infrastructure project delivery — and translating its principles into the heavy engineering, manufacturing, and defence contexts where your career will operate.
What Scalable Risk Management Actually Means
The Core Principle
Scalable project risk management provides the minimum level of effort appropriate to a particular project depending on its size and complexity. The key word is appropriate — not minimum in the sense of cutting corners, but minimum in the sense of eliminating activities that add overhead without adding insight.
Every project, regardless of size, faces risk. A AUD 500,000 equipment refurbishment and a AUD 500 million warship construction programme both have uncertainties that can affect cost, schedule, scope, and quality objectives. The difference lies in what analytical tools are needed to understand and manage those uncertainties effectively.
The Scalability Spectrum
At one extreme, a simple project needs only a documented list of risks with basic priority ratings and assigned owners. At the other extreme, a mega-project requires full probabilistic modelling using Monte Carlo simulation, schedule risk analysis with specialised software, and dedicated risk management personnel operating continuously throughout the project lifecycle.
Between these extremes lies the critical design decision: where do you draw the boundaries, and what determines which level applies to a given project?
The Three-Tiered Scalability Model
The public infrastructure agency model establishes three distinct levels of risk management effort, primarily determined by total project cost (capital plus support), with provisions for escalation based on complexity factors.
Tier Structure
| Scalability Level | Estimated Total Cost | Risk Management Requirements |
|---|---|---|
| Minor Projects | Less than AUD 1 million | Risk register encouraged (not mandatory) |
| Level 1 | Less than AUD 5 million | Risk register required |
| Level 2 | AUD 5 million to AUD 100 million | Risk register with qualitative analysis |
| Level 3 | Greater than AUD 100 million | Risk register with quantitative analysis |
What Changes Between Levels
The critical insight is that every level performs risk identification, risk response, risk monitoring, and communication. These are non-negotiable regardless of project size. What changes is the depth of risk analysis — the process that sits between identification and response.
| Risk Management Process | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| Risk Identification | Yes | Yes | Yes |
| Qualitative Analysis | Simple Rating (H/M/L) | Probability × Impact Matrix | N/A (superseded by quantitative) |
| Quantitative Analysis | N/A | N/A | Monte Carlo Simulation |
| Risk Response | Yes | Yes | Yes |
| Risk Monitoring | Yes | Yes | Yes |
| Communication | Yes | Yes | Yes |
Escalation Beyond Cost Thresholds
Cost is the primary sorting mechanism, but the model explicitly recognises that other factors may warrant employing a higher scalability level. These factors include:
- Political sensitivity — A relatively small project that attracts ministerial or parliamentary attention may need Level 3 rigour regardless of cost
- Project type — Novel technology integration, even at modest cost, introduces uncertainties that simple ratings cannot capture
- Stakeholder complexity — Multiple agencies, international partners, or contested community interests elevate risk management requirements
- Strategic importance — A project that is critical-path to a larger programme milestone may need quantitative analysis to inform portfolio-level decisions
- Sponsor sensitivity — When the project sponsor has low tolerance for cost or schedule variance, more sophisticated analysis provides the confidence levels needed for informed decision-making
When Level 3 Applies Regardless of Cost
Certain project activities trigger Level 3 analysis irrespective of total cost. These include:
- Validating contingency allowances — When the standard contingency percentage needs justification or adjustment
- Requesting additional contingency above standard thresholds
- Checking remaining contingency adequacy during construction or execution phases
- Requesting supplemental funds — A quantitative risk assessment provides the evidence base for additional funding requests
- Design-build risk allocation — Establishing risk ownership between contracting parties requires probabilistic understanding
- Setting budget or completion targets to a desired confidence level — this is impossible without quantitative analysis
The Project Risk Management Team (PRMT)
Composition and Purpose
The PRMT is the core group responsible for performing, updating, and reviewing all risk management activities. It operates under the direction of the Project Risk Manager (PRM), who has been trained in the processes.
Critically, the PRMT is not identical to the Project Development Team (PDT) or the broader project team. It includes members of the PDT, but not necessarily all members. The PRMT should collectively have all of the expertise required to identify, assess, and respond to risks across every functional area the project touches.
Composition Principles for Heavy Engineering
In a defence or heavy engineering context, the PRMT should draw from:
- Design engineering — understanding technical risks, material uncertainties, and interface challenges
- Construction / manufacturing — understanding execution risks, logistics, and site/shop-floor conditions
- Project management — understanding schedule interdependencies, resource constraints, and contractual obligations
- Functional specialists — environmental, quality, safety, supply chain, and regulatory personnel relevant to the project's risk profile
- External stakeholders (where appropriate) — client representatives, partner organisations, or regulatory bodies
Roles and Responsibilities
| Role | Primary Responsibilities |
|---|---|
| Project Manager | Owns the PRM process from inception to completion; promotes and directs risk management; populates and maintains the risk register; ensures proactive response to all risks; produces risk reports for sponsors; obtains sign-offs at accountability checkpoints |
| Project Risk Manager | Facilitates the PRM process; schedules and conducts risk meetings; ensures risk data quality; tracks response effectiveness; compiles lessons learned. (For Level 1 and 2 projects, the PM generally serves as PRM) |
| Risk Management Coordinator | Provides expertise, direction, and assistance to project managers; obtains expert services as needed; liaises with headquarters/corporate risk management |
| Team Members / Task Managers | Identify and assess risks; develop responses; document response actions; communicate new risks and risk retirements to the PM |
Implementing Scalable PRM: The Planning Phase
Creating the Risk Management Plan
A written Risk Management Plan (RMP) is not required for every project. Whether one is needed depends on project size, complexity, and the amount of risk management effort required. The project manager and the team decide whether a formal RMP is necessary.
When produced, the RMP defines:
- The scalability level at which risk management will be performed
- The frequency of risk management meetings and register updates
- The membership of the PRMT by discipline
- The budget for risk management activities
- The communication and accountability checkpoints applicable to the project
First Steps Checklist
The planning phase follows a structured sequence:
- Determine the scalability level for the project based on cost and complexity factors
- Obtain the risk register template for the assigned level
- Determine meeting frequency and applicable communication/accountability checkpoints
- Assemble the PRMT — identify who brings the expertise needed
- Budget for PRM activities — if significant effort or external consultants will be involved, include cost estimates in work plans
- Obtain approvals for the RMP if applicable
The First PRMT Meeting
The inaugural meeting sets the tone for the entire risk management effort. The project manager should brief the team on:
- The importance and objectives of the PRM process
- The process itself and how it integrates with project delivery
- Roles and responsibilities
- The risk register structure and how it will be maintained
- Communication and accountability checkpoints
- Risk management activities in the project schedule
- The expectation that risk will be managed, documented, and reported
At this first meeting, the team begins eliciting risks. For Level 2 projects, the team should also establish the impact and probability definitions so that everyone applies consistent interpretations to the rating scales.
Scalability in Defence and Heavy Engineering Contexts
Translating the Model
The public infrastructure agency model was designed for transportation infrastructure, but its principles translate directly to defence and heavy engineering. Consider how the three tiers map to typical defence programme structures:
| a public infrastructure agency Level | Defence/Heavy Engineering Equivalent | Example Projects |
|---|---|---|
| Level 1 (< AUD 5M) | Minor modifications, sustainment tasks, component upgrades | Radar software patch deployment; workshop tooling upgrade; hull coating maintenance |
| Level 2 (AUD 5–100M) | Work packages within major programmes, mid-scale procurements | Propulsion system integration; combat system testing phase; facility construction |
| Level 3 (> AUD 100M) | Major platform programmes, fleet-wide capability upgrades | New frigate build programme; armoured vehicle fleet acquisition; submarine life-of-type extension |
The Scalability Decision in Practice
In a defence contracting environment, the scalability decision often involves additional considerations beyond cost:
- Classification and security — Classified projects may need more rigorous documentation and communication controls around risk information
- Multi-nation partnerships — International programmes (e.g., a multinational defence partnership, multinational security partnerships collaborations) introduce political and coordination risks that elevate analytical requirements
- Regulatory and certification requirements — Projects subject to airworthiness, seaworthiness, or nuclear safety certification carry inherent complexity that may warrant Level 3 treatment regardless of cost
- Contractual risk allocation — Design-build, alliance, or incentive-based contracts require quantitative analysis to establish equitable risk-sharing arrangements
Common Pitfalls in Scalable PRM
Over-Scaling
The most common failure mode is applying Level 3 rigour to Level 1 projects. The result is a risk management process that consumes disproportionate resources, produces analysis that exceeds the team's ability to interpret or act on, and generates cynicism about the value of risk management.
The Fix: Resist the temptation to demonstrate sophistication through complexity. A well-maintained risk register with honest High/Medium/Low ratings, clear ownership, and active response tracking delivers more value on a small project than an elaborate Monte Carlo model that sits on a shelf.
Under-Scaling
Equally dangerous is treating a genuinely complex project with Level 1 simplicity. Simple ratings cannot capture the portfolio-level interactions, probabilistic dependencies, and confidence-level requirements that inform major investment decisions.
The Fix: Use the escalation factors explicitly. When a project has novel technology, political sensitivity, multiple stakeholders, or strategic importance beyond its dollar value, escalate the risk management level proactively.
The "Stovepipe" Problem
When functional units perform risk management in isolation, the project-level view fragments. Design engineers identify design risks, construction teams identify construction risks, and nobody examines the interfaces between them — which is precisely where the most dangerous risks reside.
The Fix: The PRMT structure explicitly bridges functional boundaries. Risk meetings must include representation from all disciplines, and risks must be discussed in the team setting where cross-functional impacts become visible.
Discontinuity at Phase Transitions
Risk management frequently breaks down when a project transitions from design to construction, from development to production, or from acquisition to sustainment. The risk register goes stale, new team members are unfamiliar with previously identified risks, and institutional knowledge evaporates.
The Fix: The PRMT is expected to stay together to manage risks until project completion. Communication checkpoints at phase boundaries ensure that the receiving team explicitly reviews, accepts, and commits to managing the inherited risk profile.
Key Takeaways
- Scalable risk management calibrates effort to project needs — not every project requires Monte Carlo simulation, but every project requires a risk register with active ownership and response tracking
- The three-tiered model uses cost as the primary sorting mechanism, with explicit escalation factors for complexity, political sensitivity, stakeholder density, and strategic importance
- All levels perform identification, response, monitoring, and communication — what changes between levels is the depth of risk analysis
- The PRMT is a cross-functional team that brings collective expertise to risk identification and assessment, preventing the stovepipe failures that plague siloed organisations
- Phase transitions are vulnerability points — the PRMT must persist across phase boundaries, and communication checkpoints ensure explicit handoff of the risk profile
- The ultimate aim is to manage risk, not simply to analyse it — every analytical step must lead to actionable responses, or the process is incomplete