Who owns a benefit after the project has gone?

When the named lead is not enough

Ask a room of project professionals who owns a benefit and the answer will usually be quick and confident: the sponsor. That is the right starting point. Benefits often mature after transition into use, so accountability cannot sit only with the project team. Yet that answer can be too tidy. It suggests that once a name is in a benefit profile, the problem has been solved.

Benefits rarely travel in a straight line. They pass through projects, programmes, portfolios, operational teams, finance processes, data systems, users and customers. They depend on adoption, behaviour change and sustained use. By the time a benefit appears, the original project may have closed and the receiving business may face pressures that were not visible when the case was approved.

This is why benefits can disappoint without an obvious delivery failure. The product may have gone live, the milestone may have been met and the reporting may look healthy. The problem appears later, when delivery teams believe the job is done and operational teams are asking what, exactly, they are now expected to own.

That is uncomfortable for the project profession because benefits management is where delivery claims meet organisational reality. If the benefit cannot be held through that reality, the business case promise starts to weaken.

RACI still earns its place. Used well, it clarifies who is responsible, accountable, consulted and informed. For tasks, approvals and deliverables, that clarity matters. The difficulty is that a benefit is not a task. It is a change in performance, capability, experience or value that emerges when an output is used well and long enough.

Benefits rarely sit with one person. A project may enable a capability, a programme may reshape the operating model, a portfolio may prioritise the investment and business-as-usual may have to realise the value. Each area touches the benefit, but none holds the whole journey alone.

Benefits depend on behaviour as much as delivery. Outputs create the conditions for benefit. People, processes and operating choices convert those conditions into value. RACI can show who is accountable for a deliverable, but it cannot, on its own, maintain adoption, remove organisational friction or preserve intent after transition.

Where responsibility starts to fray

The sponsor gap: Sponsors are rightly central to benefits realisation, but they often carry several priorities and may move role before longer-term benefits mature. A name on a profile is not enough if no one is testing whether the benefit remains realistic, risks have changed or escalation is needed.

The operations gap: Operational teams may inherit an output without inheriting the original strategic intent. Unless benefits are built into service measures, performance routines or business planning, they can quietly drop below the waterline.

The portfolio gap: Portfolio teams can approve investment on the basis of expected value, but they may not control the operational choices, resourcing or data needed to make that value appear.

In practice, this is less about naming a lead and more about keeping someone close enough to the benefit to notice when it starts to slip. The real distinction is between a name in the document and someone still paying attention as the benefit moves away from the project and into use. A steward does not have to do everything personally. They do need to know who is doing what, which assumptions are starting to weaken and when the organisation needs to intervene rather than simply explain a missed benefit after the fact.

What helps in practice

Map responsibility across the benefit lifecycle, not just at approval. At each handover, be clear about what is transferred, what evidence is available and who has the authority to act if the benefit starts to drift. For significant benefits, make stewardship explicit. This need not mean a new job title. It can sit within portfolio, programme or business change governance, provided someone is expected to spot when responsibility is becoming blurred.

Boards should ask whether the project is on time, on budget and within scope. They should also test whether the organisation is set up to realise the benefit that justified the investment. A benefit that lives only in a business case or benefits register is vulnerable. It needs to appear in operational measures, management reporting, service objectives or strategic KPIs.

Benefits assurance should test whether the measurement route is credible, dependencies are live, the receiving business is engaged and someone can still influence the outcome. The question is not only whether it can be measured, but whether anyone can still make it happen.

Project professionals are increasingly expected to demonstrate value, not just delivery. That is fair, but it exposes a recurring weakness: we can be diligent about writing benefits into cases, profiles and registers, while being less disciplined about keeping them active when the work moves into use.

Keep RACI in the toolkit, but use it for what it does well. It can clarify responsibility at a point in time. It cannot, by itself, keep a benefit alive as the work moves from delivery into use.

The next time a benefits profile lists a single accountable person, we should ask one more question: who will still be holding this benefit when the project has gone?

Partly AI supported; human-validated