In Part 1, I wrote about what happens after an ERP implementation fails. The staff morale collapse, the customer relationship damage, the credibility crisis.
This part is about preventing that from happening in the first place... specifically, the work that happens before a single vendor is contacted. The preliminary, foundational work that most companies skip or compress because they're eager to get to the demos, the RFPs, the "real" project.
That eagerness is exactly how failures begin.
If you want the operational warnings (scope discipline, executive sponsorship, data migration, vendor incentives), I wrote about those separately: I've Watched ERP Projects Fail for 25 Years. The Mistakes Haven't Changed.
This piece is about everything that should happen before you commit.
ERP Failures Are Human Failures
ERP failures are almost never caused by bad software.
They happen because someone missed something in the gap analysis, because testing was signed off on without actually being tested... not a cursory walkthrough, but rigorously, with real data, under real conditions. They happen because a parallel test was never completed before cutover, because you relied too heavily on outside consultants who didn't understand your customer-specific processes, because a requirement that seemed obvious to the people doing the work never made it onto a requirements document.
I've seen every one of these. Multiple times.
Those are human failures dressed up as technology failures. And they're entirely preventable.
Do You Actually Need a New System?
Before you even think about vendors, demos, or RFPs, you need to answer a more fundamental question... do you actually need a new ERP system?
I call this the Business Operations State Review. The concept is simple. You're exploring whether a major ERP implementation or upgrade is even necessary.
Maybe your current system does what you need and you just haven't configured it properly. Maybe there's a training issue and your people aren't using the capabilities that already exist. Maybe someone built a workaround five years ago and it became "the way we do things" even though the system was designed to handle it differently.
This doesn't need to be a formal audit. It's a company-wide conversation. You ask: What's working? What isn't? What's the best part of the system? What's the worst? What do you wish the system could do that it isn't doing?
Expect it to turn into a complaint session. That's fine. Let people vent, then steer them toward specifics. Plan for a second round of follow-up sessions, because the first round will surface things that need clarification.
This work lays the groundwork for everything that comes next. Skip it and you're building on assumptions. I've watched companies commit six figures to a new system when the real problem was that nobody had trained the warehouse team on the module they already owned. That's not a technology failure. That's an expensive way to discover you didn't ask the right questions.
Due Diligence: The Step Everyone Rushes
If the Business Operations State Review confirms that you do need to move forward, the next phase is due diligence. And this is where most projects go off the rails before they've even started.
Due diligence is a structured evaluation process conducted before software selection or implementation. Its purpose is to validate whether your business can actually operate the system you're about to commit to... not just whether it has the right features, but whether it supports how your business actually runs today and how you intend to grow.
Too many ERP projects are treated as IT projects instead of business projects. IT leads because they're told to lead. But IT, no matter how capable, doesn't know the day-to-day intricacies of your supply chain, your customer-specific processes, your sales operations.
You need cross-functional stakeholder representation from the very beginning. Finance, operations, sales, warehouse, customer service... the people who will live in the system every day need to be in the room when you're deciding what the system should do. Not consulted later. In the room. From the start.
What does due diligence actually cover? Several dimensions, and skipping any of them creates risk you won't see until it's too late.
You need operational and financial validation... aligning business processes with system design, defining clear financial decision rights, validating data integrity to ensure the system can operate reliably under real conditions. I've seen companies discover six months after go-live that their costing model doesn't work and every margin report they've run is wrong. That's what happens when you skip this.
You need risk assessment... identifying structural risks like misaligned costing, weak reporting logic, poor governance. These lead to unreliable financials, manual workarounds, and audit exposure. You'll spend the next two years explaining variances to your board that nobody can trace.
You need stakeholder and resource review. Do you have executive sponsorship? Real sponsorship, not a name on an org chart. Do you have the human resource capacity to sustain a project of this scale? Are the right people aligned? Your best people will burn out six months in if you haven't planned for this.
You need vendor and technology evaluation. Investigate potential vendors' financial health and legal history. Examine your existing ERP architecture... licensing structures, customization depth, integration complexity. I've watched companies sign contracts and then discover the vendor is being acquired, the licensing model is changing, or their "simple" integration requires a six-figure middleware investment nobody budgeted for.
You need feasibility and requirements work. Conducting feasibility assessments to justify ROI, creating comprehensive Business Process and System Requirements documents that define critical business needs and identify fit/gap areas. Skip this and you'll build a system based on what the vendor demo showed, not what your business actually needs.
Gap Analysis: Where Reality Meets the Sales Demo
Gap analysis is where you take the theoretical requirements gathered during due diligence and turn them into a practical assessment of fit. This is where you find out whether the ERP you're considering can actually do what your business needs it to do... or whether you're going to spend the next two years building workarounds.
A proper gap analysis identifies shortcomings. It catalogs disconnects and deficiencies in the proposed system relative to your primary business needs. Not the nice-to-haves. The things that matter.
The results inform decisions. Should you proceed with this solution? How should you configure it? Do you need customizations, workarounds, or third-party integrations?
Done early, gap analysis reduces risk. It prevents the scope creep, budget overruns, and implementation failures that occur when issues are discovered too late... usually after go-live, when your staff is scrambling and your customers are waiting.
Do not skip this. Do not compress it. Do not set a hard completion date because someone wants to hit an arbitrary go-live. ERP projects have massive effects on your business. Treat the decision with the gravity it deserves.
Software Selection: More Than a Demo
Once you've completed due diligence and gap analysis, you move to software selection. This is where most companies think the process starts. It doesn't. Everything before this point is what makes selection meaningful.
Proper software selection includes Requests for Information and Requests for Proposal to gather detailed data from vendors. It includes demonstrations... not just the executive dog-and-pony show, but functional demos that show the software handling your actual business processes, technical demos that reveal what's under the hood. It includes vendor assessments covering financial stability, development roadmap, and support capabilities. And it includes reference checks to validate real-world performance. Talk to companies like yours. Ask what went wrong, not just what went right.
The goal is to select the ERP software that most effectively meets the critical "must-have" requirements you identified during due diligence. Not the one with the best demo. Not the one with the most impressive slide deck. The one that fits your business.
Commit the Resources or Don't Start
As a business leader, understand what you're signing up for. An ERP implementation of any meaningful scale will require sustained commitment of internal resources over months or years. Your best people will need to be pulled into this project. If you can't sustain that without crippling your operations, you need to supplement with outside help.
And if you decide to move forward, the project should be part of your corporate strategy. Not a side initiative. Not something IT is "handling." A strategic priority with executive visibility, regular monitoring, and accountability at the highest level.
If you're not willing to commit at that level, don't start. A half-committed ERP project is worse than no project at all. I've inherited those. They don't end well.
The 10 Commandments of ERP Project Success
Between this article and the piece I wrote on operational failures, you have the full picture. Here's the summary:
- Thou shall confirm thy need before thy search. Conduct a Business Operations State Review to determine if a new system is even necessary.
- Thou shall treat this as a business project, not an IT project. Cross-functional representation from day one.
- Thou shall not skip thy due diligence. Validate operational fit, financial alignment, and organizational readiness before thou touch a vendor.
- Thou shall conduct a real gap analysis. Find the disconnects before they find thee.
- Thou shall select software based on fit, not demos. Reference checks matter more than slide decks.
- Thou shall commit thy resources or not start at all. A half-staffed project will fail.
- Thou shall require active executive sponsorship (showing up, not just signing off). Show up or step aside.
- Thou shall define thy scope early and defend it ruthlessly. Saying no is a leadership function.
- Thou shall not customize without justification. Before approving any customization, ask: Is this process necessary in the first place? Does the system offer something out of the box that could work instead? Employ the 5 Whys. Most "must-have" customizations are preferences dressed up as requirements.
- Thou shall clean thy data before the project, not during. Thou either fix it now or import garbage.
Print this list. Tape it to your wall. Reference it before every steering committee meeting. It won't guarantee success, but ignoring it will almost certainly guarantee failure.
______________________________________________________________________________________________
Raphael Savastano is the founder and principal consultant of ROFONIC LLC. With 25+ years in IT, 16 years in leadership, including 8 years as CIO scaling technology for a global manufacturer from M to 0M. He now helps growing companies get executive-level technology and operations leadership without the full-time cost. Want to know where your technology actually stands? Take the Founder’s IT Reality Check →
