Back to ER Diagram
Risk Management

Risk Management Logic

Risk register, assessment matrix, mitigation planning, contingency allocation, opportunity tracking, and real-time risk monitoring.

PostgreSQL
6 Tables
Schema: risk
Mitigation Tracking

Overview

Risk Management provides a structured approach to identify, assess, mitigate, and monitor project risks. Risks are scored using a probability × impact matrix (5×5) producing a risk rating (Low/Medium/High/Critical). Each risk gets an owner, mitigation plan, and contingency budget. Opportunities (positive risks) are also tracked. Monthly risk reviews update assessments and close resolved risks.


Identify

Assess

Plan Mitigation

Monitor

Close/Escalate
6
Risk Tables
5×5
Risk Matrix
Monthly
Review Cycle
Auto
Risk Score

Status States

StatusDescriptionAllowed ActionsNext States
IdentifiedRisk recognized and loggedAssess, Assign OwnerAssessed
AssessedProbability and impact scoredCreate Mitigation PlanMitigating
MitigatingActive mitigation actions in progressMonitor, UpdateMonitoring
MonitoringRisk under watch with residual scoreReview, Close, EscalateClosed, Escalated
ClosedRisk resolved or no longer applicableArchive
EscalatedRisk exceeds project authority, escalated to PMOPMO DecisionMitigating, Closed

Database Schema

risk.risk_register

  • risk_id — PK, unique risk entry
  • project_id — FK → project.project
  • risk_code, risk_title — Identifier and short description
  • category — technical | financial | schedule | external | hse
  • probability, impact, risk_score — 5-point scales; score = P × I
  • risk_owner_id — FK → admin.user
  • status — Lifecycle state

risk.risk_assessment

  • assessment_id — PK
  • risk_id — FK → risk.risk_register
  • assessment_date — Date of review
  • probability, impact, risk_score — Updated scores
  • residual_probability, residual_impact — Post-mitigation scores
  • assessed_by — FK → admin.user

risk.risk_mitigation

  • mitigation_id — PK
  • risk_id — FK → risk.risk_register
  • mitigation_strategy — avoid | transfer | mitigate | accept
  • action_description, responsible_id — Specific action and assignee
  • target_date, actual_date — Planning vs completion
  • cost_estimate — Mitigation budget

risk.contingency

  • contingency_id — PK
  • project_id — FK → project.project
  • risk_id — FK → risk.risk_register (optional)
  • allocated_amount, utilized_amount — Budget set aside for risk events
  • approval_status — Draft → Approved → Utilized

Risk Management Steps

1

Risk Identification

Project team identifies risks using checklists, brainstorming, SWOT analysis, and lessons learned from similar projects. Each risk logged with category, description, and initial owner.

2

Risk Assessment

Score probability (1-5) and impact (1-5) for each risk. Risk score = P × I. Plot on 5×5 matrix. Scores 1-5 = Low (green), 6-12 = Medium (yellow), 15-20 = High (orange), 25 = Critical (red).

3

Mitigation Planning

For Medium/High/Critical risks, create mitigation actions with strategy type (avoid, transfer, mitigate, accept), responsible person, target date, and cost estimate.

4

Contingency Allocation

Allocate contingency budget for high-impact risks. Contingency draw-down requires Project Director approval. Utilized amounts tracked against original allocation.

5

Monitoring & Review

Monthly risk review meetings update assessments, check mitigation progress, identify new risks, and close resolved items. Risk dashboard shows trend of open risks over time.

Risk Queries

Risk Heat Map Data

-- Risk distribution for heat map visualization
SELECT r.probability, r.impact,
       COUNT(*) AS risk_count,
       STRING_AGG(r.risk_title, ', ') AS risk_titles
FROM risk.risk_register r
WHERE r.project_id = :project_id
  AND r.status NOT IN ('Closed')
GROUP BY r.probability, r.impact
ORDER BY r.probability DESC, r.impact DESC;

Validation Rules

Business Rules

  • Risk Score: Score must be probability × impact (1-25 range)
  • Mitigation Required: High/Critical risks must have at least one active mitigation action
  • Contingency Cap: Total contingency ≤ 5% of project budget unless approved by PMO
  • Review Frequency: All open risks must be reviewed at least once per month

Integration Points

Connected Modules

  • Project: Risks linked to project WBS elements and milestones
  • Finance: Contingency budget feeds commitment accounting
  • Contract: Contract risks linked to clause library for claim support
  • HSE: Safety risks cross-referenced with HSE incident data

Best Practices

Recommended

  • Maintain a minimum of 10 risks per ₹100 Cr project
  • Use quantitative risk analysis (Monte Carlo) for mega-projects
  • Link risks to specific WBS elements for targeted monitoring
  • Archive closed risks as lessons learned for future projects