The Handoff Nobody Budgeted For
You signed off on the business case. The project team delivered on time. Go-live happened, the vendor did a lap of honour, and everyone moved on to the next priority. Eighteen months later, you find out the rostering system nobody complained about is being quietly worked around by three teams using spreadsheets, because the system fell behind what your organisation actually needed and nobody’s job was to notice.
This is not a story about a bad system. It’s a story about what happens after a good one goes live, and it happens more often than any board paper admits.
Once the project ends, four things have to keep happening for that system to keep delivering what you paid for — and in most organisations, no single person is accountable for all four at once.
Access has to stay current. Someone leaves finance and moves to operations. If nobody updates their system permissions, they’re either locked out of what they now need, or — worse — still able to approve payments in a role they left six months ago. Auditors find this one every time.
The data has to stay clean. A ratepayer’s address gets updated in one system but not the other. A supplier record gets duplicated. Six months of this and staff stop trusting the reports, so they build their own version in Excel — and now you’re paying for a system that’s being quietly ignored.
The software has to stay patched and current. This one is invisible until it isn’t. Nobody in the organisation notices a missed update. Then there’s a security incident, or the vendor tells you the version you’re on is no longer supported, and suddenly a routine maintenance task is a crisis project.
People have to keep being trained. The system you rolled out with a full training program eighteen months ago now has three new starters who learned it from a colleague, badly, in twenty minutes. They’re using ten percent of what the system can do, and they’ve never been told the other ninety percent exists.
Each of these, on its own, looks manageable. IT patches the software. HR runs onboarding, eventually. Someone in operations notices data errors when they trip over them. The problem is that no one is holding all four at the same time, on a cycle, as one job. They’re four separate people doing four separate things, none of whom would recognise that they’re jointly responsible for whether your investment is still paying off.
Where it usually lands, and why that’s not enough
Most organisations park this with Service Delivery — the help desk, the support function. And Service Delivery does its job: password resets, “the system is running slow,” “how do I run this report.” What it almost never does is sit down with the person who owns the product and ask a harder question: is this system still doing what we need it to do, for the organisation we are today?
That conversation — Service Delivery and the Product Owner, in the same room, on a standing cycle, looking at access, data, software currency, and training together — is the difference between a system that ages well and one that quietly gets replaced by workarounds. It’s a short meeting. It rarely happens.
You approved the investment once. Nobody re-approves the return on it every quarter — because nobody’s role is to ask whether it’s still there.
So the question worth taking back to your executive team isn’t whether you have a support desk. You do. It’s: who, by name, is accountable for noticing when your system starts drifting away from what your organisation actually needs.
