The First Week After Go-Live

Acceptance testing proves a system does what the specification says under the circumstances the test described. Go-live is when it starts meeting circumstances nobody described: the night shift, the product changeover, the one operator who does things differently, the weekend when the network team pushes a firewall change.

Plan for that week specifically. It is not the tail of the project, it is a distinct phase with its own work, and treating it as "we finish on Friday and support picks it up on Monday" is how good systems acquire bad reputations in their first fortnight.

Be present. Someone from the project should be on site, on the floor, during the shifts that matter — including at least one night shift, because the night shift is where the undocumented practice lives and where nobody will phone a supplier to ask a question. What you learn standing next to an operator in the first week is information that no amount of later reporting will produce, because the things that annoy people are exactly the things they stop mentioning after a fortnight and simply work around.

Watch for workarounds rather than complaints. A complaint is easy; someone tells you the screen is wrong. A workaround is silent: a value written on paper because the system's number is not trusted, a step done before the system sees it, a second spreadsheet maintained in parallel. Every workaround is a defect report that has given up on being filed, and finding them is worth more than any satisfaction survey.

Expect data problems before functional ones. The logic usually works; it was tested. What was not tested is a year of real inputs — the batch with a missing code, the tag that reads exactly zero when a sensor is disconnected rather than going to fault, the operator entry with a comma in it, the shift that starts at 06:00 on weekdays and 07:00 on Saturdays. These surface in the first fortnight and they look like software bugs. Mostly they are assumptions meeting reality.

Keep a single visible list. One place where every issue goes, with an owner and a state, visible to the customer as well as the project team. This sounds bureaucratic for a week of work and it is the difference between a controlled handover and a series of half-remembered phone calls. It also gives you the evidence, at the end, that the noise level dropped — which is the only honest basis for saying the system is stable.

Resist the urge to fix everything immediately. The temptation in week one is to change things on the running system as they come up, because the team is there and it is quick. Two weeks of that produces a system whose live configuration matches neither the documentation nor the test environment, and nobody can say what changed when something breaks. Batch the changes, apply them deliberately, record them, and keep the emergency path for actual emergencies.

Finally, set the exit criteria before the week starts, in writing: what has to be true for the project to hand over. A number of open issues below some threshold, a period with no severity-one events, the operators signing that they can run it, the documentation matching the built system. Without that, handover happens when the project team runs out of budget, which is not the same thing at all — and the support organisation inherits a system nobody has declared finished.