Implementation debt: what happens after go-live
The go-live email goes out on a Friday afternoon, with thanks to everyone involved and a screenshot of the first live transaction. By the following Thursday, the operations team has a shared document called "post go-live issues" with forty rows in it, and most of the project team has been assigned to the next thing.
Few of those rows are defects. Most are items the project agreed, sensibly at the time, to handle manually for now or move to a later phase. Each one was a reasonable trade to protect the date. Together they are implementation debt: the distance between a system that is live and an operation that can run on it without extra effort.
Like financial debt, it charges interest. The interest is paid daily, in analyst hours, by people who were not in the room when the trade was made.
Where it comes from
Implementation projects get measured on date and scope, and when both come under pressure the usual release valve is to move work past go-live. The debt that results tends to fall into a few recognizable kinds.
Manual workarounds are the most visible. The automated settlement file from the new processor slipped, so an analyst downloads a report every morning, reformats it in Excel and uploads it to the reconciliation tool. That arrangement was meant to last two weeks.
Missing reports come next. The management pack or the partner report that was scheduled for phase two is now built by hand, often from the old system, which therefore cannot be switched off. A platform kept alive for one report still carries its license fee and still needs somebody who remembers how to run it.
Unowned configuration is harder to see. Fee tables, routing rules, limits and approval thresholds were set up by the implementation consultants during the build. Nobody in operations has changed one yet, nobody is certain who is allowed to, and the notes on how it was done sit in a folder belonging to a project that has closed.
Then there is training. The team was trained on test data four weeks before launch, when half the configuration was still moving. Anyone who joins afterwards learns by sitting next to someone, which means they pick up the workarounds along with the process.
Why it costs more than it looks
Take one illustrative item: forty-five minutes a day for one analyst to reformat and load a file. Over roughly 250 working days that is close to 190 hours a year, before you count the mornings the file gets loaded twice, and the time spent investigating the breaks that follow. On its own the number looks small, which is exactly why it survives review after review. A large implementation can leave a dozen of these behind, each belonging to a different person, so nobody ever adds them up.
The larger cost lands on the next project. New work gets designed on top of the current state, workarounds included. A manual step in reconciliation becomes an input the next team assumes will be there, and removing it two years later needs its own business case. The original business case, meanwhile, promised fewer manual touches and a decommissioned legacy system. If the debt stays, those benefits stay in the slide deck and never reach the cost base.
Every item moved to "after go-live" is a decision that the operations team will do that work by hand until somebody schedules the fix.
Keeping a register and paying it down
The shared document is a start, but it needs more discipline than a list of grievances. For each item, record the workaround in place, who performs it, how long it takes per week, what risk it carries, the proper fix and an owner who will still be there after the project team has gone. Risk is the column people skip, and it is the one that reorders the list: a step that skips an approval or leaves a single person holding a process matters more than one that merely costs time.
Then reserve capacity. If every release is fully booked with new features, the register only grows, so agree a fixed share of each release for debt items before the roadmap is set. Order them by hours per week and by risk. The file reformatting that one analyst does every morning usually goes near the top. Some items you will decide to live with, and that is a legitimate answer, as long as it is written down with a date to look again.
The cheapest place to deal with all of this is the go/no-go meeting, before anything goes live. Add operational criteria to the acceptance list: the reports the business needs run from the new system, every configurable table has a named owner in operations, the runbook exists and has been used at least once in a rehearsal, and each deferred item has an owner and a date. We set out what that handover should include in handing a project to the team that will run it.
A project can still go live with open items. Plenty should. The difference is whether the people approving it know how many hours a week they are signing the operations team up for, and until when.
Discuss your operations
