Why ERP Success Starts Outside of IT

Why higher ed sometimes gets ERP wrong and what it takes to get it right.

Many years ago, I got a late-afternoon call from the board chairman of the local hospital. The hospital was recovering from a crisis. A new electronic health record system had gone live, and it failed badly. Doctors, overwhelmed and distrustful of the system, stopped admitting new patients altogether, creating a sizable financial crisis. External consultants had been brought in, and the system was stabilized. I was asked to join the board to help chart the course of IT moving forward, and I agreed.

A root cause analysis told a clear story: the project had been led by the CIO, without clinical leadership at the center. The CEO was known to erupt when given bad news, so little truth ever surfaced. And the doctors and nurses, those closest to the work, were sidelined and left out of critical decisions that shaped the system’s rollout.

That experience was a vivid reminder that major system rollouts don’t fail because of bad technology. They fail because of a bad leadership structure. In today’s Dispatch, I lay out what stakeholder leadership really means for ERP implementations, how these projects must be organized to succeed, and why, despite all the technical complexity, their success ultimately has more to do with people and process than technology.

The big idea

In too many colleges and universities, ERP projects are still seen as technical initiatives. Executives may understand that the change is institution-wide, but when it comes to execution, they turn to the IT leadership to lead the project day-to-day. The assumption is simple: these are technology projects and IT should lead them.

ERP isn’t just about software; it’s about how an institution works. These systems encode how employees get paid, how budgets flow, and how decisions take shape. Success depends on institutional clarity, not technical cleverness. The system is only as good as the decisions that shape it, and just as important, how those decisions are carried out. That work belongs to the business. Stakeholders can’t simply approve designs in committee; they must lead the effort daily: visibly, operationally, and with authority. IT provides the technical foundation and scaffolding, but it’s the business that must model the change, make it real, and advocate for it across the institution.

Treating ERP like a technology project is like building a hospital without input from doctors. The structure may be sound, but the workflows won’t work. ERP fails not because technologists get it wrong, but because operational leaders aren’t leading. Stakeholders must do more than advise; they must lead the change: translating system design into daily decisions, process alignment, and real-world implementation. Without that leadership, even the best-built system will miss the mark.

It’s more like construction

ERP projects are best understood when using the analogy of designing and building a campus building. You need architects and engineers, project managers, developers, and integrators who understand budget, timeline, and technical complexity. But those professionals can’t determine what the building is for. They don’t decide where the classrooms go, how students flow through the space, or how services are delivered.

That’s the job of the client. In construction, that means the faculty, the student affairs leaders, the financial team, and whoever will live and work in the space. In ERP, the analogy holds. Stakeholders must define the business processes, the priorities, the exceptions, and the tradeoffs. They are the ones who know how the institution runs.

The real design happens not in committee, but in the day-to-day advocacy that shapes how work gets done. Because ERP always brings business process change, stakeholder leaders must do more than approve plans; they must visibly lead the implementation, take ownership as change impacts the community, and actively advocate for its value. That’s what turns a system from a technical deployment into an institutional upgrade.

Three projects, three lessons

I’ve seen this dynamic play out firsthand across three major ERP implementations I’ve helped deliver over my 23-year career as a CIO:

• Pepperdine (2007–2009): We had top-tier technical staff, some straight from PeopleSoft. They knew the system inside and out. But they didn’t have the authority or the insight to guide institutional change. Because IT led the project, campus stakeholders weren’t front and center. New processes were rolled out, but they weren’t embraced. The system worked, but the institution resisted it. We spent years rebuilding trust because of the perception of what “IT did to us.”

• UGA Banner (2012–2014): This project had strong stakeholder participation, but a trust gap emerged between at least one stakeholder and a key IT leader (me). For that stakeholder, I was perceived to be the “no police” who wouldn’t listen, while as CIO I felt pushed toward unnecessary complexity that threatened deliverables. Without trust or disciplined tradeoffs, progress stalled. Only under the pressure of go-live did team alignment emerge, just in time to make it over the finish line.

• UGA PeopleSoft (2016–2018): This project worked because it was led from the business side. The University’s former comptroller ran the effort day-to-day. She had deep credibility, decision-making authority, and the ability to align operational leaders around change. IT played a vital role, but we weren’t steering the ship. We were building it, maintaining it, and keeping it on course. Her leadership made the system usable, acceptable, and transformative.

As I now embark on my fourth ERP project (Workday Finance and HCM), those lessons are front of my mind. Before timelines, integrations, or data conversions are planned, the priority is ensuring the right stakeholder leadership is in place. If the people who own the business processes aren’t visibly leading the change, the system won’t stick. My job is to create the conditions where that leadership can thrive.

What CIOs should do

None of this minimizes the role of IT. Quite the opposite. The CIO must act like a general contractor: managing complexity, keeping the vendors honest, ensuring the project stays on scope, on budget, and on time. But most importantly, the CIO must forge a relationship of trust with the stakeholder leadership. That relationship is the difference between transactional coordination and true collaboration.

When that trust exists, the project has a chance to thrive. Decisions flow more smoothly. Risks are shared. Communication is honest. The institution moves together. Without it, even the best-designed systems will feel like foreign impositions, and adoption will stall, and tremendously difficult work will be even more difficult.

The best CIOs lead by enabling others. They don’t own the ERP project; they create the conditions for stakeholder leadership to succeed. That means more than managing scope and timelines; it means shaping the narrative with stakeholders. A good CIO helps the community see the system as more than technology, linking it to shared values, making the change human, and reinforcing why it matters.

The bottom line

ERP is not about technology or software projects. It’s about institutional self-understanding. It’s about process, policy, priorities, and people. It’s about making hard decisions together and sticking with them when the system forces clarity. 

If your ERP project is led by IT, you’re building the wrong kind of building. If your project is led by stakeholders, those who understand the business, live the work, and own the outcomes, with IT as a trusted and disciplined partner, then you’re not just building a system. You’re building alignment. You’re reinforcing trust. You’re creating a durable foundation for how your institution operates, adapts, and serves its mission.

ERP success isn’t about getting the software to work; it’s about building something that lasts, because the people it’s meant to serve were leading from the start.