At BCG, I worked on transformation programs where the strategy deck was brilliant — hundreds of slides, clear logic, compelling ROI projections. Eighteen months later, the client would be 30% through the roadmap, over budget, and quietly wondering whether to pull the plug.
Then I went to Razorpay and BrowserStack. Fast-moving companies. No transformation “programs” — just continuous change, sprint by sprint, with immediate accountability. Things shipped. Things broke. Things got fixed. The contrast was striking.
The lesson I took from both experiences: transformation fails because of execution design, not technology selection. The technology almost always works. The organization around it usually doesn’t.
The Four Failure Patterns
After seeing enough of these programs — from both the advisor side and the operator side — the failure patterns are remarkably consistent:
1. Technology-led strategy. Someone decides “we need to move to the cloud” or “we need an AI platform” without first defining what business outcome they’re trying to achieve. The technology decision precedes the business decision. This is backwards, and it leads to expensive infrastructure that nobody knows how to use for anything that matters.
2. Roadmaps without owners. The transformation roadmap exists as a beautiful Gantt chart. Everyone nods at the steering committee. Nobody owns specific outcomes. When things slip, there’s no individual who feels personally responsible. At Razorpay, every initiative had a single owner who presented weekly. The accountability was uncomfortable and effective.
3. “Change management” as communication. Most transformation programs treat resistance as a messaging problem. “People just need to understand the vision.” No. People resist change because their incentives, skills, and daily workflows aren’t aligned with the new reality. That’s a structural problem, not a communication one. Fix the structure, and the messaging takes care of itself.
4. Vendor dependency by accident. This one is insidious. It starts with a reasonable vendor selection, then scope creep, then institutional knowledge concentrating at the vendor, then the realization that switching would cost more than the original project. By the time leadership notices, the vendor effectively controls the transformation timeline. I’ve seen this pattern at government institutions where the vendor relationship outlived the original contract by years.
What Works Instead
Start with a 90-day horizon, not a 3-year one. Long-range roadmaps are necessary for budgeting, but they’re terrible for execution. The teams doing the work should be focused on what they’re delivering in the next 90 days, with clear milestones and visible progress. Course corrections happen quarterly, not annually.
Measure business outcomes, not project milestones. “Platform migration complete” is not a business outcome. “Customer onboarding time reduced from 14 days to 3 days” is. “60% of support tickets now resolved by AI” is. If your transformation metrics can’t be stated in terms a CFO cares about, they’re the wrong metrics.
Do vendor due diligence like you’re buying a company. Before committing to a major technology vendor, examine: What’s the total cost of ownership over 5 years, including migration, training, and customization? What’s the exit cost if the vendor underperforms? How dependent will you become on their professional services team? What happens if they get acquired? Most organizations evaluate vendors on feature checklists. That’s necessary but insufficient.
Build internal capability from day one. Every transformation program should be reducing dependency on external help over time, not increasing it. If your team can’t explain how the new system works six months after implementation, the transformation hasn’t really happened — you’ve just outsourced the problem.
The Due Diligence Most Organizations Skip
There’s a type of technology due diligence that almost nobody does well: evaluating a vendor’s claims against real-world performance with organizations similar to yours. Reference calls with the three clients the vendor recommends are worthless — of course those went well. The real signal is in the references the vendor doesn’t volunteer, the implementations that ran over budget, and the customers who switched away.
When we do technology due diligence, we look at four things that matter more than the demo: integration complexity with your existing stack, vendor staff turnover on your account, contract terms around price increases and exit, and the gap between the reference architecture and what you’ll actually deploy. The demo is the least informative part of the evaluation.
The Leadership Question
Transformation is a leadership exercise disguised as a technology project. The technology decisions matter, but they’re downstream of harder questions: Are we willing to change how we work? Can we hold people accountable for specific outcomes? Will we make the organizational changes that the new technology requires?
If the answer to those questions is “not really,” save the budget. No platform can compensate for an organization that isn’t ready to change how it operates.