21.1 Benefits of Risk and Issue Management and Contingency Planning

Risk vs Issue — The High-Yield Distinction

On the APM PMQ, risk and issue management is learning objective 23 in Area D (Planning and managing deployment). Almost every long-response scenario that mentions a problem will test whether you classify it correctly.

Memory cue: risk = might; issue = is. Once a risk occurs, the immediate situation is managed as an issue. The original risk record may remain useful for history, residual exposure, and lessons — but day-to-day control shifts to issue action.

APM's definition of an issue is narrower than everyday usage

Most people use "issue" loosely, to mean any problem that has already happened. APM's own glossary is tighter: an issue is a problem that is now breaching, or is about to breach, delegated tolerances for work on a project, and it requires support from the sponsor to agree a resolution. Two consequences follow, and both are markable.

First, a problem the project manager can absorb inside delegated tolerance is not an issue in APM's terms — it is ordinary day-to-day management, resolved without escalation. Second, the defining feature of an issue is not that it is unwelcome but that it exceeds the authority of the person managing it. That is why the issue process ends in escalation and assignment of actions rather than in a probability score. If a scenario tells you the project manager can absorb a problem within their delegated cost and time limits, do not assert that it must go to the sponsor; if the scenario shows a tolerance being breached, escalation is exactly what the marks are looking for.

Worked classification

• "The specialist may leave before commissioning" → risk (threat) until they resign or become unavailable.
• "The specialist resigned yesterday; commissioning starts Monday" → issue (plus new residual risks, e.g. quality if a temporary cover is used).
• "A partner team might share a tool that would cut two weeks" → risk (opportunity).
• "The regulator has already refused the original design approach" → issue (design path blocked now).

Exam trap: Calling every problem a risk. Once the event has happened, marks usually expect issue management language: log, impact, owner, action, escalation — not only a probability score.

Benefits of Risk and Issue Management

Structured risk and issue management is not bureaucracy; it is how the project protects objectives and supports sponsor decisions.

1. Protects objectives — time, cost, quality, benefits, safety, and reputation are managed before damage compounds.
2. Improves decision quality — boards and sponsors see exposure, options, and residual risk, not only optimistic progress.
3. Enables proactive control — responses can reduce probability or impact before events hit the critical path.
4. Supports contingency and funding — known risks justify contingency; open issues justify corrective action and re-planning.
5. Clarifies ownership — named risk and issue owners prevent "everyone assumed someone else would act."
6. Provides an audit trail — decisions, escalations, and closures are visible to assurance and lessons reviews.
7. Surfaces opportunities — risk management is not only defensive; it can capture upside that improves value.
8. Links to change and benefits — materialising risks and issues often drive change requests or benefits reforecasts.

Weak projects discover problems only in crises. Strong projects make uncertainty and live problems visible, owned, and decided.

What the absence of it costs

Examiners reward benefits that are argued rather than merely listed, and the quickest way to argue one is to state the counterfactual. With no managed risk process, estimates carry no explicit allowance for uncertainty, so the first threat to materialise is absorbed by quietly squeezing quality or by an unplanned request for more money. Responses become reactive only, and the project pays crisis prices — expedited freight, overtime, emergency contractors — for events it could have anticipated. Exposure lives in individual heads instead of a register, so it leaves when those people leave, and the sponsor discovers problems from slipped milestones rather than from a forecast. Assurance and audit are left with no evidence trail, and the lessons that would have protected the next project are never captured.

Who the benefits land on

A strong long-response answer routes each benefit to a named party rather than listing generic virtues.

Role of Contingency Planning

Contingency planning prepares for residual risk after primary responses are chosen. It answers: If this still happens, what will we do, and what time or money have we set aside? APM defines contingency as the provision of additional time or money to deal with the occurrence of risks should they occur, and a contingency plan as resource set aside for responding to identified risk.

Contingency planning is tightly linked to governance: who may draw down contingency, at what threshold, and with what reporting. Blindly spending contingency on every overrun destroys the signal that risk exposure is rising.

How contingency gets sized

"How much?" is the question that separates a planned provision from a guess, and PMQ answers should demonstrate a method rather than assert a number.

• Expected value. For each identified risk, multiply probability by impact and sum across the register. A 20% chance of a £50,000 rework contributes £10,000. It is quick and defensible, but it describes an average across the portfolio of risks, not any single outcome — no individual risk ever costs £10,000.
• Quantitative simulation. Where impacts are large or interdependent, three-point estimates are modelled across the cost plan or schedule and a confidence level is chosen. Funding to a P80 figure means the organisation expects to finish within budget in 80% of simulated outcomes. PMQ does not ask you to run the arithmetic, but naming the technique and the confidence level earns credit.
• Percentage rules of thumb. Adding a flat 10% is common and weak: it is unconnected to the actual register, it invites estimators to pad a second time on top of padded estimates, and it cannot be defended to a board that asks which risks the money covers.

Time contingency deserves the same discipline as money. A buffer parked at the end of the schedule protects the completion date but conceals which activity consumed it; buffers held against specific high-risk work packages show where exposure is crystallising, but tempt teams to treat the buffer as ordinary float. Whichever placement is used, the reserve must be owned, triggered, and reported — otherwise it is absorbed silently and the project forfeits the earliest warning it has that the plan is failing.

Example: A project accepts residual risk of a two-week customs delay on imported equipment. Primary response: early order and dual shipping quote. Contingent response: air freight alternative and a pre-agreed cost/time contingency draw if the sea shipment misses a trigger date. Without that plan, the team improvises under pressure and often breaches financial authority.

Answering a 23a question

Outcome 23a is phrased around benefits and the role of contingency, so a bare list scores poorly against a long-response mark scheme. Use the pattern benefit → mechanism → project consequence: "Risk management improves decision quality because the board sees quantified exposure alongside progress reporting, so gate decisions rest on the real position rather than on optimism." Three or four benefits developed that way beat eight named in isolation. Where the question also mentions contingency, state explicitly what it is provided for (identified residual risk), how it was sized, and who authorises its release.