Benefits realisation: people first, projects second
Geert Barandat · updated 26 September 2026
Benefits realisation makes sure a change delivers the value it was started for. It does not begin with the project. It begins with the benefit, and with the people who have to make it real: what value do you want, what has to change for them, and which project actually helps.
Why the benefit disappears after go-live
Most organisations start with the project. There is an objective, a project is set up for it, and the benefit sits in the business case. That order looks logical. It gets stuck in four places.
After approval, the yardstick changes. The business case exists to win the budget. From then on, success means on time and on budget. The benefit becomes a document in a folder.
Delivery counts as success. Go-live is green, even if nobody works differently. Whether the benefit arrives, nobody measures, because the project is closed.
People only come in at the end. Change management becomes the phase where you sell a solution that was already designed. Resistance is expensive by then, because it has already been built.
Every gap becomes a project. If you think in projects, you solve everything with a project. Including what a different working agreement, a new role or some training would have solved.
The cycle, step by step
Starting from the benefit turns the order around. The project does not come first. It comes last, as a means.
- The benefit
- The change
- The intended way of working
- What is missing
- Project or intervention
- ↺ What you hearadjusts: the change · the intended way of working · what is missing · the project
1 · The benefit. What value do you want, and how will you see that it is there? A benefit without a starting point is a wish. You record where you stand today, and where that number comes from.
2 · The change. What has to be different for staff, teams and the organisation to make that benefit possible? In the usual route, this question is only asked at the end.
3 · The intended way of working. How does the organisation work then, in practice? Who does what, with which agreements, in which role? The people who carry the change help fill this in.
4 · What is missing. What can the organisation not do today that it will need to do then? That is the gap to close.
5 · The project, or a smaller intervention. Only now do you choose the means. Sometimes that is a project. Sometimes a working agreement, a role or some training is enough. You choose the smallest means that closes the gap.
6 · What you hear. During delivery you listen to the teams. What you hear can adjust the change, the intended way of working, what is missing and the project, while they run. Only the benefit stays put: it is the yardstick. The end is not go-live. It is the moment the benefit is there.
How this relates to MSP and the Benefits Dependency Network
Starting from the benefit is not new in itself. MSP draws a blueprint of the future organisation first, and only then the projects. Ward and Daniel's Benefits Dependency Network is built from the objective towards the means, with the changes as a separate link. This approach stands on their shoulders.
The difference lies in three things the classic methods leave open.
Who fills in the intended way of working, and when. In many programmes, the programme team draws the blueprint. Here, the people who carry the change help fill it in, before anything is built.
Feedback changes the project, not only the reporting. In the classic cycle you adjust between tranches. Here, what the teams say can reshape a project while it runs.
The assumption stays visible. Between an outcome and a benefit there is always an assumption. You do not calculate it away. You put what you expected next to what you see, and someone decides, with a name and a date.
What it asks of an organisation
This route is not harder, but it is more honest. It asks four things.
A benefit with a starting point. Without a baseline, every later measurement is an opinion.
The willingness to stop. If a project no longer contributes to the benefit, you adjust it or stop it. That is not failure. That is portfolio management.
Change at the start. The change manager is at work before the project starts, to help shape the change and the intended way of working.
A fixed rhythm to look back. Every quarter, or every wave of initiatives, the question: is the benefit coming, and does our assumption still hold?
In Cohentis, the benefit comes first
Click to enlarge
In the change portfolio you start with the benefit. The benefit map shows the chain to the initiative, and by default reads from the benefit: where you want to go, and what it takes. What a benefit costs, the disbenefit, sits in the same column. For each benefit you see the starting point, the target and the latest measurement, with the date and the plan that measurement came from.
You link a success criterion in a change plan to the benefit in the portfolio. What the change manager measures travels back to the benefit it was about. So at portfolio level you see whether the change lands, not only whether the project runs.
In your working agreements you record that there is a change manager before the project starts. The dashboard flags every initiative approved without one.
Common questions
What is benefits realisation?
Benefits realisation makes sure a change delivers the value it was started for. It starts from the benefit and chooses the project as a means, instead of the other way round.
What is the difference between an output, an outcome and a benefit?
An output is what a project delivers, for example a new system. An outcome is what happens differently because of it, for example teams doing their planning in that system. A benefit is the value that creates, for example less overtime.
What is a disbenefit?
A disbenefit is what a change costs or makes harder, for the people it touches. It belongs next to the benefit, so the trade-off stays visible.
When do you stop a project?
When it no longer contributes to the benefit it was started for, and adjusting it is not enough. That takes a benefit with a starting point and a fixed moment to look back.
How does this approach relate to MSP?
MSP also starts from the intended future state. This approach adds two things: the people who carry the change help fill in that state, and what the teams say adjusts the projects while they run.