The supplier whose credit rating fell: a payment platform build

The suggestion is too simplistic. A risk is an uncertain event; an issue is a certain event that is already affecting the project. Vantage's missed payment run and lost developers are facts and should be recorded as issues. But the risk that Vantage fails to deliver the fraud engine remains uncertain, so the risk entry should be reassessed, not simply reclassified.

The project manager should:

• Reassess probability and impact using the new evidence. A 10% probability is no longer credible.
• Record the missed payment run and developer losses in the issue register and assess their effect on the schedule and quality.
• Confirm the risk owner. The IT director is on leave, so the board should appoint an interim owner with authority to act, rather than letting the risk drift.
• Review the response. Options include reducing the risk through code escrow, retention payments, additional testing or dual running; transferring through contractual remedies; or avoiding by switching supplier. Acceptance may be appropriate only if the board understands the compliance exposure.
• Check the risk budget and escalate if the response needs more than the delegated amount.

Using the change budget for overtime is not an automatic fix. Any change to baselines must go through change control with impact analysis and the correct authority.

Switching suppliers is an avoidance response, but avoidance is not automatically the best response just because the current supplier is in difficulty. The project manager should compare it with reducing or transferring the risk.

Key questions are: does another provider exist with the required API certification; how long would certification, contracting and integration take; what would it cost; and what would happen to the 14-week regulatory deadline? Vantage is described as the only certified provider, so a switch may not be feasible before the deadline. Even if a second provider exists, the migration and testing effort could create more schedule risk than it removes.

A more realistic response may be to reduce the risk: insist on code escrow, require Vantage to assign named developers, add independent testing, and prepare a contingency plan. Transfer through contractual penalties or insurance may recover money but will not protect the deadline. The board should decide using its low appetite for compliance risk: if the deadline cannot be protected, it may need to accept a regulatory conversation rather than assume a late switch will work. The recommendation should include cost, time, compliance impact and the effect on the business case, not just supplier preference.

The risk owner is accountable for managing the risk and its response, not merely for being named in the register. That includes monitoring triggers, ensuring the response is actioned, and reporting progress to the project manager and board. The IT director's absence therefore leaves the risk without active ownership at the worst possible time.

The project manager should raise this with the executive or project board and ask for an interim risk owner with the authority to commit the response, such as a senior IT or compliance manager. The project manager can support and coordinate, but should not silently become the owner unless the board explicitly agrees and the role is recorded. The risk register should show the interim owner, the revised probability and impact, the response actions, and the next review date.

If the response requires funding beyond delegated tolerance, the interim owner should support an escalation to the board. The board also needs to see that its low compliance-risk appetite is reflected in the response, not just in the risk register wording.