11.7 Monitor Risks
Keep watching for new risks and check whether existing responses still work.
Monitoring and Controlling / Risk · ← PMBOK reference · See it on the map
Why it matters
A risk register frozen at kickoff goes stale fast; new threats appear and old ones change shape as the project moves forward.
What done looks like
The risk register is being actively reviewed and updated as the project proceeds.
First time tip
Put a risk review on the same recurring calendar slot as your status meeting. A review that only happens when someone remembers rarely happens at all.
What you need (Inputs)
- Risk Management Plan
- Risk Register
- Risk Report
- Issue Log
How Scrum/Kanban projects satisfy this — counted from: impediments (driftless/models/agile.py:Impediment) — an impediment IS an issue raised against the team's progress; healthy once none are open or in progress - Lessons Learned Register
How Scrum/Kanban projects satisfy this — counted from: sprint retrospective evidence (driftless/models/delivery.py:Sprint) — a sprint closed with retrospective notes is a lesson captured, the way a predictive project files one as prose - Work Performance Data
- Work Performance Reports
How Scrum/Kanban projects satisfy this — counted from: sprint review evidence (driftless/models/delivery.py:Sprint) — a sprint closed with review notes is the periodic report the sprint's own cadence produces, fresh while the latest is inside the reporting window
How you do it (Tools & Techniques)
What you get (Outputs)
- Work Performance Information
How Scrum/Kanban projects satisfy this — counted from: sprints under way (driftless/models/delivery.py:Sprint) for an agile project, or service levels and incidents (driftless/models/operations.py) for an operations-cadence one — a sprint under way is the work performance data an agile team reads instead of a baseline-and-actuals pair; an operations-cadence project reads the same question off its service levels and the incidents raised against them - Change Requests
- Risk Register
- Risk Report
Worked example
At each weekly meeting in the month before the festival the committee walks the register. The forecast has turned settled, so the storm drops down the list, but a new risk has appeared: the roadwork on the approach now overlaps the festival weekend and could block the delivery route. It is logged, rated and given an owner the same way as the rest.
Common pitfalls
- Reviewing the register only when somebody remembers, which in a busy month means not at all.
- Adding new risks but never closing or lowering the ones that have passed.
- Checking that responses still exist without checking they still work after the plan has changed.
How driftless helps
- Audits can be run here.
- Meetings can be run here.
- Risk Register can be created in the wizard.