The fundamental reason any program exists is to bring about benefits. All programs produce outcomes. An outcome might be that we do things differently, or that we do different things. But an outcome alone is not necessarily a benefit – perhaps we now do things in a worse way than before, for example.
Because the raison d’être of all programs is to bring about benefits, every program without exception should begin with the definition of the benefits it is expected to produce.
Each program, through its projects, produces some form of deliverables. These deliverables combined might be a new system, and new consumer device such as an X-box, or even a new way of working, such as changing a large organisation to Lean methodologies. What all of these deliverables have in common is that they are all used in some way – the X-Box is used by the consumer; the new system is used and operated within the existing organisation.
It is through use of these deliverables described above that the potential for a benefit to be realised is achieved. If an organization can extract these benefits, it can reap the reward and enjoy the benefits. The Benefits Management Process exists to ensure an organization is very clear about the benefits it is seeking from its investment. Benefits Management essentially links and coordinates the use of any new processes and technology to maximize the value of the benefits delivered to the business.
Because benefits are so important (they are the reason the program exists), there is a very strong case that the program manager shouldn’t be responsible for benefits management. Mid program execution, the program manager is like a cyclist in the Tour de France trying to get to the top of Alpe d’Huez – they are head down just trying to reach the finish line. Their mind is simply not focused on the ongoing viability of their program. Because of this, it is often advisable to have an individual Benefits Manager within the program be specifically responsible for the realisation and extraction of benefits from the program. Additionally, some benefits will be realised after the program is perceived to have finished, and the Benefits Manager role can outlive the program to continue tracking the realisation of these benefits after the program has disbanded.
Typically there is a many-to-many relationship between the deliverables of each individual project and benefits. For example, the culmination of a number of projects may result in the realisation of a single benefit, or a single project deliverable may contribute to a number of benefits.
Sometimes not all the deliverables will result in a change for the better. There will often be some dis-benefits (negative benefits) resulting from the program. These dis-benefits need to be tracked and measured in the same way as (positive) benefits. Steps should be undertaken during program execution to ensure that these dis-benefits minimise their impact on the (positive) benefits of the program.
So, how to you start measuring your benefits? The Business Case is the starting point for benefits management, as it provides a snapshot of the anticipated benefits at any point in time.
To conclude, the only reason any program exists is to provide some form of benefit to the organization investing the it. Benefits Management exists to ensure the value of these benefits realised is maximized.
Program Management: Understanding Effort and Influence
Customer Journey Programmes in Financial Services
Lean Startup and Program Management
Program Manager Job Description
The Importance of a Plan
What is Program Management?
Scenario Planning and Program Management
Program Management Communication Tips