Cataloguing Strategic Innovations and Publications
Why I Killed Transformation Programs, And Saved Millions.
Sanjay K Mohindroo
After three decades leading enterprise IT, here's why killing the wrong transformation program can create more value than completing it.
The Transformation Programs I Have Killed, And Why It Was the Right Call
A CEO once asked me a question that changed the course of a nine-figure transformation.
"Are we too far in to stop now?"
My answer was immediate.
"No. We're just early enough to avoid making a very expensive mistake."
We shut the program down that week.
Months of work stopped. Several consulting teams left. Budgets were reallocated. People questioned the decision.
Eighteen months later, the company launched a completely different transformation. It was smaller, faster, tied directly to business priorities, and delivered measurable returns within the first year.
Killing the first program was not a failure.
It was one of the best transformation decisions we ever made.
That experience wasn't unique. Over nearly three decades leading enterprise technology across industries and regions, I have approved major transformation initiatives. I have rescued others. And yes, I have deliberately killed several.
Not because transformation is risky.
Because continuing the wrong transformation is far riskier.
The Dangerous Myth That Every Transformation Must Continue
Corporate culture has unintentionally created a dangerous belief.
Once a transformation starts, it must continue.
The thinking sounds reasonable.
"We've already invested millions."
"The Board has approved it."
"We've announced it internally."
"The implementation partner is already mobilized."
"We're halfway there."
None of those are business reasons.
They're emotional reasons.
They're symptoms of the sunk cost fallacy, one of the most expensive biases in executive decision-making.
Capital already spent should never determine future investment.
Future value should.
Yet organizations continue funding transformation programs that no longer solve the problems they were created to address.
That isn't leadership.
It's avoidance.
Technology Is Rarely the Real Problem
When transformations fail, technology usually receives the blame.
The platform wasn't mature.
The vendor underperformed.
Integration became too complex.
AI wasn't ready.
Cloud migration took longer than expected.
Those explanations are convenient.
They are rarely accurate.
The real problem is almost always strategic misalignment.
Technology projects begin as business initiatives.
Somewhere along the way, they quietly become technology delivery programs.
Success starts being measured by deployment milestones instead of commercial outcomes.
Suddenly the organization celebrates activities instead of results.
Applications are implemented.
Infrastructure is modernized.
Dashboards are built.
But customers don't notice.
Revenue doesn't improve.
Margins remain unchanged.
Decision-making stays slow.
Nothing meaningful has actually transformed.
The Meeting That Told Me Everything
One experience still stands out.
A global manufacturer operating across four continents had invested heavily in a multi-year digital transformation.
The steering committee reviewed progress every month.
Hundreds of milestones were reported.
Thousands of tasks had been completed.
Every dashboard was green.
Then I asked one question.
"What business metric has improved because of this program?"
The room went quiet.
Not because executives didn't know.
Because nobody had asked the question.
The transformation team could explain architecture.
They could explain implementation.
They could explain timelines.
Nobody could explain commercial value.
That was the moment I knew the program had lost its purpose.
The technology wasn't failing.
The governance was.
Why Boards Need Different Questions
Transformation governance often focuses on execution.
Is the program on schedule?
Is spending within budget?
Are milestones being achieved?
Those questions matter.
But they are secondary.
Boards should begin somewhere else.
Is the original business problem still important?
If we started today, would we fund this program again?
Has market reality changed?
Is this still our highest-return investment?
If those answers become uncertain, stopping deserves serious consideration.
The objective isn't finishing transformation.
The objective is creating enterprise value.
The Conventional Wisdom I Challenge
Conventional wisdom says this:
Successful leaders finish what they start.
I disagree.
Successful leaders finish what still deserves finishing.
Everything else should be questioned.
Persistence is admirable.
Persistence without evidence is expensive.
Business environments evolve faster than transformation roadmaps.
Competitive pressures shift.
Customer behavior changes.
Economic conditions tighten.
Regulatory priorities evolve.
Technology itself changes.
Programs designed three years ago often solve yesterday's problems.
Continuing them simply because they exist creates opportunity cost.
And opportunity cost rarely appears on project dashboards.
The Five Tests Before Every Major Transformation Continues
Over the years, I developed a simple executive framework.
Before approving another funding cycle, I ask five questions.
If several answers become "no," stopping becomes the responsible decision.
1. Does the Business Problem Still Matter?
Many programs continue solving problems that no longer exist.
Markets evolve.
Strategies change.
Customer expectations shift.
The first question should always be whether the original problem remains strategically important.
If the answer is no, the transformation has already become obsolete.
2. Can We Measure Business Value?
Technology metrics are not business metrics.
Servers migrated.
Applications deployed.
Users trained.
Those are implementation statistics.
Boards should instead ask:
Revenue increased by how much?
Operating cost reduced by how much?
Cycle time improved by how much?
Customer retention improved by how much?
If value cannot be measured, it probably isn't being created.
3. Would We Approve This Investment Today?
This may be the single most revealing question.
Ignore previous spending.
Ignore politics.
Ignore internal commitments.
If the proposal landed on today's investment committee agenda, would leadership approve it again?
If the answer is no, continuing makes little sense.
4. Is Leadership Still Personally Committed?
Transformation cannot survive executive indifference.
When senior leaders stop talking about outcomes and start asking only for status updates, momentum disappears.
Technology teams notice.
Business teams disengage.
The program becomes operational rather than strategic.
That is usually the beginning of decline.
5. Are We Creating Competitive Advantage?
Modernization alone isn't transformation.
Replacing old technology with newer technology may reduce technical debt.
That matters.
But competitive advantage comes from changing how the business competes.
Customers should experience something different.
Employees should make decisions differently.
Leaders should allocate capital differently.
If competitors can achieve the same outcome by buying the same software, you haven't transformed.
You've upgraded.
Those are not the same thing.
Isn't Killing a Transformation Too Risky?
A fair challenge.
Stopping a major initiative creates disruption.
It affects credibility.
It impacts people.
It may even attract uncomfortable Board conversations.
But continuing an ineffective transformation creates larger risks.
More capital disappears.
Management attention remains consumed.
Strategic opportunities are delayed.
Confidence erodes gradually instead of visibly.
Visible failure often gets attention.
Invisible waste quietly destroys enterprise value.
That's the greater danger.
The Best Transformations Often Start After the First One Ends
The transformation we cancelled years ago wasn't replaced by nothing.
It was replaced by clarity.
The organization redefined the business objective.
Investment became more focused.
Technology became an enabler rather than the destination.
The second transformation delivered in eighteen months what the first hadn't achieved after several years.
Not because execution improved dramatically.
Because strategy did.
That's an important distinction.
Good execution cannot rescue poor direction.
Leadership Means Knowing When to Stop
We often celebrate executives who launch ambitious initiatives.
We should spend more time recognizing leaders willing to stop them.
Stopping isn't surrender.
It's capital discipline.
It's strategic accountability.
It's evidence-based leadership.
The best CIOs, CEOs, and Boards I've worked with all shared one characteristic.
They were emotionally detached from programs but deeply committed to outcomes.
That's a powerful difference.
Programs exist to serve strategy.
Strategy does not exist to justify programs.
Too many organizations have forgotten that.
Perhaps it's time we remembered.
I'd be interested in your perspective.
Have you ever stopped a major transformation initiative? Looking back, was it the right decision, or do you wish you'd pushed through?
If this perspective resonates, subscribe to Technology Trends or join the conversation by leaving a comment.
Why Transformation Roadmaps Fail Within 90 Days.
Sanjay K Mohindroo
Most transformation roadmaps become obsolete within 90 days. Learn why adaptive governance beats rigid execution and how boards should respond.
Why Most Transformation Roadmaps Are Obsolete Within 90 Days
Every transformation roadmap looks impressive on the day it is approved.
Three months later, half of its assumptions are already wrong.
I have sat through more transformation steering committees than I can remember. The presentations were polished, the milestones were color coded, the investment cases were approved, and everyone left the room believing they had a clear path forward.
Yet the projects that succeeded rarely followed the roadmap that was originally approved.
The ones that failed usually did.
That sounds counterintuitive because conventional wisdom says successful transformation depends on following a disciplined plan. My experience tells me the opposite.
Successful transformation depends on knowing when to abandon the plan.
The problem is not that organizations spend too little time planning. It is that they mistake planning for certainty.
Markets change. Customers change. Competitors change. Technology changes. Regulation changes. Talent changes. Capital costs change.
Your roadmap does not.
That is why most transformation roadmaps are obsolete within ninety days.
Not because the strategy was poor.
Because the world refused to cooperate.
The Dangerous Illusion of the Perfect Roadmap
Boards like certainty.
Investors like certainty.
Finance teams like certainty.
Project Management Offices certainly like certainty.
So organizations create transformation roadmaps that attempt to remove uncertainty.
The irony is that transformation exists because uncertainty already exists.
A roadmap that assumes today's environment will still exist twelve months from now is not reducing risk.
It is hiding it.
Several years ago, I worked with the leadership team of a global manufacturer operating across four continents. The company approved a three-year technology transformation program with more than fifty strategic initiatives.
Every dependency had been mapped.
Every milestone had an owner.
Every investment had board approval.
Within twelve weeks, three major assumptions had already changed.
A competitor announced a significant acquisition.
Raw material costs rose sharply.
A key regulator introduced new compliance requirements in one of the company's largest markets.
Nothing in the roadmap had anticipated those events.
The organization faced a choice.
Continue executing the approved roadmap because governance required it.
Or rethink the priorities because reality had changed.
Fortunately, leadership chose the second option.
The roadmap changed.
The destination did not.
That distinction is where successful transformation begins.
Transformation Is Not a Construction Project
One reason organizations struggle is that they borrow planning models from industries where change is predictable.
If you are building a bridge, changing the blueprint every month is a terrible idea.
If you are transforming a business, refusing to change the blueprint is even worse.
Construction projects optimize for execution.
Business transformation optimizes for adaptation.
The two require fundamentally different leadership behaviors.
Yet many organizations still measure transformation success by asking questions such as:
- Are we delivering according to the original timeline?
- Are we spending according to budget?
- Are milestones still green?
Those are useful operational metrics.
They are poor strategic metrics.
The more important questions are different.
- Are our assumptions still valid?
- Has customer behavior changed?
- Has the competitive landscape shifted?
- Are we solving the highest-value problem today?
Those conversations happen far less often.
The Conventional Wisdom Is Wrong
The accepted view is simple.
Create a detailed roadmap.
Gain executive alignment.
Execute with discipline.
Minimize deviation.
I disagree.
Discipline should apply to outcomes, not plans.
The roadmap is only a hypothesis.
The business outcome is the objective.
Confusing those two creates enormous waste.
I have seen organizations continue funding initiatives because they appeared on last year's roadmap, even after the business case had disappeared.
Nobody wanted to admit that circumstances had changed.
The roadmap became a political document instead of a management tool.
That is not governance.
That is organizational inertia.
Why Roadmaps Expire So Quickly
Most transformation roadmaps are built around assumptions that are invisible.
The timeline is visible.
The assumptions are not.
Those assumptions usually include:
- Customer demand will remain stable.
- The competitive environment will remain broadly similar.
- Regulations will not materially change.
- Internal capabilities will develop as planned.
- Technology costs will follow expected trends.
- Capital allocation priorities will remain unchanged.
The problem is not that these assumptions exist.
Every strategy requires assumptions.
The problem is that organizations rarely revisit them with the same discipline they apply to project milestones.
They monitor progress.
They forget to monitor relevance.
Those are very different things.
The 90-Day Assumption Review Framework
Instead of asking whether the roadmap is on track, leadership should ask whether the assumptions behind the roadmap are still true.
I recommend a simple framework that every board can institutionalize.
Every ninety days, review five questions.
1. Which assumptions have changed?
List every major assumption made when the roadmap was approved.
Then identify which ones are no longer valid.
This sounds obvious.
Very few organizations actually do it.
2. What has changed outside the organization?
Competitors.
Customers.
Regulation.
Economic conditions.
Supply chains.
Technology maturity.
The external environment changes faster than internal governance.
Ignoring that gap creates strategic risk.
3. What have we learned from execution?
Transformation creates information.
Treat execution as a learning process rather than a delivery process.
If new evidence contradicts the original plan, the evidence should win.
Not the PowerPoint.
4. Where should capital move now?
Every transformation roadmap represents a capital allocation decision.
Capital should follow opportunity.
Not history.
Boards should feel comfortable stopping initiatives that no longer justify investment.
That is good governance, not failure.
5. Which priorities deserve acceleration?
Reviewing assumptions should not only identify what to stop.
It should identify what deserves more investment.
Some opportunities emerge unexpectedly.
The best organizations create enough flexibility to pursue them before competitors do.
Governance Should Reward Adaptation
Many governance structures unintentionally punish good decision-making.
Imagine a program sponsor who recommends stopping a major initiative six months after launch.
If leadership interprets that as failure, nobody will recommend stopping anything again.
Instead, they will continue spending money to protect reputations.
That behavior destroys value.
The better question is this:
What did we learn that justified changing direction?
The strongest leaders I have worked with never confused consistency with effectiveness.
They understood that changing course after learning something new is evidence of good leadership.
Not weak leadership.
But Doesn't Constant Change Create Chaos?
This is the obvious counterargument.
If organizations keep changing priorities, won't transformation become impossible?
Only if every decision changes.
That is not what I am advocating.
The destination should remain stable.
The route should remain flexible.
Think about modern navigation systems.
You enter a destination once.
The route updates continuously.
Nobody complains when the GPS recalculates.
In fact, we expect it to.
Business transformation should operate the same way.
Strategy defines where you are going.
Execution determines the best path based on current conditions.
What Boards Should Measure Instead
Most transformation dashboards still emphasize delivery metrics.
Completion percentage.
Budget utilization.
Milestone status.
Those metrics matter.
But they should not dominate board discussions.
Instead, boards should ask:
- How many original assumptions remain valid?
- Which initiatives have materially improved business outcomes?
- Where has capital been reallocated because new information emerged?
- What risks did we avoid by changing course early?
- Which new opportunities did we capture because governance allowed flexibility?
Those conversations create better decisions than another page of green status indicators.
The Best Roadmaps Are Designed to Change
After nearly three decades working with enterprise leaders across industries and regions, one lesson continues to stand out.
Transformation is not a project.
It is a sequence of decisions made under uncertainty.
The roadmap should support those decisions.
It should never replace them.
The best transformation leaders I have met are not the ones who followed the original roadmap most faithfully.
They are the ones who recognized early when reality had changed and dared to adapt before everyone else did.
That is not poor planning.
That is strategic leadership.
Because in business, the greatest risk is rarely changing direction.
It is following yesterday's roadmap into tomorrow's market.
What has been your experience? Have you ever seen a transformation succeed because leadership changed the roadmap early, or fail because it refused to? I'd be interested to hear where you've seen this play out.
If this perspective resonates, follow Technology Trends for practical, experience-led insights that cut through the hype and focus on what actually matters in IT.
#Leadership #BoardGovernance #DigitalTransformation #BusinessStrategy #CIO #TechnologyLeadership #EnterpriseTransformation #CorporateStrategy #ChangeManagement #BusinessTransformation #ExecutiveLeadership #InnovationStrategy #ITLeadership #Governance #TechnologyTrends