The Meeting Nobody Schedules — Why Post-Implementation Benefits Reviews Never Happen
Delivery has an owner. Operations has an owner. The benefit — which lives in the seam between them — has no one.
The Review That Everyone Agrees With and Nobody Holds
There is a meeting written into almost every business case I have read. It sits near the back, after the cost tables and the risk log, described in confident language: a post-implementation review, held some months after go-live, at which the organisation will confirm that the benefits promised at approval have actually arrived. Everyone signs up to it. Nobody argues against it. And in my experience, it is the single most reliably cancelled meeting in the entire lifecycle of a change programme.
The pattern is so consistent that it has stopped surprising me. The project reaches go-live. There is a sense of relief, sometimes a celebration. The delivery team, which has often been assembled from contractors and secondees, begins to disperse within weeks. The sponsor, whose visible accountability ran to implementation, turns to the next priority. The programme office closes its accounts, files its lessons-learned document, and moves the initiative from the “live” column to the “complete” column. And the benefits review — the moment when someone was supposed to ask whether any of this was worth it — quietly falls off the calendar.
We treat go-live as the finish line. It is closer to the starting line. The benefits a business case promises almost never exist on the day the system goes in — they accrue, if they accrue at all, in the months and years afterward, precisely when the organisation has stopped paying attention.
Why the Diary Stays Empty
It would be comforting to put this down to carelessness, because carelessness is fixable with a reminder. But the honest account is that the review does not happen for reasons that are structural, and structural problems do not yield to good intentions.
- The people who would run it have gone. The delivery team is optimised for delivery. Once the thing is delivered, the team is, by design, dismantled. The knowledge of what was promised and why leaves the building with them.
- The sponsor’s incentive expired at go-live. Sponsors are rewarded, formally and informally, for shipping. I have rarely seen a sponsor’s standing rise or fall on whether the benefits materialised eighteen months later. By then they are being judged on something else.
- The baseline was never captured in a usable form. You cannot measure improvement against a “before” that nobody wrote down. Time and again the original figures turn out to have been estimates produced to clear the approval hurdle, not measurements taken to enable comparison.
- Nobody owns the number once the project closes. Delivery has an owner. Operations has an owner. The benefit — which lives in the seam between them — has no one. It is everybody’s success and therefore nobody’s responsibility.
Put these together and the cancelled meeting stops looking like an oversight. It looks like the entirely predictable output of the way we organise change.
We Fund Delivery, Not Realisation
Underneath all of this sits a single uncomfortable truth: our funding and governance machinery is built to deliver capabilities, not to realise benefits. We release money against milestones, and the last milestone is almost always implementation. We convene boards to scrutinise spend and schedule, and we stand those boards down when the spend stops. The entire apparatus of control is pointed at the phase that ends at go-live.
The benefit, though, belongs to the phase that begins at go-live. A new system does not save money because it has been installed; it saves money when people work differently, when roles are redesigned, when the old process is switched off and the headcount or the error rate or the cycle time actually falls. That is operational, cultural, and slow. It happens long after the governance that authorised it has dissolved. We have, in effect, designed a process that stops watching at exactly the moment the thing we care about is supposed to start happening.
What the Textbooks Get Right, and What They Leave Out
The literature is not silent on this. The better methodologies insist on named benefit owners drawn from the operational side of the house, on benefit profiles with baselines and measurement dates, on a realisation plan that outlives the delivery plan. This is all correct, and I would not remove a word of it.
What the textbooks leave out is that every one of these mechanisms is asking people to do work whose payoff lands after their own accountability has ended. That is not a documentation problem. It is a problem of incentives, and no template solves it. You can mandate a benefits review in the governance framework and still watch it not happen, because the framework has no purchase on anyone once the project is closed. The gap between the prescription and the practice is not laziness on the practitioner’s part — it is the entirely rational behaviour of people responding to the incentives actually in front of them.
What I Have Seen Work
I am wary of offering a framework here, because the whole point of this argument is that frameworks are not the binding constraint. But there are a handful of moves that, in my observation, shift the odds.
- Give the benefit an owner who is still there afterwards. The most reliable predictor of whether a review happens is whether a named operational manager — not the project — carries the benefit in their own objectives, with a measurement date that falls on their watch. Ownership has to survive the closure of the project. If it does not, nothing else matters.
- Hold the closure hostage to the baseline. Do not let a project formally close until the “before” numbers are captured and lodged somewhere durable. A review with no baseline is theatre; the time to prevent that is at the start, and the leverage to enforce it is the closure sign-off.
- Book the review before you need it, and fund it. Put the review date in the operational calendar, not the project plan, and attach a small budget to it. An unfunded, unscheduled intention does not survive contact with a busy year. A funded, dated commitment sometimes does.
- Separate the accountability for realisation from the accountability for delivery. As long as the same person is judged on both, delivery wins — it is nearer, more visible, and more career-defining. Splitting the two is uncomfortable, but it is the only way the benefit gets an advocate who is not already exhausted by go-live.
None of these are elegant. They are, essentially, ways of arranging for someone to still care once the applause has died down.
The Meeting Is a Symptom
If I am honest, the cancelled review is not really the problem. It is the symptom of an organisation that has confused installing a capability with improving. We are very good at the former and strangely incurious about the latter, and the incuriosity is comfortable precisely because it protects everyone from finding out whether the promises were true.
The organisations that realise their benefits are not the ones with the best review template; they are the ones willing to still be in the room, asking an awkward question, long after everyone else has decided the project was a success. The meeting nobody schedules is worth scheduling — not because the ritual matters, but because the question it forces is the only one that separates the organisations that change from the ones that merely spend. It is an uncomfortable question, held by someone who would rather not hold it, about whether any of it was worth doing. That discomfort is the point. An organisation unwilling to sit with it will keep funding delivery, keep declaring victory at go-live, and keep wondering, quietly, why the savings never quite show up in the numbers.