Cataloguing Strategic Innovations and Publications
Reviving a Stalled Digital Transformation
Sanjay K Mohindroo
Learn a practical board-level recovery playbook to revive stalled digital transformation initiatives before more capital, time, and credibility are lost.
Reviving a Stalled Transformation: A Recovery Playbook
Every transformation looks successful until the board asks one question.
"What business value have we actually captured?"
I remember sitting in a steering committee with the executive team of a global manufacturer operating across four continents. The transformation had been running for nearly three years. More than $180 million had been committed. Hundreds of milestones had been marked green. Every dashboard looked healthy.
Revenue growth had not moved. Operating margins were flat. Customer complaints had increased. The CEO looked around the room and asked a simple question.
"So what exactly did we transform?"
Silence.
That moment reinforced something I have seen repeatedly across three decades.
Most transformations do not fail because execution stops. They fail because the organization keeps executing long after the original business problem has disappeared, changed, or become irrelevant.
The conventional wisdom says a stalled transformation needs more funding, stronger governance, or a new technology platform.
I disagree.
A stalled transformation rarely needs more momentum.
It needs permission to stop doing the wrong work.
Why Most Transformation Recovery Efforts Fail
When a transformation stalls, organizations almost always respond in predictable ways.
They create another steering committee.
They hire another consulting firm.
They add new reporting dashboards.
They launch an executive "reset."
None of this address the real problem.
A stalled transformation is rarely an execution issue. It is usually an alignment issue.
Somewhere along the journey, the organization quietly shifted from solving business problems to protecting transformation activity.
Projects become objectives.
Milestones become success.
Budgets become commitments that nobody wants to challenge.
By the time leaders recognize this, the transformation has become its own customer.
The Hidden Cost of Continuing
Stopping a transformation is politically difficult.
Continuing one is financially dangerous.
Every quarter spent funding initiatives that no longer support strategic priorities creates three invisible costs.
First, capital becomes trapped.
Second, leadership attention disappears into governance rather than growth.
Third, employees lose confidence because they see effort without impact.
The biggest risk is not wasted technology investment.
It is organizational credibility.
Once people stop believing transformation creates value, every future initiative becomes harder.
Transformation Recovery Starts with One Question
Whenever I have helped executive teams recover struggling programs, the first workshop never begins with project status.
It begins with one question.
If we were starting today, knowing what we know now, would we approve this transformation again?
Boards rarely ask this.
They should.
Because transformation decisions should not be protected by sunk costs.
They should compete against today's priorities.
That single question changes the conversation.
Instead of defending yesterday's decisions, leaders begin evaluating tomorrow's opportunities.
The Recovery Playbook
Over the years, I have found that successful recoveries usually follow the same pattern.
Not because organizations copy one another.
Because leadership eventually returns to the same business fundamentals.
Step 1. Re-establish the Business Problem
Many transformations continue solving problems that no longer exist.
Markets evolve.
Customers change.
Competitors move faster than expected.
Regulation shifts.
The first responsibility is to redefine the business problem.
Not the technology roadmap.
Not the implementation schedule.
The business problem.
If executives cannot describe the problem in one sentence, the transformation has already lost direction.
Step 2. Separate Activity From Value
Transformation offices love activity metrics.
Projects completed.
Systems deployed.
Users trained.
These measure effort.
Boards should measure value instead.
Examples include:
- Revenue acceleration
- Margin improvement
- Customer retention
- Cycle time reduction
- Capital efficiency
- Risk reduction
Every initiative should clearly explain which business outcome it improves.
If nobody can answer that question, stop funding it until they can.
Step 3. Kill Projects Without Regret
This is the hardest leadership decision.
It is also the most important.
In one multinational organization, nearly 30 percent of active workstreams were paused after executive review.
Initially, leaders feared backlash.
Instead, delivery accelerated.
Why?
Because talented people finally focused on work that mattered.
Stopping projects is not failure.
Continuing irrelevant projects is.
Step 4. Simplify Governance
One organization I worked with had thirteen governance forums reviewing the same transformation.
Every decision required multiple approvals.
Everyone owned governance.
Nobody owned outcomes.
Recovery required eliminating nearly half the governance structure.
Decision-making became faster.
Accountability became visible.
Transformation accelerated.
Complex governance often exists because leaders no longer trust the transformation.
Ironically, it usually slows recovery further.
Step 5. Reset Executive Accountability
Technology teams cannot deliver business transformation alone.
Nor should they.
Every major business outcome should have a business executive accountable for value realization.
Not just project completion.
The CIO owns technology.
The business owns business value.
Those are different responsibilities.
Too many organizations blur them together.
The Board Recovery Framework
When boards review struggling transformations, I recommend asking five simple questions.
1. Is the original business problem still relevant?
If not, redesign the transformation.
2. Which initiatives directly improve measurable business outcomes?
If nobody knows, pause funding.
3. Which projects would we never approve today?
Stop them.
4. Where is governance creating delay instead of clarity?
Remove unnecessary approvals.
5. Who owns value after implementation?
If ownership ends at system go-live, recovery has already failed.
Simple questions often produce uncomfortable answers.
That is exactly the point.
The Counterargument
Some executives argue that stopping projects damages morale.
My experience suggests the opposite.
Employees rarely become disengaged because priorities change.
They become disengaged because leaders refuse to acknowledge reality.
People know when projects have stopped creating value.
Continuing them simply tells the organization that appearances matter more than outcomes.
Honest course correction builds trust.
Pretending everything is on track destroys it.
Recovery Is a Leadership Exercise
Technology can restart systems.
Consultants can redesign roadmaps.
Program offices can rebuild governance.
Only leadership can restore confidence.
The strongest recoveries I have witnessed shared one characteristic.
The CEO publicly acknowledged what was not working.
Not to assign blame.
To create permission for better decisions.
That single act often unlocked more progress than months of additional planning.
Transformation is not about proving previous decisions were correct.
It is about making today's decisions better than yesterday's.
That requires courage.
Not because recovery is technically difficult.
Because admitting that something needs to change is one of the hardest leadership decisions in business.
The organizations that recover fastest are rarely those with the best technology.
They are the ones willing to challenge their own assumptions before competitors do it for them.
The real transformation begins when leaders stop asking how to finish the programme and start asking whether they are still solving the right problem.
What has been the biggest reason you've seen a transformation stall: poor execution, changing business priorities, weak leadership, or something else?
If this perspective resonates, subscribe to TechnologyTrends or join the discussion in the comments.
What Don't We Know?
Sanjay K Mohindroo
Rethinking What AI Should Actually Do for Litigation
A litigator I once spoke with described the worst moment in any case this way: it isn't the day you lose an argument in court. It's the day, often late in preparation, when you realize there's a question about your own case that nobody ever answered, and you have no way of knowing whether opposing counsel already has.
It's rarely because anyone hid anything. It's because a real case file isn't a handful of documents you can hold in your head. It's thousands of pages: pleadings, emails, messages, financial records, scanned exhibits, witness statements. Somewhere in that volume, a question sits unasked.
Not what does this document say?
But what haven't we looked for yet?
That distinction is the starting point for a system I've been designing, and it's why I think there is still an important problem for legal AI to solve.
The limits of the "answer machine"
Today's legal AI tools can do remarkable things. They can search enormous document sets, summarize depositions, identify clauses, build timelines, help draft submissions, and surface information that would otherwise take hours to find.
But many of those workflows still begin in the same place: with a question the lawyer already knows to ask.
"Summarize this deposition."
"Find every clause referencing termination."
"Show me communications between these two people."
"Draft a response to this motion."
The system may answer extremely well. But the interaction remains largely reactive.
In litigation, that is a narrower kind of help than it first appears.
Cases are not always weakened by a document nobody read. Sometimes they are weakened by a document nobody thought to go looking for, a contradiction nobody cross-checked, an assumption everyone treated as settled, or a gap in the evidentiary chain that only becomes obvious once opposing counsel points it out in front of a judge.
An AI system that waits entirely for the right question can still miss this category of risk.
Because nobody asked.
A different question: what don't we know?
The idea I've been designing around inverts the usual approach.
Instead of only answering what the evidence says, the system should also actively surface what the available evidence doesn't establish, and flag that gap as something requiring attention rather than treating silence as an answer.
Imagine that, for every material proposition in a case, the system maintains something like this:
Claim: The disputed communication was sent by the account holder.
Evidence currently available: Login record, email metadata, one witness statement.
Evidence potentially missing: Authentication logs, device history, IP records, provider access logs covering the relevant period.
Why the gap matters: The available material may establish that the account was used, but not necessarily that a particular person or device sent the communication. Attribution therefore remains contestable.
Recommended next step: Determine whether provider or device-access records exist for the relevant period and, if appropriate, seek them before they become unavailable.
This is a small example, but the pattern can generalize across an entire case.
Every witness statement. Every contested date. Every material allegation. Every proposition resting on only partial documentary support.
The output isn't simply another narrative summary of the case.
It's a structured map of where the case stands, where the evidence is strong, and where it does not yet stand at all.
But how does a system know something is missing?
This is the difficult part.
A system cannot call something "missing" unless it has some basis for believing that the evidence should exist, might ordinarily exist, or would be relevant to establishing the proposition in question.
That requires more than semantic search.
For each material proposition, the system would need to reason about the kinds of evidence that could support or undermine it: documentary records, communications, system logs, witness testimony, financial trails, timelines, approvals, provenance, authentication, or other evidence depending on the nature of the case.
In other words, the task is not merely:
What documents do we have?
It is also:
What would we ordinarily expect to examine before treating this proposition as established?
That distinction matters.
The system should not invent evidence that ought to exist. Nor should it present an absent record as proof of anything. It should identify an unresolved evidentiary question, explain why that question follows from the material already available, and let the lawyer determine whether the gap is real, relevant, obtainable, or immaterial.
This is less about magically discovering every "unknown unknown" in a case.
It's about systematically turning some unknown unknowns into known unknowns while there is still time to investigate them.
Why gaps matter more than answers
Opposing counsel's job, in an adversarial system, is in significant part to find these weaknesses precisely: the places where your case rests on an inference, an assumption, an incomplete chain of evidence, or a witness whose account doesn't quite align with the documents.
The earlier your own side identifies those weaknesses, the more options you have.
You may obtain the missing evidence.
You may discover that the evidence doesn't exist.
You may reconsider part of the theory of the case.
Or you may decide that the gap cannot be closed and prepare a considered response to it before somebody else raises it.
A system that only tells you what you already have can make preparation faster.
A system that also tells you what you may still need could make preparation different.
It changes the question from:
"Have we read everything?"
to:
"What would we still need to know before we were comfortable defending this proposition?"
Then attack your own case
There is a related capability that I think matters just as much, but it is slightly different.
Finding gaps is one task.
Actively exploiting them is another.
Once the system has mapped the claims, evidence, contradictions and unresolved questions in a case, it should be capable of switching sides.
If instructed to act as opposing counsel, how would it attack the case?
Which witness accounts conflict?
Which propositions rely disproportionately on one source?
Which dates don't reconcile?
Which documents support an inference without actually proving it?
Where is causation assumed?
Where is attribution uncertain?
What would a hostile cross-examination focus on?
What alternative interpretation of the same evidence could reasonably be advanced?
The purpose wouldn't be to predict exactly what opposing counsel will say. It would be to subject your own case to structured adversarial pressure before somebody else does.
These are therefore two related but distinct functions:
Gap detection: What haven't we established yet?
Adversarial testing: Given what we have established, how could someone attack it?
The goal of both is the same: surface risk while there is still time to do something about it.
What this isn't
This kind of system should not be presented as a replacement for legal judgment.
Quite the opposite.
Every gap it identifies, every contradiction it flags, and every vulnerability it suggests should be traceable to the material from which the conclusion arose.
A lawyer should be able to move from an AI-generated observation directly to the relevant document, page and passage and see exactly why the system raised it.
If the system says two accounts contradict each other, show both.
If it says a proposition is supported only indirectly, show the chain of evidence.
If it suggests that a particular category of evidence might be missing, explain why that evidence would matter.
And where the system is uncertain, it should say so plainly.
There is an important difference between:
"The evidence does not establish this."
and
"Based on the material currently available to the system, I cannot establish this."
Legal AI needs to understand that distinction.
Evidence-grounded and verifiable versus persuasive but unverifiable is, in my view, one of the lines separating an AI tool that genuinely reduces risk from one that quietly introduces new risk into a case.
Where this goes next
This is currently a design, not a finished product, and I think that's the honest way to describe it.
Before building further, I want to test the underlying problem against how litigators, in-house counsel and law firms actually work today.
How do legal teams currently identify gaps in large case files?
At what stage do they usually discover that something important is missing?
How much of this happens systematically, and how much depends on the instincts and experience of individual lawyers?
What tools already help?
Where do those tools fall short?
And, most importantly, would a system that continuously maps evidentiary gaps and stress-tests the case actually change how lawyers prepare, or would it simply become another dashboard nobody has time to look at?
If you litigate, manage a firm's caseload, work in-house, or have been on the other side of one of these late-discovered gaps as a litigant, I'd like to hear about it.
What's the moment in your own case preparation where you most wished you'd known what you didn't know?
Those conversations, rather than my own assumptions about the problem, should decide whether this is worth building and what it should actually do first.
Reach out at info@usscpartners.com. I'm setting up a handful of conversations with practicing lawyers over the next few weeks.
Transformation Success Metrics That Actually Matter
Sanjay K Mohindroo
Most transformation metrics measure delivery, not business impact. Discover the framework boards should use to assess true transformation success.
The Uncomfortable Truth About Transformation Success Metrics
Two weeks before a board meeting, a CEO asked me a simple question.
"Can we finally call this transformation a success?"
The programme had consumed more than three years, several hundred million dollars in investment, multiple consulting firms, and countless executive reviews. Every dashboard was green. Every milestone had been achieved. Adoption metrics exceeded targets. The ERP was live. The cloud migration was complete.
Yet revenue growth had stalled. Operating margins had barely moved. Customer complaints were rising. Competitors were pulling ahead.
The uncomfortable truth was obvious to everyone in the room, but nobody wanted to say it aloud.
The transformation had been delivered.
The business had not transformed.
After nearly three decades of leading technology organizations across industries and geographies, I have come to believe that we measure the success of transformation almost entirely the wrong way.
The conventional wisdom says successful transformation is about delivering programmes on time, within budget, and according to plan.
My experience tells me something very different.
Transformation should never be measured by what was delivered.
It should be measured by what became possible.
Why Most Transformation Metrics Are Designed to Impress, Not Inform
Walk into almost any executive steering committee, and you will see familiar measures:
- Percentage of applications migrated
- Cloud adoption rates
- Number of users trained
- Projects completed
- Budget variance
- Milestone completion
- System availability
These are useful operational metrics.
They are not transformation metrics.
They tell you whether a programme office executed efficiently. They do not tell you whether shareholders received value from the investment.
That distinction matters.
Boards do not approve transformation budgets because they want new systems.
They approve them because they expect stronger competitive positioning, improved economics, faster growth, lower risk, or greater resilience.
Technology is simply the vehicle.
Somewhere along the journey, many organizations begin celebrating the vehicle instead of checking whether they reached the destination.
The Board Only Cares About Four Questions
Across hundreds of executive discussions, I have noticed something interesting.
Regardless of industry, geography, or company size, board members usually come back to four simple questions.
Are we growing faster?
Are we operating better?
Are we reducing risk?
Are we creating options our competitors do not have?
Notice what is missing.
Nobody asks how many workloads were migrated.
Nobody asks how many agile squads were created.
Nobody asks how many AI pilots were launched.
Those are management activities.
Boards invest for business outcomes.
A Transformation That Looked Perfect
Several years ago, I worked with a large multinational organization operating across four continents.
The transformation office reported exceptional performance.
Programme milestones exceeded expectations.
Technology debt was reduced significantly.
Legacy platforms were retired.
Employee adoption surpassed ninety percent.
Every steering committee ended with congratulations.
Eighteen months later, the CEO commissioned a strategic review.
The conclusion was uncomfortable.
Product development cycles had not improved.
Customer acquisition costs remained unchanged.
Decision-making was still slow.
Regional businesses continued operating independently despite shared platforms.
Technology had changed.
Business behaviour had not.
Nobody had asked the most important question throughout the programme.
"What specific business capability will this investment create?"
Without answering that question first, every success metric became an exercise in measuring activity instead of impact.
The Transformation Success Pyramid
After years of seeing organizations repeat the same mistake, I now use a much simpler framework.
I call it the Transformation Success Pyramid.
Level 1: Delivery Success
Did we deliver what we promised?
This includes scope, budget, timeline, quality, security, and operational stability.
Necessary.
Never sufficient.
Level 2: Adoption Success
Did people actually change how they work?
This includes utilization, process adherence, productivity improvements, and behavioural change.
Many programmes stop here.
They should not.
Level 3: Business Performance
Did measurable business outcomes improve?
Examples include:
- Revenue growth
- Operating margin
- Customer retention
- Market share
- Cash conversion
- Product launch speed
- Cost to serve
Now the conversation starts becoming meaningful.
Level 4: Strategic Advantage
This is the level almost nobody measures.
Ask questions like:
- Can we enter new markets faster?
- Can we integrate acquisitions more rapidly?
- Can we launch products competitors cannot?
- Can we respond to regulatory changes with less disruption?
- Have we fundamentally improved decision speed?
These are the outcomes that justify transformation investments.
Everything below this level simply enables them.
The Biggest Mistake CEOs Make
Many CEOs unintentionally create the wrong incentives.
Transformation leaders are rewarded for delivering programmes.
Business leaders are rewarded for quarterly performance.
Nobody owns connecting the two.
The result is predictable.
Technology teams optimize delivery.
Business units continue operating as before.
Transformation becomes another large capital project rather than a strategic capability.
The accountability gap is rarely discussed.
It should be one of the first board conversations.
Stop Measuring Outputs, Start Measuring Capability
One of the most valuable shifts I have seen is replacing output metrics with capability metrics.
Instead of asking:
"How many systems did we modernize?"
Ask:
"How much faster can we launch a new product?"
Instead of asking:
"How many workflows were automated?"
Ask:
"How much management capacity has been redirected toward growth?"
Instead of asking:
"How many AI models were deployed?"
Ask:
"Which strategic decisions are now materially better because of AI?"
Outputs describe activity.
Capabilities describe competitive advantage.
What About Compliance and Infrastructure Programmes?
This is the obvious counter-argument.
Not every transformation directly increases revenue.
Some programmes are driven by cybersecurity, regulation, resilience, or infrastructure renewal.
That is absolutely true.
But even these investments deserve better metrics.
Instead of saying:
"We implemented zero trust."
Measure:
- Reduction in business interruption risk
- Reduction in expected financial exposure
- Faster recovery times
- Lower insurance costs
- Higher regulatory confidence
- Reduced operational disruption
Every investment should connect to business value.
Sometimes that value is growth.
Sometimes it is resilience.
Both matter.
Five Questions Every Board Should Ask Before Approving Transformation
Before approving another major programme, I believe every board should insist on clear answers to five questions.
1. What business capability will exist after this investment that does not exist today?
If nobody can answer this clearly, stop.
2. Which executive owns the business outcome?
Not the CIO.
Not the PMO.
The executive accountable for the commercial result.
3. Which metrics disappear after go-live?
If success ends when implementation finishes, it was never a transformation metric.
Business metrics should continue for years.
4. What competitive advantage will this investment create?
Every major investment should improve position, speed, economics, resilience, or optionality.
If none of these improve, why invest?
5. What would shareholders notice?
This is perhaps the simplest test.
Would an investor eventually see evidence of this transformation in financial performance, market position, customer experience, or strategic flexibility?
If not, the organisation may simply have modernized technology rather than transformed the business.
Transformation Is a Means, Never the End
Technology leaders often inherit programmes that are already measured incorrectly.
Changing those measures requires courage.
It means replacing comfortable dashboards with uncomfortable conversations.
It means telling boards that every milestone being green does not necessarily mean the investment is working.
It means asking business leaders to own outcomes rather than simply sponsor projects.
Most importantly, it requires remembering why organizations transform in the first place.
Customers do not care whether your systems are cloud native.
Investors do not reward ERP implementations.
Markets do not respond to migration percentages.
They respond to companies that become faster, smarter, more resilient, and harder to compete against.
Transformation is successful only when the business itself changes.
Everything else is implementation.
What metrics does your organization use to define transformation success, and do they truly measure business transformation or simply programme delivery?
If this perspective resonates, subscribe to TechnologyTrends or share your thoughts in the comments. The most valuable conversations usually begin with uncomfortable questions.
#Leadership #DigitalTransformation
#BusinessStrategy #CIO #CEO #BoardLeadership #EnterpriseIT
#TechnologyLeadership #BusinessTransformation #ITStrategy #CorporateGovernance
#DigitalLeadership
Why Every Transformation Needs a Stop Doing List
Sanjay K Mohindroo
Most transformation programs fail because they add instead of subtract. Learn why every successful transformation starts with a disciplined stop-doing list.
Why Your Transformation Needs a "Stop Doing" List Before a "Start Doing" List
A few years ago, I sat in a board review where a transformation program had crossed its third anniversary.
The company had invested well over nine figures. Every steering committee showed progress. Every workstream was marked green. Yet the CEO asked one simple question: "Why does the business still feel exactly the same?"
Nobody had an answer.
The uncomfortable truth was that the transformation had become another layer of the business instead of replacing the old one.
This is far more common than most organizations admit.
When executives talk about transformation, the conversation almost always begins with what needs to be built. New platforms. New operating models. New capabilities. New teams. New governance.
Very few leadership teams begin with a much harder question.
What are we willing to stop doing?
That, in my experience, is the real measure of transformation.
The Most Dangerous Assumption About Transformation
Conventional wisdom says transformation is about change.
I disagree.
Transformation is about subtraction.
Organizations rarely fail because they started too few initiatives. They fail because they never retired enough of the old ones.
Every new platform introduced while legacy systems remain.
Every new governance committee created without removing an existing one.
Every AI initiative layered on top of outdated processes.
Every dashboard added while nobody agrees which one drives decisions.
Transformation becomes expansion.
Not simplification.
Boards often celebrate activity because activity looks like progress.
Markets reward outcomes.
There is a significant difference.
Complexity Is the Hidden Tax Nobody Measures
One global manufacturer operating across four continents asked why operating costs kept increasing despite multiple successful technology programs.
The answer wasn't poor execution.
Each initiative had delivered what it promised.
The problem was accumulation.
Over seven years the organization had added:
- New ERP capabilities
- Two analytics platforms
- Multiple workflow systems
- Additional governance forums
- Regional reporting structures
- New approval layers
Almost nothing had been retired.
The organization wasn't running one operating model.
It was running five generations of operating models simultaneously.
Every transformation had added complexity without removing complexity.
Technology wasn't the issue.
Leadership discipline was.
Every Transformation Creates Organizational Debt
We often discuss technical debt.
Far less attention is given to organizational debt.
Every transformation leaves behind assets that continue consuming time, capital, and management attention:
- Legacy applications
- Duplicate reports
- Parallel approval structures
- Shadow processes
- Temporary project offices that become permanent
- Steering committees whose original purpose no longer exists
None of these individually create major problems.
Collectively, they slow decision-making, increase operating costs, and reduce accountability.
Most importantly, they make the next transformation even harder.
The Wrong Success Metrics
Many transformation programs celebrate:
- Systems implemented
- Users trained
- Features released
- Milestones achieved
- Budget utilization
These are delivery metrics.
Boards should care equally about elimination metrics.
How many systems were retired?
How many approvals disappeared?
How many reports stopped being produced?
How many meetings no longer exist?
How much organizational complexity was permanently removed?
Those numbers tell you whether transformation actually changed the business.
Your "Stop Doing" List Is a Capital Allocation Strategy
Every activity consumes resources.
Time.
Money.
Leadership attention.
Political capital.
When leaders refuse to stop old activities, they quietly reduce the return on every new investment.
Imagine buying a modern manufacturing plant while continuing to operate the old factory beside it indefinitely.
No board would approve that.
Yet organizations routinely do exactly that with business processes and technology.
Transformation isn't only about funding the future.
It is equally about defunding the past.
That is a governance decision, not an IT decision.
A Framework Boards Can Use
Whenever I review transformation programs, I encourage leadership teams to ask five questions before approving the next initiative.
1. What Will We Stop?
Every new capability should have a matching retirement commitment.
No exceptions.
If nothing disappears, transformation is probably becoming expansion.
2. Who Owns the Exit?
Organizations assign owners to implementation.
Few assign owners to shut down.
Without clear accountability, legacy survives indefinitely.
Every process, platform, committee, and operating model should have an owner responsible for its retirement.
3. What Complexity Are We Removing?
Every investment proposal should quantify complexity reduction.
Examples include:
- Applications retired
- Vendor contracts eliminated
- Approval steps removed
- Decision cycle time reduced
- Manual effort eliminated
If complexity isn't declining, operating costs rarely will.
4. Are We Measuring Business Replacement or Technology Deployment?
Installing software is not transformation.
Changing how the business operates is.
The board should regularly ask:
"What percentage of the old operating model still exists?"
That question usually produces more insight than another implementation dashboard.
5. What Happens If We Stop This Program Today?
This is perhaps the hardest question.
If a transformation stopped tomorrow:
Would customers notice?
Would employees work differently?
Would costs permanently improve?
Would decisions become faster?
Would revenue become more resilient?
If the honest answer is no, the organization may have been running a large project instead of executing a transformation.
How to Know When to Stop a Transformation Program
Another uncomfortable truth.
Not every transformation deserves to reach completion.
Sometimes the bravest executive decision is ending a program that no longer creates strategic value.
Boards often struggle with this because of sunk costs.
Millions have already been invested.
Years have already passed.
Teams have become emotionally attached.
Yet previous investment is not a reason for future investment.
The right question is simple.
"If we were making this decision today, knowing what we know now, would we still approve this program?"
If the answer is no, continuing becomes an exercise in protecting past decisions rather than creating future value.
Stopping is not failure.
Continuing without value creation is.
The Counterargument
Some leaders argue that retiring legacy capabilities introduces operational risk.
They are correct.
Controlled retirement requires planning.
Critical services cannot disappear overnight.
Regulatory obligations remain.
Customer commitments continue.
The answer, however, is not permanent coexistence.
It is disciplined transition.
The best organizations establish explicit exit milestones before launch.
A platform is not considered successful because it went live.
It is considered successful because the legacy platform was switched off.
That difference changes behavior across the organization.
Implementation teams start planning for adoption rather than deployment.
Business leaders begin preparing operational change instead of simply accepting new technology.
Transformation becomes measurable through business outcomes instead of project completion.
Boards Should Demand One Additional Dashboard
Every transformation office already produces progress reports.
I would add one more.
Call it the Retirement Dashboard.
Track:
1. Systems retired
2. Processes eliminated
3. Governance forums removed
4. Reports discontinued
5. Vendors exited
6. Operating cost permanently reduced
7. Management hours released
8. Decisions accelerated
This dashboard measures whether complexity is actually declining.
Because that is what creates agility.
Not another project launch.
The Real Test of Transformation
After nearly three decades across industries and geographies, I have noticed something surprisingly consistent.
The organizations that transform successfully are rarely the ones investing the most.
They are the ones saying "no" the most often.
They retire legacy faster.
They simplify relentlessly.
They protect leadership attention as carefully as financial capital.
Transformation is not defined by everything you start.
It is defined by everything you finally have the discipline to stop.
What is the hardest thing your organization has chosen to stop doing during a transformation, and did it create more value than what you started?
If this perspective resonates, subscribe to TechnologyTrends or leave a comment below. I'd be interested in hearing your experience.
#Leadership #DigitalTransformation #BusinessTransformation #BoardLeadership #CIO #EnterpriseArchitecture #BusinessStrategy #TechnologyLeadership #CorporateGovernance #OperatingModel #ExecutiveLeadership #Transformation #BusinessChange #ITLeadership
AI for Science: The Next Big AI Opportunity
Sanjay K Mohindroo
AI's biggest opportunity may not be productivity, but faster discovery. What boards need to know about AI, science, R&D and competitive advantage.
AI’s Next Big Opportunity Is Not Productivity. It Is Discovery.
200 million.
That is roughly how many protein structure predictions AlphaFold has made available to researchers. A scientific problem that had consumed enormous amounts of experimental time was suddenly attacked at computational scale.
That number matters far beyond biology.
For most of the past few years, the business conversation around artificial intelligence has been dominated by productivity: write the report faster, automate customer service, reduce coding effort, remove administrative work.
All useful.
I also think we may eventually look back and conclude that this was the least interesting part of the AI revolution.
After three decades around enterprise technology decisions, I have seen the same pattern repeatedly. A new technology arrives, and management instinctively asks the safest question first:
What existing process can this make cheaper?
The more valuable question is usually different:
What becomes possible now that was previously too slow, too expensive, or too complex to attempt?
That is why the movement of talent and capital toward AI-assisted scientific discovery deserves boardroom attention.
The conventional wisdom says that the next stage of AI is about smarter assistants and autonomous agents doing more knowledge work.
I disagree.
The much bigger prize may be systems capable of shortening the cycle between a question and a verified answer.
That is not merely productivity.
That is discovery as an economic capability.
The AI Race Is Moving Beyond Productivity
The signals are becoming difficult to ignore.
In August 2026, Google announced that long-time technology leaders Jeff Dean and Sanjay Ghemawat were leaving to create an independent public benefit corporation focused on accelerating discoveries in machine learning, science and engineering. Alphabet is supporting the venture as a founding investor and Google Cloud partner. Other prominent researchers are pursuing similar AI-for-science efforts.
The important part of that story is not executive movement.
It is where some of the industry's most valuable talent believes the next frontier lies.
We are seeing the pieces converge:
- increasingly capable reasoning systems,
- enormous computing capacity,
- robotic and automated laboratories,
- specialised scientific datasets,
- experienced researchers willing to build companies around the problem,
- and investors willing to fund long-duration bets.
Periodic Labs, for example, is building around automated experimentation and scientific discovery. Lila Sciences has pursued a similar model combining AI with automated laboratories. The common idea is significant: generate knowledge by allowing computational systems to participate directly in the experimental cycle, rather than merely analyse information after humans produce it.
This is the shift boards should pay attention to.
The first enterprise AI wave asks:
How can AI make our current work faster?
The next may ask:
How can AI increase the rate at which our organisation learns something competitors do not know?
Those are very different investment propositions.
Scientific Discovery Is Fundamentally a Cycle-Time Problem
Strip away the complexity and much of science follows a loop:
Observe. Form a hypothesis. Design an experiment. Run it. Analyse the result. Revise the hypothesis. Repeat.
The constraint has traditionally been that parts of this loop are expensive, sequential and dependent on scarce expert time.
AI potentially changes several parts simultaneously.
A system can search literature.
It can identify relationships across enormous datasets.
It can propose hypotheses.
It can suggest experimental designs.
It can analyse results and determine what should be tested next.
Increasingly, those recommendations can be connected to automated experimental systems.
Recent research illustrates how quickly that boundary is moving. A 2026 Nature paper described Co-Scientist, a system intended to support hypothesis generation, identify unexpected connections and assist with experimental planning. Another Nature paper described Robin, a multi-agent system automating hypothesis generation and data analysis in experimental biology.
More importantly, the loop is beginning to touch the physical world.
OpenAI reported an experiment in which GPT-5-driven iterations improved the efficiency of a molecular cloning protocol by 79 times. In another collaboration involving an AI-driven autonomous laboratory, it reported a 40 percent reduction in cell-free protein production cost. These are specific experimental results, not proof that AI can autonomously transform biology, but they demonstrate the economic variable boards should watch: how rapidly the cost and time per validated experiment can fall.
That is where the disruption begins.
Stop Measuring AI by How Many Hours It Saves
Most enterprise AI business cases still rely heavily on labour efficiency.
Hours saved.
Headcount avoided.
Tickets resolved.
Code produced.
Documents generated.
Those metrics make sense because they are measurable.
But they can also trap management into using a transformational technology to optimise yesterday's operating model.
In science-intensive industries, the more valuable metric may be:
Cost per validated learning cycle.
Consider the difference.
If AI allows a pharmaceutical research team to prepare reports 30 percent faster, that is productivity.
If AI allows the organisation to test ten times as many plausible hypotheses against experimental evidence using the same capital base, that is strategic leverage.
If a materials company can explore thousands of candidate compounds while a competitor explores hundreds, the advantage is not primarily administrative efficiency.
It is learning velocity.
Over time, learning velocity becomes competitive advantage.
The company that conducts more high-quality experiments, learns from failures faster and redirects capital earlier may discover the winning molecule, material, process or design before everyone else.
That is something a board should understand immediately.
The Real Moat Will Be the Discovery Loop
There is another piece of conventional wisdom worth challenging.
Much of today's AI strategy assumes the model itself is the differentiator.
I doubt that remains true for many industries.
Models will improve. Access will broaden. Capabilities that appear extraordinary today will become commercially available tomorrow.
The harder advantage to replicate will be the system surrounding the model.
Imagine two companies using roughly equivalent AI capability.
Company A has decades of clean experimental data, digital access to laboratory equipment, automated testing capacity and disciplined mechanisms for validating results.
Company B has fragmented data, manual processes, isolated research teams and an AI licence.
They do not possess the same capability.
The first company owns a discovery loop.
The second owns software.
That distinction will become increasingly important in pharmaceuticals, chemicals, energy, semiconductors, advanced manufacturing, agriculture and any industry where value depends on discovering better answers before competitors.
The Five-Loop Test for Boards
Before approving a large AI-for-discovery programme, I would want the board and CEO to answer five questions.
1. Are we attacking a valuable bottleneck?
Do not start with the technology.
Start with the constraint.
Where does the company currently lose years, capital or strategic optionality because experimentation is too slow or expensive?
Perhaps it is identifying new compounds.
Perhaps it is testing engineering configurations.
Perhaps it is optimising manufacturing parameters.
Perhaps it is screening drug candidates.
The business case begins with the value of removing that constraint.
If nobody can quantify why learning faster matters, do not fund the AI programme.
2. Do we possess a data advantage?
Generative models trained on publicly available information may produce useful suggestions.
Competitive advantage usually requires something competitors cannot reproduce easily.
That may be proprietary experimental results, historical failures, manufacturing telemetry, clinical observations or decades of specialised engineering knowledge.
This leads to an uncomfortable board question:
Is the company's accumulated knowledge actually usable by machines?
Many enterprises possess valuable data in theory but not in practice.
It sits inside documents, isolated databases, spreadsheets, instruments and the memories of retiring specialists.
The race to organise that knowledge may prove as important as the race to acquire models.
3. Can AI close the experimentation loop?
This is where many strategies will fail.
Producing hypotheses quickly has limited value if experiments still require months to design, approve, schedule and execute.
The critical question is not whether AI can think faster.
It is whether the organisation can test faster.
That may require automated laboratories, simulation environments, robotics, digital twins, better instrumentation or simply redesigned research workflows.
The organisations that connect reasoning with execution will have a much stronger advantage than those treating AI as an advisory layer.
4. How will we independently validate the answer?
Science has one discipline that enterprise AI desperately needs: evidence.
An AI-generated hypothesis is not a discovery.
A predicted molecule is not an approved medicine.
A simulated breakthrough is not a commercial product.
The output becomes valuable only when reality confirms it.
Boards therefore need governance around reproducibility, traceability, human review and independent validation.
This becomes particularly important in medicine, biology and other areas where incorrect conclusions can carry consequences far beyond financial loss.
The faster the discovery engine becomes, the stronger the validation engine must become.
5. Can discovery translate into economic value?
This is the step technology enthusiasts regularly underestimate.
A scientific breakthrough does not automatically create shareholder value.
A drug still needs development, trials, regulatory approval, manufacturing and distribution.
A new material still needs scalable production, customer qualification and economically viable supply chains.
The board should therefore track two loops:
Scientific learning velocity and commercialisation velocity.
Accelerating the first while ignoring the second merely creates a larger backlog of interesting ideas.
Medicine Shows Both the Opportunity and the Limitation
Medicine is where the excitement will probably become greatest.
It is also where expectations require the most discipline.
AI may dramatically compress specific activities involved in understanding proteins, designing molecules, reviewing evidence or choosing experiments.
AlphaFold's database of more than 200 million predicted protein structures is already an extraordinary example of what happens when one research bottleneck becomes computational.
But discovering a promising candidate and safely delivering a medicine to millions of people are very different achievements.
Clinical evidence cannot simply be generated by a language model.
Manufacturing constraints do not disappear.
Regulatory accountability does not disappear.
Human biology does not become predictable because computing gets cheaper.
This is why I am sceptical when people describe AI as replacing scientists.
The more credible opportunity is much more interesting.
AI can potentially allow scientists to investigate more possibilities, discard weak options earlier and spend scarce human judgment on the questions where it matters most.
The aim is not scientist removal.
It is scientist leverage.
What Should CEOs Do Now?
For most companies, the answer is not to build an autonomous laboratory next quarter.
It is to identify where the economics of learning matter.
Ask your R&D leaders:
What experiment takes us six months that should take six weeks?
What hypothesis do we avoid testing because experimentation is too expensive?
Which historical failures contain knowledge we have never systematically captured?
Where does expert scarcity constrain the number of ideas we can evaluate?
What would happen economically if we could increase validated experiments per year by five times?
Those conversations will produce a far more useful AI strategy than another discussion about enterprise chatbot adoption.
The winners may not be the companies spending the most on AI.
They may be the companies that redesign themselves to learn faster than everyone else.
The Next AI Advantage Will Be Measured in Years, Not Tokens
For several years the AI industry has competed on parameters, benchmark scores, context windows and model capability.
Important measures, certainly.
But businesses eventually care about outcomes.
A pharmaceutical company cares whether a therapy reaches patients.
A manufacturer cares whether a new process reduces cost.
An energy company cares whether a new material improves economics.
A board cares whether capital produces durable advantage.
That brings us to the metric I believe will eventually matter most:
How much real-world discovery time did AI remove?
If a problem that once required ten years can reliably be solved in five, enormous value is created.
If five years becomes one, entire industries change.
That is why I believe scientific discovery may become one of AI's most important opportunities.
Not because AI will suddenly become a genius scientist.
Not because laboratories will empty of people.
And not because every scientific problem will yield to more computing.
It matters because we may finally have the ingredients required to attack one of innovation's oldest constraints:
the speed at which we can turn uncertainty into verified knowledge.
For boards, that is the opportunity to watch.
And for companies whose competitive advantage depends on R&D, it may soon become the capability they cannot afford to ignore.
What is the most expensive unanswered question in your industry, and what would change if your organisation could answer it five times faster?
If this is the kind of technology conversation you value, subscribe to TechnologyTrends or add your perspective in the comments.
When to Stop a Transformation Program
Sanjay K Mohindroo
Most transformation failures come from continuing too long. Learn the five board-level tests every CEO and CIO should apply before investing further.
"The most difficult transformation I ever led wasn't the one that failed. It was the one I chose not to finish."
The room fell silent.
Months of planning had gone into the programe. Hundreds of people were involved. Significant capital had already been committed. Every dashboard showed progress. Every steering committee meeting ended with another milestone achieved.
Then I recommended reducing the scope.
Not because the programme was failing.
Because the business had changed.
That recommendation was far more controversial than cancelling an unsuccessful initiative would have been. Cancelling failure is easy to explain. Scaling back something that appears to be succeeding is much harder.
Over three decades leading enterprise technology across industries and geographies, I have learnt that one of the least appreciated leadership skills is knowing when not to continue.
Most transformation programes do not fail because the technology is wrong.
They fail because leaders become emotionally committed to a roadmap that no longer reflects business reality.
The Most Dangerous Assumption in Transformation
There is a belief that perseverance is always a virtue.
It isn't.
Transformation has become synonymous with endurance. Boards admire programes that continue for years. Consultants celebrate multi-year roadmaps. Vendors promote continuous expansion.
The underlying assumption is simple.
If you've started, you should finish.
I disagree.
That mindset confuses commitment with effectiveness.
The purpose of transformation is not to complete a roadmap.
The purpose is to improve business performance.
Those are two very different objectives.
When circumstances change, continuing to execute the original plan can become the highest-risk decision in the room.
Success Can Become the Biggest Risk
One programme I was involved with had clear objectives, executive sponsorship and strong delivery discipline.
The governance was solid.
The milestones were being achieved.
Budgets remained under control.
On paper, it was exactly what every transformation should look like.
Then the company's strategic priorities shifted.
A combination of market conditions and changing commercial realities meant leadership needed to redirect investment toward areas that would produce measurable business impact much sooner.
Nothing about the programme itself had deteriorated.
The business context had.
Continuing the programme exactly as planned would have consumed leadership attention, capital and organizational capacity that were suddenly needed elsewhere.
We had two options.
Continue because the original business case had once been correct.
Or reduce the scope because today's priorities mattered more than yesterday's assumptions.
We chose the second option.
Looking back, that decision probably created more value than completing the original programme ever would have.
Transformation Is Not an Asset. It Is an investment
Boards understand investments.
They also understand sunk costs.
Yet transformation programes are often treated differently.
Once organizations have invested significant money and executive attention, the programme starts acquiring an identity of its own.
It becomes something that must be protected.
Additional phases are approved because earlier phases have already been completed.
New workstreams appear because "while we're doing this, we might as well..."
Budgets quietly expand.
Timelines stretch.
Success metrics become increasingly focused on programme delivery instead of business outcomes.
The transformation begins serving itself.
This is classic sunk cost thinking.
No board would continue funding a business unit purely because substantial money had already been invested.
No CEO would maintain an unprofitable product simply because development took three years.
Yet organizations routinely do exactly that with transformation programes.
Completion becomes the objective.
Value quietly becomes secondary.
The Wrong Question
Whenever executive teams review large programes, the discussion usually revolves around familiar questions.
Are we on schedule?
Are we within budget?
Have milestones been achieved?
Have risks been mitigated?
These are important operational questions.
They are not strategic questions.
The real question is much simpler.
If we were making this investment for the first time today, knowing what we know now, would we still approve it?
That single question changes the conversation completely.
Because it forces leadership to ignore history.
It removes emotional attachment.
It removes sunk costs.
It removes organizational pride.
Instead, it evaluates the programme against today's business priorities.
That is exactly how capital allocation decisions should work.
Transformation deserves the same discipline.
Why Leaders Keep Going Anyway
If the answer is obvious, why do organizations continue programes that no longer make strategic sense?
In my experience, there are four recurring reasons.
1. Nobody Wants to Admit the Context Changed
Changing direction is often interpreted as admitting failure.
Executives worry about credibility.
Programme sponsors worry about reputation.
Project teams worry about morale.
So, everyone continues.
Not because it remains the right decision.
Because changing course feels politically harder.
Ironically, boards rarely criticize thoughtful course corrections.
They criticize organizations that ignore obvious reality.
2. Success Is Measured by Delivery, Not Outcomes
Large programes develop their own reporting structures.
Delivery milestones become the language of success.
Green dashboards create confidence.
But green dashboards do not necessarily create shareholder value.
I've seen programes receive excellent delivery ratings while producing very little measurable competitive advantage.
Execution quality is important.
Business relevance is more important.
3. Scope Expands Faster Than Value
Transformation rarely stays the same size.
Every department identifies additional opportunities.
Every vendor proposes another capability.
Every steering committee finds another dependency.
The programme gradually shifts from solving a business problem to modernizing everything.
Eventually, nobody remembers where the original value was supposed to come from.
Scope becomes momentum.
Momentum becomes strategy.
That is dangerous.
A Board-Level Framework: The Five Tests Before You Continue
When business priorities change, I encourage leadership teams to resist making emotional decisions.
Instead, apply five simple questions.
These are not technology questions.
They are business questions.
1. Is the original business problem still the business's biggest problem?
The reason you started may no longer be the reason you should continue.
Markets change.
Customers change.
Regulation changes.
Competition changes.
Capital becomes more expensive.
Growth priorities evolve.
If the original problem has fallen down the strategic agenda, the programme should not automatically retain its original priority.
Business relevance must always outrank historical commitment.
2. Would we approve this investment today?
Ignore everything already spent.
Ignore completed phases.
Ignore political ownership.
If this proposal arrived in today's investment committee, would it still receive funding?
If the answer is no, leadership already knows what needs to happen.
3. Are we creating competitive advantage, or simply keeping busy?
Every transformation reaches a point where activity can be mistaken for progress.
New workstreams are launched. Additional capabilities are added. More teams become involved. Steering committee meetings become longer. Dashboards become more detailed.
The programme appears healthy because everyone is working hard.
But effort is not the same as advantage.
Boards should ask a tougher question.
What measurable business outcome will this next phase create that competitors will struggle to replicate?
If the answer is vague, the programme is probably entering the law of diminishing returns.
Technology should create differentiation, improve resilience, increase speed, or strengthen customer value.
If it is merely modernising for the sake of completeness, it is consuming capital without strengthening the business.
4. What is the opportunity cost of continuing?
This is the question that is often missing from transformation governance.
Every pound, dollar, or rupee committed to an existing programme is capital that cannot be invested elsewhere.
Every senior executive spending time reviewing transformation dashboards is time not spent on growth, customers, acquisitions, or new markets.
Every specialist assigned to a programme is unavailable for another strategic priority.
Transformation programes are rarely evaluated against alternative investments.
They should be.
A board would never approve a capital allocation decision without considering opportunity cost.
Technology investments deserve the same discipline.
Sometimes the right decision is not to stop because the programme is underperforming.
It is to stop because another opportunity now offers a better return.
5. Can we stop with confidence, or are we simply afraid to?
This is ultimately a leadership test.
Fear keeps many programes alive long after their strategic value has declined.
Fear of criticism.
Fear of admitting circumstances have changed.
Fear that teams will interpret a reduced scope as failure.
In reality, mature organisations understand that strategy is dynamic.
Markets evolve.
Customer expectations shift.
Economic conditions change.
No credible board expects a three-year roadmap to remain untouched.
The question is not whether plans will change.
The question is whether leadership dares to acknowledge it.
Reducing Scope Is Not the Same as Losing Ambition
One misconception deserves addressing.
Whenever I argue for stopping or reducing a transformation programe, someone inevitably says, "Won't that send the wrong signal to the organization?"
Only if it is communicated poorly.
There is an important difference between abandoning a vision and adjusting the route.
A transformation should have a stable destination.
The roadmap to reach it should remain flexible.
The organizations that adapt fastest are not constantly changing direction.
They are constantly reassessing whether the next investment still serves the destination.
Reducing scope should never mean lowering ambition.
It should mean concentrating effort where it creates the greatest business value.
That distinction matters.
The Counterargument: Doesn't Stopping Create Transformation Fatigue?
A reasonable concern is that changing direction too often can erode confidence.
Employees begin to believe every initiative will eventually disappear.
Business sponsors hesitate to commit.
Momentum is lost.
That risk is real.
But it usually stems from poor governance, not from stopping itself.
Transformation fatigue is created when organizations repeatedly launch programes without clear business outcomes, continually redefine success, or chase the latest technology trend.
Stopping a programme for disciplined strategic reasons has the opposite effect.
It demonstrates that leadership is serious about capital allocation.
It reinforces that transformation exists to serve the business, not the other way around.
In my experience, people lose confidence when leaders refuse to make difficult decisions.
They gain confidence when those decisions are explained clearly and backed by evidence.
What Boards Should Expect from Every Transformation
Before approving another phase of funding, I believe every board should insist on five things.
1. A refreshed business case. Not the one written two years ago, but one based on today's strategic priorities.
2. Evidence of realized value. Focus on measurable business outcomes, not completed milestones.
3. An opportunity cost assessment. What alternative investments are being deferred by continuing?
4. A clear stop, continue, or reduce recommendation. Management should not present continuation as the default option.
5. A defined exit point. Every transformation should have conditions under which it will end, pause, or be scaled back.
If these conversations become routine, transformation governance changes fundamentally.
Programes stop becoming permanent fixtures.
They become investments that must continually earn the right to continue.
The Leadership Test That Matters Most
Looking back over the transformations I have been involved with, I do not judge success by whether every milestone was completed.
I judge success by whether the organization emerged stronger.
Sometimes that meant accelerating investment.
Sometimes it meant expanding the programe.
And occasionally, it meant reducing the scope of something that appeared to be succeeding because the business needed something else more.
Those were never easy decisions.
They were certainly unpopular at the time.
But leadership is rarely about defending yesterday's roadmap.
It is about making today's best decision with tomorrow's business in mind.
Transformation is not a promise to finish everything you started.
It is a commitment to invest where it creates the greatest value.
Sometimes the smartest transformation decision is not knowing how to begin.
It is knowing when to stop.
Transformation Is a Portfolio, not a Project
Sanjay K Mohindroo
Transformation succeeds through portfolio management, not project execution. Learn the board framework that drives better capital allocation and business outcomes.
Transformation Is a Portfolio, not a Project: How Boards Should Actually Run It
Two weeks before a board meeting, a CEO proudly told me that 87% of the company's transformation projects were "green."
The board meeting did not go well.
Revenue growth had stalled. Margins were under pressure. Customer satisfaction had slipped. Despite hundreds of millions invested over three years, the business was losing market share to competitors moving faster and making bolder bets.
Every project was succeeding.
The transformation was failing.
After nearly three decades of working with executive teams across industries and geographies, I have seen this pattern repeat itself more times than I can count. Organizations become exceptionally good at managing projects while becoming surprisingly poor at managing transformation.
The distinction matters.
Projects deliver outputs. Transformation creates enterprise value.
Confusing the two is one of the most expensive mistakes a board can make.
The conventional wisdom says transformation succeeds through disciplined project execution, detailed roadmaps, and rigorous governance.
I disagree.
Transformation succeeds because leadership continuously reallocates capital, talent, and executive attention toward the bets that matter most. It is a portfolio management problem, not a project management problem.
That single shift in thinking changes almost every boardroom conversation.
Why Most Transformation Programs Underperform
Boards rarely approve a single transformation initiative.
They approve dozens.
There are usually ERP modernization, cloud migration, AI initiatives, cybersecurity investments, customer experience programs, operating model redesign, data platform upgrades, supply chain digitization, sustainability reporting, and multiple business unit initiatives running simultaneously.
Each project has its own sponsor.
Each project has its own steering committee.
Each project reports status independently.
Collectively, however, nobody owns the value created by the entire investment portfolio.
That is where transformation begins to fail.
I once worked with a global manufacturer operating across four continents. The company had more than 120 active transformation initiatives.
Every executive could explain the importance of their own program.
Nobody could explain which ten initiatives were expected to generate 80% of the strategic value.
That is not governance.
That is administration.
Boards often receive hundreds of pages of status reports.
Green.
Amber.
Red.
Milestones achieved.
Budgets consumed.
Risks mitigated.
Useful information, certainly.
But almost none of it answers the questions directors should actually be asking.
Is this investment still the best use of capital?
Should another initiative receive more funding instead?
What assumptions have changed?
If we had to stop 20% of our projects tomorrow, which ones would we shut down first?
Those are portfolio questions.
Very few organizations answer them well.
Projects Optimize Delivery. Portfolios Optimize Value.
A project manager is expected to deliver scope on time and within budget.
That is exactly what they should do.
A portfolio owner has a different responsibility.
Their job is to maximize enterprise value across competing investments.
Those objectives are not always aligned.
Imagine two initiatives.
Project A is progressing exactly according to plan.
Project B is struggling because market conditions have changed, new competitors have emerged, and customer demand is shifting faster than expected.
Traditional governance rewards Project A.
Portfolio thinking asks a different question.
Which project is now more strategically important?
Sometimes the struggling initiative deserves more investment because the opportunity has become larger.
Sometimes the successful project should lose funding because it is solving yesterday's problem.
That feels uncomfortable.
It also reflects how successful investors think.
No experienced investor keeps adding money to every stock simply because it was included in the original portfolio.
Markets change.
Businesses change.
Technology changes.
Investment decisions change with them.
Transformation should operate the same way.
The Wrong Metrics Create the Wrong Conversations
One of the first board packs I review during advisory engagements often includes metrics such as:
- Percentage complete
- Budget utilization
- Milestones achieved
- Issues closed
- Training completed
- Resources assigned
None of these are inherently bad.
They are simply insufficient.
Imagine applying the same logic to your investment portfolio.
Would you judge its success because every investment completed its paperwork on time?
Or because every investment generated superior returns?
Transformation reporting should work no differently.
Boards should spend less time discussing activity.
They should spend significantly more time discussing value creation.
That means asking questions such as:
- Which initiatives are increasing competitive advantage?
- Which initiatives have become less relevant because market conditions changed?
- Which projects should receive additional capital immediately?
- Which investments should be stopped despite being technically successful?
- What percentage of transformation spend is now delivering measurable business outcomes?
Those conversations are considerably harder.
They are also considerably more valuable.
The Sunk Cost Trap
One of the biggest barriers to effective transformation is psychological rather than operational.
Executives become emotionally attached to projects they sponsored.
Large budgets create political commitment.
Teams become invested in proving earlier decisions were correct.
The result is predictable.
Projects continue long after their strategic justification has disappeared.
This is classic sunk cost thinking.
Boards should actively resist it.
One financial services organization I advised had invested heavily in a customer platform that made perfect sense when approved.
Eighteen months later, competitor behavior, regulatory changes, and customer expectations had shifted dramatically.
The project remained technically healthy.
Commercially, it was becoming irrelevant.
The difficult decision was made to significantly reduce the scope and redirect investment toward a different customer capability that had emerged as strategically critical.
From a project perspective, it looked like failure.
From a portfolio perspective, it was disciplined capital allocation.
There is an important lesson here.
Stopping a project is not evidence of poor governance.
Sometimes it is evidence of excellent governance.
Boards should celebrate intelligent exits just as much as successful deliveries.
A Better Mental Model: Treat Transformation Like an Investment Fund
Instead of viewing transformation as a collection of independent projects, imagine managing an investment fund.
Every initiative competes for limited capital.
Every initiative has an expected return.
Every initiative carries uncertainty.
Every initiative should be reviewed against alternatives, not against its original business case alone.
The portfolio evolves continuously.
Some investments grow.
Some shrink.
Some are exited entirely.
Capital moves toward opportunities with the greatest expected strategic impact.
This is exactly how private equity firms think.
It is how venture capital funds think.
Ironically, many corporations that invest this way externally continue managing internal transformation as though every approved project deserves equal protection until completion.
It doesn't.
The moment an investment no longer represents the best use of scarce resources, leadership has a responsibility to reconsider it.
Transformation is not about finishing everything.
It is about maximizing enterprise value with the capital available.
The Board Framework: Five Questions That Change Transformation Governance
If transformation is a portfolio, then governance must evolve beyond project reviews.
Over the years, I have found five questions consistently separate organizations that create value from those that simply deliver programs.
1. Are We Funding Strategy or Funding History?
Every initiative was approved based on assumptions that were true at a point in time.
Markets move.
Customers evolve.
Competitors innovate.
Regulation changes.
Technology advances.
The first responsibility of the board is to determine whether those original assumptions still hold.
A project that was strategically essential eighteen months ago may now be delivering diminishing returns. Equally, a smaller initiative may have become far more valuable because market conditions have shifted.
Capital should follow today's strategy, not yesterday's approval.
2. What Is the Opportunity Cost?
Every dollar committed to one initiative is a dollar unavailable for another.
Yet opportunity cost is remarkably absent from many transformation discussions.
Boards routinely ask whether projects are on budget.
Far fewer ask whether that budget could create greater value elsewhere.
That distinction matters.
A transformation portfolio should never be viewed as a fixed collection of approved initiatives. It is a living investment strategy competing for finite resources.
The best organizations continuously ask one simple question:
"If we were starting today, would we still invest in this initiative?"
If the answer is no, continuing simply because work has already begun is not discipline. It is inertia.
3. Are We Measuring Enterprise Outcomes?
Project metrics matter.
Enterprise metrics matter more.
Boards should spend significantly more time reviewing measures such as:
- Revenue growth attributable to transformation.
- Margin improvement.
- Productivity gains.
- Customer retention.
- Speed to market.
- Risk reduction.
- Capital efficiency.
These are the outcomes shareholders ultimately value.
A project can meet every milestone and still fail to improve any of these measures.
Conversely, a project that required multiple course corrections may create exceptional long-term value.
Delivery performance should inform governance.
Business outcomes should drive governance.
4. Are We Reallocating Resources Fast Enough?
One characteristic consistently separates high-performing organizations from average ones.
It is not planning.
It is speed of reallocation.
Winning organizations move funding, talent, executive sponsorship, and organizational attention quickly when evidence changes.
Poor performers wait for annual planning cycles.
By then, competitors have often moved first.
Transformation portfolios require the same agility that investment portfolios demand.
Holding on to underperforming initiatives because governance cycles make change inconvenient is rarely a competitive advantage.
5. Who Actually Owns Portfolio Value?
This may be the most important question of all.
Most organizations have clear ownership for individual projects.
Fewer have clear ownership for the value created across the portfolio.
Someone must have explicit accountability for answering questions such as:
- Are we investing in the right mix of initiatives?
- Are dependencies creating hidden risks?
- Are multiple business units solving the same problem independently?
- Are we creating measurable enterprise value rather than localized success?
Without that accountability, transformation becomes fragmented.
Every project succeeds on its own terms.
The organization struggles to realize value as a whole.
Boards should insist on portfolio ownership, not simply project sponsorship.
Addressing the Common Counterargument
Whenever I present this perspective, one objection almost always emerges.
"If we keep changing priorities, won't transformation become chaotic?"
It is a fair question.
The answer lies in understanding the difference between discipline and rigidity.
Portfolio management is not about constantly changing direction.
It is about continuously validating whether current investments remain aligned with strategic priorities.
Good portfolio management introduces greater discipline, not less.
The strategic destination remains stable.
The investment path evolves as new information becomes available.
Think of navigating a long ocean voyage.
The destination rarely changes.
The course is adjusted repeatedly to account for weather, currents, and unexpected conditions.
No experienced captain would describe those adjustments as a failure of planning.
They are evidence of sound navigation.
Transformation deserves the same mindset.
The Leadership Shift That Matters Most
Technology has never been more capable.
Capital has never been more available for digital investment.
Boards have never had greater visibility into execution metrics.
Yet transformation success rates remain stubbornly inconsistent.
I believe one reason is that organizations continue solving the wrong problem.
They focus on delivering projects better.
The real challenge is making investment decisions better.
That requires a different leadership mindset.
Less emphasis on governance theater.
More emphasis on capital allocation.
Less discussion about project health.
More discussion about strategic relevance.
Less attachment to past decisions.
More willingness to reallocate resources toward future value.
That is what portfolio thinking delivers.
The companies that create lasting competitive advantage are rarely those that complete every transformation initiative exactly as planned.
They are the ones that repeatedly place better bets than their competitors.
Some projects succeed.
Some projects are stopped.
Some evolve into something entirely different.
Viewed individually, those decisions may appear inconsistent.
Viewed as a portfolio, they represent disciplined leadership.
The next time your board reviews a transformation update, resist the temptation to ask whether every project is on schedule.
Instead, ask a more valuable question:
If we were allocating this capital for the first time today, would we make the same decisions?
The answer will tell you far more about the health of your transformation than another dashboard full of green status indicators ever will.
What governance question has most improved transformation outcomes in your organization? Have you seen portfolio thinking change boardroom conversations, or do most organizations still manage transformation one project at a time?
If this perspective resonated, subscribe to TechnologyTrends or join the discussion by sharing your experiences in the comments.
The Hidden Cost of Transformation Theatre.
Sanjay K Mohindroo
Many transformations look successful but fail to create value. Learn how boards can identify transformation theatre before it destroys competitive advantage.
A board meeting. Three dashboards. Twenty-seven green status indicators.
The company still missed its EBITDA target by 14%.
I've sat in enough transformation reviews over the past three decades to recognize this pattern within the first fifteen minutes.
Every workstream is reporting progress. Every steering committee is meeting on schedule. Every milestone is marked "green." Yet customers are leaving, operating costs remain stubbornly high, product launches continue to slip, and the promised business outcomes never arrive.
The uncomfortable truth is this:
Many organizations are no longer running transformation. They are performing it.
This is transformation theatre.
It looks impressive. It generates activity. It produces presentations, governance forums, executive updates, and endless reporting.
But it creates remarkably little enterprise value.
The greatest hidden cost is not the consulting fees or technology investments.
It is the opportunity cost of believing you are changing while your competitors actually are.
What Is Transformation Theatre?
Transformation theatre happens when the organization becomes more focused on demonstrating change than delivering it.
The goal quietly shifts.
Instead of asking:
"Did we improve the business?"
Leadership starts asking:
"Did we complete the program?"
Those sound similar.
They are not.
A project can finish perfectly while the transformation fails completely.
I've seen global organizations spend hundreds of millions modernizing platforms, consolidating systems, and redesigning operating models.
Two years later, customer acquisition costs were unchanged.
Decision cycles remained painfully slow.
Margins barely moved.
The transformation had technically succeeded.
The business had not.
That distinction matters more today than ever before.
Why Smart Organizations Fall into this Trap
Transformation theatre rarely begins because people are incompetent.
It begins because organizations reward certainty over outcomes.
Business outcomes are uncertain.
Projects are measurable.
You can report:
- Number of applications migrated
- Percentage of milestones completed
- Budget utilization
- Training sessions delivered
- Steering committees conducted
These create comfort.
What they cannot tell you is whether competitive advantage has improved.
Boards often receive hundreds of pages of transformation reporting while missing the five numbers that actually matter.
Revenue growth.
Customer retention.
Operating margin.
Decision speed.
Return on invested capital.
When measurement focuses on activity instead of value, theatre becomes inevitable.
The Conventional Wisdom Is Wrong
The common belief is simple:
"Large transformations fail because organizations resist change."
I disagree.
Most organizations are surprisingly willing to change.
Employees adopt new systems every year.
They learn new processes.
They reorganize teams.
They attend workshops.
Resistance is rarely the primary problem.
The real issue is that organizations confuse organizational movement with business progress.
There is a difference.
Movement creates noise.
Progress creates value.
One fills calendars.
The other improves enterprise performance.
That distinction should fundamentally change how boards govern transformation.
The Hidden Costs Nobody Calculates
The financial investment in transformation is visible.
The invisible costs are usually much larger.
Opportunity Cost
A global manufacturer operating across four continents invested heavily in modernizing its technology landscape.
The program was delivered almost exactly as planned.
While leadership focused internally for three years, two competitors launched new digital services, entered adjacent markets, and strengthened customer relationships.
Nothing had gone wrong inside the program.
Everything had changed outside it.
Markets rarely pause while transformation catches up.
The greatest cost was not implementation.
It was lost strategic momentum.
Leadership Bandwidth
Transformation consumes executive attention.
Every governance meeting.
Every escalation.
Every steering committee.
Every status review.
Leadership bandwidth is finite.
If CEOs and executive teams spend the majority of their time reviewing project status instead of discussing customers, competition, innovation, and capital allocation, transformation begins competing against the business itself.
That is a dangerous trade.
Decision Fatigue
Large programs create governance layers.
Governance eventually creates bureaucracy.
Soon even straightforward decisions require multiple approvals, steering committees, architecture boards, risk forums, finance reviews, and executive sign-offs.
Ironically, organizations attempting to become more agile often become slower.
The transformation designed to improve responsiveness ends up reducing it.
Organizational Cynicism
Employees notice patterns faster than executives expect.
When the third transformation promises revolutionary change yet daily work barely improves, people stop believing.
Engagement falls.
Execution slows.
Future initiatives encounter skepticism before they even begin.
Trust becomes another casualty.
And unlike technology, trust cannot simply be upgraded in the next phase.
Why Technology Often Gets Blamed
Technology is rarely the problem.
Expectations are.
Technology can enable better decisions.
It cannot make them.
Technology can simplify workflows.
It cannot remove unnecessary governance.
Technology can improve visibility.
It cannot create accountability.
When organizations expect technology alone to solve structural leadership problems, disappointment becomes almost inevitable.
This explains why companies running similar technology platforms often produce dramatically different business outcomes.
One transformed leadership.
The other transformed software.
Those are not the same investment.
The Board Should Ask Different Questions
One board meeting changed my perspective years ago.
The transformation office presented more than eighty slides.
Everything appeared healthy.
Near the end, one independent director asked a simple question.
"Which customer problem has become easier because of everything we've just seen?"
The room fell silent.
No one had an immediate answer.
Not because people lacked competence.
Because nobody had structured reporting around business value.
That single question exposed months of activity that had never been connected back to customer outcomes.
Since then, I've encouraged boards to replace many traditional transformation metrics with a much smaller set of business questions.
The quality of governance improves immediately.
A Practical Framework: The Four Tests of Real Transformation
Whenever I review transformation programs today, I mentally apply four simple tests.
If any one of them fails, the transformation deserves closer scrutiny.
Test 1: Outcome Before Output
Every major initiative should clearly answer one question:
"What measurable business outcome improves?"
Not system availability.
Not implementation completion.
Business performance.
Revenue.
Margin.
Customer experience.
Cycle time.
Risk reduction.
If the answer remains unclear, the initiative is probably measuring outputs instead of outcomes.
Test 2: Capital Efficiency
Transformation is ultimately an investment decision.
Boards should evaluate every initiative exactly as they would any other capital allocation.
Does this investment produce higher returns than the alternatives?
Would the organization make the same decision knowing what it knows today?
Past spending should never justify future spending.
Capital discipline matters just as much during transformation as it does during acquisitions.
Test 3: Decision Velocity
The healthiest transformations reduce organizational friction.
If governance expands faster than execution, something is wrong.
Measure how quickly important decisions move through the organization before and after transformation.
Faster, better-informed decisions usually indicate genuine progress.
Slower governance rarely does.
Test 4: Competitive Position
Perhaps the most overlooked question is also the simplest.
Are we becoming more difficult to compete against?
Transformation should strengthen competitive differentiation.
Customers should notice.
Competitors should respond.
Investors should recognize improved performance.
If competitors remain unaffected, transformation may have improved internal operations without strengthening market position.
That is operational improvement.
Not strategic transformation.
A Fair Counterargument
Some will argue that transformation requires foundational work before business value becomes visible.
That is true.
Infrastructure matters.
Data quality matters.
Modern platforms matter.
No serious enterprise can ignore them.
But foundational work should never become an excuse for indefinite value creation.
Every foundation should clearly connect to future business outcomes.
Otherwise, organizations risk building increasingly sophisticated infrastructure that serves increasingly unclear objectives.
Foundations are valuable because they enable the building.
Not because they exist.
Transformation Is a Leadership Discipline
Technology receives most of the headlines.
Leadership determines most of the outcomes.
The organizations consistently creating lasting value from transformation share one characteristic.
They treat transformation as a business discipline.
Not a technology program.
Not a PMO exercise.
Not a communications campaign.
Every investment is linked to measurable enterprise outcomes.
Every governance discussion begins with business performance.
Every executive understands that transformation is only successful when customers, shareholders, employees, and markets experience the difference.
Everything else is supporting activity.
Transformation theatre is expensive.
Not because of the technology.
Not because of the consultants.
Not because programs occasionally fail.
It is expensive because it creates the illusion of progress while consuming the one resource no organization can replenish.
Time.
Markets continue moving.
Competitors continue investing.
Customer expectations continue rising.
Organizations that mistake activity for advantage usually discover the truth only after the market has already moved on.
The companies that win are rarely those running the biggest transformations.
They are the ones delivering the clearest business outcomes.
What question does your board ask most often during transformation reviews: "Are we on schedule?" or "Are we creating measurable business value?" The answer may reveal more about your transformation than the dashboard ever will.
If this perspective resonated, follow TechnologyTrends for practical insights that cut through the hype and focus on what actually matters in enterprise IT.
Why ERP Rollouts Fail: The Real Problem Is Sequencing
Sanjay K Mohindroo
Most ERP failures are not technology failures. Learn why sequencing organizational change before implementation is the key to successful ERP transformation.
What a Failed ERP Rollout Taught Me About Sequencing Change
Cutting Through the Hype to What Actually Matters in IT
A project worth $180 million failed before the software was switched on.
Not because the technology was wrong.
Not because the vendor underperformed.
It failed because the organization changed the systems before it changed the business.
That lesson has stayed with me for nearly three decades of leading enterprise technology across industries and geographies. It is also the lesson I see organizations continue to ignore.
Every few months another headline appears about an ERP implementation that runs over budget, misses deadlines, or quietly gets written off after consuming years of executive attention. The postmortem usually points to familiar culprits: poor project management, inadequate testing, scope creep, weak training, or resistance to change.
Those factors certainly matter.
But they are rarely the real reason.
The deeper issue is sequencing.
Most organizations automate an operating model that is still being debated. They digitize inconsistent processes. They standardize work that nobody has agreed should actually be standard. Then they wonder why users reject the system.
Technology simply exposes the organizational confusion that already existed.
The software did not create the problem.
It made it impossible to ignore.
ERP implementations rarely fail because of ERP
One experience early in my career shaped how I think about transformation.
The organization was a global manufacturer operating across four continents. Growth through acquisition had left it with multiple finance systems, overlapping procurement processes, different manufacturing practices, and conflicting reporting structures.
Leadership approved a large ERP transformation with the expectation that standardization would naturally emerge once everyone was using the same platform.
That assumption proved expensive.
Regional teams interpreted supposedly "global" processes differently. Business units continued protecting local exceptions. Managers argued over approval workflows that had never previously been documented. Every workshop uncovered another disagreement about how the company actually operated.
The project team kept building.
The business kept changing its mind.
The implementation became larger, slower, and more expensive with every attempt to accommodate competing views.
By the time executive leadership recognized the pattern, confidence had already eroded.
The software was functioning.
The organization was not.
That distinction matters more than many boards realize.
The conventional wisdom is backwards
The standard advice sounds sensible.
"Choose the right ERP."
"Hire a stronger implementation partner."
"Invest more in change management."
Those are worthwhile recommendations.
They are also incomplete.
They assume technology is the center of the transformation.
It isn't.
The operating model is.
ERP should document and reinforce business decisions that have already been made.
Instead, many organizations use ERP workshops to make those decisions for the first time.
That is like pouring concrete before agreeing on the building design.
Once the foundation is set, every correction becomes slower, more expensive, and politically harder.
This is why so many implementations appear technically successful while delivering disappointing business outcomes.
The software works exactly as designed.
The business does not.
Technology magnifies leadership decisions
One observation has repeated itself across industries.
Technology rarely creates organizational complexity.
It amplifies it.
If governance is inconsistent, ERP exposes it.
If accountability is unclear, ERP highlights it.
If incentives conflict across business units, ERP forces those conflicts into every workflow.
Executives sometimes view ERP as an IT modernization initiative.
Boards often approve it as a capital investment.
Employees experience it as an organizational redesign.
Only one of those perspectives captures what is actually happening.
The organization is redefining how decisions get made.
That is why these programs cannot be delegated entirely to technology teams.
They require business leadership from day one.
The sequencing mistake
When I review struggling transformation programs, I usually find one common pattern.
The organization follows this sequence:
1. Select the software.
2. Launch implementation.
3. Discover process disagreements.
4. Debate governance.
5. Negotiate organizational change.
6. Delay deployment.
The order should be almost exactly the opposite.
That sounds obvious.
Yet very few organizations actually work this way because software procurement creates urgency while organizational alignment feels slow.
The result is predictable.
Technology moves faster than executive agreement.
Eventually, technology has to stop and wait.
That waiting is where budgets disappear.
The Five-Step Sequencing Framework
Over the years, I have found one framework consistently reduces both implementation risk and executive frustration.
It is not revolutionary.
It simply puts difficult conversations before expensive technology decisions.
1. Align the business before configuring the system
Every major business process should have a clear owner before implementation begins.
Not six owners.
Not regional variations hidden behind the word "exception."
One accountable decision-maker.
If executives cannot agree how procurement, finance, supply chain, or customer service should operate, ERP is the wrong place to resolve the disagreement.
Resolve it first.
Then configure the software.
2. Simplify before you standardize
Organizations often try to preserve every historical process because someone believes it is unique.
Most are not.
Many evolved simply because different business units solved similar problems independently.
Standardizing unnecessary complexity creates standardized inefficiency.
The better question is:
"What process would we design today if history did not exist?"
That conversation usually eliminates far more complexity than software ever could.
3. Build governance before dashboards
Executives love dashboards.
Boards ask for real-time reporting.
But data quality follows governance.
If business definitions differ across regions, no analytics platform can produce trustworthy insights.
One version of the truth begins with one version of the business.
Not one version of the database.
4. Pilot decisions, not just software
Many organizations treat pilots as technical validation exercises.
I believe they should primarily validate decision-making.
Can managers approve work within the new governance model?
Can finance close the books using the redesigned processes?
Can procurement resolve supplier disputes without reverting to old habits?
If the answer is no, expanding the rollout simply spreads confusion faster.
A successful pilot is not one where the software performs flawlessly.
It is one where the business demonstrates that the new operating model actually works.
5. Scale only after behaviors become consistent
This is perhaps the hardest discipline for executive teams.
Large transformation programs create pressure to show progress. Investors expect milestones. Boards want to see deployments completed. Vendors want reference customers.
That pressure often encourages organizations to scale too early.
I have seen companies declare victory because the software was live in twenty countries.
Six months later, each country had quietly developed different workarounds, spreadsheets, and manual controls.
The organization achieved global deployment.
It did not achieve global consistency.
The objective is not geographic coverage.
The objective is repeatable execution.
Only when the operating model becomes the default way of working should the rollout accelerate.
"But we don't have time"
Whenever I advocate spending more time on sequencing, someone inevitably says:
"We can't delay implementation. The business needs the new platform now."
I understand the pressure.
Markets move quickly. Legacy systems become expensive to support. Regulatory expectations continue to increase.
But there is an important distinction between moving quickly and moving prematurely.
Speed without alignment creates rework.
And rework is the most expensive phase of any transformation.
Every month invested in agreeing on governance before configuration can save many months of redesign after deployment.
This is not about slowing down.
It is about preventing the organization from running in the wrong direction.
The irony is that the fastest transformations I have been part of spent more time making decisions before writing a single configuration document.
Once those decisions were made, implementation accelerated because everyone was solving the same problem.
What Boards Should Be Asking
One of the biggest misconceptions surrounding ERP programs is that they are technology investments.
Boards therefore ask technology questions.
Is the implementation on schedule?
Is the budget under control?
Are testing milestones complete?
Those questions matter.
But they are lagging indicators.
The better questions are strategic.
- Have we agreed on the operating model this system is expected to reinforce?
- Which business decisions remain unresolved?
- How many process exceptions are we allowing, and why?
- Who owns each enterprise process?
- What behaviors are we trying to change, not just what software are we installing?
- If the software went live tomorrow, would people actually work differently?
Those conversations reveal more about project health than another dashboard full of green status indicators.
ERP Is Not an IT Project
This may be the most important point of all.
Calling ERP an IT project almost guarantees the wrong governance.
Technology teams can implement software.
They cannot resolve competing commercial priorities.
They cannot simplify organizational structures.
They cannot decide how authority should flow across business units.
Only business leadership can do that.
The CIO has a critical role.
But the CEO owns the operating model.
The executive committee owns the decisions.
And the board owns the accountability for ensuring those decisions are made before capital is committed at scale.
The organizations that understand this distinction consistently outperform those that do not.
The Lesson I Still Carry
Looking back, I no longer remember every technical challenge from that failed implementation.
I remember the meetings.
The unresolved decisions.
The repeated attempts to configure software around disagreements that should have been settled in the boardroom months earlier.
That experience fundamentally changed how I approach transformation.
Whenever someone asks me which ERP platform I recommend, my first question is rarely about technology.
Instead, I ask:
"Has your leadership team agreed how the business should actually operate?"
If the answer is uncertain, the ERP selection is not the next decision.
It is several decisions too early.
Technology is an extraordinary accelerator.
But acceleration only creates advantage when everyone is moving in the same direction.
Otherwise, it simply helps organizations reach failure faster.
The conventional wisdom says ERP projects fail because the software is difficult.
My experience suggests something different.
ERP projects fail because leaders try to sequence technology before strategy, systems before governance, and implementation before alignment.
Software is rarely the first domino.
Leadership is.
What has your experience been? Have you seen transformation programs struggle because of technology, or because the organization wasn't aligned before implementation began?
If this perspective resonates, subscribe to TechnologyTrends or join the conversation in the comments. The most valuable lessons in enterprise technology often come from the projects that did not go according to plan.
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