4.5.31: Project Reckon Risk Register and Control Log
- Page ID
- 54808
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\dsum}{\displaystyle\sum\limits} \)
\( \newcommand{\dint}{\displaystyle\int\limits} \)
\( \newcommand{\dlim}{\displaystyle\lim\limits} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\(\newcommand{\longvect}{\overrightarrow}\)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\ket}[1]{\left| #1 \right>}\)
\(\newcommand{\bra}[1]{\left< #1 \right|}\)
\(\newcommand{\braket}[2]{\left< #1 \vphantom{#2} \right| \left. #2 \vphantom{#1} \right>}\)
\(\newcommand{\braopket}[3]{\left< #1 \vphantom{#2}\vphantom{#3} \right| #2 \vphantom{#1}\vphantom{#3} \left| #3 \vphantom{#1}\vphantom{#2} \right>}\)
\(\newcommand{\qmvec}[1]{\mathbf{\vec{#1}}}\)
\(\newcommand{\op}[1]{\hat{\mathbf{#1}}}\)
\(\newcommand{\expect}[1]{\langle #1 \rangle}\)
\(\newcommand{\dfn}[1]{\emph{\textbf{#1}}}\)
Purpose of the Risk Log
Project Reckon is a fully outsourced product development initiative. Risks do not appear suddenly — they accumulate gradually.
Students must maintain a living Risk Register across all scenarios.
Each week:
- New risks may be added.
- Existing risks must be updated.
- Risk severity may increase or decrease.
- Mitigation actions must be documented.
- Residual exposure must be evaluated.
This artifact becomes cumulative and is submitted at the end of the practicum.
Risk Log Structure
Students must maintain the following table:
Project Reckon Risk Register
| Risk ID | Risk Description | Category | Trigger/Event | Likelihood (1–5) | Impact (1–5) | Risk Score | Mitigation Action | Owner | Status | Residual Risk |
|---|
Field Definitions
Risk ID
Unique identifier (R-01, R-02, etc.)
Risk Description
Concise but specific statement.
Example:
“Synchronization Engine defect clustering may indicate architectural instability in concurrent update handling.”
Category
Choose one:
- Scope
- Schedule
- Budget
- Quality
- Architecture
- Vendor Management
- Integration
- Political/Executive
- Dependency
- Change Control
Trigger/Event
What caused the risk to be logged?
Example:
“Iteration 3 defect spike in integration module.”
Likelihood (1–5)
1 = Rare
2 = Unlikely
3 = Possible
4 = Likely
5 = Almost Certain
Impact (1–5)
1 = Minimal
2 = Low
3 = Moderate
4 = High
5 = Severe
Risk Score
Risk Score = Likelihood × Impact
Interpretation:
- 1–5 = Low
- 6–10 = Moderate
- 11–15 = Elevated
- 16–25 = Critical
Mitigation Action
Specific and actionable.
Example:
- Require architectural walkthrough.
- Increase QA concurrency testing.
- Initiate formal change control.
- Freeze new feature additions.
Owner
Who is accountable?
- C-Bay PM
- ZynoxDev Architecture Lead
- QA Manager
- Steering Committee
Status
- Open
- Monitoring
- Mitigating
- Escalated
- Closed
Residual Risk
After mitigation, what level remains?
Low / Moderate / High / Critical
Weekly Risk Log Requirements
At the end of each scenario submission, students must:
- Add any new risks.
- Update likelihood/impact of existing risks.
- Adjust mitigation status.
- Identify any risks requiring escalation.
- Explain if risk posture is improving or deteriorating.
Example Entry (Scenario 2)
| Risk ID | Risk Description | Category | Trigger/Event | Likelihood | Impact | Score | Mitigation | Owner | Status | Residual |
|---|---|---|---|---|---|---|---|---|---|---|
| R-02 | Integration defect clustering may reflect architectural instability | Architecture | Iteration 3 defect spike | 3 | 4 | 12 | Require root cause analysis and concurrency testing expansion | ZynoxDev Arch Lead | Mitigating | Moderate |
Risk Log Grading Component
Students are graded on:
| Criteria | Points |
|---|---|
| Risk Identification Accuracy | 20 |
| Appropriate Likelihood & Impact Calibration | 20 |
| Mitigation Precision | 20 |
| Escalation Discipline | 20 |
| Longitudinal Risk Tracking Across Weeks | 20 |
Total: 100 points (cumulative)
Cumulative End-of-Module Requirement
Final Submission must include:
- Complete Risk Register
- Risk Trend Analysis (2–3 pages)
- Which risks increased?
- Which were contained?
- Which were underestimated?
- Risk Posture at Release Decision
- Lessons Learned in Risk Detection
Teaching Impact
This artifact forces students to:
- Think longitudinally
- Recognize pattern formation
- Avoid “week-by-week amnesia”
- Practice early detection
- Understand mitigation vs resolution
- Avoid reactive management
It converts smulation into enterprise realism.