Most ERP selections go wrong months before anyone signs a contract. A shortlist gets built around which vendors responded fastest or gave the slickest demo, and by the time the business realizes the system doesn’t fit how it actually operates, the budget is spent and implementation is already underway.
Budget overruns and missed timelines are common enough in ERP projects that most people in this line of work plan around them as the default outcome, not the exception. That pattern usually traces back to how the decision got made in the first place, not to anything that happened during the build.
The usual approach starts backwards. A business decides it needs “a new ERP,” books a handful of vendor demos, and picks whichever one impressed the room most. The demo becomes the decision-making tool, which is a problem, because a demo is built to sell, not to diagnose. Every vendor shows the version of their system that looks best: polished modules, simple workflows, reports that look good on a screen. None of that tells you whether the system fits how your business actually runs.
Without clear requirements going in, a few things happen almost every time. Features that looked exciting in the demo turn out to be irrelevant once the system is live. Something the business genuinely needed — a specific approval workflow, a reporting format a regulator requires — gets discovered missing only after go-live. Budget conversations happen before anyone has a clear sense of what’s actually required versus what’s just nice to have, so the business either overpays for capability it won’t use or underbuys and hits a wall within a year.
None of this is unique to ERP, but ERP makes it expensive. A website choice can be walked back in a few weeks. An ERP choice gets built into years of financial and operational workflow, which is exactly why getting it wrong costs so much more to unwind.
The fix starts from a different premise than most vendor-led selection processes: assessment comes before any recommendation, not after. That’s the sequence we actually run with clients — discovery, a diagnostic phase to get at root causes, requirements definition, vendor evaluation against those requirements, governance through the build, staying present through go-live and stabilization, and a formal close-out once it’s done.
Most of the real work happens in that diagnostic phase. It’s where current processes get documented as they actually are, workarounds and spreadsheets included — the ones that crept in because the old system couldn’t handle something. That workaround is almost always covering for a genuine requirement, and it’s usually invisible until someone goes looking for it.
From there, requirements become something you can actually evaluate vendors against, instead of something discovered mid-demo. Vendors get scored on what the business genuinely needs, not on how good their presentation was, which matters more than it sounds. A vendor who presents well and a vendor who fits well are frequently not the same company.
What keeps this honest is simple enough: there’s no referral arrangement sitting behind the recommendation, so the advice reflects fit rather than incentive, and the person who ran the diagnostic is still around through implementation and into go-live rather than disappearing once the contract’s signed. A lot of what goes wrong with ERP projects happens right there, in the handoff between whoever scoped it and whoever built it.
Where a business comes in depends on where it actually stands. Some just want the diagnostic, enough to know whether replacement is even necessary. Others want the whole journey, start to finish. A few have already picked a vendor and just want someone watching the build.
The real test of an ERP decision isn’t the signing moment. It’s six months after go-live, when the business can point to the actual requirements that drove the choice and say, honestly, whether the system is meeting them, not just running. Staff aren’t quietly rebuilding workarounds in spreadsheets because something critical got missed. There’s a record of what was delivered and agreed to, so “did this work” has a real answer instead of a shrug.
Most ERP projects don’t end up there. The ones that do are usually the ones where somebody insisted on understanding the problem before buying anything meant to solve it.
Firm Methods is a strategic IT and digital consulting firm that works closely with business owners and leadership teams to design, govern, and execute technology initiatives the right way.
Firm Methods is a strategic IT and digital consulting firm that works closely with business owners and leadership teams to design, govern, and execute technology initiatives the right way.
