Why Benefits Leak After Go-Live — and How to Detect It Early

Go-live is a dangerous moment because it feels like success.

The system is live. The new process is published. The launch email has gone out. Hypercare has a rota. The steering committee relaxes a little. Someone says, “Well done, everyone,” and, in fairness, they probably mean it. A lot of hard work has happened.

But go-live is not the moment when benefits are realized.

It is the moment when benefits become vulnerable.

This is where many transformations lose value. Not because the business case was fake, necessarily, or because the project team was careless. Benefits leak because the organization confuses delivery with adoption, and adoption with value capture. The new capability exists, but people don’t use it fully. Or they use it inconsistently. Or they use it, but old behaviours, old KPIs, old workarounds, and old decision habits quietly remain in place.

McKinsey has argued that large transformations typically begin with ambition and energy but then lose, on average, 42% of expected value in the later phases, where execution and sustainment become the real problem. That should make every go-live celebration slightly more cautious.

• Benefits leak when the solution is delivered but the new way of working does not stick.
• Go-live is not benefit realization; it is the start of the most fragile adoption period.
• Early warning signs appear in usage, proficiency, workaround behaviour, data quality, support tickets, and manager reinforcement.
• The business must own benefits after project closure, not politely hand them back to the project team.
• The best time to detect benefit leakage is before it shows up in the financial report.

The basic mistake: treating go-live as the finish line

Projects are naturally built around delivery milestones. Design signed off. Testing completed. Training delivered. Cutover executed. Go-live achieved.

That rhythm is useful. Without it, large programmes would drift into fog.

But the business case was not approved because someone wanted a technically successful go-live. The business case promised something else: lower cost, faster cycle time, better data, higher productivity, lower risk, improved customer experience, reduced manual work, more reliable decisions, or some combination of these.

Those benefits usually require people to behave differently after the project has delivered.

This is why PMI’s benefits realization guidance is useful. It explicitly includes the need to sustain benefits after the project has ended and the work has transitioned into the business. In other words, benefits do not automatically belong to the project just because the project created the enabler. They must be carried into operations, tracked, owned, and protected.

That transition is where leakage starts.

What benefit leakage looks like in real life

Benefit leakage is rarely dramatic. It is usually small, cumulative, and annoyingly plausible.

An ERP system goes live, but planners still export data into Excel because the new report is not trusted.
A CRM process is launched, but sales managers still ask for pipeline updates in old meeting formats.
An AI assistant is made available, but employees use it privately, inconsistently, or not at all because governance is unclear.
A shared services model is implemented, but local teams keep duplicate shadow processes “just until things stabilize.”
A new approval workflow exists, but senior leaders continue to bypass it for urgent cases — and somehow every case becomes urgent.

Nothing explodes. The dashboards may even look acceptable for a while. But value is escaping.

Leakage is the gap between potential and captured value

BCG makes a useful distinction between gross value targets and net value actually reaching the bottom line after costs, delays, and leakage. That distinction sounds financial, but it is deeply behavioural. A transformation may identify large gross benefits; the real question is how much of that survives implementation friction and becomes measurable business value.

This is the unpleasant truth: many transformations create theoretical value.

Captured value is harder. It has to survive contact with operations.

Why benefits leak after go-live

There are several recurring causes. They overlap, of course. In actual programmes they usually arrive as a knot.

1. Adoption is shallow

People use the new system or process just enough to comply, but not enough to generate the benefit.

They log in. They complete the minimum fields. They attend the new meeting. They follow the new workflow when someone is watching.

But the deeper behaviour has not changed.

Prosci’s adoption model is helpful here because it separates three human factors that shape ROI: speed of adoption, ultimate utilization, and proficiency. It is not enough that people eventually touch the new process. The value depends on how quickly they adopt it, how many people adopt it, and how well they perform the new way of working.

This is why “users trained” is a weak benefit indicator. Training completion may show exposure. It does not prove speed, utilization, or proficiency.

2. Old workarounds remain alive

Workarounds are benefit leaks with familiar names.

Spreadsheet trackers. Local reports. Manual reconciliations. Informal approvals. Side-channel decisions. Personal databases. Shared inboxes nobody admits are still critical.

Some workarounds are temporary and useful during stabilization. Others are the old operating model refusing to die.

The problem is not the existence of a workaround on day five after go-live. That’s normal. The problem is when nobody tracks whether workarounds are declining. If the old way remains easier than the new way, the organization will keep paying for both.

3. Proficiency is lower than expected

A user may adopt the new tool and still use it badly.

This is common in ERP, CRM, procurement, finance, customer service, and AI-enabled workflows. People may enter transactions but create data errors. They may follow the process but misunderstand exceptions. They may use AI outputs but fail to validate them. They may use a new reporting dashboard but still make decisions based on old assumptions.

From the outside, adoption appears to be happening. From the inside, quality is weak.

That is a classic leakage zone: usage without proficiency.

4. Managers don’t reinforce the new behaviour

A project can launch a new way of working, but managers decide whether it becomes normal.

If a manager still asks for the old report, the old report survives. If a manager accepts manual workarounds without challenge, workarounds become semi-official. If a manager does not make time for practice, people will learn under stress and revert under pressure.

Manager reinforcement is one of the most underestimated post-go-live controls. Not because managers are magically powerful, but because they sit where work becomes routine.

5. Benefit ownership is vague

This is perhaps the biggest leak.

Before go-live, the benefit has many friends. It sits in the business case, steering deck, programme charter, sponsor speech. Everyone agrees it matters.

After go-live, the benefit needs an owner.

Who tracks it?
Who explains underperformance?
Who removes blockers?
Who decides whether adoption is good enough?
Who changes KPIs, roles, routines, or incentives if the benefit is not appearing?

If the answer is “the project team,” be careful. The project team may be leaving.

How to detect leakage early

The trick is to detect benefit leakage before the CFO asks why the business case has not materialized. By then, the evidence is late and usually political.

Early detection means watching the behaviours and operating signals that sit upstream of financial benefit. Those signals are the subject of the adoption risk resources: where adoption is weak, why it is weak, and what that does to expected value.

1. Track adoption by role, not only enterprise usage

Enterprise-level usage hides weak spots.

A system may show 85% active usage, but the people who matter most for the benefit may be underusing it. For example, if sales administrators use the CRM but account managers don’t update opportunities properly, the pipeline benefit leaks. If finance users post transactions but upstream teams don’t maintain data quality, reporting benefits leak.

Useful adoption questions:

• Which roles must adopt for the benefit to appear?
• Are those roles using the new process at the expected frequency?
• Are some teams adopting only because old channels are still available?
• Where is adoption slower than the benefit case assumed?

Do not average away the problem.

2. Measure proficiency, not just utilization

Utilization tells you whether people are using the change. Proficiency tells you whether they are using it well enough.

Useful proficiency indicators include:

• first-time-right transaction rate;
• data-quality defects;
• rework volume;
• exception rates;
• approval rejections;
• AI output correction rates;
• manager assessment of team confidence;
• time taken to complete core workflows.

A slightly awkward but useful question is: “Would we trust this process output enough to make a decision from it?”

If not, the benefit is still fragile.

3. Watch workaround persistence

Workarounds should be named, not whispered about.

Create a simple workaround register during hypercare and stabilization. Track:

• what workaround exists;
• which team uses it;
• why it exists;
• whether it is temporary or structural;
• what benefit it threatens;
• who owns removal;
• target closure date.

This sounds a little bureaucratic. But without it, workarounds become folklore. Everyone knows they exist, nobody owns their removal, and six months later the “new process” is merely an additional layer on top of the old one.

4. Read support tickets as adoption intelligence

Support tickets are not just technical noise. They are early evidence of adoption quality.

Look for patterns:

• Are tickets concentrated in specific roles or locations?
• Are users asking basic “how do I?” questions after training?
• Are errors caused by poor process understanding or poor system design?
• Are the same issues recurring?
• Are tickets declining, or just being replaced by informal help channels?

A high ticket volume may be a healthy sign immediately after go-live. Silence can be dangerous too. Sometimes people stop asking for help because they have found a workaround.

5. Check whether managers have changed their routines

This is often the missing diagnostic.

Ask managers:

• Are you using the new reports in team meetings?
• Are you asking for decisions through the new workflow?
• Are you challenging old behaviour?
• Are you giving people time to practise?
• Are you escalating blockers, or absorbing them locally?

If management routines remain old, the benefit will struggle. The process may be live, but the operating system of the team has not changed.

6. Compare benefit assumptions with real adoption speed

Many business cases quietly assume fast and full adoption. Few say it openly.

After go-live, compare the original benefit assumptions with actual adoption data:

• Did the business case assume 100% utilization?
• By when?
• At what proficiency level?
• What happens financially if adoption is 60% for the first three months?
• Which benefits are delayed, reduced, or lost?

This is where value leakage becomes visible before it becomes a surprise.

The early warning dashboard

A useful post-go-live benefit dashboard should not be a giant spreadsheet that nobody reads. It should show a short chain from adoption to value.

For each major benefit, track:

• Benefit: what value is expected?
• Owner: who owns it after go-live?
• Adoption dependency: what behaviour must change?
• Leading indicators: usage, proficiency, workaround reduction, quality.
• Lagging indicators: cost, cycle time, revenue, risk, customer outcome.
• Leakage signal: where value is being lost or delayed.
• Action: what must be fixed, by whom, and by when?

The useful dashboard does not merely report red, amber, green. It explains why value is at risk.

A simple example

Suppose an ERP implementation promised faster month-end close.

The business benefit is not “ERP live.”
The benefit is “close cycle reduced from eight days to five days.”

Possible leakage signals:

• finance users trained, but still rely on manual reconciliations;
• upstream data entered late or incorrectly;
• managers still request old Excel-based reports;
• support tickets cluster around intercompany postings;
• close timetable unchanged because decision rights were not redesigned;
• the old report pack survives “temporarily.”

In this case, the system may be live, but the benefit is leaking through data quality, old routines, and incomplete process adoption. Another training email will not fix that. The business needs targeted action: clean upstream ownership, remove duplicate reporting, reinforce new close routines, and track first-time-right transactions.

Why this matters for AI programmes too

AI benefits leak even faster because adoption is often informal and uneven.

A company may deploy an AI assistant and expect productivity gains. But if employees use it mainly for low-value drafting, avoid it for core workflows, mistrust outputs, or use unapproved tools privately, the expected benefit becomes hard to capture.

For AI, leakage signals include:

• high licence activation but low repeat use;
• usage concentrated in generic tasks rather than business-critical workflows;
• no measurable reduction in cycle time or rework;
• managers unable to explain approved use cases;
• outputs not trusted enough to influence decisions;
• employees hiding AI use because norms are unclear.

AI value does not come from access. It comes from changed work design, trusted usage, and disciplined judgement.

The business must own the benefit after go-live

There is a handover problem in many transformations. The project delivers the capability, then closes. The business inherits the result, but not always the measurement discipline.

That creates drift.

A better handover should include:

• named benefit owners;
• baseline and target metrics;
• adoption assumptions;
• leading indicators to watch;
• known leakage risks;
• workaround removal plan;
• manager reinforcement actions;
• review cadence after project closure.

The phrase “business as usual” is a little misleading here. After a serious transformation, business as usual should not be usual. That’s the point.

How to stop leakage before it becomes normal

Once leakage becomes part of daily operations, it hardens. Workarounds become accepted. Low proficiency becomes “how we do it here.” Benefits are quietly revised downward. The business case is forgotten.

Early action matters.

Practical actions include:

• keeping benefit reviews active for at least one or two performance cycles after go-live;
• running adoption clinics based on real support-ticket patterns;
• closing old channels deliberately, not just hoping people stop using them;
• making managers accountable for reinforcement;
• tracking workaround reduction as a benefit-protection metric;
• comparing actual adoption speed with business-case assumptions;
• assigning operational owners to each benefit, not generic programme owners.

None of this is glamorous. It is exactly the kind of post-go-live discipline organizations skip when they are already tired and eager to move on.

Which is, of course, why benefits leak.

The sharper question after go-live

After go-live, the wrong question is: “Did the project deliver?”

The better question is: “Is the organization capturing the value we said this change would create?”

That question forces a different conversation. It connects adoption to performance. It makes workarounds visible. It exposes weak proficiency. It asks whether managers have changed routines. It keeps benefits alive after the project team starts packing up.

Go-live is worth celebrating. People worked hard. The launch matters.

But it is not the finish line.

It is the point where the business case starts telling the truth.

Benefit leakage is one symptom of a wider pattern. Explore the adoption risk resources to see how usage, proficiency, workarounds and manager reinforcement are tracked before they turn into lost value.