The Situation
A leading UK wealth manager — with close to £70 billion in assets under management and offices across the UK, Ireland, and the Channel Islands — had engaged a platform vendor to implement a digital wealth management solution.
By the time I was brought in, the programme was approaching the end of its first year. The situation was severe:
Budget Overrun
The delivery team had consumed over 80% of the total budget while delivering less than 40% of the scope required for go-live.
Unrealistic Expectations
Commitments made during the sales process had set expectations the delivery team could never meet — and no one had corrected the course.
Uncontrolled Scope
The client’s product owner had repeatedly introduced additional requirements, differentiators, and “delights” during refinement sessions — none of which went through any formal change process, because no change process existed.
Client Escalation
The client had escalated at the highest level, citing a fundamental loss of trust in the vendor’s ability to deliver.
Undocumented API
The client’s API gateway was treated as an unchangeable component, as there was no documentation. Every integration had become a custom effort, far exceeding the originally assumed out-of-the-box approach.
Root Causes
Beneath the visible symptoms, I identified several structural failures:
Sales-to-Delivery Misalignment
Expectations set during the sales cycle bore little resemblance to what the platform could deliver out of the box. The delivery team inherited commitments they had no part in making — and never formally reset.
Undocumented Integration Layer
The client’s API gateway had no documentation. Rather than flagging this as a project risk early, the team attempted integrations against an unknown interface — resulting in fully custom work where standard connectors had been assumed.
No Change Management Process
When the client’s product owner introduced new or expanded requirements, the delivery team absorbed them without challenge. There was no mechanism to distinguish contractual scope from client wishes — every request was treated as mandatory.
No Delivery Discipline in Tooling
Jira workflows lacked rigour. Accountability for defects was ambiguous, reporting was manual and inconsistent, and there was no shared view of progress that both sides trusted.
What I Did
I focused on establishing the controls that should have existed from day one — scope discipline, integration transparency, and a shared definition of what we were actually building.
Stakeholders Interviews and Assessment
In the first two weeks, I interviewed both the client’s leadership and the internal delivery and commercial stakeholders to map the gap between expectations, commitments, and reality.
Forced the API Documentation Issue
I progressively brought the client to recognise that undocumented APIs are a severe liability — introducing unpredictable risk and cost into every integration. The client accepted the argument and agreed to fund a dedicated small team to reverse-engineer and document the APIs ahead of the main delivery team.
Introduced a Change Management Process
I negotiated a formal change process between the parties and trained the delivery team to trigger a change flow every time a requirement deviated from the out-of-the-box product or the originally assumed scope. This gave both sides a shared language for separating contracted work from new asks.
Disciplined the Client's Scope Through MoSCoW
I worked with the client’s product owner and stakeholders to categorise every requirement using a MoSCoW matrix. This shifted the mindset from “everything is essential” to an MVP approach — focusing delivery effort on what was genuinely needed for go-live and deferring the rest.
Restructured Jira Reporting
I reconfigured Jira with a stricter workflow that enforced clear statuses, accountability on defects, and lean reporting. Both sides could now see the same data and draw the same conclusions.
Rebaselined the Plan
With realistic scope (post-MoSCoW), documented APIs reducing integration surprises, and a functioning change process in place, we rebaselined the delivery plan with commitments both parties could stand behind.
Outcomes
Within 12 weeks:
What we could not fix: the integration layer remained heavily custom — a direct consequence of expectations set during the sales phase that could not be unwound. The cost of that misalignment was already baked in.
The Turning Point
The decisive moment was the client accepting the MoSCoW categorisation of their requirements. For the first time, they distinguished between what they needed to go live and what they wanted — and agreed to sequence accordingly. That single shift turned an undeliverable scope into a credible plan.