ERP Is an Organizational Decision, Not a Technology Decision
There's a pattern that shows up in almost every municipality we work with.
The conversation about ERP starts in IT. Someone recognizes that the current system is aging, that workarounds are multiplying, that reporting is unreliable. They raise it with leadership. There's agreement that something needs to happen.
And then the project gets treated as an IT initiative.
IT leads the requirements. IT manages the vendor conversations. IT owns the timeline. Other departments participate when asked, but the project lives inside a technology frame from start to finish.
This is where things start to go sideways.
Not because IT isn't capable. In most municipalities, IT is doing excellent work with limited resources. But ERP touches every department. It changes how finance processes payments, how HR manages onboarding, how operations tracks assets, how the organization reports to council. Treating it as a technology project limits the decisions to technical ones, and the most important decisions in an ERP project aren't technical at all.
The decisions that matter most are organizational.
Which processes are we going to keep? Which ones are we going to change? Who is going to own what in the new system? How are we going to manage the transition for staff who have been doing things a certain way for years?
These are not IT questions. They're leadership questions. And when they get deferred or delegated, they don't go away. They just resurface later, usually during implementation, when they're harder and more expensive to deal with.
Research backs this up consistently. Among organizations that have completed an ERP implementation, 77% identified leadership support as the single most critical factor in whether the project succeeded. Not the software. Not the vendor. Not the technical architecture. Leadership.
And roughly half of ERP deployments in state and local government agencies ultimately fall short of expectations. The common thread in those failures is rarely the technology itself. It's governance gaps, unclear ownership, poor change management, and a lack of organizational alignment before the project started.
What "organizational" actually looks like.
When we talk about treating ERP as an organizational decision, we mean a few specific things.
It means the project has visible sponsorship from senior leadership, not just support on paper. The CAO or city manager is actively involved, not just informed.
It means governance is established before procurement begins. There's a steering committee that can make decisions. There's a working group that includes people from finance, HR, operations, and IT, not just IT alone.
It means change management starts early. Staff hear about the project before it's already underway. They understand why it's happening and what it means for their work. When that doesn't happen, resistance during implementation is almost guaranteed.
And it means the organization takes a hard look at its own processes before it starts evaluating software. Every municipality has ways of working that have built up over time. Some of those processes are necessary. Others exist because they always have. ERP has a way of exposing that. If those conversations happen early, the organization goes into procurement with much more clarity. If they don't, those same issues show up later, when the stakes are higher.
The shift that makes the difference.
The municipalities that have the smoothest ERP experiences tend to make one fundamental shift early on. They stop asking "what system should we buy?" and start asking "what do we need to be ready for?"
That shift changes who's involved, what gets prioritized, and how the project is governed. It moves the centre of gravity from IT to the organization as a whole.
ERP is a technology project in the same way that building a new city hall is a construction project. Technically, yes. But the decisions that determine whether it serves the community well have very little to do with the building itself.
The same is true here. The system matters. But the organization's readiness to use it well matters more.