Trust Before Technology: Why Council ERP Programs Fail Before Go-Live

Every council ERP program produces a go-live readiness report. It usually looks healthy. Training attendance is high. Survey scores are green. The change champions have met  every month. The steering committee signs off. 

Then the system goes live, and within weeks someone finds the spreadsheets. 

The payroll officer who still calculates overtime by hand before entering it. The rates  team that keeps a parallel register "just to check". The finance officer who exports every  report to Excel because she does not believe the numbers on the screen. None of this  was in the readiness report. All of it was there before go-live. 
Shadow spreadsheets are not a training problem. They are a trust problem. And most  council ERP programs fail on trust long before they reach go-live. 

The plan did everything right 

Local government has become good at change management. Most ERP programs now  come with a communications calendar, a network of change champions, training for  every team and a readiness survey before cutover. 

None of it is wrong. But every change management plan assumes something it never  tests: that people believe what they are being told. 

Consider a payroll team that lived through the last system change. They were told it  would make their work easier. Instead, they spent eighteen months on workarounds  while the people who made that promise moved on to other roles. When the new  program arrives, they attend every session. They complete every survey. They answer  the readiness questions the way they know they are meant to. And they quietly keep  their spreadsheets, just in case. 

From the steering committee, this looks like adoption. It is compliance. From the front  of the room, the two look identical. The difference only shows when the program needs  something that cannot be compelled: honest defect reporting in testing, extra effort  during cutover, and a willingness to let the old spreadsheet go. 
This is why so many programs look ready and are not. The readiness data is only as  honest as the people filling it in. When trust is low, people act right rather than do right.  They say what is expected in the workshop and save what they really think for the  corridor. Defects go unreported in user acceptance testing because nobody wants to be  the one holding up the project. Process owners sign off designs they have not fully understood, because asking questions feels risky. 

Each of these small silences becomes a problem after go-live. The shadow spreadsheet  is simply where they end up. 

Trust does not come with the title 

A CIO or Director has authority on day one. They can approve the budget, choose the  vendor and set the go-live date. What they cannot do on day one is get people to believe  them. The title gives a leader the right to be heard. It does not give them the right to be  believed. 

Trust is earned by being genuine and truthful, and by working sincerely towards a  common goal while serving the people affected. On an ERP program, each of these  shows up in practical ways. 

Genuine means the message to the steering committee matches the message to staff.  If the board paper says the project is on track and the corridor says otherwise, people  believe the corridor. 

Truthful means saying the inconvenient thing early. Telling staff that the timeline is at  risk before they discover it themselves. Admitting that a design decision made six  months ago was wrong. Truth told early costs something. Truth discovered later costs  far more, and it is paid for in trust. 

A common goal means the program is about better services and less rework for staff, not about someone's career, budget or legacy. People can tell whose goal it is. 

Service shows up in small, unglamorous decisions. Who gets protected when testing  goes badly. Whose workload is considered when the deadline moves. Who gets the credit when the first pay run balances. Staff watch these decisions far more closely than they listen to project briefings. 

What leaders can do before go-live 

Trust cannot be built in the final month of a program. But leaders can stop eroding it,  and start earning it, well before cutover. 

Acknowledge the history. If the last system change hurt people, say so before  launching the next one. Staff are not resisting the new system. They are remembering the old promise.

Ask where the spreadsheets are, and why. Treat shadow systems as information, not  defiance. Each one points to a process the new system does not yet support, or a number someone does not yet believe. 

Reward bad news. When a tester raises a serious defect late, thank them in public. The  first person punished for honesty will be the last person to offer it. 

Keep one message. What goes to Council, the executive and the project team should  be the same story, told at different levels of detail. 

Be in the room. When a leader says the first month will be hard, people will judge that  statement by where the leader is during that first month. 

The order matters 

Most organisations treat trust as an outcome of good change management. Run the process well, communicate clearly, and trust will follow. It works the other way.

Trust is the precondition. Without it, the best change plan becomes a list of activities that  people complete without committing to. 

Technology rarely fails councils as often as we say it does. The system usually works.  What fails is the belief that it will, and the willingness to let the old way go. 

So before the next readiness report is signed, it is worth asking one uncomfortable  question. 

If you removed your title tomorrow and asked your staff to give up their spreadsheets,  how many would?