Six Teams, One Regulator, and an Undocumented API

The programme has high technical and vendor uncertainty, so a full end-to-end design assumes knowledge that does not yet exist. The vendor API will change three times, the identity service is already a bottleneck, and six teams will discover constraints only by integrating. A design approved before any team starts becomes a batch of untested assumptions. Percentage completion against that design measures conformance to a plan, not delivered capability or reduced risk. It can look healthy while integration is failing. In a regulated context, the real measures are working increments, evidence of data integrity, traceability, and resolved dependencies. Upfront design still has a role for stable architectural principles and compliance controls, but it should be a runway that evolves, not a gate that freezes learning. The Gantt chart and team Sprint plans conflict because they represent different models of how uncertainty is handled; the Gantt assumes deterministic sequencing.

Establish a shared cadence and a single integrated view of dependencies. Use a Scrum of Scrums or equivalent coordination forum focused on blockers, integration, and upcoming cross-team decisions, not status reporting. Map dependencies explicitly and age them; the identity service should have one accountable owner and a thin interface contract so teams can proceed with test doubles. Create an architecture runway with lightweight decision records and a facade around the vendor API so version changes are isolated. Run time-boxed spikes against the undocumented API and publish findings immediately. Align teams to end-to-end slices of the migration rather than layers. Use contract tests, continuous integration, and regular joint integration events. Each team keeps its own backlog and Sprint Goal, but the programme has a shared product goal and release forecast. The release manager should maintain a forecast and dependency view, not a parallel task schedule that competes with Sprint plans.

Report evidence and risk, not plan conformity. Show working increments of migrated records, verified data integrity checks, passed compliance controls, and the number of records safely migrated and reconciled. Use a release burnup that displays scope changes and forecast ranges, plus cumulative flow and dependency aging. Present top risks with owners and mitigation evidence, especially vendor API versions and the identity service. Provide a traceability view that maps regulatory requirements to tests and delivered evidence. Forecast with confidence ranges based on throughput and unresolved dependencies. Explain what decisions the steering group must make and what the consequences of each option are. This gives the regulator auditability and gives the steering group genuine control, whereas percentage completion against an untested design hides the very uncertainty that threatens the 14-month date.