View source for Benefit Mapping in Change Programs

==Abstract==
In order to stay competitive organizations must recognize and act upon the fact that they need to change and adapt to changing environments and fast-moving markets <ref> Divert, Henriette; Kræmmer, Michael ''Change and Effect: Five Principles for Implementing Real Organizational Change'', p.2, (2017)</ref>.

When a company is going through a change process, the desired direction is steered by the company strategy that is defined by the senior management <ref> Geraldi, Joana; Thuesen, Christian; Oehmen, Josef; Stingl, Verena ''How to Do Projects, p. 61'', (2017) </ref>. The strategy and priorities are the ground for the portfolio that have a purpose to achieve a number benefits that will put the company in a preferably position in the future <ref> PMI, ''Program Management: The Standard for Program Management p.12'', (2017) </ref>. This article focuses on benefits related to organizational change, meaning changes where the purpose is to transform how the company is functioning order to be more efficient, effective or both. These benefits can be achieved by executing a change program, which consist of a number of projects that have the purpose to enable the desired organizational change when combined.

No matter what level of change a company strives for, it will demand people changing the way they work <ref> Lawson, Emily Price,''The Psychology of Change Management'', (2003) </ref>. thus, a change in human behavior. This makes it highly important for an organization to understand the different levels of impact of the change being initiated, so it can be translated and communicated to all relevant stakeholders, in a way that ensures a successful implementation <ref> Münster, Morten, ''Jytte fra marketing er desværre gået for i dag, p.15-16'', (2017) </ref>. However, “a general view states that up to 60 percent of change programs fail to achieve the targeted outcomes” <ref> Hayes, John, ''The Theory and Practice of Change Management'', p.4 (2018) </ref> this indicates, that organizations lack the capability of driving the change successfully.   
A way to drive change, that has been proven to increase the success rate, is to use the methodology of Benefit Realization which focuses on the connection between purpose and deliverables, and proposes multiple layers between the two, that must be considered in order to ensure executing the right actions <ref> Rytter, Rasmus; Krøyer, Jesper; Svejvig, Per, ''Gevinst-Realisering: Skab mere værdi i dine projekter p.47'', (2018) </ref>.
The overview of the entire connection is gained by using the method benefit mapping, which creates paths from purpose to benefits through five different steps as seen on figure 1.  

[[File:Figur1.JPEG|center|700px]]

The aim of this article is to provide the reader with a general understanding of change management and program management. In addition, it will give the reader the acquired knowledge to discuss the general theory behind benefit realisation and apply the different steps of benefit mapping on a change program.

==Change Programs==
The Project Management Institute states that “Organizations employs program management to improve their abilities to deliver benefits.”<ref name="PMI15"> PMI ''Program Management: The Standard for Program Management p.15 (2017)'' </ref>. In addition they suggest that in commercial organizations, these benefits would most often relate to business value which can both be tangible such as financial KPI’s and non-tangible such as brand recognition <ref name="PMI15" />. There are many ways to achieve desired benefits, which creates  which these the ground for different types of programs, one of them being organizational change programs <ref> Oehmen, Josef, ''Advanced Engineering Project, Program, and Portfolio Management: Introduction to Program Management Part 1'', (2019) </ref>. A change program focuses on optimizing functionality of the organization and should have the purpose to “realize benefits, which are aligned to strategic and operational objectives, that may not be realized when components are managed individually. The programme may also improve efficiency, reduce threats and realize opportunity” <ref> DS/ISO, ''Standard 21503 p.2'', (2017) </ref>. Concrete examples are:

* Agile transformation (going from working waterfall to agile)
* Merging with another company
* Going from silo to matrix organization
* Splitting up functions into smaller units
* Large Cost Cutting/ Restructuring 

All of the above have in common, that the goal is to realize a certain benefit, and that to succeed, the organization must change how they work. Thus, the result of the program depends deeply on the program managements capability to ensure that the future way of working realizes the benefit thereby aligning the operation of the company with the strategy. In this section, the context of Change Management and Program Management are established, in addition some challenges of succeeding with change programs are investigated. 

===Change Management===
As stated earlier, an organization must change in order to survive, and thus, every company must be able to manage change.
The general change management process can be divided into five main phases that must be completed in order to succeed with the change, while also having a focus on learning and leading and managing people issues, this can be seen on figure 2:

[[File:Change management process.png|500px]]  

''Figure 2: The Change Management Process (redrawn from <ref> Hayes, John ''The Theory and Practice of Change Management, page 2'', (2018) </ref>)''

Within each step there are a number of theories and practices that can be used in order to succeed with the individual step <ref> Hayes, John ''The Theory and Practice of Change Management'', (2018) </ref>, these both contain management of soft issues hear meant as the culture and change willingness of the people involved and the hard issues understood as the capabilities of executing new behavior.
However, even with a large theoretical toolbox within change management, the degree of uncertainty is considered very high. According to Ollson and Attrup <ref> Ollson, John Ryding; Attrup, Mette Lindgaard ''Power in Projects, Programs, and Portfolios'', (2015) </ref> a project concerning organizational change, is the project type with highest uncertainty due to two factors: Lack of clear definition of deliverables from start-up and low degree of structure and standardization, the scale can be seen at figure 3. As change programs consists of change projects and components, it is assumed that the logic can be used on programs as well.

[[File:Uncertainty_project_types.png|700px]]

''Figure 3: Project types in relation to uncertainty (redrawn from <ref> Ollson, John Ryding; Attrup, Mette Lindgaard ''Power in Projects, Programs, and Portfolios, page 59'', (2015) </ref>)

The factor concerning structure and standardization indicates, that change projects and programs lack a formal organization and cannot use standards within project execution. The other factor concerning how specific the project/program is, states that within change projects/programs it is not possible to define and predict which deliverables the projects will produce <ref>name=''Power in Projects, Programs, and Portfolios, page 59''</ref>.
The core of this article will not focus on the standardization of change programs, however, the process of defining and maneuvering through deliverables, will be the objectives of the last part of the article. 

The decision of what needs to be done and if the change should be executed through a single project, or if the complexity and/or size demands multiple aligned projects, thus a program <ref> PMI ''Program Management: The Standard for Program Management, page 11'', (2017) </ref>, is made in the beginning of phase three - plan the change, and will rely directly of the discoveries in the diagnosis phase <ref> Name=''The Theory and Practice of Change Management'' </ref>. If it is revealed that program level is suitable, the organization should initiate this program, and perform program management, which is described in the following.

===Program Management===
To understand the fundamentals of programs and program management the ISO standard for Guidance in Program Management (12) suggests four definitions which will be used in this article. These are seen on figure 4:

[[File:Program_definitions.png|700px]]

''Figure 4: Definitions of program terminology (information from: <ref> DS/ISO''21503'', (2017) page 1 </ref>'' 

Looking at the organizational context of program management, Prince2 states that it is the link between the outputs seen as products from projects and benefits being the business value within one or more strategic goals, that the cumulative delivery of products leads <ref> Geralde, Joana; et.al ''How to Do Projects, page 71-72'' (2017 </ref> <ref> Prince2''Agile Wiki'', Last modified(2017), visited 13/3 2019</ref>. 
Thus, making the Program Management responsible for translating desired benefits into project objectives and managing an ongoing amount of projects into delivering the results needed to realize the benefits. This is illustrated on figure 5.

[[File:Prince2_triangle.png|800px]]

''Figure 5: Relation between Output, Outcome, and Benefit (redrawn from <ref>''Agile Wiki''</ref>)

Taking a closer look at the program management organization it should, according to ISO 21503, consist of three main roles each taking a specific responsibility <ref> DS/ISO ''21503 page 8'' (2017) </ref> :

* '''Program Sponsor:''' “Responsible for the overall programme strategy and advocacy of the programme” <ref>name=''21503 page 8''</ref>

* '''Program Manager:''' “Responsible for the overall performance of the programme and coordinating the programme components” <ref>name=''21503 page 8''</ref>

* '''Program Management Team:''' “Responsible for the performance and implementation of one or more programme components or functions.” the team could consist of: The program sponsor, program manager, change manager, program component manager and administrative support  <ref>name=''21503 page 8''</ref>.

These are the main persons responsible for the initiation and execution of the program. When initiating a program, the ISO 21503 suggest that the program management:

* '''Make a framework''', that enhances the performance of the program, by establishing responsibilities and accountabilities, and facilitating support functions and providing the right amount of resources <ref> DS/ISO ''21503 page 9'' (2017) </ref>.

* '''Develop a programme design and plan''', that plan and identify elements of the program examples are: interdependencies of components, program roadmap, and stakeholder management strategy. <ref> DS/ISO ''21503 page 10'' (2017) </ref>.

The initiating work lays the ground for the entire program, and it is crucial that this is done properly. However, it is also important to know, that during the lifecycle of the program, changes should create value. In relation to program management change management “is proactive and adaptive to focus program on an evolving understanding of benefits, capabilities and environment” <ref>name=''Advanced Engineering Project, Program, and Portfolio Management: Introduction to Program Management part 1''</ref>. 

As a program consists of many components, involves a lot of stakeholders throughout the organization, it is often a complex process, and it is crucial that the program management are able to integrate different elements of the program. On figure 6, it is seen what areas should be involved in program integration.  

[[File:Program_integration.png|700px]]

''Figure 6: Program Integration (information from <ref>name''21503 page 10''</ref>)

In order to ensure continuous integration, the areas above should be managed throughout the program existence, however, it is important to have a exhaustive overview before the execution of the program begins, this will be considered in the last part of this article.

When execution a program, general practices across program components should be established. Examples of areas such practices may cover are: Risk and Issue Management, Quality Management and, Schedule Management . 
Finally, the program is closed. The closure procedure contains completing, verifying, and archiving different elements of the program components. It also include the verification that the program benefits have been realized or transferred <ref> DS/ISO ''21503 page 13'' (2017) </ref>. 

There exists many possible causes that can affect the success of the program. However, based on information provided in this section two ground causes can be identified:
# The program deliverables are not completed
# The program deliverables does not trigger the desired benefit

The next part of the article will have its focus on benefit realization, the part of program management that focuses on ensuring and maintaining the link between deliverables and desired benefit, thus minimize the risk of failing due to the second ground cause.

==Benefit Realization==
The realization of benefits is a central part of every program, and benefit management is also mentioned as an independent element in the ISO 5305 (12) and the PMI Standard for Program Management (7). Project Management Institute’s pulse of the profession In-depth report on benefits (14), it is stated that “Organizations with high BRM (Benefit Realization Management) maturity see an average of 50% more projects meeting original goals and business intent” (14). This is based on answers from over one thousand project management professionals in various industries, indicating that using the methodology enhances the success rate significant. 
Thus, it is considered highly important for an organization to be able to apply a process to enhance the chance of realizing the desired benefits. 

===Benefits===
A benefit can be defined as “gains and assets realized by the organization and other stakeholders as the result of outcomes delivered by the program” <ref> PMI; et. al. ''Program Management: The Standard for Program Management page 44'' (2017) </ref>. As stated earlier benefits can both be tangible and intangible, in addition it was concluded that change programs was uncertain partly due to the fact, that it is difficult to identify what should be delivered in order to create the desired change. Rytter et. al. agree with these points <ref> Rytter, Rasmus; et. al. ''Gevinstrealisering: Skab mere værdi i dine projekter page 78'' (2018) </ref>. They suggests that benefits should be estimated in order to evaluate them in relation to the business case <ref name="Rytter86"> Rytter, Rasmus; et. al. ''Gevinstrealisering: Skab mere værdi i dine projekter page 86'' (2018) </ref>. Thus, benefits should be divided into 4 categories depending on their traceability and quantifiability. This is illustrated on figure 7:

[[File:Benefit_categories.png|500px]]

''Figure 7: Categories for identified benefits (redrawn from <ref name="Rytter86" />)''

It should be noted that identified benefits that are not in the high/high category should still be managed and realized, however, the overview provides the insights that there exists different types of benefits within a program or project, and creates a ground for considering different approaches to the management of different benefits throughout the whole benefit realization process that is explained in the following.

===The Benefit Realization Process===
Looking at the process of benefit realization, the PMI standard for program management (7) suggest five phases, these can be seen on figure X, where an overview and a brief description of each are provided.

FIGURE

As illustrated benefit management is executed from the program initiation to program closure.

==Benefit Mapping==

===The Tool===

===Applied Example===

==Limitations==

==Bibliography==
<references />