The First Six Months Decide Everything

ERP implementations fail early, quietly, and for reasons most leaders never see coming.

For the twelfth year, I’m teaching business process management at the University of Georgia. It’s a sixteen-week crash course in ERP implementation consulting, focused on process discovery, redesign, and financial modeling. Early in the course, we cover BPMN: Business Process Management Notation, a technical but essential skill for diagraming processes as a first step before configuring systems like Workday.

A student once told me, “My mom’s a systems implementation consultant. I mentioned we’re learning BPMN, and she said, ‘That’s a great skill but most clients won’t pay for it anymore. They just want to go straight to implementation.’” That led to conversation about the consequences of skipping process improvement. Everyone wants the benefits of transformation, but few want to pay for the discipline it requires.

That mindset reflects why ERP implementations fail. When you rush design, skip discovery, and treat the system as an IT project, the result is always the same: missed deadlines and exploding costs. In today’s Dispatch, I discuss why ERP projects fail and why treating them like construction projects is the key to getting them right.

The big picture

Enterprise systems are the operational backbone of modern institutions. They don’t just support administrative work, they are the work. These systems manage financial operations, HR, procurement, payroll, budgeting, benefits, and customer data. When they function well, the institution runs smoothly. When they don’t, everything suffers.

ERP implementations can go off track. Deadlines slip, costs escalate, trust erodes. But the root cause isn’t the software. It’s a failure to understand that ERP isn’t an IT deployment; it’s an institutional reconstruction. And the most common failure pattern is leadership treating it like a tech upgrade rather than a business transformation.

If your institution is preparing to move to a fourth-generation ERP platform like Workday or Oracle, this is your opportunity, and your only shot, to get it right. These are generational investments. Done well, they strengthen the institution’s core operations. Done poorly, they become expensive systems that few use effectively.

ERP’s Evolution and the Road Ahead

ERP systems have gone through four generations, each aiming to fix the shortcomings of the last, while introducing new tradeoffs along the way.

First-generation systems were built from scratch, tailored to fit exactly how institutions operated. But they were brittle, expensive to maintain, and quickly became obsolete. Second-generation platforms offered vendor products with heavy customizations. The promise was vendor support without sacrificing control, but over time, those customizations broke upgrade paths and reintroduced support risks.

Third-generation systems brought modularity. Institutions adopted a core system and integrated third-party systems using Internet technologies. This improved flexibility and user experience, but it fragmented the data landscape. Every tool had its own schema and logic, making institutional reporting slow, expensive, and error-prone.

Fourth-generation platforms like Workday and Oracle Netsuite have shifted the model again. These are cloud-native, designed for configuration instead of customization. They unify data, embed reporting, and come with long-term support contracts that reduce the risk of technical debt. It’s a move from building and owning everything to orchestrating adaptable systems that evolve with the institution.

This shift, from ownership to orchestration, will define business information systems for the next 20 years. The primary IT agenda is clear: migrate legacy ERP systems to modern, cloud-native platforms. But this isn’t just a tech upgrade. It’s a full-scale redesign of business processes and data strategy. Treating it as an IT project, or outsourcing the thinking, guarantees delays, cost overruns, and loss of trust.

Why ERP Projects Fall Apart

The best way to understand an ERP implementation is to think of it as a construction project. There are four distinct phases: defining a project, designing the system, implementing it, and then stabilizing. Just like in construction, each phase builds on the last. If the foundation is shaky, the structure won’t hold. You wouldn’t revise architectural plans after pouring the foundation of a building, yet in ERP projects, institutions routinely change requirements midstream, expecting the implementation team to absorb the impact without delay or cost. That’s where things begin to unravel.

In construction, late changes trigger change orders. They’re visible, expensive, and disruptive. In ERP, the same shifts often happen informally and invisibly. Processes aren’t fully mapped. Requirements shift late. Testing reveals mismatches. Consultants are asked to stay longer, deadlines slip, and scope expands in all directions. Every month of delay can add millions in additional consulting costs. More importantly, the trust of stakeholders erodes and that’s much harder to recover than budget.

Most ERP failures follow the same pattern. Institutions rush the early phases. Process discovery is shallow. Documentation is incomplete. Executives aren’t close enough to the way real work gets done. Then, in implementation, the gaps surface and rework begins. Testing cycles break down. Data doesn’t align. These are not technical failures. They are planning failures. Strategic failures. Leadership failures. You cannot outsource planning. If the project skips the hard work up front, no amount of vendor effort will fix it later. The cost of clarity is paid at the beginning or tenfold at the end.

The Four Phases of ERP—If You Want to Get It Right

ERP implementations succeed when leaders respect the structure of the work. Like construction, these projects unfold in stages. Skip one, rush one, or treat it as a formality, and the entire project suffers downstream. Each phase builds institutional muscle: clarity, coordination, trust. And each one takes time. A full ERP rollout, from early commitment to full stabilization, typically spans three to four years. Not because it’s inefficient, but because it’s comprehensive. Here’s what it takes to get it right:

1.Define & Discover (Year 1)

• Inventory existing business processes across units.

• Conduct a competitive procurement for the core ERP platform.

• Select an experienced implementation partner.

• Build a detailed budget and long-term business case.

• Secure board and executive-level commitments.

This is the phase where the institution steps into the project with eyes open. You are committing to a multi-year transformation that will reshape how the organization works. There’s no turning back once this phase is complete so get alignment early.

2. Design (Year 2)

• Apply Lean/Six Sigma principles to eliminate redundant steps and reduce handoffs.

• Document a “fit-gap” analysis between current processes and system capabilities and resolve mismatches through:

  • Business process redesign,

  • Integration with third-party tools, or

  • Minimal, well-governed customization (as a last resort).

• Define your data conversion and reporting needs.

• Begin end-user training and stakeholder engagement.

This is the most important phase and the one most likely to be compressed. Don’t. The discipline applied here determines whether implementation is straightforward or chaotic. This is where the work becomes real for the people who will live with the system every day.

3. Implement (Year 3)

• Configure the ERP to match redesigned business processes.

• Convert and validate historical and operational data.

• Conduct end-to-end testing across functional areas.

• Finalize reporting dashboards and reconciliation tools.

• Train users and prepare for go-live.

By this point, scope discipline is critical. If timelines compress, you can’t throw more consultants at the problem, they won’t know your business well enough to help. You’ll need to reduce scope intentionally, not improvise under pressure.

4. Stabilize (Year 4 and beyond)

• Resolve defects and support pain points from go-live.

• Monitor system performance and user adoption.

• Address deferred scope items or shadow systems still in use.

• Optimize reports, workflows, and automation over time.

Go-live isn’t the end, it’s the beginning of ERP stewardship. Stabilization is where institutions earn or lose long-term trust in the system. The most successful teams build continuous improvement into their roadmap from the start.

An ERP project is not a sprint. It’s an institutional reset. Rushing early phases may feel efficient in the moment, but the cost comes later in delays, defects, and disillusioned users. If you want your system to work for the long haul, respect the phases. Don’t skip the foundation and hope the roof holds.

When Crunch Time Comes, You Will Cut Scope

When ERP projects enter the final stretch, problems often surface: dirty data, failed testing, missing functionality, or unresolved edge cases. At that point, your options narrow quickly. Extending the timeline usually means extending every consultant’s contract, often at a cost of hundreds of thousands per month. Bringing in new consultants to help isn’t a real solution either; they don’t know your business, can’t ramp up fast enough, and often create more confusion than clarity. And shifting the go-live date triggers a cascade of operational impacts, financial calendars, HR cycles, academic terms, that are difficult, sometimes impossible, to realign.

So what happens? You cut scope. You keep some legacy systems in place a little longer. You ask users to handle certain processes manually. You defer some reporting features or integrations until phase two. And none of that is failure, unless it comes as a last-minute scramble. The difference between a successful go-live and a painful one is whether those scope decisions were strategic or reactive. Strong projects plan for triage in advance. They define what must go live, what can wait, and how to manage the trade-offs. Weak projects pretend everything will work, until it doesn’t.

The final word

ERP implementations don’t fail at go-live; they fail in the first six months, when leaders shortcut discovery, skip process redesign, and rush into implementation. The early phases are where clarity is built or where confusion takes root. Too often, leaders treat ERP as a technology project and hand it off, as if IT staff are capable of filling in the gaps. But IT can’t fix what the business hasn’t defined. When decisions are left vague, the real costs show up later in rework, delays, and eroded trust.

You only get one chance to implement a new ERP system. If users lose faith during rollout, they rarely come back for phase two. That’s why the early phases matter most. Invest the time. Involve the right people. Make hard calls early. And when the pressure hits, cut scope strategically, not reactively. ERP isn’t a software purchase. It’s a once-in-a-generation opportunity to rebuild how your business actually works.

Build trust early or spend years digging out.