Strategic enterprise programmes rarely fail overnight. They erode. Timelines slip by a sprint, then two. Scope becomes contested. Status reports keep showing amber, even though everyone in the room knows the reality is worse. And then one day, the client escalates to your CEO, and suddenly the programme is “red”, as if it happened without warning.
Except it didn’t. The warning signs were there for months. They were just ignored, rationalised, or buried in optimistic reporting.
After more than a decade of leading enterprise delivery for B2B platform vendors selling into banks, wealth managers, and telcos across Europe, I’ve seen this pattern repeat with striking consistency. The details differ (the product, the geography, the client), but the structural causes are almost always the same.
The Five Patterns That Kill Programmes
1. The Governance Gap
The most common root cause is the absence of basic delivery governance. No functioning Definition of Ready. No Definition of Done. No structured work-tracking discipline. The team is “agile” in name, but in practice, work enters the sprint unrefined, exits without clear acceptance criteria, and the defect backlog grows silently.
When I assess a distressed programme, the first thing I look for is whether the vendor and client teams share a common understanding of what “done” means. In most cases, they don’t. And that gap between what was delivered and what was expected becomes the foundation of every escalation.
It’s surprisingly basic, yet it remains the single most reliable predictor of whether a programme will end up in crisis.
2. The Trust Erosion
Once delivery starts slipping, trust follows. Client stakeholders lose confidence in the delivery team and start requesting direct access to your leadership for status updates. The conversation shifts from collaboration to oversight, and every missed commitment deepens the damage.
What makes this particularly dangerous is that trust erosion is rarely visible in a Jira dashboard. It lives in the tone of emails, the body language in steering committees, and the conversations your client has internally about whether to escalate. By the time you hear about it, the relationship is already in recovery territory.
I’ve seen programmes where the delivery metrics looked acceptable on paper, but the client had already decided to escalate because they no longer believed the numbers they were being shown.
3. The Scope Illusion
In most troubled programmes, the plan on paper no longer reflects reality. The scope was defined during the sales cycle, often with optimistic assumptions about the client’s readiness and the product’s fit. Then requirements shift, new stakeholders emerge, and the team absorbs changes silently rather than triggering a formal change control process.
The result is a growing gap between what was sold, what was planned, and what is actually being built. The timeline stays the same. The budget stays the same. But the work has expanded far beyond what either side originally agreed to. Nobody wants to be the one to raise the flag, because raising the flag means admitting that the original deal was flawed. So the illusion persists until reality forces a reckoning.
4. The Reporting Fog
Status reporting in troubled programmes is often fragmented, inconsistent, or deliberately optimistic. Different stakeholders receive different versions of reality. The delivery team reports green because they completed the sprint tasks. The project manager reports amber because the timeline is at risk. The client sees red because they’re not getting what they expected.
This reporting fog serves nobody. It delays hard conversations, allows problems to compound, and creates the conditions for a surprise escalation that should never have been a surprise.
In my experience, the moment you see three different status assessments from three different people in the same programme, you already have a governance failure, whether anyone has named it yet or not.
5. The Blame Spiral
When a programme is in trouble, blame becomes the default currency. Sales blames Professional Services for overpromising. PS blames Product for gaps in the platform. Product blames the client for unclear requirements. The client blames the vendor for everything.
And in the middle of this, nobody owns the recovery. Everyone is defending their position rather than solving the problem. This is the most visible symptom of a programme in crisis, and it’s the hardest to reverse without independent intervention.
The blame spiral is self-reinforcing: the longer it continues, the more entrenched each party becomes, and the less likely anyone is to propose a way forward that requires them to accept any share of responsibility.
What Recovery Actually Looks Like
Recovery is not about adding more people, working longer hours, or replacing the project manager. Those are the reflexive responses, and they almost never work.
Real programme recovery starts with an honest, independent assessment of the situation: the scope, the risks, the defect backlog, the governance structures, and the stakeholder dynamics. It requires someone who can look at the programme objectively, without the political baggage that comes from having been involved in the original sale or delivery.
From there, it’s about imposing structure where there is none: clear Definitions of Ready and Done, a triaged defect backlog, realistic milestones, transparent reporting, and a single point of accountability. It’s not glamorous work. It’s disciplined, methodical, and sometimes uncomfortable for everyone involved.
But it works. I’ve seen programmes that were headed for contract termination or legal escalation turn into controlled deliveries within six to eight weeks. Not by throwing resources at the problem, but by restoring the basics of delivery governance and rebuilding stakeholder trust one honest conversation at a time.
The common thread in every successful recovery I’ve led is this: the turnaround didn’t start with a new plan. It started with someone telling the truth about where things actually stood, and everyone in the room agreeing to work from that shared reality instead of the version they’d been reporting upwards.
Is Your Programme Showing These Signs?
If any of this sounds familiar, I’ve created a free Red Programme Diagnostic: a 10-question self-assessment designed to help you gauge whether your programme is heading for escalation before it gets there. It takes less than three minutes, and it will give you an honest reading of where you stand.
You can take it at mirkogrewing.com/diagnostic.
I’m Mirko Grewing. I help B2B software vendors recover escalated enterprise programmes with banks and telcos, and restore control and credibility. You can find my services and case studies on this website.
0 Comments