A strange thing happens to many business cases the moment they’re approved. Before approval, benefits are scrutinised from every angle; finance questions the assumptions, leadership challenges the scale, and delivery teams debate feasibility. Everyone with skin in the game understandably wants confidence that the investment will generate the value it promises.
But after approval, things often become eerily silent; the investment moves into delivery mode, with milestones (not value) becoming the be-all and end-all, and those benefits that did so much to justify the investment quietly fade into the background.
Then months, sometimes years, later, when someone asks whether the investment actually delivered the expected value, the answer is often unclear. And that’s not necessarily because the benefits were unrealistic, but because no one ever truly owned them.
The moment accountability should increase
Both in theory and just using common sense, approval should be the point where benefit ownership becomes clearer, not weaker. Once an organisation commits funding, the real challenge begins, as delivering the project is only part of the story. The real objective should be delivering the outcomes that justified the investment in the first place.
Yet bafflingly, you actually find that in many organisations, accountability becomes less defined at this stage. The culprit is the fact that responsibilities are clearly assigned for delivery; PMs own milestones, product teams own features, finance tracks budget and spend etc. But when it comes to the benefits themselves, ownership often dissolves into something much more vague.
Benefits become “expected outcomes” rather than assigned responsibilities, and as we all know, when something is technically everyone's responsibility, it almost always actually ends up as no one's responsibility.
How benefits quietly disappear after approval
Benefit ownership rarely disappears suddenly though; rather, it fades gradually as the project moves through its lifecycle.
At the beginning, you usually find that the business case clearly links the investment to outcomes, with revenue growth, cost reduction, risk mitigation, or operational improvements all being diligently defined.
But once delivery begins, attention shifts, and the organisation starts tracking different things, such as milestones, timelines, budget variance, and scope changes. Now, don’t get me wrong, all of these are important in their various ways, but the key thing to realise is that they're delivery metrics, not value metrics.
What this means is that by the time the project finishes, success is often judged on whether it was delivered:
⌚ on time
💸 on budget
📏 with the agreed scope
and at that point, the team disbands, stakeholders merrily move on to the next initiative, and the organisation just assumes that the big tick alongside each of their delivery goals means that the promised benefits will naturally follow.
Sometimes they actually do, it’s just that often they don't. And when the inevitable question eventually arises (“did this investment deliver the ROI we expected?”), the answer is usually vague, anecdotal, or impossible to measure.
The organisational gray zone
Part of the challenge is structural, as benefits rarely sit neatly inside one function, and often depend on multiple teams changing behaviour after the project is delivered.
👉 e.g.
A CRM implementation may depend on sales teams adopting new processes
A data platform may require analysts across multiple departments to change how they work
An automation initiative might rely on operational teams redesigning workflows
In other words, the benefits are realised through behaviour change, not just system delivery, and this creates a grey zone:
🚚 The project team finishes delivery
🔄 The operational teams return to business as usual
📈 Leadership moves on to the next investment decision
And somewhere between those transitions, benefit ownership quietly disappears. No one disputes that the benefits are important; it’s just that no single team feels fully responsible for delivering them.
The incentive problem
There is another (less visible) reason this problem persists, and that’s that owning benefits introduces risk, because if someone is formally responsible for delivering the outcomes of an investment, they can also be held accountable if those outcomes fail to materialise.
Ostensibly, that sounds like a positive thing (accountability fostering ownership etc), but in reality, many roles inside orgs just aren’t designed around that kind of accountability. On the whole:
📦 Project managers are incentivised to deliver successfully
💰 Product teams are incentivised to ship valuable features
⚖️ Operational leaders are incentivised to run stable, efficient processes
but benefits often require cross-functional change, and the incentives for driving that change are rarely aligned. In fact, from an incentive perspective, it’s much safer to own delivery than to own outcomes, because delivery can be controlled, whereas outcomes depend on adoption, behaviour, and external factors.
It’s perhaps not particularly surprising that organisations therefore naturally drift toward measuring what’s easier to manage, which means that our all-important benefits quietly fall into the gap.
When delivery becomes the finish line
These structural and incentive challenges mean that many organisations end up treating delivery as the finish line, i.e. once the project is complete, the organisation declares success, there's probably a lovely shout out in the next Town Hall, and everyone moves on.
But benefits rarely appear at that exact moment; they often emerge months later, after the much less glamorous activities of adoption, training, workflow changes, and operational adjustments have taken place.
👉 e.g.
A new platform may need time before teams trust it
An automation initiative may require process redesign before efficiency gains appear
A data capability might take months before insights actually translate into better decisions
What you find is that if no one owns that post-delivery period, the organisation loses visibility into whether the expected value ever materialised.
Why organisations tolerate this gap
We’ve now seen how and why this is a problem, so why do orgs put up with it rather than just fixing it? The uncomfortable answer is that for many organisations, it’s just convenient.
Clear benefit ownership introduces a level of accountability that organisations aren’t always prepared to manage, as when benefits have explicit owners, it becomes impossible to avoid difficult questions, such as:
Why didn’t this investment deliver the expected return?
What changed between approval and delivery?
Were the assumptions in the business case realistic?
Should we have funded this project at all?
Without clear ownership, those questions become much harder to answer, and the org can assume that benefits were “partially realised” or “difficult to measure”.
Ambiguity, therefore, protects everyone involved, but it also prevents the organisation from learning anything meaningful about its investment decisions.
The learning that never happens
When benefits aren’t owned, chances are they also won’t be measured properly, and when they aren’t measured, organisations can’t learn from them.
That means that every subsequent business case is then unnecessarily built using the same (potentially flawed) assumptions, projections, and (misplaced) optimism as the last one.
Over time, this creates a cycle of corporate amnesia, where organisations repeatedly make investment decisions without fully understanding the outcomes of the previous ones.
It’s not because they lack intelligence, just because a feedback loop that was very much available to them was never closed. Without that feedback loop, ROI forecasts remain theoretical rather than evidence-based (or put more cynically, based on hope rather than any sort of reality), and each additional business case slowly drifts further into the realms of fantasy.
What real benefit ownership looks like
Now, the last thing I’m going to suggest to fix this problem is a complicated governance framework, as something simpler and more deliberate is much more my style: Benefits just need owners in the same way budgets do. That's it. What this effectively means is three practical changes:
🏷️ A named owner for each major benefit: someone who is accountable for whether the outcome actually materialises, not just whether the project is delivered.
📊 Measurements that continue after delivery: benefits should be tracked for as long as it takes for the expected value to emerge, even if that extends beyond the formal project timeline (think pragmatism over textbook).
🔁 Feedback into future investment decisions: the results should inform how future business cases are built, reviewed, and approved.
None of these ideas are particularly radical, but they are still surprisingly rare.
In Summary: Approval should be the beginning, not the end
Business cases exist to justify investment decisions, but the real test of a business case happens after approval, not before it, as that's when assumptions meet reality, adoption challenges appear, and benefits either materialise or quietly disappear.
If no one owns that moment, the organisation loses the opportunity to understand whether the investment truly worked, and if that learning never happens, the next business case will always start from guesswork instead of evidence.
In that sense, the problem isn’t just about benefit ownership, it’s about whether organisations treat ROI as something to predict, or something to prove.
