Go-Live Is Not the Goal

A go-live date is the most heavily defended date in an ERP project and the least meaningful one. It is the day the system starts, not the day the work finishes. Yet almost every project plan we inherit treats it as the closing entry: success criteria, budget, steering committee and the availability of the people who understood the design all expire within a fortnight of it. The project gets declared a success for having switched over. Whether it produces the result it was bought to produce is, by then, nobody’s remit.

Governance treats a milestone as an ending

Read the success criteria in most implementation plans and you find that they describe an event rather than a result. Did the system go live. Did it go live on the agreed date. Did anything break in the first week. Was the cut-over finished inside the weekend window. Every one of those is answerable by Monday morning, which is exactly why they get chosen. They close cleanly.

The questions the business actually cared about when it signed do not close on a Monday. Nobody buys an ERP in order to have an ERP. They buy it to close the month in days rather than weeks, to stop pricing errors reaching customers, to see stock across three warehouses on one screen, to hand an auditor a figure without a week of reconciliation. Those can only be answered once two or three full cycles have run through the new system — which is well after the project, as governed, has ended. Readiness and the date are separable in the other direction too. Our Waterlogic Czech Republic implementation was built, tested and production-ready while the client postponed the go-live date; the system was no less finished for the date having moved.

What leaves in the fortnight after go-live

• The steering committee holds its closing meeting and stops meeting. An escalation route that resolved a blocker in two days becomes a service-desk queue.
• The budget line closes. Anything discovered in week three is a change request competing with next year’s new initiatives, rather than protected work inside this one.
• The consultants and key users who made the design decisions roll off. The reasoning behind a configuration choice leaves with them and gets rediscovered later by trial and error.
• Key users return to their day jobs at full load, having been at half availability for months — precisely when colleagues start asking them how to do things. In a mid-sized Belgian company those are often the same three people who also close the books.
• Attention moves on. The sponsor has already reported the milestone upwards, and reopening it looks like backsliding.

None of this is a failure of will. It is an organisation doing exactly what its governance told it to do, because the plan said the project ends here. The timing is unfortunate in a specific way: the fortnight in which support capacity collapses is the same fortnight in which real volume, real edge cases and real user behaviour reach the system for the first time. The load arrives as the help leaves.

A silent go-live is evidence, not an ending

A silent go-live is a switch-over that is a non-event. Monday arrives, people log into a different system, orders keep shipping, nobody escalates anything. It is the right thing to aim for, and we aim for it on every implementation, because a quiet cut-over is the visible proof of unglamorous work done months earlier: the migration was rehearsed, the data was reconciled before the weekend rather than during it, and the people using the system on Monday had already used it in testing. The quiet is earned in advance, not on the night. It is also the most misread outcome in the project. Quiet gets taken as complete — if nothing broke, the reasoning runs, there is nothing left to do — and the calm that all that preparation bought is spent disbanding the team that produced it.

Nothing breaking on Monday tells you the cut-over worked. It tells you nothing about whether the system does what you bought it for.

Measure what the system was bought to produce

• Cycles completed, not deployments completed. Has the business closed a full month, run a full payroll, survived a quarter-end inside the new system? A cycle that has not run has not been tested.
• The reconciliation gap. How far apart are the new system’s numbers and the numbers the business trusted before it, and can you explain every remaining difference? That, not the migration sign-off, is the real acceptance test for data.
• Workarounds counted. How many teams have built a spreadsheet alongside the system in the first six weeks? Each one is a requirement that was missed, deferred or badly trained — cheap to fix now, expensive once it hardens into habit.
• Ticket shape rather than ticket volume. Volume always spikes and always falls. The mix is the signal: “how do I” tickets are a training gap and decay on their own, while “the system gives the wrong answer” tickets are a design or data problem and will not.
• Who answers the question. If every non-trivial question still routes to the implementation partner after two months, knowledge transfer has not happened, whatever the handover document says.
• The business case, restated. Whatever justified the spend — days to close, error rate, hours of manual re-entry, stock accuracy — is the scoreboard. Report against those figures once two cycles have run, not against how the launch weekend felt.

When a project is actually finished

Our position is that an implementation is finished when the organisation can run and change the system without the people who built it. Three things have to be true. The business has completed at least two full reporting cycles in the new system with no parallel run behind it. The workarounds that appeared in the first weeks have either been designed away or consciously accepted as permanent. And internal staff, not the partner, resolve the ordinary questions. For a mid-sized ERP that point usually falls somewhere between two and four months after cut-over, not two weeks.

Which has three plain governance consequences. The steering committee keeps meeting, at lower frequency, until those conditions are met. The budget reserves a share for the period after go-live instead of treating cut-over as full expenditure. And at least one person who made the design decisions stays reachable through the months in which the questions actually arrive. None of that is expensive next to the implementation itself — it is only expensive next to a plan that assumed the work was already over. Move the finish line to where the outcome is, and go-live goes back to being what it always was: a quiet Monday in the middle of the project rather than the end of it.