Why Planning How to Manage Risk Comes Before Managing Risk
There is a crucial distinction that many project managers miss: Plan Risk Management is not about identifying project risks. It is about deciding how the team will approach risk management on this specific project. Before a single risk is documented, before any probability-impact matrix is populated, the project team must establish the methodology, roles, budget, timing, categories, definitions, and reporting formats that will govern the entire risk management effort.
Think of it this way: you would not begin machining a precision component without first selecting the right tooling, fixturing, speeds, feeds, and inspection criteria. Plan Risk Management is the equivalent of that setup process — it ensures that when you begin the actual work of identifying and analysing risks, every member of the team is using the same methods, speaking the same language, and working toward the same standards.
This proportionality principle is critical. A six-month internal process improvement project does not need the same depth of risk analysis as a multi-billion-dollar naval frigate programme. The Plan Risk Management process establishes the appropriate level of rigour for the project at hand.
What Is the corresponding activity in the earlier process model — Plan Risk Management?
Plan Risk Management is the process of creating the Risk Management Plan — a subsidiary component of the overall Project Management Plan that describes how risk management activities will be structured and performed throughout the project.
The process follows the standard PMBOK® Inputs → Tools & Techniques → Outputs structure:
| Inputs | Tools & Techniques | Outputs |
|---|---|---|
| Project Management Plan | Analytical Techniques | Risk Management Plan |
| Project Charter | Expert Judgment | |
| Stakeholder Register | Meetings | |
| Enterprise Environmental Factors | ||
| Organisational Process Assets |
How It Works: Inputs to Plan Risk Management
Project Management Plan
All approved subsidiary management plans and baselines must be reviewed to ensure the risk management plan is consistent with them. Four subsidiary plans are particularly relevant:
The Scope Statement defines the project boundaries and directly determines the type and volume of risks likely to be encountered. In a defence context, a scope statement for a vehicle armour upgrade programme immediately flags risks around ballistic certification testing, material supply chains, and integration with existing platform systems. The Cost Management Plan defines how risk-related budgets, contingencies, and management reserves will be reported and accessed. If the cost management plan requires Earned Value Management (EVM) reporting, the risk management plan must align with those reporting cycles. The Schedule Management Plan includes activity timing, internal and external constraints, and dependencies — all of which help identify risk areas. A compressed schedule with multiple parallel work streams inherently carries more schedule risk than a sequential approach with built-in float. The Communications Management Plan identifies key stakeholders and their specific risk concerns, governing how risk information should be communicated. In defence programmes, this often includes classified risk information that requires special handling under security protocols.
Project Charter
The charter provides high-level risks, project descriptions, and requirements that were identified during project initiation. These early risk indicators set the initial context for the risk management planning effort.
Stakeholder Register
This lists and classifies all project stakeholders. Understanding which stakeholders are risk-averse versus risk-tolerant — and which risks concern them most — is essential for calibrating the risk management approach. A public-sector acquisition authority will have very different risk concerns than a subcontractor's production manager.
Enterprise Environmental Factors
These include the legal and regulatory frameworks governing the project, industry norms toward risk, and the performing organisation's appetite for risk. In national defence contracting, factors such as the applicable defence-industry security programme (the applicable security programme), Work Health and Safety Act obligations, and ITAR/EAR compliance requirements all constitute enterprise environmental factors that shape risk management planning.
Organisational Process Assets
These include risk categories from previous projects, common definitions, risk statement templates, standard roles and responsibilities, authority levels for decision-making, and lessons learned — all of which provide a foundation for the current project's risk management approach rather than starting from scratch.
How It Works: Tools and Techniques
Analytical Techniques
These are used to understand and define the overall risk management context of the project. This involves analysing the combination of stakeholder risk attitudes and the strategic risk exposure of the current project. The result is a calibrated understanding of how aggressively or conservatively the project should approach risk management.
In practice, this often involves stakeholder risk profiling workshops where key decision-makers articulate their tolerance thresholds for schedule, cost, and performance risks. A Tier-1 defence prime bidding on a fixed-price development contract has fundamentally different strategic risk exposure than the same company executing a cost-plus support contract.
Expert Judgment
Expertise is drawn from subject matter experts, project stakeholders, senior management, and lessons learned from previous projects. In defence and heavy engineering, this often includes retired programme managers, test and evaluation specialists, and supply chain experts who have direct experience with the risk landscape of similar platforms and systems.
Meetings
Risk management planning meetings bring together the project manager, project sponsor, selected team members, key stakeholders, and anyone with risk management responsibilities. The quality of these meetings — their preparation, facilitation, and decision-making processes — has a disproportionate impact on the effectiveness of the entire risk management effort.
In defence programmes, these planning meetings often include representatives from the customer (e.g., the customer acquisition authority in Australia, the customer acquisition authority in the UK), prime contractor, key subcontractors, and independent verification and validation (IV&V) agencies — each bringing different risk perspectives and tolerance levels that must be reconciled.
How It Works: The Output — The Risk Management Plan
The Risk Management Plan is the sole output of this process, and it is arguably the most important risk document produced during the entire project. It does not list specific risks — that comes in the corresponding activity in the earlier process model (Identify Risks). Instead, it establishes the framework within which all subsequent risk management activities will operate.
The plan contains the following ten elements:
1. Methodology
Defines the approaches, tools, and data sources that will be used for risk management on the project. This might specify whether the team will use qualitative analysis only, or also employ quantitative techniques such as Monte Carlo simulation. For a small defence maintenance project, qualitative methods using a 5×5 probability-impact matrix may suffice. For a major platform acquisition, the methodology section would mandate quantitative schedule risk analysis (SRA) and cost risk analysis (CRA) using tools like simulation software or schedule-risk software.
2. Roles and Responsibilities
Specifies who is responsible for each type of risk management activity and clarifies their authority and accountability. This includes identifying the risk owner role (the person accountable for monitoring and responding to each specific risk) and the risk manager role (the person overseeing the overall risk management process).
3. Budgeting
Assigns resources for risk management activities, estimates the funds needed, and establishes how contingency funding will be accessed if risks materialise. This section must address both the cost of performing risk management (staff time, tools, meetings) and the cost of managing realised risks (contingency and management reserves).
4. Timing
Defines when and how often the risk management process will be performed throughout the project lifecycle. In defence programmes with multi-year timelines, this typically specifies monthly risk reviews at the working level, quarterly risk reviews at the programme level, and risk deep-dives aligned with major milestone reviews (PDR, CDR, TRR, etc.).
5. Risk Categories
The Risk Breakdown Structure (RBS) provides a hierarchically organised depiction of identified project risks arranged by risk category and subcategory. It ensures a comprehensive process of systematically identifying risks to a consistent level of detail. An organisation can use a previously prepared categorisation framework, which might take the form of a simple list of categories or a structured RBS like the one shown above.
In defence and heavy engineering, typical top-level RBS categories include: Technical, Programmatic, Supply Chain, Regulatory/Compliance, Commercial, and External/Environmental. Each category is then decomposed into subcategories that reflect the specific risk landscape of the project.
6. Definitions of Risk Probability and Impact
This section ensures that all stakeholders share a common understanding of what probability and impact ratings actually mean in practical terms. Without explicit definitions, one team member's "high probability" is another's "medium" — rendering the entire qualitative assessment meaningless.
The definitions must be project-specific. Below is an example of impact scale definitions for a defence manufacturing project:
| Impact Level | Schedule | Cost | Scope | Quality |
|---|---|---|---|---|
| Negligible (<5%) | No effect | <1% budget increase | Minimal scope reduction | Very minor deficiencies |
| Minor (10%) | Trivial delay | <8% budget increase | Minor areas affected | Minimal quality impact |
| Moderate (20%) | <8% schedule increase | 15–20% budget increase | Major areas affected | Specific quality impacts requiring sponsor review |
| Significant (40%) | 15% schedule increase | 40–50% budget increase | Scope unacceptable to sponsor | Quality requires sponsor approval |
| Severe (60%+) | 25%+ schedule increase | 55%+ budget increase | Project abandoned | Sponsor rejection; project terminated |
7. Probability and Impact Matrix
The P&I Matrix is the tool used to prioritise risks according to their potential implications for project objectives. It maps combinations of probability and impact to risk ratings (e.g., Extreme, High, Moderate, Low, Minimal), which in turn drive the type and urgency of management response.
| Impact → | Negligible (1) | Minor (2) | Moderate (3) | Significant (4) | Severe (5) |
|---|---|---|---|---|---|
| >81% | Low | Moderate | High | Extreme | Extreme |
| 61–80% | Minimal | Low | Moderate | High | Extreme |
| 41–60% | Minimal | Low | Moderate | High | High |
| 21–40% | Minimal | Low | Low | Moderate | High |
| <20% | Minimal | Minimal | Low | Moderate | High |
The specific thresholds and colour-coding within this matrix are set by the organisation, not by the PMBOK® Guide. This means they must be established and agreed upon during the Plan Risk Management process, before any risk assessment begins.
8. Revised Stakeholder Risk Tolerances
If the planning process reveals a need to revise stakeholder risk tolerance levels — for example, if the project sponsor's stated tolerance for schedule risk is inconsistent with the contracted delivery milestones — those revisions are documented here.
9. Reporting Formats
Describes how risk management outcomes will be documented, analysed, and communicated. This includes the content and format of the risk register, risk reports for governance boards, and any specialised reporting requirements (e.g., the responsible acquisition authority risk reporting templates, allied technical-agreement risk reporting formats).
10. Tracking
Describes how risk activities will be recorded for the benefit of the current project and future projects, including whether and how risk management processes will be audited. This section captures the lessons-learned mechanism and feeds into the organisation's process assets for future programmes.
Defence Application: Scaling the Risk Management Plan
The proportionality principle means the Risk Management Plan must be scaled to match the project's complexity, value, and strategic importance:
| Project Type | Risk Management Approach |
|---|---|
| Minor maintenance project (e.g., workshop tooling upgrade) | Qualitative analysis only; 3×3 P&I matrix; risk register in spreadsheet; monthly reviews by project lead |
| Medium engineering project (e.g., vehicle subsystem integration) | Qualitative + selective quantitative analysis; 5×5 P&I matrix; formal risk register; bi-weekly risk reviews; dedicated risk coordinator |
| Major defence acquisition (e.g., new combat vehicle platform) | Full quantitative schedule and cost risk analysis (Monte Carlo); comprehensive RBS; dedicated risk manager; weekly risk working groups; quarterly risk boards; integrated with Earned Value Management |
The Risk Management Plan for a multi-billion-dollar defence programme will be a substantial document in its own right. The plan for a small internal improvement project might be a single page within the Project Management Plan. Both are correct, provided they are commensurate with the risks and importance of the project.
Common Pitfalls
Skipping this process entirely. Many project teams jump straight to identifying risks without first establishing the framework. The result is inconsistent assessments, unclear ownership, and risk registers that nobody trusts or uses. Adopting a one-size-fits-all template. Using the same risk management plan template for every project, regardless of size and complexity, either over-burdens small projects with unnecessary bureaucracy or under-equips large projects with inadequate rigour. Failing to define probability and impact scales. Without explicit, project-specific definitions, qualitative risk assessments become subjective opinions that cannot be meaningfully compared or aggregated. Ignoring the budget for risk management. If risk management activities are not explicitly resourced in the project plan, they will be deprioritised when schedule or cost pressures emerge. Not engaging stakeholders in the planning process. Risk tolerances and communication preferences vary significantly across stakeholders. A Risk Management Plan developed without stakeholder input will inevitably misalign with their expectations.
Key Takeaways
Plan Risk Management (11.1) is about establishing the approach, not identifying specific risks — it creates the framework that governs all subsequent risk management activities.
The sole output is the Risk Management Plan, which contains ten elements: methodology, roles and responsibilities, budgeting, timing, risk categories, probability and impact definitions, the P&I matrix, revised stakeholder tolerances, reporting formats, and tracking.
The Risk Breakdown Structure (RBS) provides a hierarchical categorisation framework that ensures systematic and consistent risk identification.
Probability and impact definitions must be explicit and project-specific — without them, qualitative assessments are meaningless subjective opinions.
The plan must be proportionate to the project's complexity, value, and strategic importance — neither over-engineering the process for small projects nor under-resourcing it for major programmes.