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|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===
PMI Thought Leader Series suggests that “BRM helps maximize project, program, and portfolio value by incorporating and articulating accountabilities across stakeholders to identify, execute, and sustain strategic outcomes.” (16 p.3). Thus, incorporating a BRM process should increase an organization’s ability to link the strategy with program components and project deliverables. PMI states that the Strategy helps identify desired outcomes and outputs that guides the project execution used to accomplishes the strategic objectives. At the same time, the elements has a reverse effect adjusting each other, as the process progresses. An overview and illustration of the link between these are shown on figure 8:

[[File:Brmp_triggers.PNG|300px]]

''Figure 8: Relations between: Strategy, Outputs and outcomes, and project execution (redrawn from <ref> PMI; Boston Consulting Group ''PMI Thought Leader Series: Connecting Business Strategy and Project Management'' (2016) </ref>)''

The connection between the elements shown on figure 8, is triggered through a BRM process. The PMI standard for program management suggest a process consisting of five phases. These can be seen on figure 9.

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

''Figure 9: The Benefit Realization process (redrawn from <ref> PMI ''Program Management: The Standard for Program Management page 46" (2017)</ref>)''

As illustrated benefit management is executed from the program is initiated and until the program closure, the ISO 5305 suggests that it should begin when the project is in consideration, and increase the detail level, as the program is established <ref>DS/ISO "21503" </ref>. 

Within each step of the process the Program Management Team has different assignments to accomplish or delegate. To do this, different tools and sub-processes are developed <ref>PMI "Program Management: The Standard for Program Management, chapter 4''(2017)</ref>. This article will not go into further detail with the different phases, but focus on one important tool within BRM. This tool is called Benefit Mapping, the next section will explain the use of the tool in practice, to provide practical insights to the reader.

==Benefit Map==
A benefit map is a visual overview of identified benefits and their connection concrete deliverables. There exists different versions of the tool, Gojko Adzic suggests the following elements should be present: “Strategic Objective”, “Benefits”, “Business Change”, and “Enabler” <ref name="gojko"> Gojko, Adzic "Impact Mapping"(2012)</ref>. Rytter, Lind and Svejvig  propose a version with five elements: “Purpose”, “Benefits”, “New behaviour”, “New Competences”, and “Project deliverables” <ref name="Rytter"> Rytter, Rasmus; et.al "Gevinstrealisering: Skab mere værdi i dine projekter"(2018)</ref>. There is a clear resemblance between the two mentioned versions and they both have the objective of increasing the insights from the why to the how of the program or project <ref name="gojko" /> <ref name="Rytter" />. This article will use the version proposed by Rytter et. al. presented in the book Benefit Realization: Create more value in your projects <ref name="Rytter" />. The model is seen at figure 10:

[[File:Benefit_map.png|1000px]]

''Figure 10: Benefit Map (redrawn from <ref> Rytter, Rasmus; et.al "Gevinstrealisering: Skab mere værdi i dine projekter page 49" (2018)</ref>)''

Zooming in on benefits, it is seen that the area is larger than the others, do to the fact that it is suggested to divide benefits into two categories “Performance Benefits” ie. 10% less complaints and “End Benefits” ie. reduced staffing resulting in a yearly cost reduction of 200.000 <ref name="rytter53"> Rytter, Rasmus; et.al "Gevinstrealisering: Skab mere værdi i dine projekter page 49" (2018)</ref>. It is also seen that negative benefits are also addressed, this should also be considered on a high level scale, and could include for example loss in performance <ref name="rytter53" />

===The Tool===
As stated, the benefit map is a way to approach the break down of a project or program purpose into concrete components or deliverables. To increase the chance of success, the tool forces deep considerations into the linkage, by addressing the mechanism that lies between. Overall the benefit map is said to (list <ref> Rytter, Rasmus; et.al "Gevinstrealisering: Skab mere værdi i dine projekter page 48" (2018)</ref>):

* Give an overview of the benefits
* Show how benefits are created
* Indicate the size of the change assignment
* Be a communication tool that explains the “why” 
* Is used for the control of scope 

In addition it can be used as a central tool for the process of defining ownership and delegating responsibilities, which as stated is an important part of creating a program framework. 

Looking closer at the model, it is seen that it directly mentions the change in behaviour that is demanded to achieve desired benefits, this makes it highly relevant to use in auspices of Change Management, as implementation of new behaviour is, as stated earlier, a crucial success criteria within this field. Rytter et.al. suggests that training of employees in new processes, tools, systems etc. is done in order to establish new competences, thus a link between “deliverables” and “competences”, and that change management practices are in focus when the new competencies are becoming new behaviour <ref> Rytter, Rasmus; et.al "Gevinstrealisering: Skab mere værdi i dine projekter page 51" (2018)</ref>. 

The benefit map is considered very beneficial to use in relation to change programs <ref>Thomas, Steven "Benefit Map: Impact Mapping for Programme Managers"(2013)</ref>, as it makes it clear what is needed, how it is achieved and why it should be done. 


===The Tool in Practice===
The benefit map can be used for multiple purposes and is often not created in one go <ref name="Rytter" /> Taking a standing point in change programs, the practice of how to use a benefit map is explained in the following.

==Limitations==

==Suggested Reading==
====Change Management====
* '''John Hayes: The Theory and Practice of Change Management'''
* '''Change Impact: 
* '''Morten Münster: Jytte fra Marketing er desværre gået for i dag (behavioral change)'''

====Program Management====
* '''DS ISO: 21503
* '''PMI: Program Management: The Standard of Program Management
* '''John Ryding Ollson and Mette Lindegaard Attrup: Power in Projects Portfolios

====Benefit Realization and Benefit Mapping====
* '''Rasmus Rytter, Jesper Krøyer Lind, Per Svejvig: Gevinstrealisering: Skab mere værdi i dine projekter'''
* '''Gojko Adzic: Impact Mapping'''

==Bibliography==
<references />