The Supplier Has Gone, and a £340k Change Arrives in the Same Week
Six months into an 18-month ERP rollout, the prime supplier gives notice that it is in serious financial difficulty. In the same week the finance director raises a change request to add a treasury module; the supplier's impact assessment shows +£340k and +10 weeks. The current stage tolerance is ±£150k and ±4 weeks. The project manager logs the supplier's financial difficulty as a risk, records the change request as 'rejected - out of scope', and reports the stage as amber. The risk management approach specifies monthly risk reviews at the project board, which next meets in five weeks.
1. Correct the project manager's handling of both events.
Read the worked answer
Both entries are in the wrong place, and each error has consequences.
Supplier financial difficulty. A supplier in financial difficulty is not a risk - it has happened, so it is an issue (a problem or concern) and belongs in the issue register. Its consequences are risks: loss of key staff, inability to deliver the next work package, intellectual property becoming unavailable, re-procurement delay. Those go into the risk register with owners, causes and effects. Filing the parent event as a risk means nobody is managing the live situation; the project manager is managing a forecast instead of a fact.
The change request. 'Rejected - out of scope' is not the project manager's call in these circumstances, for two reasons: the +£340k/+10 weeks impact exceeds the stage tolerance of ±£150k/±4 weeks, and a treasury module changes the scope on which the business case benefits were justified. The project manager's job is to complete the impact analysis (cost, time, risk, business case, quality) and escalate it to the project board via an issue report, since the board holds the change authority at that level and owns the business case.
Also: an amber report without a corresponding escalation is misreporting - the forecast is outside tolerance, so it should be red and escalated.
2. Who should decide on the change, what must they be given, and how does the tolerance position change the mechanism used?
Read the worked answer
The project board decides, because the change exceeds the change authority delegated to the project manager and materially affects the business case.
The board must be given an issue report containing: the change requested and by whom; the full impact assessment (cost, timescale, risk, quality, benefits); options rather than a single recommendation (approve, defer to a later phase, reject, descope something else to pay for it); and the effect on the business case. Approving +£340k of scope without repricing the benefits is how projects become expensive without becoming more valuable.
Mechanism: the same assessment shows the stage is forecast to exceed its ±£150k/±4 weeks tolerance, so the vehicle is an exception report, and if the board accepts the change, an exception plan replacing the remainder of the stage plan is produced under Managing a Stage Boundary and authorised by the board.
The judgement being tested: it is not the size of the number that matters but whether the decision lies inside or outside the delegated tolerance, and whether the business case is affected.
3. The board does not meet for five weeks. Assess whether the project manager can wait, and what this reveals about the project's controls.
Read the worked answer
She cannot simply wait. Tolerances are delegated authority with an obligation attached: the project manager works within them, and escalates as soon as a forecast breach appears - that is what manage by exception means. A board calendar is not a shield. If the forecast breach is visible now, the project manager raises an exception report now and asks the executive to convene the board or to take an interim decision within their authority between meetings (ad hoc direction).
What this episode reveals about the controls:
- The escalation route was never made operational. A monthly risk review cadence with a five-week board cycle leaves a gap in which tolerances can be breached with nowhere to report.
- The risk management approach is out of date. It should specify proximity-based triggers and how urgent issues reach the board out of cycle, not just a monthly meeting.
- Change authority may be under-delegated. If every sizeable change waits five weeks, the project will lose time regardless of the decision - worth reviewing delegated limits deliberately rather than by default.
The recommendation to the board is not 'meet more often' but 'define how urgent exceptions reach you within 48 hours'.