Supplier dependency slips and a workaround is offered
A government digital identity programme is delivering a reusable identity verification service across four departments. The programme depends on a shared API being delivered by another programme, Data Exchange. Data Exchange has moved its API release from March to September, citing security testing. The identity programme's tranche 1 is due to close in July and its business case assumes 1.2 million verifications in year one. The supplier contract for the identity programme has a milestone payment of £800k tied to integration testing in April. The supplier has offered to build a temporary workaround for £250k, which would not meet the target architecture and would need decommissioning. The programme board has a risk appetite statement that says no compromise on security accreditation. The PMO reports the dependency as amber.
1. Should the programme manager accept the supplier's temporary workaround?
Read the worked answer
Start with the board's risk appetite: no compromise on security accreditation. A workaround that does not meet target architecture and would need decommissioning is not automatically a security failure, but it must be tested against accreditation. The programme manager should ask: will the workaround be accredited for use, or will it create an unaccredited data path? What is the cost of decommissioning, and who pays? Does it create technical debt that outlives tranche 1? Would it allow the 1.2 million verifications, or only a subset? The £250k is not the main issue; the main issue is whether accepting it sets a precedent for bypassing architecture and security. A conditional acceptance is possible only if the workaround is time-boxed, accredited, funded from contingency, and has a decommissioning plan owned by the programme. Otherwise reject it and re-plan tranche 1 around the September API. The programme manager should record the decision and rationale, because audit will ask why a non-target solution was accepted.
2. What should the programme manager do about the £800k supplier milestone payment?
Read the worked answer
Do not pay for a milestone that has not been achieved. The payment is tied to integration testing in April; if the API is not available, integration testing cannot have occurred. The programme manager should check the contract's relief events, dependency provisions and acceptance criteria. Was the API dependency disclosed to the supplier at contract award? If yes, the supplier may be entitled to relief, but that does not automatically trigger payment. If no, the programme may be exposed. The right action is a commercial conversation, supported by the contract manager and legal, to agree a revised milestone plan linked to the September API. Avoid accepting the workaround as a way to earn the milestone; that would convert a supplier issue into a programme architecture issue. Also separate the supplier relationship from the dependency programme: the supplier is not responsible for Data Exchange's delay. Document the position and inform the board, because an £800k payment without achievement would be a governance failure.
3. How should the programme manager manage the dependency and the tranche boundary?
Read the worked answer
Treat the dependency as a programme-level risk, not an amber PMO statistic. The programme manager should agree with Data Exchange a joint dependency plan with a firm API release date, entry and exit criteria, and a named owner on both sides. Escalate to the programme board or a cross-programme forum, because one programme cannot control another's delivery. Re-plan tranche 1: what can close in July without integration testing, and what must move to tranche 2? Update the business case's year-one verification forecast and the benefits profile. Review the tranche boundary: closing tranche 1 with an unresolved critical dependency would be a false gate. The programme manager should also assess whether the September date is credible - security testing can slip again - and set a trigger for the workaround decision if it does. The judgement is to protect the tranche gate's integrity rather than close on time with an untested service.