21.2 The Risk and Issue Management Processes
Key Takeaways
- The risk process runs through identification, analysis, monitoring, escalation, response, and closure, and each stage has a distinct purpose.
- The issue process runs through logging and analysis, escalation, and assignment of actions, because an issue has already happened and needs resolution.
- Analysis assesses probability and impact so that limited management attention goes to the exposures that matter most.
- In linear life cycles risk activity concentrates around phases and gates, with formal reviews and a longer horizon of uncertainty to manage.
- In iterative life cycles risk is revisited every increment, so identification is more frequent, horizons are shorter, and responses are absorbed into backlog prioritisation.
Outcome 23b names the stages of both processes explicitly — risk: identification, analysis, monitoring, escalation, response and closure; issue: logging and analysis, escalation, and assignment of actions — and then adds a second requirement: understand why these stages are different for linear and iterative life cycles. Both halves are examinable, and the life-cycle comparison is the one most often left out.
Stages of the Risk Management Process
APM PMQ expects you to know the stages of risk management and what each achieves. Labels vary slightly by organisation; the syllabus cluster is identification, analysis, monitoring, escalation, response, and closure (order in practice is iterative — identify → analyse → respond → monitor/escalate → close — with loops).
| Stage | What happens | Typical outputs |
|---|---|---|
| Identification | Discover threats and opportunities that could affect objectives | Risk descriptions, sources, assumptions, risk register entries |
| Analysis | Assess probability and impact (qualitative scales; quantitative modelling where justified) | Priority, exposure, risk ranking, understanding of combined effects |
| Response | Select and plan treatment (proactive actions and contingent plans) | Response strategy, actions, owners, residual risk estimate |
| Monitoring | Track triggers, residual exposure, response effectiveness, and new risks | Updated register, status, early warnings |
| Escalation | Raise risks that exceed delegated tolerance, appetite, or authority | Escalation pack: impact, options, recommendation |
| Closure | Close risks that are no longer relevant, have expired, or have been fully treated | Closure rationale; lessons; any residual transfer to BAU |
Identification
Sources include workshops, checklists, lessons learned, assumptions analysis, SWOT, supplier and stakeholder input, technical reviews, and life-cycle planning. Good risk statements are specific: cause → uncertain event → effect on objectives — not vague labels like "IT risk."
Analysis
Qualitative analysis prioritises using probability and impact scales (and often proximity or velocity). Quantitative analysis models combined uncertainty numerically (e.g. on cost or duration) when the investment justifies it. Both can cover threats and opportunities. Analysis without prioritisation wastes effort treating noise while major exposures sit unowned.
Response, monitoring, escalation, closure
Response choices are covered in depth in the next section. Monitoring checks whether triggers are approaching and whether responses work. Escalation is correct control when residual exposure breaches appetite, tolerance, or the project manager’s authority — not a personal failure. Closure keeps the register live and credible; dead risks left open destroy management attention.
The risk register is the controlled record of identified risks, assessments, owners, responses, status, and residual exposure. It supports monitoring, escalation, and board reporting; it does not replace the schedule or the business case, but it informs both.
Stages of the Issue Management Process
Issue management is faster and more action-centric because the problem is already real.
| Stage | What happens | Why it matters |
|---|---|---|
| Logging | Capture the issue with description, date, category, and initial severity | Creates visibility and a single source of truth |
| Analysis | Assess impact on objectives, stakeholders, compliance, and related risks | Stops firefighting the symptom while missing benefits or safety impact |
| Escalation | Raise issues beyond tolerance, authority, or that need senior unblock | Protects business case and organisational priorities |
| Assignment of actions | Name owners, actions, deadlines, and success criteria | Issues without owners do not resolve |
Issues often generate change requests, re-plans, or new risks (secondary effects). Closing an issue means the problem is resolved or formally accepted with residual risk transferred — not merely that the team stopped talking about it.
Scenario: risk becomes issue
A hospital IT project logs a risk that a clinical data migration window may be refused by operations. Probability medium, impact high on go-live benefits. Response: early engagement, dual window options, contingency for a four-week slip. Two months later operations confirm refusal of the original weekend. That is now an issue: log it, analyse impact on schedule and benefits, escalate to the sponsor/board if tolerances are threatened, assign actions (re-plan migration, revise comms, possibly change control for date). Related residual risks (staff overtime fatigue, data quality if rushed) stay on the risk register.
Why Stages Differ for Linear vs Iterative Life Cycles
The stages still exist in both life cycles. What changes is cadence, formality, artefacts, and when major commitment is made.
| Aspect | Linear (predictive) | Iterative (adaptive) |
|---|---|---|
| Identification focus | Heavy early workshops; phase-end re-identification | Continuous discovery each iteration; backlog and demo feedback surface new risks |
| Analysis timing | Detailed before stage gates; progressive update | Lightweight frequent re-scoring; deep analysis when exposure threatens product goals |
| Response planning | Built into stage plans and baselines; contingency at gates | Responses may be backlog items, spikes, or capacity reserved in upcoming sprints |
| Monitoring | Register reviews aligned to reporting cycles and gates | Daily/iteration reviews; burn-down and impediments often surface issues fast |
| Escalation path | Formal exception reports to sponsor/board at gates or when tolerances breach | Product owner may prioritise within vision; strategic/investment exposure still escalates to sponsor/board |
| Issue handling | Formal issue log, change control linkage | Impediments may be cleared inside the team; material issues still log and escalate |
| Contingency | Often cost/time contingency released progressively by stage | Capacity buffers, priority flexibility, and smaller funding envelopes; still needs ownership |
| Closure | Risk/issue closure at phase and project close; residual to BAU | Frequent close of short-cycle risks; product-level residual risk may span many increments |
Exam point: iterative delivery does not abolish risk management or governance. It compresses feedback loops so identification and monitoring are more continuous, while sponsor accountability for appetite, investment, and major escalation remains.
Hybrid hint
Many real projects are hybrid: predictive control on contracts, safety, and capital gates; iterative control on product features. Risk and issue processes must cover both rhythms — a single monthly register review is rarely enough for a two-week iteration team that discovers blockers daily.
Putting Process Together for Exam Answers
When a scenario describes uncertainty or a live problem:
- Classify risk vs issue (and threat vs opportunity if relevant).
- Name the process stage that is missing or weak (e.g. no owner, no analysis, no escalation).
- State the next management action and who should own it.
- Mention contingency or re-plan if residual exposure remains.
- Note life-cycle fit (gate review vs iteration impediment) without dropping governance.
That chain matches LO23(a)–(b): benefits, contingency, process stages, and linear vs iterative differences — before you dive into named response strategies in the next section.
How do risk management stages typically differ between linear and iterative life cycles?