The Situation
This delivery governance engagement involved a global digital banking platform vendor — operating primarily as a PaaS provider — that identified a growing demand from its UK customer base for significantly higher adherence to UK-specific regulatory and payments requirements. ISO 20022, Strong Customer Authentication, Confirmation of Payee for domestic payments, Verification of Payees for international payments, UK-specific payment rails (CHAPS, Faster Payments, SWIFT), and Open Banking/PSD2 compliance were all on the table.
The vendor’s response was ambitious: rather than address these requirements piecemeal, they decided to create a dedicated multidisciplinary, multi-department team to build a UK-focused product plugin — effectively moving from PaaS towards a more finished, SaaS-like proposition for that specific market.
This was unprecedented for the organisation. The initiative required coordination across a core delivery team of around a dozen people, an R&D team whose roadmap would need to accommodate product-level changes, and a marketplace/third-party team responsible for embedding external components into the platform.
I was brought in as Programme Director before the programme had properly started — not to rescue something that had gone wrong, but to impose the governance and structure that would prevent it from going wrong in the first place.
Root Causes
Why Governance Was Needed From Day One:
Multiple teams, conflicting priorities
R&D needed to support the initiative, but that meant rethinking their existing roadmap. Every feature built for the UK plugin competed for bandwidth with other product commitments — and no one had defined how those trade-offs would be made.
UK vs EU tension
European customers were simultaneously pushing for their own Open Banking requirements. Since UK and EU regulations do not perfectly overlap, the team needed to prioritise UK delivery while maintaining compatibility with future EU enhancements — a balancing act that required constant, deliberate decision-making.
No existing playbook
The organisation had never done anything like this before. There was no internal template for running a cross-functional product initiative of this nature.
Regulatory and customer-driven deadlines
The programme was bound by hard regulatory dates and customer-driven delivery commitments. Missing either would have direct commercial and compliance consequences.
Third-party dependencies
Key functionality depended on external components managed by the marketplace team. Without early identification and tracking, these dependencies could silently block testing and delivery.
What I Did
I focused on building the governance structure that would make this unprecedented initiative manageable — clear accountability, early visibility, and a decision-making framework that could handle the politics.
Established a Unified Steering Committee
I brought all parties — the core delivery team, R&D, and the marketplace/third-party team — into a single weekly steerco. This was deliberate: rather than letting each team operate in its own silo and surface conflicts late, the steerco created a shared forum where issues, dependencies, and trade-offs were visible to everyone from the start.
Created a Bespoke SteerCo Deck
I designed a purpose-built steering committee deck for this initiative — not a generic project status template, but a format tailored to the cross-functional, multi-stakeholder nature of the programme. It gave senior stakeholders a consistent, structured view of progress, risks, and decisions needed.
Enforced Rigorous RAID Log Discipline
I applied a thorough RAID framework (Risks, Assumptions, Issues, Dependencies) with particular emphasis on the Decisions log. With multiple senior stakeholders holding conflicting priorities, having a formal, transparent record of what had been decided — and why — was essential to keeping the programme moving and preventing revisited arguments.
Encouraged Difficult Conversations Early
Rather than letting conflicts simmer beneath the surface, I actively pushed the team and stakeholders into the hard conversations — competing roadmap priorities, regulatory trade-offs, UK vs EU sequencing — to resolve them quickly rather than let them fester into blockers.
Identified and Tracked Third-Party Dependencies
We mapped hard dependencies on external components early, particularly those that would gate testing. This allowed the team to plan around third-party timelines rather than discover blockers when it was too late to adjust.
Embedded an Upgrade Strategy
We built an upgrade strategy into the programme from the start, ensuring that the UK plugin would maintain alignment with the evolving core product. This prevented the initiative from becoming a disconnected fork that would require expensive reintegration later.
Brought Customers Into Requirements Validation
We invited selected UK customers to validate our requirements directly, ensuring the team was building against real-world needs rather than internal assumptions about what the market wanted.
Engaged External Regulatory Expertise
We brought in a UK regulatory expertise firm to support the requirements gathering process — ensuring that the team’s interpretation of ISO 20022, SCA, Confirmation of Payee, and Open Banking requirements was accurate and defensible.
Applied Core Jira Principles
I structured the work-tracking in Jira with the same disciplined approach used in client-facing engagements — clear workflows, accountability, and lean reporting that gave all stakeholders a shared view of delivery progress.
Outcomes
The Turning Point
There was no single crisis moment — and that was the point. The turning point was the organisation realising, weeks into the programme, that a cross-functional initiative of this complexity was running smoothly because the structure had been imposed before the problems could emerge. The steerco, the RAID log, and the decision-making discipline turned what could have been a chaotic, politically fraught initiative into a delivery engine that outlasted my involvement.
Want to build governance before things go wrong?
Looking for structured governance before your programme hits trouble? Let’s discuss how I can bring cross-functional alignment, delivery predictability, and decision-making discipline to your most critical initiatives.
You might also find these useful
Rescuing a Wealth Platform Programme
How structured governance and on-the-ground delivery leadership turned a red programme around in 4 months
Restoring Delivery Control
How scope discipline, API reverse-engineering, and MoSCoW prioritisation turned an overrun programme into a controlled delivery in 12 weeks.