Benefits realization: from delivery to real value
The project delivered on time, the system went live and the team celebrated. A year later, someone in senior management asks: did things actually get better? And nobody knows. That is exactly the problem researchers John Ward and Elizabeth Daniel at Cranfield School of Management tackled in their 2006 book Benefits Management.
Their message is uncomfortable but liberating: the benefits of a project do not arise at delivery. They arise in the business, afterwards, and only if someone owns them and actively works to make them happen. The approach they describe is often called benefits realization, and it has become a natural part of modern project and portfolio governance.
What does the research say?
Ward and Daniel built their book on many years of research into investments in information systems and IT. A recurring pattern was that organizations claimed benefits in the business case — more efficient processes, happier customers, lower costs — but never followed up on whether they actually materialized. The benefits were assumed to appear automatically once the technology was in place. They rarely do.
Their explanation: technology and project deliverables create no value in themselves. Value only arises when people in the business change the way they work. That is why benefits must be identified early, linked to concrete changes in the business and, above all, given owners — people in the business, not in the project, who are responsible for making sure the benefits are actually captured. Ward and Daniel describe a complete working process for this, with a benefits realization plan and follow-up that continues after the project has closed.
An important consequence is that project goals and benefit goals must be kept apart. The project is responsible for delivering an output — a system, a process, a product — within its constraints. The benefit, the measurable improvement in the business, is owned by the client or sponsor and is realized long after handover. If the two are mixed up, no one can be held accountable for either — the project gets blamed for missing benefits it cannot control, and the business escapes its responsibility for the change.
What does this mean for you as a project manager?
Separate project goals from benefit goals in every document. State explicitly: this is what the project delivers, this is the benefit that should arise afterwards, and it is owned by the sponsor. That protects both you and the benefit — you are judged against the right thing, and the benefit gets an owner.
Demand an owner for every benefit. If no one in the business is willing to put their name next to a promised benefit, that is a warning sign: either the benefit is not credible, or no one will drive it home. Raise it with your sponsor before the project gets seriously under way — it is far easier to sort out ownership then than when delivery is approaching.
Use the business benefits as a compass along the way. When change requests and cutbacks are being discussed, go back to the benefits: which of the promised effects is strengthened or threatened by this decision? It raises the quality of the decisions and of your conversations with the steering group.
How to practice this
The hardest part of benefits realization is often the conversation with the sponsor: handing responsibility for the benefit back to where it belongs, kindly but firmly, without damaging the relationship or the trust along the way. In Project-simulator you practice sponsor and steering group conversations against AI counterparts and get feedback grounded in your own words. You can try it free for a week.
In Project-simulator you practice these conversations against an AI counterpart and get feedback grounded in research like this.
Try free for 7 days