If you are a city, county or utility leader trying to figure out what change management really means for a government ERP project, my short answer is this: it is not a communications plan and a round of training a month before go live. It starts the day you decide to replace the system, it needs a sponsor who will make hard decisions and stand behind them, it deals honestly with how roles, processes and in some cases labor agreements will change, and it gives you a way to hold go live until your people are ready rather than until the calendar says so. The rest of this post explains why I see it that way and what it looks like in practice.
Why the software is rarely what fails
When a government ERP implementation goes badly, the software usually gets the blame, but in my experience the software is rarely the real problem. The system does what it was configured to do. What goes wrong is that the people who use it every day were not part of the decisions that shaped it, the new way of working was never explained in terms that made sense to them, and the old way of working was left running in the background as a safety net that everyone quietly kept using. Months after go live, the agency has a new system and the same spreadsheets it had before.
The public sector makes this harder in ways a private company does not face. Staff often have long tenure and deep knowledge of the current system and its workarounds. Departments operate with real independence, and some, like an elected Auditor or Treasurer, answer to voters rather than to the manager. Pay and work rules may be set by collective bargaining agreements. And every misstep happens in public, in front of a council or board that approved the budget. A change management approach borrowed from a corporate playbook tends to miss all of that.
Start with a sponsor who will make decisions
The single most important change management decision is who sponsors the program, and I mean sponsor in the full sense. Your sponsor should be a senior leader with authority across departments who shows up, explains why the agency is making this change, and resolves the disagreements that the project team cannot. ERP projects create a steady stream of those disagreements, because a decision that simplifies life for finance may add a step for a department director, and someone has to decide which matters more.
If nobody at that level is willing to make those calls, they do not go away. They end up being made by the implementation vendor, by whoever argues longest in a design session or by default when the deadline arrives. That is how agencies end up with a system configured to replicate every old exception, which is the opposite of what they paid for. Governance with clear decision rights is not bureaucracy. It is the part of change management that keeps the project from drifting.
Map who is affected and how
Before you write a communications plan, figure out who is actually affected and what changes for each group. A payroll specialist, a department timekeeper, a purchasing buyer, a field supervisor approving overtime and a budget analyst will each experience the new system very differently. Some will gain visibility they never had. Some will lose a manual step they were proud of. Some will take on approvals that used to sit with someone else.
I like to build that picture with the people themselves, walking through a normal week and naming what changes, what goes away and what is new. That exercise does two things. It tells you where resistance is likely to come from and why, which is usually a reasonable concern rather than stubbornness. And it gives you a group of respected staff in each department who understand the change early and can carry it to their colleagues, which is far more persuasive than any message from the project office.
Bring labor and policy in early
In many local governments, changing how time is recorded, how leave is approved or how overtime is calculated touches a collective bargaining agreement, a civil service rule or a personnel policy. If those questions surface during testing, you are negotiating under deadline pressure, and that is a bad place to be. If they surface during design, you have time to work through them properly with HR, labor relations and union leadership.
The same goes for policy. A new system is often the first time an agency has to write down rules that have only ever lived in people’s heads, such as who can approve a purchase over a certain amount or how a grant expense gets coded. Treat those decisions as part of change management, because they are exactly the kind of change people feel most directly.
Make readiness a gate, not a date
Training matters, and I have written separately about why public sector ERP training fails and how to fix it. The short version is that people need to practice their own work, with their own data, close to when they will actually do it. But training is only one part of readiness. Before go live, you should be able to say with evidence that each department knows what is changing, that key users have completed realistic practice, that support is in place for the first weeks, and that the old system and the shadow spreadsheets have a planned end date.
When Los Angeles World Airports brought us in for an independent health check of its ERP program, one of the findings was that phases were advancing on calendar targets rather than on validated completion, and that governance existed but was not being used to stop progress when readiness criteria were not met. That pattern is common, and it is exactly what readiness gates are meant to prevent. Slipping a go live date is uncomfortable. Going live with people who are not ready is far more expensive, and I have made the longer case for a deliberate slip in you can’t outrun organizational gravity.
Plan for the months after go live
Change management does not end at go live. The first few pay cycles, the first month end close and the first fiscal year end are where people decide whether the new system is something they trust. Plan for extra support during those periods, keep a visible list of issues and fixes so staff can see that problems are being heard, and measure adoption directly. Are approvals happening in the system or by email? Are departments still running their own spreadsheets? Those answers tell you where the change has taken hold and where it has not.
On the HR and payroll implementation for the City of Winston-Salem, our role centers on governance and change management, with clear decision making protocols, a communication strategy set early, and particular attention to user readiness, training alignment and adoption planning. Payroll is a good teacher here, because every employee finds out on payday whether the change worked. That is the standard I would apply to every module.
My view
Across more than a hundred engagements, the government ERP projects I have seen succeed were not the ones with the best software or the biggest training budget. They were the ones where leadership owned the change, the people affected helped shape it and go live waited for readiness. If you want the same principles applied to a single module, my post on eProcurement change management walks through them for purchasing, and my earlier six steps to successful change management in government IT covers the broader framework.
If your agency is about to start an ERP implementation, or you are in the middle of one and worried that people are not coming along, I would be glad to talk it through with you. Book a decision review and we will look at where your change effort stands and what it would take to get your people ready before go live.