The 5–10 year tail: funding the optimisation that realises the business case

Here is the uncomfortable arithmetic of an electronic patient record. You spend years and a great deal of money getting to go‑live. Go‑live arrives, everyone is exhausted and relieved, the ribbon is cut — and you have, at that point, realised almost none of the benefits you promised the board. The value doesn’t live at go‑live. It lives in the five to ten years afterwards. And that is precisely the period most organisations underfund, under‑govern, and quietly forget.

If you take one thing from this piece, make it this: go‑live is the midpoint of the value story, not the end of it. Treat it as the end and you will have bought a very expensive system that does roughly what the old one did, with a workforce that’s a bit more tired.

Why the benefits arrive late

Benefits from an EPR are not switched on with the system. They accrue as the organisation learns to use it well: as workflows are refined, as order sets are tuned to how clinicians actually practise, as reports become trustworthy enough to act on, as the documentation burden is engineered down rather than up. This is the optimisation tail, and it’s where the real money is — patient flow, clinical workforce productivity, safety.

The first year after go‑live is often negative on productivity. That’s normal. People are climbing a learning curve, the configuration is still rough, and the reporting layer is immature. The benefits case assumed a curve that starts flat and climbs steeply through years two, three and four. Which means the years you most need to invest in optimisation are exactly the years the programme budget has run out and the attention has moved on.

The optimisation tail is where the business case is either realised or quietly abandoned. Usually it’s abandoned by accident.

How the tail gets defunded

Nobody decides to abandon benefits realisation. It happens by a series of reasonable‑sounding local decisions.

The programme team demobilises — that was always the plan, and they’re expensive. The remaining budget is swept up to cover the overspend everyone politely didn’t mention. The optimisation work is handed to a business‑as‑usual IT function that is already underwater and has no mandate to redesign clinical workflow. The clinical leads who drove the build go back to their day jobs. And the benefits, which needed active cultivation, are left to happen on their own. They don’t.

Eighteen months later a finance director asks the reasonable question — did we get the benefits we paid for? — and discovers there’s no one who owns the answer, no instrument that tracks it, and a general sense that things are “bedding in”. The business case has become a document nobody is accountable to.

Building a tail you can actually fund

The fix isn’t heroic. It’s structural, and it has to be designed in before go‑live, because after go‑live the money and the will are gone.

Separate realisation from optimisation

These are two different jobs and conflating them is why both get done badly. Benefits realisation is a measurement and accountability discipline: naming each benefit, assigning an owner, baselining it, and tracking it against the case. Optimisation is a delivery discipline: the continuous redesign and reconfiguration work that actually moves the numbers. One measures; the other moves. You need both, and you need them to be different people with different mandates who talk to each other constantly.

Give every value line an owner with authority

A benefit that flatters a slide but belongs to no one is not a benefit; it’s a hope. Every material value line — reduced length of stay, documentation time returned to clinicians, medication safety — needs a named operational owner who can actually change how work is done, not a programme manager who can only report on it.

Stand up the forums that keep it honest

Realisation needs governance with teeth: a group that reviews each value line on a cadence, challenges the evidence, and has the standing to reprioritise the optimisation backlog toward the benefits that are lagging. Without it, optimisation drifts toward whatever is loudest rather than whatever is most valuable.

Fund it as a named line, ring‑fenced

The single most effective intervention is also the most political: put the optimisation tail in the business case as its own funded line, for its full duration, and ring‑fence it. If optimisation money can be swept to cover a go‑live overspend, it will be. Protect it in writing, at approval, when you still have the leverage.

The board conversation

This is fundamentally a board conversation, and it’s better had before approval than after disappointment. The line I’d put in front of any board is simple: the day we go live, we will have spent most of the money and realised almost none of the benefit. If we don’t fund the years that follow, we’re approving the cost without the return.

Boards understand that framing, because it’s the same logic as any capital investment with a payback period. The mistake is treating an EPR as a project that ends at go‑live rather than an asset that has to be actively managed to yield. Get that framing right at approval, and the optimisation tail stops being an afterthought that gets cut and becomes what it always was: the part of the programme where the value actually lives.