In my twenty years of leading technology transformations, I’ve been called into some of the most high-pressure environments on the planet. From $200M enterprise portfolios to mission-critical public sector platform migrations, the mandate is usually the same: "Kunal, it’s broken. Fix it."
At Dark Consultancy, we pride ourselves on an execution-first mindset. We don't do slide-deck consulting; we do programme rescue consulting. But here is the uncomfortable truth that most consultants won't tell you: Not every programme wants to be saved.
Recent data from McKinsey and the Standish Group shows that roughly 70% of digital transformations still miss their objectives. While technology is often the scapegoat, the root cause is almost always leadership, culture, and the systemic refusal to face the truth.
I’ve had to walk away from three major programmes in my career. Not because the technology was impossible to fix, but because the leadership preferred a comfortable lie over an uncomfortable recovery.
Here are those stories and the lessons they hold for every CIO and CTO.
1. The £120M Government Platform: The "Green Dashboard" Trap
A few years ago, I was brought into a massive public sector modernisation initiative. The budget was £120M, and they were eighteen months into a three-year timeline. On paper, everything was "Green." The dashboards were glowing. The steering committee was smiling.
But when we looked under the hood during our Delivery Diagnostic, we found a "Watermelon" programme: green on the outside, but deep red in the middle. The vendor had stopped delivering functional code months ago, the technical debt was mounting, and the core architecture was fundamentally flawed.
I presented a blunt recovery plan: stop the current sprint, reset the architecture, and have a difficult conversation with the vendor about performance.
The sponsor’s response? "Kunal, I don't need a recovery plan. I need a progress report that keeps the board happy."
They chose the vendor who promised to "get back on track" without changing a single process. They chose the comfortable story. Six months later, the programme was halted by the National Audit Office.
The Lesson for CIOs: A dashboard is not delivery. If your governance doesn't allow for the truth, your delivery governance consulting is just theatre. You cannot fix what you refuse to see.
2. The Global Bank: Death by 14 Layers of Approval
In the world of financial services, risk is everything. But in this specific bank’s core modernisation programme, "risk management" had turned into terminal bureaucracy.
We were tasked with accelerating the delivery of a new cloud-native ledger system. However, we quickly discovered that a single infrastructure change: something that should take minutes in a modern environment: required fourteen levels of manual approval across six different departments.
It wasn't a technology problem; it was a governance problem. I told the CIO that unless they collapsed these silos and empowered the delivery teams, the programme would collapse under its own weight.
The bank’s culture was so entrenched in "defensive decision-making" that no one was willing to sign off on a leaner governance model. They were more afraid of making a mistake than they were of failing the entire transformation.
Eighteen months later, the programme was cancelled after spending $40M with zero production deployments.
The Lesson for CIOs: Governance should be a catalyst for speed, not a handbrake. If your PMO is more focused on policing than enabling, you need to rethink your approach to PMO as a Service.
3. The Energy Trading Platform: The Captured PMO
The third programme I couldn't save was a high-stakes energy trading platform. Here, the issue was "Vendor Capture."
The primary systems integrator had been on-site for so long that they had effectively become the PMO. They were marking their own homework. When I pointed out that the vendor’s delivery velocity was 40% lower than industry benchmarks and their "unique" technical challenges were actually standard problems they were over-engineering, the client wasn't ready for the confrontation.
The relationship between the internal IT leads and the vendor had become so personal and enmeshed that a critique of the vendor was seen as a critique of the client’s own management.
We walked away when it became clear that the client was more interested in protecting the relationship than delivering the platform.
The Lesson for CIOs: Your failed IT programme recovery starts with objectivity. If your internal teams are too close to your vendors, you lose the ability to hold anyone accountable. You need an independent partner who isn't afraid to tell you when your "trusted partner" is actually the problem.
Why We Walk Away (And Why We Usually Stay)
At Dark Consultancy, we are practitioners, not theorists. We measure our success by business outcomes, not billable hours. This means that if an organisation isn't ready to face the truth, we aren't the right partner for them.
However, for the CIOs and CTOs who do want the truth: the ones who are tired of the Junior Tax and the "Watermelon" dashboards: we have a 100% success rate on the programmes we take on.
The 3 Signs Your Programme Needs a Real Rescue
If you are seeing these signs, don't wait for the comfortable story to fail:
- The Dashboard Disconnect: The status is green, but the users are complaining and the features aren't landing.
- The Decision Stall: It takes longer to get a decision approved than it does to write the code.
- The Vendor Echo Chamber: Your PMO sounds exactly like your systems integrator.
Final Thoughts
Saving a programme is rarely about the code. It’s about the courage to dismantle the structures that caused the failure in the first place. It’s about moving from "management by slides" to "leadership by execution."
If you’re leading a programme where failure is not an option, let’s have a real conversation. Not a pitch, just the truth.
FAQ: Failed IT Programme Recovery
What is the first step in a programme rescue?
The first step is always a Delivery Diagnostic. You cannot fix what you don't understand. We spend 14 days looking at the people, processes, and tools to find the real bottlenecks: not just the ones on the status report.
Why do most IT programme recoveries fail?
Most recoveries fail because they only address the symptoms (hiring more developers, changing a tool) rather than the root cause (governance, leadership alignment, or vendor capture).
How do I know if my programme is "beyond saving"?
No programme is technically beyond saving, but some are culturally beyond saving. If the executive leadership is unwilling to change the governance model or hold vendors accountable, no amount of technical expertise will fix the outcome.
What is "Vendor Capture" in consulting?
Vendor capture occurs when a consulting partner or systems integrator becomes so deeply embedded in a client’s PMO and decision-making processes that the client loses the ability to manage them objectively.
About the Author
Kunal Patel : CEO & Founder, Dark Consultancy
Kunal Patel founded Dark Consultancy after two decades leading technology and transformation programmes across the public sector, financial services, defence, and energy industries. He has directly managed programme recovery engagements for government agencies, development finance institutions, and regulated enterprises across the US, Middle East, South Asia, and Southeast Asia ; ranging from $5M platform migrations to $200M+ enterprise transformation portfolios. Kunal is a recognised practitioner in delivery governance for regulated environments and holds PMP and PRINCE2 Practitioner certifications. He leads every new client engagement personally and remains accountable throughout the programme lifecycle. Connect with Kunal on LinkedIn