Go-live gets celebrated as the finish line – it's only half the job

A new business system was delivered on time, correctly configured, with zero downtime. Champagne on Friday, back to business as usual on Monday. We've seen the same pattern play out at a public transport operator that had just taken over a vehicle maintenance system: the technical delivery was done, but nobody owned what came next. Four months later we were still working to make sure the organisation actually used the system as intended – not because the technology was broken, but because no one was accountable for it.

It's the most common misconception in IT and AI projects: go-live gets treated as the finish line instead of the starting line. Once the technology works, everyone assumes the rest will sort itself out.

Why focus disappears exactly when it's needed most

Project budgets and project teams are sized to deliver a solution – not to manage a change in behaviour. Once the system is configured, tested and live, the project organisation gets wound down, often in the same week as launch. What's left is the line organisation, holding a new tool and the same old habits, with no one left holding the mandate – or the time – to keep pushing the change through.

Without someone actively owning the question "is this actually being used correctly?", the organisation falls back on what's familiar: workaround spreadsheets, informal shortcuts, questions that bounce between vendor, IT and line managers without ever landing anywhere. The system is there, but the business value isn't – not because the technology is wrong, but because no one carried the change forward once the technical delivery was signed off. That gap is exactly why so many AI and system investments never show up on the bottom line.

What actually makes a system change stick

In the case above, we solved it by explicitly extending ownership past go-live, rather than handing over and moving on. Every task within the system was documented as a process – not as a technical manual, but as a way of working communicated to the business until it became habit and routine. Without that communication, a system change stays an IT project instead of becoming part of how the work actually gets done.

We also took on the role of the business's single point of contact for everything related to the system, rather than letting questions scatter between vendor, IT and line managers with no clear owner. That made it possible to prioritise further development based on what the business actually ran into day to day – not on whatever was easiest to build next.

The third, and arguably most important, piece was an established communication plan between the business, the operations team and the development project, running through every phase, with weekly check-ins and reporting to the leadership team. That kept actual usage as visible as budget and timeline already were – instead of being the thing nobody asked about until the ROI failed to appear.

The payoff of owning the time after launch

After four months, the system wasn't just technically implemented – it was embedded: documented and communicated processes, a clear communication plan, and a business that knew exactly who to turn to with questions. That's the difference between an IT or AI investment that shows up in the results, and one that only shows up in an operating budget nobody remembers the reason for.

Practical takeaway: Don't spend the entire project budget getting to go-live. Set aside explicit time, mandate and a named point of contact for the first months after launch – because that's exactly when the change is at risk of never happening, long after everyone else has already moved on.