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.