Stop blaming your ERP vendor

Early in my career, I watched a mid-sized manufacturer spend 18 months and several times their original budget on an ERP implementation that never fully went live. The post-mortem, predictably, focused on the vendor. The software was blamed for being too complex. The implementation partner was blamed for poor support. The project was declared an industry cautionary tale.

I have spent more than 25 years leading enterprise software implementations across manufacturing, financial services, healthcare and federal contracting. And I have watched that same narrative play out more times than I can count: when ERP projects fail, the finger points outward.

I started to question that narrative when I began my doctoral research at Walden University, studying ERP implementation strategies specifically in small businesses. The ERP implementation failure rate is well documented. Analysts estimate that 50% to 75% of implementations fail to meet their original objectives. Nike lost over $100 million on a failed ERP rollout. Waste Management’s collapse cost more than $500 million. But nearly all of the research examining those failures focuses on large enterprises. Small businesses, where the margin for error is thin and recovery options are limited, have been largely overlooked.

So, I went looking for answers in a context that had not been thoroughly studied. What I found challenged almost everything I had assumed about why ERP projects succeed or fail. It also pointed toward something more useful than a cautionary tale: a clear, evidence-based picture of what the organizations that got it right actually did.

What the research revealed

For my doctoral study, I conducted in-depth interviews with six IT managers from small businesses in central Pennsylvania who had each led a full ERP implementation within the past five years. I reviewed their project charters, implementation plans, training records, change control logs and postimplementation reviews. I was looking for patterns in what distinguished the implementations that worked.

Three themes emerged consistently across all six cases: implementation preparation, implementation approaches and scope control. None of that was surprising. What was surprising was what I found when I asked participants directly about factors outside their control.

Not one of them pointed to their vendor.

I asked each manager specifically about the role of external factors: vendor relationships, vendor support, regulatory pressures, market conditions. The response was consistent across all six cases. When asked what drove their outcome, every manager pointed inward. Change management. Strategic alignment. Preparation quality. Scope discipline.

This runs counter to much of the existing ERP implementation literature, which frames vendor relationships and external conditions as significant sources of risk. But for these six managers, external factors were either absent or effectively neutralized by the strength of their internal practices. The accountability, it turned out, was entirely their own.

The three things that actually determine your outcome

I want to be clear: I am not suggesting that vendors are blameless or that external factors never matter. The geographic and industry context of my study probably contributed to relatively stable vendor relationships and limited regulatory complexity. Organizations in highly regulated industries or volatile markets may experience a different picture.

What the research does suggest is that for many small and mid-market organizations, the primary determinants of ERP success are squarely within the organization’s control. Here is what that looks like in practice.

• Preparation is everything. Every participant identified thorough preparation as foundational. Not preparation in a general sense, but specifically: strategic alignment before the project started, with the ERP initiative explicitly connected to measurable business goals. Active executive sponsorship, not nominal approval but leaders who were visible, who communicated the project’s importance and who enforced accountability across departments. Deliberate rollout strategy selection. Five of the six managers chose phased implementations over a Big Bang approach, introducing functionality incrementally. That choice consistently correlated with smoother transitions and higher adoption. And data migration treated as a first-class workstream from day one, not an afterthought discovered at go-live.
• How you execute matters as much as what you plan. The standout finding in implementation approaches was role-based, department-specific training. Five of six participants named it as essential. Generic system overviews do not prepare people to use an ERP. Employees need to understand how the system connects to their specific daily responsibilities. The managers who invested in that kind of tailored training consistently reported higher adoption rates and less resistance. Beyond training, the research identified strong governance structures, active change management throughout the project lifecycle and a consistent policy of minimizing customizations in favor of system best practices.
• Scope control is non-negotiable. All six participants, without exception, identified scope control as critical. This was the most universally emphasized theme in the research. Scope creep does not announce itself. A stakeholder requests an additional report. A department wants a process handled differently than the standard configuration allows. Each addition seems reasonable in isolation. Collectively, they compound complexity, extend timelines and exhaust budgets. The managers who succeeded maintained formal scope baselines, required written business cases for any proposed customization and reviewed all proposed changes against original project objectives before approving anything. That discipline is not about slowing the project down. It is about ensuring that every addition to scope is a deliberate choice with a known cost, rather than an accumulation of decisions that quietly redefine what the project is supposed to deliver.

Why this matters for how you lead your next implementation

I have thought a lot about why the vendor-blame narrative persists and I think part of the answer is that it is easier. If the vendor failed you, the problem is outside your control. There is nothing to learn, nothing to do differently next time and no accountability to sit with.

But if the research is right, and I believe it is, then the story IT leaders tell themselves after a failed ERP project may be getting in the way of the lesson that could actually prevent the next one.

I have seen this play out on both sides. I have managed implementations that succeeded because the organizational groundwork was solid: the executive team was genuinely engaged, the scope was protected and the training was built around how people actually worked. I have also seen implementations that struggled despite capable vendors and solid software, because change management was treated as a communication task rather than a strategic imperative, or because scope crept quietly through dozens of individually reasonable decisions.

The technology is rarely the problem. The leadership, the planning and the discipline to protect the project from its own stakeholders: that is where implementations are won or lost. I have yet to meet a failed ERP project where the root cause was genuinely the software. I have met plenty where it was the decisions made long before the software was ever configured.

If you are planning an ERP project or sitting in the middle of one that is drifting, I would ask you to resist the instinct to look outward when things get hard. Audit your preparation. Examine your scope baseline. Assess whether your training program is building genuine competence or just coverage. Look at whether your executive sponsor is actively engaged or nominally present.

The outcome is far more within your control than the post-mortems typically suggest. And owning that fact is the first step toward actually changing it.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?