Important note:  this work was completed in 2009.

I was assigned as program manager to implement a major telecommunications ebonding capability for mobility services to signature customers throughout the world. This was a program to make a repeatable process that would help define a customized catalog of services for each customer yet a common interface to performing suppliers that would actually fulfill the orders for example a customer may have mobility needs in multiple countries throughout the world one in South America one in Asia one in Germany warning the Netherlands one in United States one in Mexico etc. etc. and there was no common wireless carrier they could fulfill all these orders. Each country had its own set of rules and data sets that made a single interface impossible to implement. My role as program manager involves several different steps:

1. Determine the key stakeholders in the program. I was given the charge to implement program management but there wasn’t any formal documents that made such an announcement. So I created a program charter and had an executive sign it and email it to his peers to authorize resources to plan the program.
2. Assembled a small team from the product house, operations, and IT to create a joint definition of work effort.
3. Shared this document with multiple organizations to assemble a core team of stakeholders and a responsibility matrix.
4. Created a program plan which defined various work packages and the time box timeframe for certain deliverables. Among these deliverables were a business requirements document. Benefits realization plan, and a governance model.
5. Developed seven project charters to implement the work efforts. Three of the charters were specific to IT development one of the charters was to the marketing and technical implementation plan two of the charters were specific to process and lifecycle support, and final charter were specific to developing a repeatable process for catalog management.
6. Mapped the cost of the projects based on a high-level order magnitude to a benefits realization plan and established the expectations for the deliverables.

To summarize, my planning processes is first to make sure I have owners and executive sponsorship from the business, next it is to do a program charter the authorized organizations to commit resources to the planning, next is planning the roadmap and the business realization plans, next is to issue a program plan which outlined how work package are aligned which then will generate a charter for each project that will help meet those objectives. Once the charters are defined a project manager will be assigned there will be responsible for implementing the requirements of the work. Tools and techniques that I use in this planning process is constant communication and dialogue with key stakeholders and a small work team. Interacting with knowledge workers through facilitating meetings with different organization to define business rules, program requirements, baselining documents and using the concept of progressive elaboration to monitor control their evolution from a planning cycle until project implementation. Finally, the process involves interacting with the teams through a defined governance model so all organizations know the protocol for handling issues, communicating status, and reporting task completion.

What vs. When?

It never fails to amaze me how many hours are spent trying to wordsmith terms and schedules in order to meet rules of political correctness.   I have spent hours of my career pretending we are developing a project plan focused on including a suite of capabilities to be delivered together, when in reality – there is an imposed constraint (due date) that must be met.  So therefore the question needs to be asked:  Is it a case of WHEN we can deliver all the capabilities, or is it a question of WHAT can we deliver by a certain date.  I’m not arguing one over the other, my argument is that time is much better spent using the Benefits model when there is a dictated delivery date.  The scope needs to be focused on WHAT can be delivered in the timebox.

This is where a well-defined benefits hierarchy helps the program manager.  The benefits hierarchy of benefit, outcome, and capability is a foundation for creating the roadmap and eventually the project deliverables.  Focusing on what provides the biggest benefits – rather than the contents of the "what in this timeframe can be defined" should drive the best decision within the defined constraints. (Let’s assume that all capabilities have the same cost/quality as this information may be implied within the benefit definition and associated attributes).  In the simplest sense, the scope of the project in the given time box can be determined by doing a binary check of each capability and what it contributes to the benefit.   Can we deliver this benefit in this timeframe? 

I know this assumes a logical quantitative world in which there are no pet projects and all people are rational – but it’s nice to dream.   However; in the imperfect world in which we live the capabilities should be prioritized first as high, medium, and low.  I imagine at that point all the lows are crossed off the list and ice boxed and the mediums are put on hold.  Then you should take the high benefit contributing capabilities and rank those as high medium and low.  (High is the same as mandatory).  Then ask the question:  Can all these be delivered in the timebox?  If the answer is no – you must move the time constraint!!!. 

If the answer is yes, you then ask, can it include any more capabilities?  If that answer is yes, you then need to independently rank the mediums and then go down one by one and ask the question: can we do the highs plus this one?  If yes – add it to the list, if no – it gets put into the icebox.

Now somebody will bring up the idea of well if I can have 2 and 5 but not 1, then I want to do that.  This exercise is one of those that sounds nice in theory, but becomes very expensive in practice.  The program manager really needs to make sure that the benefit/capabilities stand on their own.  And if they want to combine them – then the combined benefit is what must be evaluated against the line.  It really doesn’t make sense to spend lots of cycles piecing together different scenarios in order to see WHAT CAPABILITIES  we can get delivered, we should focus on WHAT BENEFITS can we start to realize.  This game leads to the bad practice of putting in low value capabilities just because we can get them in by a date as opposed to looking at the high value capabilities that will drive real benefits.

My daydream is over.  The politics of organizations will drive the game.  Unless a complete OCM project has been implemented that drives the decision model driven by benefits is in place – the games of how many things can I fit in the time box will continue.    But keep the faith program managers – by forcing benefits to be evaluated while these decisions are being made will be worth it when the icebox is opened for the next timebox.

Defining Benefits: Forced Extraction

The benefits definition, qualification, and quantification process can be somewhat confusing to many people.  Defining a benefit can be tricky and misinterpreted, especially by upper management.  There may be some members of the team who look at all results as a function of benefit realization, while the true definition of Benefits Realization rests in organic improvements as a result of change. One item that causes confusion is called a force extraction.

A forced extraction is when a company forces financial results on an organization.  For example the budget for a department is cut by 10%.

While that forced extraction may provide economic results to the company, it is not considered a Program Benefit.

Program Benefits are identified as a result of the outcomes of the components.

It is important that benefits are identified as a result of the outcomes of the components and not as a direct result of a business allocation of resources.   While a factor in the overall program may be a budget reduction, it should not be tracked as a program benefits because it is not a result of the outcomes delivered by program components.

The Project Management Institute® (PMI) has defined a Benefits Realization model for a Program Manager to use to help the company capture the expectations of an investment.  The concept of the model is to provide a structure from the initial planning through to actual realization (or booking) of the benefits into a new Business As Usual change.  The five steps are loosely structures to be hierarchical in flow, but allows for a progressive elaboration approach as more information becomes available during program implementation.

Benefits Identification

This is the initial step of capturing the potential benefits that can be realized by the program.  This step is analogous to a brain storming session and will result in a canonical listing of potential benefits.  There are many sources for gathering this information including business documents, brainstorming sessions, extraction from a business plan, external factor analysis, organizational strategic objectives, and expert knowledge.  Many organizations will group the list into various categories to assist in analysis and eventual ownership.   The outcome of this step should be a list of potential benefits in a benefits register.

Benefits Analysis and Planning

This is the means of qualifying and quantifying benefits.  If the benefits Identification step produces a canonical list of benefits, then each benefit needs to pass a “test” to see if it truly qualifies as a benefit, or to help prioritize benefits.  The benefits register should contain the associated algorithms and business rules/logic required to define the value of the benefit.   The analysis will also include setting an expectation for the value of the benefit and a relationship of the benefits against sequence, time, and dependencies.  A significant portion of this step is to align company performance metrics (KPI) to be able to measure, demonstrate, the results of the implementation.  The end result of this step should be the Benefits Realization Plan (BRP) which formally documents the activities required for achieving the program’s planned objective.  Included in the Benefits Realization Plan is a program roadmap which documents the expected delivery of the value of the benefit against time.   The BRP will also define how the benefits will be transition to operations at the end of component deliver and the sustainability expectations.  The Benefits Realization Plan is a control document and needs to be baselined and managed under strict change control throughout the life of the program.

Benefits Delivery

This is the means of actually placing the changes into the business and the start of seeing the expected benefits in the business reporting infrastructure.  Since Programs will include multiple components, the delivery will be an iterative process and will span from the first project completion through to Program Closure.  Using the baselined BRP, the program resources will conduct monitor and control activities to analyze the results and prescribe corrective action.   Part of this prescriptive corrective action is to ensure the Benefits Register is aligned with the monitor and control activities.  The final litmus test of the benefit delivery is to ensure the results are properly accounted in the company Profit and Loss (P&L) applications (or  they are “booked”).

Benefits Transition

This is the means of recognizing the programs have defined ends and that benefits might be realized long past the closure of the program.  The Benefits Owner will eventually assign benefits realization to an operations function where it measures the benefits as part of a “Business As Usual” process.  This implies that monitor and control and associated prescriptive action is no longer the responsibility of the Program manager, but not the operations manager.

Another important aspect of the Benefits Transition is that operations team will often view a suite of benefits as one item.  For example there may be six benefits included in a project software enhancement, the operations team will most likely look at that as one enhancement.  Therefore, the benefits transition process, and associated artifacts, will consolidate coordinated benefits into the package to east transition.  The outcome of this phase will be the standardized reporting of benefits to associated benefit and business owners.

Benefits Sustainment

Finally, benefits need to be sustained over the lifecycle of the change initiative.  Many times the benefits will be forecasts over time, as defined in the benefits roadmap, and the time frames will expand past the life of the program.  After benefits are transitions, they need to be sustained.

Monitor and control and taking corrective action is a portion of the sustainment steps, but it can include much more.  It is possible that during the lifecycle of the change that previously unidentified benefits are realized, these “emergent” benefits should be documented and through the use of structured change control, incorporated into the benefits reporting models. 

Conclusion

The PMI Benefits realization model defines a structured set of phased to support the identification of, analysis of, monitoring and control of, the transition of, and the sustainment of benefits throughout the lifecycle of the change.  The model also encompasses the “care and feeding” of benefits after transition to operations and helps to validate the true return on investment to the organization.  Benefits Management needs to be incorporated into an organizations knitting and be considered in all aspects of the program.

Sources

Letavec, Craig J. Strategic Benefits Realization: Optimizing Value through Programs, Portfolios and Organizational Change Management. Plantation, Fl.: J. Ross, 2014. Print.

The Standard for Program Management. Vol. 3. Newtown Square, Pa: Project Management Institute, 2013.

We're All In This Together !!!

Dave

I have been invovled in Benefits Realization for quite a while and the first challenge I always stumble upon is: "what is a benefit"?  Of course there is no simple answer and in some ways it will be defined by your engrained culture.  So to start things off, I will go to published literature regarding benefits and post this information.  Then over time, I will delve into my definition. 

So please, strap in and welcome aboard as we try to get a better handle on what is benefits realization and how can I use it in my job.

Definitions of Benefit

This is a short compare and contrast exercise to see the variation (and hopefully, consistency) between different people’s definition of Benefit in the context of Benefits Management. Note how specific and context focussed some definitions are.

Cranfield 1996
An outcome which is regarded as favourable, with reference to a previous situation. In this sense, a benefit may be regarded as a favourable change in some value between a previous state and a current state, or between the current state and a future state.

Thorp 2003
An outcome whose nature and value (expressed in various ways) are considered advantageous by an organisation.

Gartner 2005
Benefits are real sources of value to the business, such as increased revenues, better customer retention, lower costs or quicker time to market”

Ward & Daniel 2006
Business Benefit – An advantage on behalf of a particular stakeholder or group of stakeholders

Bradley 2006
A benefit is an outcome of change which is perceived as positive by a stakeholder.

Remenyi, Bannister and Money 2007
A term used to indicate an advantage, profit or gain attained by an individual or organisation

OGC 2003
The quantifiable and measurable improvement resulting from an outcome which is perceived as positive by a stakeholder and which will normally have a tangible value expressed in monetary or resource terms. Benefits are expected when a change is conceived. Benefits are realised as a result of activities undertaken to effect the change.

NHS Connecting for Health (ISIP) 2007
The value placed by a stakeholder on the performance improvement or new capability resulting from an outcome.
Benefits are identified by asking stakeholders to articulate how they believe they (or the people they represent) will experience the value of the outcome, i.e. stakeholders answer the question “what’s in it for me?”

OGC PRINCE2 2009
The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders.

OGC Management of Value 2010
A measurable improvement resulting from an outcome perceived as an advantage by a stakeholder.

OGC MSP 2011
The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders, and which contributes towards one or more organisational objective(s0.

APMG Managing Benefits 2012
The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders, which contributes towards one or more organisational objective(s).

NHS IC 2010 Benefits Glossary
The value placed by a stakeholder on the performance improvement or a new capability resulting from an outcome.
A dis-benefit is an outcome that the stakeholder sees as detrimental to personal interests.

APM Body of Knowledge 6th Edn
The quantifiable and measurable improvement resulting from completion of deliverables that is perceived as positive by a stakeholder. It will normally have a tangible value expressed in monetary terms that will justify the investment.

Dave Davis Definition

An outcome of Change which is seen as positive by the stakeholders.

My definition is simplistic, but as we dive in, we will discover the many implied dimensions. 

I confesss this list is not original and was saved a while ago and I forget the origin.  I will work on finding the source and share it.  Meanwhile - here we go.

We're All In This Together !!!

Dave