What Actually Breaks After the Project Team Leaves
The period right after go-live is usually treated as a wind-down. The implementation partner scales back support, the internal project team returns to their regular jobs, and the energy that carried the project through testing and cutover has nowhere left to go. That’s exactly when the system is most exposed, because the habits that made it work during the project, consistent data entry, escalating issues instead of working around them, using the modules as designed, were never anyone’s permanent job. They were the project team’s job, and the project is over.
Small workarounds start first. Someone finds a field confusing and leaves it blank. A manager reverts to a spreadsheet for one report because waiting on a proper one feels slower. None of these decisions get flagged, because there’s no project team left to flag them to, and no one’s actual job is to notice. A few months in, the workarounds aren’t exceptions anymore. They’re just how certain parts of the business run.
None of this shows up on a budget line, which is part of why it goes unaddressed for so long. There’s no invoice for a workaround, no change order for a module quietly falling out of use. The cost only becomes visible later, when someone tries to pull a number the system was supposed to produce automatically and finds three people doing it manually instead, each slightly differently.
Why the Same System Looks Fine at Go-Live and Broken a Year Later
The system itself hasn’t changed. What’s changed is how much of it still matches what was configured and tested at go-live. A module that worked fine in the first weeks can be sitting almost unused a year later, not because it failed, but because nobody owns making sure it’s still being used, and usage eroded without anyone deciding it should.
Training delivered once during the project doesn’t survive staff turnover. Someone leaves, their replacement gets shown the basics by a colleague who’s also improvising, and whatever nuance the original training covered doesn’t make it to the next person. A year or two later, the system is being operated by people who were never properly trained on it, running processes that have drifted from what was actually designed, and nobody flagged any single step as the moment things went wrong.
Reporting is usually where this becomes visible, eventually. Numbers stop reconciling the way they used to. Someone asks why two reports that should match don’t, and the answer traces back through months of small workarounds and undocumented changes, none of which looked like a decision at the time.
By this point, the fix usually looks bigger than it had to be. What would have taken a short conversation a year earlier, re-explain the field, re-train the one person, re-enable the report, now takes an actual investigation: pulling transaction history, interviewing whoever’s doing each workaround, reconstructing what the system was supposed to do before anyone decides what to do about it. The irony is that the business often ends up paying for something close to a second project, just to get back to where the first one left off.
What Keeps a System Working After Everyone Stops Paying Attention
The gap closes with ownership, not another project. Someone inside the business, not a vendor, not a consultant, needs to actually own the system after go-live: watching how it’s really being used, catching workarounds before they become permanent, and making sure new hires get trained properly instead of informally by whoever’s nearby.
Usage needs checking on a real schedule, not just when something breaks. Are the modules that were implemented actually being used the way they were designed? Is data still being entered consistently? Are the reports still reconciling? These are ordinary operational questions, not emergency ones, and they only get asked if someone’s job includes asking them.
This doesn’t need to be a full-time role in most SMEs. It needs to be a defined one, with a name attached and time set aside on a recurring basis, rather than something everyone assumes someone else is handling. The same person should also be the one deciding what counts as an acceptable exception and what needs to be escalated, so workarounds stop being invisible and start being decisions someone actually signed off on.
The vendor relationship matters too, but only if it continues past go-live instead of ending with it. A system that’s still supported is still being maintained, updated, and corrected as problems come up. One treated as finished the moment the invoice clears tends to decay at the same pace people stop paying attention to it.
None of this requires reopening the project or bringing back the implementation team. It requires someone deciding, deliberately, that go-live was the start of the system’s life, not the end of the project, and treating what comes after that way from the first week rather than the first year.
