During today’s PMChat, we discussed the importance of Project Benefits Management – why it matters, why we often get it wrong and what we can do to improve our project, programme and portfolio outcomes.
This is an evergreen topic and is always fun to revisit – we last discussed it in mid-2017. This post gives you a taste of the discussion, together with a list of the questions – I hope you enjoy it.
Why Benefits Management Matters
Benefits are the foundation reason for every project that we undertake. Without them, there is no reason for starting or continuing a project. The ongoing challenge is to make sure that project work is aligned to the company strategy – that there is a direct link between the company’s strategic objectives, planned benefits and enablers.
Strategic Objectives – What do we want to achieve?
Benefits – What will these objectives deliver? How will they benefit our business?
Enablers – What will we deliver to help realise those benefits?
But here’s the catch.
So often, organisations start out with a view of their strategic drivers and business needs, yet over time the outcome of change initiatives becomes separated from those business needs. The solution often doesn’t meet the original need, and the business does not get the expected return on investment.
When we break down “benefits”, we end up thinking about using the organisation’s resources more effectively to get the best possible return on investment. This generally means either maintaining or increasing profitability, maintaining or reducing operating costs, maintaining or reducing the amount of capital tied up in the business or providing a low cost, high value solution to an externally imposed constraint (i.e. legal or regulatory requirement).
A Benefits Map is a terrific tool in this regard, and can help show how strategic objectives are aligned to planned benefits and enablers. It helps us understand how the planned benefits will be apportioned and as such, sets benchmarks/expectations around what the projects and programmes will contribute. This is bread and butter for your Portfolio Office and is definitely worth keeping in your Project Management toolkit.
Who Owns the Benefits?
Should the person who owns the Business Case outcome also define the Project Benefits? This is a contentious question. On the chat, we threw around a couple of ideas.
The Benefit Owner should own the Business Case and be responsible for defining the strategic objectives and planned benefits for the company.
The Project Sponsor should respond to the Business Case and have a role to play in determining what benefits the Project will deliver.
Should the Benefit Owner and Project Sponsor be the same person? Yes and No. In smaller or less hierarchical organisations, these could be the same person. On the other hand, in larger, more complex organisation these may be different roles, separated by functional or geographical layers.
Regardless of the company structure, the Project Manager should then define how the benefits will be delivered.
The portfolio office has a key role to play here, in making sure that the programme and project outputs are aligned to the strategic objectives. No wasted work, all initiatives aligned to the objectives.
How Project Management Can Help
As Project Managers, we can add real value here.
Our role is to maintain the linkage between planned benefits and outcomes/delivery. We need to understand the business needs and drivers, and tie project outputs specifically to them. We need to tie every project output back to the Business Case, providing a direct link between deliverables and tangible benefits.
With that in mind, when we think about Benefits Management two big hurdles jump out at us:
Who is responsible for the benefit estimates?
Our challenge is to understand who owns the benefit estimates and also, who is responsible for delivering the business outcomes. Are they the same person or are they two different people? This is where the Project Sponsor has such an important role – he or she is the person who requires the stated benefits to meet a particular need, in pursuit of a strategic goal or objective.
How do we measure a project’s success when benefits are realised downstream?
When we think about project success, we inevitably think about timing and measurement of business benefits.
Will the benefits be realised during the lifespan of the project, or will additional time be needed post-Project closure? How do we measure project success in those situations?
It’s worth reminding ourselves that our projects do not produce benefits, but rather they produce deliverables that the business can then use to change the way it operates, and improve those cost/efficiency drivers.
Should project success be measured in terms of benefits realised, or on the basis of putting in place the framework from which the business can then drive benefits?
PMChat Questions
We opened up with two contextual questions, to help set the scene.
Q1. When defining successful Project/Programme delivery, do you include Benefits as a measure of success?
Q2. As a PM, how do you help shape a successful Benefits Management outcome? How do you add value?
We then talked about benefits ownership – who defines benefits, who is responsible for owning them, and should these be the same people/person?
Q3. In your experience, who is responsible for defining Project benefits?
Q4. Business Cases. In your organisation, does anyone read them? Do they live & breathe, or are they “set and forget”?
Q5. Benefits Ownership. Should the person who owns the Business Case outcome also define the Project Benefits?
Finally, we thought about the broader picture – how we can improve our benefits management practice.
Q6. Benefits are often realised later, after the Project has closed. How does this shape your PM approach to Benefits Management?
Q7. What do you see as the most urgent area we need to focus on to improve the way we manage Project Benefits?
You’re always welcome to join us on Twitter for a chat every Tuesday (1500 PT, 1800 ET, 2200 GMT) / Wednesday (0800 AEST, 1100 NZST) – just look for the #PMChat hashtag.