Go-Live Is a Leadership Decision, Not a Project Milestone
Every ERP project reaches a moment when someone has to say, “We go live on this date.” It looks like a scheduling question. It is not. It is a question about how much risk an organisation is willing to carry, and who is willing to carry it.
Picture a line. At one end sits the view that says: on time, as soon as possible, keep pushing along. At the other end sits the opposite view: time doesn’t matter, we will not risk operations, we want everyone brought along, and we want no stress.
Each end has its own weakness. The first is over-optimistic, and it pays little attention to what the change does to people. The second protects everything and moves nothing. Neither end is wrong to want what it wants. The trouble starts when we get fixed at one of them.
The first extreme: go live because we said we would. A council announces a 1 July go-live for its new finance system. It is in the annual plan, the CEO has told Council, and elected members have mentioned it publicly. By April, testing is incomplete and the rates team has had two hours of training. But the date has been said out loud, and moving it feels like admitting failure. So the system goes live. Month-end close takes three weeks. Two experienced finance officers resign. The damage is far bigger than a delay would have caused, and it lands on people, not on a schedule.
The second extreme: never go live because it is not ready. Another council has a payroll system that is nearly there. Then one more round of testing is requested. Then a second parallel pay run. Then a pilot at one depot. Each step sounds responsible, and each can be defended in a meeting. Three years later the project team is tired, the budget is gone, the old system’s licences have been renewed again, and go-live still has no date. Nobody was ever blamed, because nobody ever decided.
Notice what the two have in common. In both cases, the decision is shaped less by the project than by a leader’s wish to look good and stay protected. In the first, protection means keeping a public promise. In the second, it means never being the person who pulled the trigger. Either way, the organisation pays for it.
So where should the line fall? There is no single answer. It depends on five things, and each one moves the position.
The project and its scope. Going live with one module, such as leave management, carries a different risk from going live with finance, payroll and rates together.
The environment we operate in. A go-live during rates notice season, the end of the financial year, or an election period carries risk that the same go-live in a quiet month does not.
People and culture. A workforce that has lived through three failed projects needs more time and more proof than one that has seen change go well.
Stakeholders. Whether the loudest voice is Council, a union, ratepayers or a regulator changes what “acceptable” looks like.
Organisational priorities. If the old system is about to lose vendor support, the cost of waiting is real, and it belongs in the decision.
Then there is the part nobody enjoys hearing. It is never going to be perfect. No system goes live with every process tested, every user confident and every report right. We must take a good level of risk. The only choice is whether we take it deliberately, with fallbacks and open eyes, or have it taken for us later.
This is why leadership is the key. The right decision today may be unpopular. It may mean telling Council the date will move. It may mean telling the project team that we go live with known imperfections. Yet decisions like these often take an organisation a long way tomorrow.
The project team can answer the question of readiness. Only leadership can answer the other one: is it prepared to take the risk, even when the decision becomes unpopular? And for those of us who advise them, will we be there to support them when it does?
