Risk Register Manager

Purpose

Systematically identify, assess, and manage project risks using a structured register with probability/impact scoring and defined response strategies.

When to use

• project kick-off to establish the initial risk baseline
• sprint or milestone reviews to update and add emerging risks
• before major decisions to assess risk exposure
• when stakeholders request a risk assessment report

When not to use

• live incident response or post-mortem analysis
• security vulnerability scanning (use security tools)
• personal task risk assessment

Inputs

• project scope, objectives, and constraints
• project type (predictive / adaptive / hybrid)
• stakeholder list and their risk tolerance
• known assumptions and dependencies
• lessons learned from similar projects (if available)

Procedure

1. Identify risks using multiple sources:
   • Internal: technical complexity, resource gaps, schedule pressure, budget
   • External: market shifts, regulatory changes, vendor reliability, geopolitical
   • PMBOK 8 emphasis: sustainability risks (ESG, climate, social impact)
   • Techniques: brainstorming, PESTLE analysis, Risk Breakdown Structure (RBS)
2. Assess each risk qualitatively:
   • Probability: Very Low (0.1) / Low (0.3) / Medium (0.5) / High (0.7) / Very High (0.9)
   • Impact: Very Low (0.05) / Low (0.1) / Medium (0.2) / High (0.4) / Very High (0.8)
   • Risk Score = Probability × Impact
   • Red zone (≥ 0.25): immediate response required
   • Yellow zone: response plan needed
   • Green zone: monitor only
3. Define response strategy:
   • For threats: Avoid / Transfer / Mitigate / Accept (active or passive)
   • For opportunities: Exploit / Share / Enhance / Accept
4. Assign ownership — every risk has one named owner.
5. Track residual risk — after response, re-score to verify reduction.
6. SAFe integration — for SAFe teams, use ROAM board:
   • R = Resolved | O = Owned | A = Accepted | M = Mitigated

Output

• risk register table: ID | Category | Description | Trigger | Probability | Impact | Score | Owner | Response Strategy | Residual Risk | Status
• risk heat map summary (red/yellow/green distribution)
• top 10 risks with detailed response plans
• escalation list for sponsor or steering committee
• risk trend over time (risk burn-down if tracked across sprints)

Definition of done

• every identified risk has a probability, impact, and score
• every red/yellow risk has a named owner and defined response strategy
• residual risk is assessed for all mitigated risks
• register is reviewable by stakeholders

Examples

• "Build an initial risk register for a 6-month ERP migration project."
• "Update the risk register after Sprint 5 — add 3 new risks we discovered."
• "We have 15 risks but no response plans. Help me define strategies for the top 10."

Quality Criteria

• All dependencies and prerequisites are documented
• Changes are reversible or include a rollback plan
• Security implications are assessed for each configuration change
• Monitoring and alerting are defined for post-deployment validation

Verification (4C)

Check	Question
Correctness	Are all configurations, permissions, and dependencies accurate?
Completeness	Does the setup cover dev, staging, and prod environments as needed?
Context-fit	Is the solution proportional to the problem (not over/under-engineered)?
Consequence	If deployed as-is to production, what is the highest-risk failure mode?

Edge Cases

• Target environment has pre-existing configuration — Scan for conflicts before applying changes. Document what to preserve.
• Permissions differ between environments — Test in staging first. Document the minimum permissions required.
• Third-party service is unavailable or deprecated — Document fallback or alternative. Include health-check endpoints.

Changelog

• v1.0.0 — Initial release