Project Risk Management | Identification & Mitigation
Identify project risks early, assess probability and impact, create mitigation plans. GitScrum tracks risk registers with status monitoring and ownership.
8 min read
Every project has risks—unknowns that could derail delivery. The difference between successful projects and failures often comes down to how risks are managed. Proactive risk management means identifying early, assessing honestly, and mitigating systematically.
Risk Management Framework
| Phase | Activity | Output |
|---|---|---|
| Identify | Find potential problems | Risk list |
| Assess | Evaluate probability × impact | Prioritized risks |
| Plan | Create mitigation strategies | Response plans |
| Monitor | Track and update | Current status |
| Respond | Execute when triggered | Resolved or escalated |
Risk Identification
Common Project Risks
RISK CATEGORIES
═══════════════
TECHNICAL RISKS:
─────────────────────────────────────
├── New technology (learning curve)
├── Integration complexity
├── Performance unknowns
├── Security vulnerabilities
├── Technical debt impact
└── Architecture decisions
RESOURCE RISKS:
─────────────────────────────────────
├── Key person leaves
├── Skill gaps
├── Team availability
├── Competing priorities
├── Contractor dependency
└── Budget constraints
SCHEDULE RISKS:
─────────────────────────────────────
├── Unrealistic timeline
├── Scope creep
├── Dependencies on other teams
├── Approval delays
├── Testing time underestimated
└── Requirements changes
EXTERNAL RISKS:
─────────────────────────────────────
├── Third-party service reliability
├── Vendor delivery
├── Regulatory changes
├── Market changes
├── Customer availability
└── External API stability
Risk Identification Techniques
RISK DISCOVERY METHODS
══════════════════════
1. TEAM BRAINSTORMING:
─────────────────────────────────────
Session: "What could go wrong?"
Each person writes 3-5 risks
Discuss and consolidate
Results: 15-20 identified risks
2. HISTORICAL ANALYSIS:
─────────────────────────────────────
Review similar past projects:
├── What problems occurred?
├── What was unexpected?
├── What would you do differently?
└── Apply learnings
3. DEPENDENCY REVIEW:
─────────────────────────────────────
For each dependency:
├── What if it's late?
├── What if it doesn't work?
├── What if person leaves?
└── Identify dependency risks
4. TECHNOLOGY ASSESSMENT:
─────────────────────────────────────
For each tech choice:
├── Is team experienced?
├── Is it proven at scale?
├── What are known issues?
└── Identify tech risks
5. PRE-MORTEM:
─────────────────────────────────────
"Imagine the project failed. Why?"
Team writes failure scenarios
Work backwards to identify risks
Powerful technique for hidden risks
Risk Assessment
Probability × Impact Matrix
RISK ASSESSMENT MATRIX
══════════════════════
│ LOW IMPACT │ MEDIUM IMPACT │ HIGH IMPACT
──────────┼───────────────┼─────────────────┼──────────────
HIGH │ MEDIUM │ HIGH │ CRITICAL
PROB │ Monitor │ Plan mitigation│ Top priority
──────────┼───────────────┼─────────────────┼──────────────
MEDIUM │ LOW │ MEDIUM │ HIGH
PROB │ Accept │ Monitor │ Plan mitigation
──────────┼───────────────┼─────────────────┼──────────────
LOW │ LOW │ LOW │ MEDIUM
PROB │ Accept │ Accept │ Monitor
SCORING:
─────────────────────────────────────
Probability:
├── Low: < 20%
├── Medium: 20-60%
└── High: > 60%
Impact:
├── Low: Minor delay, workaround exists
├── Medium: Significant delay, extra work
└── High: Major delay, potential failure
Risk Score = Probability × Impact
Risk Register
PROJECT RISK REGISTER
═════════════════════
┌─────────────────────────────────────────────────────────────────────────┐
│ ID │ Risk Description │ Prob │ Impact │ Score │ Status │
├─────────────────────────────────────────────────────────────────────────┤
│ R-01 │ Third-party API unstable│ High │ High │ CRIT │ Mitigating │
│ R-02 │ Key dev on vacation │ High │ Medium │ HIGH │ Planned │
│ R-03 │ Performance issues │ Med │ High │ HIGH │ Monitoring │
│ R-04 │ Scope creep │ Med │ Medium │ MED │ Monitoring │
│ R-05 │ Design approval delay │ Low │ High │ MED │ Monitoring │
│ R-06 │ Browser compatibility │ Low │ Medium │ LOW │ Accepted │
└─────────────────────────────────────────────────────────────────────────┘
DETAIL FOR R-01:
─────────────────────────────────────
Risk: Third-party API unstable
Description:
Payment provider API has had 3 outages in last month.
Could impact checkout flow reliability.
Probability: High (60%)
Impact: High (checkout is critical path)
Score: Critical
Mitigation Strategy:
├── Implement caching layer
├── Add retry logic
├── Build fallback payment option
├── Monitor API status page
Owner: Alex
Status: Mitigating (caching in progress)
Next Review: Jan 20
Mitigation Strategies
Response Types
RISK RESPONSE STRATEGIES
════════════════════════
1. AVOID:
─────────────────────────────────────
Eliminate the risk entirely
├── Change approach
├── Remove risky feature
├── Choose different technology
└── Example: "Use proven tech instead of experimental"
2. MITIGATE:
─────────────────────────────────────
Reduce probability or impact
├── Add buffers
├── Build redundancy
├── Cross-train team
└── Example: "Document so others can take over"
3. TRANSFER:
─────────────────────────────────────
Move risk to another party
├── Insurance
├── Contract protection
├── Use managed service
└── Example: "Use vendor's SLA guarantee"
4. ACCEPT:
─────────────────────────────────────
Acknowledge and prepare
├── Low probability/impact
├── Not worth mitigation cost
├── Have contingency plan
└── Example: "Accept and have workaround ready"
Mitigation Plans
MITIGATION PLAN TEMPLATE
════════════════════════
RISK: Key developer leaves project
Probability: Medium (30%)
Impact: High (only person who knows auth system)
Current Status: No mitigation in place ⚠️
MITIGATION ACTIONS:
─────────────────────────────────────
Action 1: Knowledge documentation
├── Owner: Sarah
├── Due: Jan 25
├── Status: In progress
└── Description: Document auth system architecture
Action 2: Cross-training
├── Owner: Sarah + Mike
├── Due: Feb 1
├── Status: Not started
└── Description: Pair program on auth changes
Action 3: Code review policy
├── Owner: Tech Lead
├── Due: Immediate
├── Status: Complete
└── Description: All auth changes reviewed by 2nd dev
POST-MITIGATION:
├── Probability: Medium → Medium (unchanged)
├── Impact: High → Medium (reduced)
├── New Score: Medium (acceptable)
└── Continue monitoring
Monitoring and Review
Risk Review Cadence
RISK MONITORING PROCESS
═══════════════════════
WEEKLY RISK CHECK (5 min in standup):
─────────────────────────────────────
├── Any new risks emerged?
├── Any risks changed status?
├── Any risks need escalation?
└── Quick update to register
BI-WEEKLY RISK REVIEW (30 min):
─────────────────────────────────────
├── Review all active risks
├── Update probability/impact
├── Check mitigation progress
├── Add newly identified risks
├── Close resolved risks
└── Communicate to stakeholders
MILESTONE/PHASE RISK REVIEW (1 hour):
─────────────────────────────────────
├── Comprehensive risk reassessment
├── New phase = new risks
├── Lessons from resolved risks
├── Update risk register fully
└── Report to sponsors
Early Warning Indicators
RISK EARLY WARNING SIGNALS
══════════════════════════
SCHEDULE RISKS:
─────────────────────────────────────
Indicators:
├── Sprint behind by day 5
├── Velocity below 80%
├── Blocked tasks increasing
├── Overtime becoming normal
└── "We'll make it up next sprint"
TECHNICAL RISKS:
─────────────────────────────────────
Indicators:
├── Spike tasks taking longer
├── Bug count increasing
├── Performance tests failing
├── Integration issues appearing
└── "It's more complex than expected"
RESOURCE RISKS:
─────────────────────────────────────
Indicators:
├── Key person frequently absent
├── Morale declining
├── Skill gaps appearing
├── Team conflicts
└── "I'm thinking about other opportunities"
ACTION:
When indicator appears:
├── Update risk probability
├── Trigger mitigation if needed
├── Escalate if critical
└── Don't wait until too late
GitScrum for Risk Management
Risk Tracking Setup
GITSCRUM RISK MANAGEMENT
════════════════════════
APPROACH 1: Labels on Tasks
─────────────────────────────────────
For risks tied to specific work:
├── Label: "risk-high" (red)
├── Label: "risk-medium" (yellow)
├── Label: "risk-low" (green)
└── Filter by label to see all risks
APPROACH 2: Risk Project/Board
─────────────────────────────────────
Separate board for risks:
Columns:
├── Identified: New risks
├── Assessing: Being evaluated
├── Mitigating: Actions in progress
├── Monitoring: Watching
├── Closed: Resolved/accepted
└── Triggered: Became issue
APPROACH 3: NoteVault Risk Register
─────────────────────────────────────
Document-based register:
├── Table format
├── Full details
├── History tracking
├── Link to related tasks
└── Shareable with stakeholders
Best Practices
For Risk Management
Anti-Patterns
RISK MANAGEMENT MISTAKES:
✗ Ignoring risks ("it'll be fine")
✗ Risk register but never reviewed
✗ Mitigation plans but no action
✗ Only PM knows the risks
✗ Adding risks after they become issues
✗ Overconfidence ("we're different")
✗ No contingency for accepted risks
✗ Not updating as project progresses