The benefit was never in the project

For most of my career, every business case that crossed my desk carried its five-year benefit numbers. Approval was the moment everyone celebrated. Whether anyone collected those benefits came years later, and by then the project team had usually moved on.

Early on, the focus was largely on delivering the project. Once it was finished, the team closed it and moved on. What happened to the benefits afterwards wasn’t routinely followed.

Portfolio management changed that. Looking across projects as a portfolio forced a different question: not just whether we had delivered what we approved, but whether the organisation ever received the benefits we had used to justify it.

We called that benefits harvesting. The discipline developed, and benefits realisation became the more usual term. By the time I was helping write our portfolio management standards, identifying, owning and tracking those benefits was required.

It was also the step most often skipped.

What I saw

The project closed, the team moved on, and nobody had been given the authority to make the change stick. On some cases, the name of the person meant to collect the benefits was left blank.

Some of the projects that went ahead with that name left blank, I was later brought in to rescue. By then, the people who made the promise had moved on, and there was no one left to own the gap between what was promised and what could actually be delivered.

What the project plan leaves out

A project can’t deliver the benefit on its own. It delivers a capability. Turning that capability into a benefit takes a change management plan, with business process improvement inside it, that changes how the work is actually done. That plan belongs inside the project plan, with its own activities and tasks in the project schedule.

The delivery work says what will be built and when. The change work says how people will work once it’s there. Leave the change work out of the schedule and the new system goes live while the old way of working carries on beside it.

What worked for us was identifying people in the business areas around the project early and mentoring them into those roles while the project was still running. When the key people eventually moved on, the knowledge had somewhere to stay.

Authority, and where it’s vested

A change plan needs authority behind it: someone who can retire the old process, change roles and hold people to the new way of working. The question that decides it is where that authority is vested.

The board and executive may approve the strategy and the investment, but benefits eventually have to be realised inside the business. That requires a named owner with enough authority to change how the work is done.

If that authority isn’t placed with someone who can actually use it, it drifts back to wherever people are comfortable, and the old way of working wins by default.

It hasn’t gone away

In July 2026, the Australian National Audit Office reported on DFAT’s program to strengthen security at Australia’s overseas missions. Its conclusion was that the expected benefits had been partly realised. There was no clear baseline to measure them against: metrics and targets had changed throughout the life of the program.

What caught my attention was the language. In its December 2023 program closure report, DFAT said that benefits would be “harvested long after the program’s closure”.

That was the term we used: benefits harvesting. And it describes the problem rather well. You can close the project, disband the team and declare the capability delivered. But if nobody remains with the authority to change how the organisation works, there may be nothing left to harvest.

A 2024 benefits realisation survey by Implement Consulting Group found 63% of the people surveyed said their organisations realised less than half of their total benefits potential. Only 13% reported assigning ownership of key benefits in every project.

Lee McCabe, who works in private equity and sits on boards, made the same point about AI recently: an exciting AI slide gets more applause than “a boring, delivered improvement”.

Before you approve the next case

If you’re the one reading a business case, ask two questions before you say yes.

Who will hold the authority to change how the work is done once this is delivered?

And whose name goes next to the benefits?

If you’re a founder, the same gap sits in your plan. It says what you’ll build. Ask what has to change in how you, or your customer, actually work before the benefit shows up.