Project Risk Management — Beyond the RAID Log
A RAID log is necessary but not sufficient. Effective risk management requires proactive identification, quantified assessment, active mitigation, and a culture where raising risks is rewarded — not punished.
The RAID Log Is Just the Beginning
Most project managers maintain a RAID log — a register of Risks, Assumptions, Issues, and Dependencies. It's a good start. But a RAID log alone is passive documentation. Effective risk management is an active discipline that:
- Identifies risks before they materialise (not just logs them when they appear)
- Quantifies impact so risks can be prioritised objectively (not by gut feel)
- Assigns mitigation actions with owners and deadlines (not just "monitor")
- Reviews and updates regularly (not just at project initiation)
- Creates a culture where raising risks early is rewarded (not seen as negativity)
Risk Identification Techniques
Pre-Mortem Analysis
Before the project starts, imagine it has failed. Ask the team: "It's 6 months from now and this project has been cancelled. What went wrong?" This surfaces risks that optimism bias normally hides.
Run a 60-minute workshop: 1. Set the scene: "The project failed. What happened?" (10 min brainstorm) 2. Cluster similar risks into themes (10 min) 3. For each theme, identify specific risk events (20 min) 4. Assess likelihood and impact for each (15 min) 5. Assign owners for the top 5 risks (5 min)
Risk Taxonomy Checklist
Use a structured checklist to ensure you haven't missed common risk categories:
- Technical: Technology maturity, integration complexity, performance requirements, security vulnerabilities
- Resource: Key person dependency, skill gaps, availability conflicts, vendor reliability
- Schedule: Dependencies on other projects, regulatory deadlines, seasonal constraints
- Scope: Requirements volatility, stakeholder alignment, acceptance criteria clarity
- External: Market changes, regulatory changes, vendor stability, economic conditions
- Organisational: Sponsor commitment, change fatigue, competing priorities, political dynamics
Assumption Testing
Every assumption is a risk in disguise. For each assumption in your RAID log, ask:
- "What if this assumption is wrong?"
- "How would we know it's wrong?"
- "What's the impact if it's wrong?"
- "When will we know for certain?"
Convert high-impact assumptions into risks with explicit validation dates.
Risk Assessment
Probability × Impact Matrix
Score each risk on two dimensions:
Probability (1-5): 1. Very unlikely (<10%) 2. Unlikely (10-25%) 3. Possible (25-50%) 4. Likely (50-75%) 5. Very likely (>75%)
Impact (1-5): 1. Negligible (< 1 week delay or < 5% budget) 2. Minor (1-2 week delay or 5-10% budget) 3. Moderate (2-4 week delay or 10-20% budget) 4. Major (1-3 month delay or 20-40% budget) 5. Critical (> 3 month delay or > 40% budget, or project cancellation)
Risk Score = Probability × Impact
- Score 1-6: Low risk (monitor)
- Score 7-12: Medium risk (mitigate)
- Score 13-19: High risk (active management required)
- Score 20-25: Critical risk (escalate to steering committee)
Expected Monetary Value (EMV)
For budget-sensitive projects, quantify risk in financial terms:
EMV = Probability × Financial Impact
Example: 30% chance of a vendor delay costing £50K in additional resources. EMV = 0.3 × £50K = £15K. This £15K should be included in your contingency reserve.
Sum all risk EMVs to determine the appropriate contingency budget.
Risk Response Strategies
For each significant risk, choose a response strategy:
Avoid: Change the plan to eliminate the risk entirely. Example: use a proven technology instead of an unproven one.
Mitigate: Reduce the probability or impact. Example: add automated testing to reduce the risk of escaped defects.
Transfer: Shift the risk to a third party. Example: use a fixed-price vendor contract to transfer cost overrun risk.
Accept: Acknowledge the risk and prepare a contingency plan if it materialises. Example: accept the risk of a key person leaving and document their knowledge as mitigation.
Escalate: The risk is beyond the project's control. Escalate to programme or portfolio level for resolution.
Active Risk Management Cadence
Weekly Risk Review (15 min in project status meeting)
- Review top 5 risks: has probability or impact changed?
- Check mitigation action progress: are owners delivering on time?
- Identify new risks from the past week's work
- Close risks that are no longer relevant
- Escalate any risk that has moved to Critical
Monthly Risk Workshop (60 min)
- Full RAID register review
- Re-score all open risks with current information
- Test assumptions: which are due for validation this month?
- Identify emerging risks from project progress and external changes
- Update contingency plans for top risks
Phase Gate Risk Assessment
At each project phase gate, conduct a formal risk assessment:
- Are the risks from the previous phase resolved or mitigated?
- What new risks does the next phase introduce?
- Is the contingency reserve still adequate?
- Should the project proceed, pause, or stop based on the risk profile?
Building a Risk-Aware Culture
The biggest risk management failure is cultural: teams that hide risks because raising them is seen as negativity or incompetence.
Create safety around risk reporting:
- Thank people who raise risks early: "Good catch — better to know now"
- Never blame the messenger
- Celebrate risks that were identified and mitigated before they materialised
- Share risk management successes in steering committees
Make risk visible:
- Display the top 5 risks on the project board (not buried in a spreadsheet)
- Start every status meeting with "any new risks this week?"
- Include risk status in every stakeholder update
Measuring Risk Management Effectiveness
- Risk identification rate: New risks identified per month (should be higher early in the project, decreasing over time)
- Mitigation completion rate: % of mitigation actions completed on time. Target: >80%
- Risk materialisation rate: % of identified risks that actually occur. If very low, you may be over-identifying. If high, your assessment is accurate.
- Surprise rate: Issues that occur without being previously identified as risks. Target: <10% of all issues. High surprise rate = poor identification.
- Contingency utilisation: % of contingency budget used. If 0%, you over-estimated. If 100%, you under-estimated.
---
Download the [Programme RAID Register template](/templates) for a comprehensive risk, assumption, issue, and dependency tracking format.