Who Owns the Funding Risk?
Verify4All is a government digital programme with five delivery projects. A project manager has logged a risk that the programme's funding may be cut at the next spending review. The programme risk register holds 120 risks, many duplicated across projects. A supplier-failure risk is owned by a project manager, but the contract is managed by the commercial director. The senior responsible owner (SRO) says, 'All risks belong to the programme board.' A risk actionee has been chasing mitigation actions for weeks but has no authority to commit spend. Separately, an operational support team is logging a live outage as a risk using the same risk ID as the project's continuity risk. The programme board wants a cleaner register and clearer accountability before the next gateway review.
1. Advise how the risks in the scenario should be allocated across the strategic, programme, project and operational perspectives. Explain the principle you would use to decide.
Read the worked answer
Principle for allocation
Allocate a risk to the perspective where the relevant objectives are set and where a named owner has the authority to manage it. Perspective is not the same as severity: a severe risk can sit at project level if that is where action can be taken, and a modest risk can be strategic if only the board can respond.
Applying the principle
- Funding risk: strategic. The project manager cannot influence a spending review. The SRO or board should own it, with the project manager escalating evidence of impact and acting on any delegated actions.
- Supplier failure: depends on the level at which the relationship is managed. The commercial director owns the supplier relationship and contract; the project manager may own the project-level consequence and act as actionee for delivery continuity. One owner for the supplier risk prevents duplication.
- Duplicated project risks: tag each risk with its perspective, link parent and child entries, and deduplicate where the same cause and effect appear. The programme register should aggregate and escalate, not absorb every project risk.
- Live outage: this is an issue, not a risk. It belongs in incident management. If there is a forward-looking risk of recurrence or continuity failure, log that separately with its own ID and operational owner.
The programme board's role is oversight and aggregation. Treating all risks as programme-owned removes accountability from the people closest to the work and overloads the board.
2. Clarify the roles of risk owner, risk actionee and programme board. Correct the SRO's statement and resolve the supplier-risk and issue-versus-risk problems.
Read the worked answer
Role clarity
A risk owner is accountable for ensuring the risk is managed. The owner needs authority, resources and access to the board. A risk actionee implements specific actions but is not accountable for the risk overall. The programme board provides oversight, challenge, aggregation and escalation; it does not own every risk.
Correcting the SRO
The statement 'all risks belong to the programme board' confuses oversight with ownership. The board owns the programme-level risks it is best placed to manage and ensures the framework works. It cannot meaningfully own 120 risks or the funding risk alone; the SRO should own the funding risk with board oversight.
Supplier risk
Name the commercial director as risk owner because they control the contract and supplier relationship. Make the project manager the actionee for delivery continuity and mitigation. If the project also faces a distinct delivery risk, link it to the supplier risk rather than duplicating it.
Actionee without authority
The actionee should escalate to the risk owner. The owner must either delegate spending authority or change the response so it can be delivered. An actionee who cannot commit resources is a sign that ownership is misplaced.
Issue versus risk
The live outage is an issue and should be managed through incident management. The project's continuity risk is a separate forward-looking entry with a different ID. Reusing the same ID destroys the audit trail and makes reporting unreliable.