Why ERP Replacements Fail: The Requirements Challenge
Enterprise Resource Planning (ERP) systems touch nearly every facet of an organization’s operations. Replacing one is not simply a technical exercise—it’s a business transformation. And yet, many projects are set up for failure before they even begin, all because of one overlooked reality:
If you don’t know what you need, you won’t be satisfied with what you get.
At the heart of ERP success lies a deceptively complex task: defining comprehensive requirements. It’s not enough to want a “better system.” You have to know what better means—precisely. The devils really are in the details.
Misstep #1: Asking the Wrong Question
One of the most common pitfalls is asking business process owners what they want from a new system. Preferences are a moving target. What’s more useful—and far more reliable—is asking what business processes they own and what outputs those processes must deliver. This anchors your requirements in reality, ensuring the new system supports core operations, not aspirational wish lists.
Misstep #2: Writing Vague, Shallow Requirements
A few bullet points in a spreadsheet cell might work for a lunch order, but they fall far short for enterprise software. A robust requirement needs to be fully articulated:
Title – A short name for discussion.
ID – A stable reference even when the title changes.
Description – Clear articulation of what the system must do.
Example – A real-world scenario to reduce ambiguity.
Reason – The value or outcome this requirement supports.
Notes – Additional context or clarifications.
This level of structure isn’t bureaucracy—it’s risk mitigation. Ambiguity early on leads to costly surprises and delays later.
Misstep #3: Using Flat Spreadsheets for Complex Structures
Early-stage projects often start with spreadsheets, which feel sufficient at the time. But requirements aren’t linear—they’re hierarchical. They need to be decomposed into levels of detail. While technically possible in a spreadsheet, the effort becomes unwieldy at scale. We’ve found tools like Smartsheet.com effective for managing hierarchical requirements with appropriate structure and traceability.
Misstep #4: Compound Requirements
Statements like “The system must do A, B, and C” may seem efficient, but they obscure clarity and hinder implementation. Each function should be broken down into a parent requirement and distinct child requirements. We find the hierarchy often gets up to 8 levels deep. This provides for more precise validation, testing, and accountability during implementation.
Misstep #5: Underestimating the Effort
Writing well-structured, business-aligned requirements is labor-intensive. Even with AI support, it takes about an hour per requirement. For an ERP system with 3,000 requirements—a modest scope by enterprise standards—that’s a full year of dedicated effort for one person.
When teams realize the scale of this task, shortcuts become tempting. But those shortcuts are costly. They lead to mismatches between business needs and software capabilities, which in turn derail timelines, inflate budgets, and compromise outcomes.
The Bottom Line
Comprehensive requirements are not just a project deliverable—they are the blueprint for success. Without them, even the most powerful ERP system will fail to deliver meaningful business value. The effort is significant, but so are the rewards: clarity, alignment, and the confidence that your new system will work as hard as your business does.