Fictional case study · Document 12 · Week 2 baseline; reviewed weekly
Risk Register
The team records what could threaten delivery and assigns owners to reduce or manage each risk.
Illustrative project record. AegisShield, BookEasy, the people, decisions and outcomes are fictional.
How this register is used
This is the fictional week-2 planning baseline. Probability and impact are qualitative estimates, not measured statistics. The PM reviews open risks with their owners weekly; an event that later happens is recorded separately as an issue in a dated update.
Scoring criteria
Low probability means the event is not expected under the current plan; Medium means there is a credible chance; High means the event is likely without action. Low impact means limited rework; Medium means a material delay or contained customer effect; High means a release blocker, data-integrity concern, service disruption, or major schedule impact.
Initial risks
| ID / risk | Probability / impact | Response and trigger | Owner |
|---|---|---|---|
| R01 — Dependency incompatibility | Medium / High | Engineering checks compatibility and runs login and API regression tests in staging; escalate if a required library blocks the selected runtime. | Engineering lead |
| R02 — Data loss or inconsistent migration | Medium / High | Database engineer validates backups, rehearses migration and restore, and reconciles agreed sample records; stop the release if recovery or reconciliation fails. | Database engineer |
| R03 — Missing or duplicate events | Medium / High | Backend and QA test stable event IDs, retry timeouts and duplicate handling; block the pilot if agreed test events are missing or duplicated. | Engineering lead |
| R04 — Customer disruption | Medium / High | DevOps plans monitoring and a controlled change window; Customer Success coordinates notice with BookEasy; pause the release if service health fails the agreed checks. | DevOps / SRE |
| R05 — Pilot or schedule delay | Medium / Medium | PM tracks dependencies and test readiness weekly; escalate a forecast slip to the sponsor and agree any schedule change. | Project manager |
Review and escalation
Risk owners report changes to the PM. If a risk occurs, the team records an issue with impact, actions and status; the PM communicates material changes to the sponsor and affected stakeholders. The baseline does not assume that any listed risk has already occurred. Later updates may record an issue and the date it materialized.
Risk controls and definitions
Each risk is managed through prevention, a trigger, and contingency. Risk: an uncertain event that could affect the project. Issue: a risk that has happened or a current problem. Risk owner: the role accountable for monitoring and responding. Trigger: a sign that the risk may be occurring. Mitigation: action taken to reduce probability or impact. Contingency: action taken if the risk occurs. Preventive controls include compatibility testing, restore rehearsal, capacity checks, and data-protection review.
Risk detail baseline
R01: version differences may cause library incompatibility and delay deployment; prevent with compatibility review, trigger on a failed target-runtime check, and revise the target if needed. R02: incomplete migration preparation may cause missing or inconsistent data; prevent with restore rehearsal, counts, integrity checks and reconciliation, and stop release if checks fail. R03: retry timeouts may create duplicate or missing events; prevent with stable IDs and timeout tests, and pause pilot approval if a repeated event is processed twice. R04: part-time capacity may delay work; prevent with availability checks and re-sequencing. R05: weak data controls may expose customer information; prevent with masked data, access and encryption checks, and stop the activity if a control fails. Each risk has an owner, status, last review date, and preventive-action due date in the working register.