Project Risk Management | Probability & Impact Matrix
Project risk management uses probability x impact scoring to prioritize threats. GitScrum tracks risk registers and supports mitigation planning.
7 min read
Every project has risks—things that might go wrong. The best teams don't ignore risks; they identify them early, assess their impact, and plan mitigations. Proactive risk management prevents surprises and keeps projects on track.
Risk Categories
| Category | Examples | Mitigation Focus |
|---|---|---|
| Technical | Unknown tech, integration | Spikes, prototypes |
| Resource | Key person leaves, capacity | Cross-training, buffer |
| External | Vendor delays, API changes | Contracts, alternatives |
| Scope | Requirements change | Clear process, buffer |
| Timeline | Deadline pressure | Realistic estimates |
Risk Identification
Finding Risks
RISK IDENTIFICATION PROCESS
═══════════════════════════
TEAM BRAINSTORM:
─────────────────────────────────────
In planning session, ask:
├── "What could go wrong?"
├── "What are we uncertain about?"
├── "What did we struggle with before?"
├── "What depends on others?"
├── "What's new to us?"
└── Everyone contributes
CATEGORIES TO EXPLORE:
─────────────────────────────────────
Technical:
├── Unknown technologies
├── Integration complexity
├── Performance concerns
├── Security requirements
├── Scale challenges
└── "Will this work?"
People:
├── Key person availability
├── Skill gaps
├── Team capacity
├── Stakeholder availability
├── Cross-team dependencies
└── "Do we have the right people?"
External:
├── Third-party vendors
├── API dependencies
├── Regulatory requirements
├── Market timing
├── Customer availability
└── "What's out of our control?"
Scope:
├── Unclear requirements
├── Scope creep likelihood
├── Stakeholder changes
├── Competing priorities
└── "Will scope stay stable?"
DOCUMENT EACH RISK:
─────────────────────────────────────
Risk: [Description]
Category: [Technical/People/External/Scope]
Probability: [High/Medium/Low]
Impact: [High/Medium/Low]
Mitigation: [Action to reduce risk]
Owner: [Who monitors this]
Status: [Open/Mitigating/Closed]
Risk Assessment
Probability × Impact
RISK MATRIX
═══════════
IMPACT
Low Medium High
┌────────┬────────┬────────┐
High │ Medium │ High │Critical│
├────────┼────────┼────────┤ P
Med │ Low │ Medium │ High │ R
├────────┼────────┼────────┤ O
Low │Accept │ Low │ Medium │ B
└────────┴────────┴────────┘
PRIORITY BASED ON SCORE:
─────────────────────────────────────
Critical: Immediate mitigation required
High: Mitigation plan, active monitoring
Medium: Mitigation plan, regular review
Low: Accept, periodic check
Accept: Note but don't actively manage
EXAMPLE ASSESSMENT:
─────────────────────────────────────
Risk Prob Impact Score
────────────────────────────────────────────────
API provider changes terms Med High HIGH
Key developer leaves Low High MEDIUM
Requirements unclear High Med HIGH
Performance issues Med Med MEDIUM
Bug in new feature High Low MEDIUM
Focus on: API and Requirements (HIGH)
Plan for: Others (MEDIUM)
Mitigation Strategies
Response Types
RISK RESPONSE STRATEGIES
════════════════════════
AVOID:
─────────────────────────────────────
Eliminate the risk entirely.
Example:
Risk: "New database might not scale"
Avoid: Use proven database we know scales
When: Possible and practical
MITIGATE:
─────────────────────────────────────
Reduce probability or impact.
Example:
Risk: "Key developer might leave"
Mitigate: Cross-train team, document knowledge
When: Can't avoid but can reduce
TRANSFER:
─────────────────────────────────────
Shift risk to another party.
Example:
Risk: "Infrastructure might fail"
Transfer: Use cloud provider with SLA
When: Someone else can manage better
ACCEPT:
─────────────────────────────────────
Acknowledge and proceed.
Example:
Risk: "Minor UI bug might occur"
Accept: Will fix if happens, not worth preventing
When: Low impact, high cost to mitigate
CONTINGENCY:
─────────────────────────────────────
Plan for if risk occurs.
Example:
Risk: "Vendor might be late"
Contingency: Backup vendor identified,
can switch within 2 weeks
When: Can't prevent, can respond
Mitigation Plans
MITIGATION PLANNING
═══════════════════
EXAMPLE RISK:
─────────────────────────────────────
Risk: Payment API integration might fail
ANALYSIS:
├── Probability: Medium
├── Impact: High (release blocked)
├── Score: HIGH
└── Must mitigate
MITIGATION ACTIONS:
─────────────────────────────────────
1. Spike first (Week 1)
├── Prototype integration
├── Validate API works as documented
├── Identify issues early
└── Owner: Senior dev
2. Backup provider (Week 2)
├── Research alternative
├── Have second option ready
└── Owner: Tech lead
3. Communication plan
├── Weekly updates on integration
├── Early warning if issues
└── Owner: PM
MONITORING:
─────────────────────────────────────
├── Weekly risk review
├── Update probability based on progress
├── Escalate if probability increases
└── Close when integration complete
Risk Tracking
Risk Register
RISK REGISTER
═════════════
Maintain list of all risks:
┌─────────────────────────────────────────────────────────────┐
│ Project Risks - Release 2.0 │
├─────────────────────────────────────────────────────────────┤
│ ID Risk Prob Impact Status Owner │
│ ────────────────────────────────────────────────────────── │
│ R-1 API integration Med High Mitigating Alex │
│ R-2 Key person leave Low High Monitor Lead │
│ R-3 Scope creep High Med Mitigating PM │
│ R-4 Performance Med Med Monitor Dev │
│ R-5 Security audit Med High Mitigating Sec │
│ │
│ Last updated: 2024-02-15 │
│ Next review: Sprint planning │
└─────────────────────────────────────────────────────────────┘
REGULAR REVIEW:
─────────────────────────────────────
Sprint planning:
├── Review all open risks
├── Update status
├── Add new risks discovered
├── Close resolved risks
├── Adjust probability based on new info
└── 10-15 minutes
Risk changes:
├── New risk identified → Add
├── Risk occurred → Move to Issue
├── Risk resolved → Close
├── Probability changed → Update
└── Keep current
Risk Communication
Stakeholder Updates
RISK COMMUNICATION
══════════════════
IN PROJECT UPDATES:
─────────────────────────────────────
Include risk section:
"Current Risks:
🔴 HIGH: API integration complexity
Status: Spike in progress
Mitigation: Backup provider identified
🟡 MEDIUM: Timeline pressure from scope add
Status: Trade-off discussion scheduled
Mitigation: Identifying scope to remove
🟢 LOW: Minor bugs expected
Status: Accepted
No new risks this week.
R-4 closed (performance validated)."
ESCALATION:
─────────────────────────────────────
When risk becomes issue:
├── Immediate notification
├── Impact assessment
├── Response plan
├── Timeline update if needed
└── Don't hide bad news
Stakeholders prefer:
├── Early warning
├── Clear impact
├── Action plan
├── Not surprises
└── Trust through transparency
GitScrum Risk Tracking
Risk Features
GITSCRUM FOR RISKS
══════════════════
TRACKING RISKS:
─────────────────────────────────────
Create task type: Risk
├── Custom fields for probability, impact
├── Status workflow: Open → Mitigating → Closed
├── Assign owner
├── Link to related tasks
└── Risk management in same tool
RISK DASHBOARD:
─────────────────────────────────────
Dashboard widget:
├── Open risks by severity
├── Risk trend (new/closed)
├── Risks requiring attention
├── Overdue mitigation actions
└── Visibility
LINKING TO WORK:
─────────────────────────────────────
Risk: API integration
├── Links to: Integration tasks
├── Blocks: Frontend work (potentially)
├── Mitigation task: Spike
└── Connected context
AUTOMATION:
─────────────────────────────────────
├── Alert when high risk added
├── Reminder for risk review
├── Overdue mitigation notification
└── Keep risks visible
Best Practices
For Risk Management
Anti-Patterns
RISK MANAGEMENT MISTAKES:
✗ Ignoring risks
✗ No mitigation plans
✗ Never updating risk status
✗ Hiding risks from stakeholders
✗ Only project manager thinks about risks
✗ No regular review
✗ Over-documenting (analysis paralysis)
✗ Under-documenting (nothing tracked)