MSP 2011 part 2

1
Managing Successful
Programmes
Trainer: Robert Edward Pinnington

2
10 The business case
11 Risk & issue management
12 Quality & assurance management
13 Transformational flow overview
14 Identifying a Programme
15 Defining a Programme
16 Managing the Tranches
17 Delivering the Capability
18 Realizing the Benefits
19 Closing a Programme
Agenda (cont‘d)

3
10.1 Introduction
10.2 Genesis of a programme business case
10.3 Contents of the business case
10.4 Reviewing the business case
10.5 Managing the business case
10.6 Business case within the transformational flow
10.7 The key roles

4
10.1 Introduction
The senior responsible owner (SRO), the sponsoring group & the programme
board must have confidence at every stage that the programme is still viable. In MSP
the business case provides the vital test of the viability of the programme. It answers
the question ‘Is the investment in this programme still worth it?’
Since this viability question is ongoing, the business case cannot be static. It provides
more than the basis for initial approval to kick off the programme. It is actively
maintained throughout the programme, continually updated with new information on
benefits, costs & risks.
The business case is an aggregation of specific information about the programme:
• Value of the benefits
• Risks to achieving the benefits
• Costs of delivering the blueprint
• Timescales for achievement.

5
10.2.1 PROGRAMME MANDATE
10.2.2 PROGRAMME BRIEF
10.2.3 LINK WITH BENEFITS
10.2.4 LINK WITH PROJECTS

6
10.2.1 PROGRAMME MANDATE
A programme begins most effectively when it is launched in the context of a clear
corporate strategy. Good strategy is robust enough to cope with continually
changing business drivers, both internal & external. Ideally, the strategy will suggest
the optimum route for programme delivery & the prioritization of new & existing work
against it. The programme mandate provides the strategic trigger at the start of a
programme. The programme mandate may be a consolidation of information from a
number of documents, policies & directives. Collectively, this programme mandate
informs & directs the activities of programme identification (in Identifying a
Programme) & definition (in Defining a Programme). A programme mandate might
contain a suggested business case, & should at least provide much of the raw
material for outlining one.

7
10.2.2 PROGRAMME BRIEF
If the programme mandate provides the trigger & context for a programme, it is the
programme brief that develops the programme concept & provides the basis for an
initial assessment of the viability & achievability of the proposed programme. As
such, the programme brief does provide an outline business case, the formal basis
for assessing whether such an investment is viable or achievable, before committing
to the detailed programme definition work. If the programme mandate is flawed, the
process of developing the programme brief should reveal this.
Achieving success requires a realistic view of the organization’s competence,
capacity & culture to accommodate change. Just because a venture looked a good
idea in a strategic planning session does not necessarily mean it can stand further
scrutiny.
The programme brief contains the outline vision statement (the picture of the future
beneficial state) & benefits, which should be validated against the organization’s
strategic objectives.

8
10.2.3 LINK WITH BENEFITS
Definition of the programme benefits evolves through the programme mandate &
programme brief, & then significant analysis & development work is done during
Defining a Programme to develop the understanding & potential of the benefits that
the programme can realize. Part of this work is to gain an understanding the level of
risk that will be associated with the investment.
The work on benefits is intrinsically linked to the development of the business case,
as it is the input information that will provide the justification for the investment. The
anticipated financial savings would be expected to exceed the cost of the projects to
deliver the capability.
The analysis isn’t always so simple, & some business cases may be based on
achieving value or benefits that are not entirely balanced by the costs of delivery.
This may be particularly the case with a compliance programme, for example, where
the benefits may be the avoidance of negative consequences rather than actual
positive effects.

9
10.2.4 LINK WITH PROJECTS
There will be individual project business cases as well as the business case for the
programme. A project business case is about balancing the costs, timescales & risks
relating to delivering the project outputs, & the context & contribution to the
realization of directly enabled benefits.
The programme’s business case is broader than a project business case. The
programme business case embraces the wider horizons of strategic outcomes
arising from the programme’s projects. It is more than a summation of the project
business cases (where they exist). It will also include the cost of business changes
required in the programme & additional benefits realization costs, showing how these
integrate with the project outputs to achieve the corporate strategic objectives.
The business cases for the programme & the projects are continually monitored,
reviewed regularly, & updated as necessary to ensure that progress remains aligned
to the strategic objectives. In the most serious case, an escalation of a major issue
from one of the projects could result in the programme’s business case becoming
unviable.

10
The programme’s full business case sets out the overall costs, the planned benefits
realization & the risk profile of the programme, in order to assess its viability & make
appropriate management decisions about its continued viability.
The business case is developed by iteration through stages of formulation & analysis
& is compiled from other information, including the:
• Blueprint
• Benefits realization plan
• Risk register
• Resource management strategy & resource management plan
• Programme plan.
The level of detail & completeness of the business case will reflect the degree of
certainty associated with the programme at that point. Initially, the programme may
tolerate high levels of uncertainty; estimates will be very approximate, with high levels
of potential variance. The blueprint may be going through frequent iterations as well.

11
10.3.1 NET BENEFIT LINE
The business case is where a trade-off is made between:
• The costs associated with delivering the new capability & embedding changes,
and
• Realizable benefits & the value to the organization of having those benefits.
The concept of ‘net benefit’ is represented by the net benefit line below. During the
early stages of a programme the cumulative costs of delivery & embedding might
outweigh the cumulative benefit to the organization(s). As the programme continues,
more benefits are realized, thus providing greater value, so the cumulative net benefit
increases.

12
10.3.2 COSTS
Type Description Sources
Project costs, sometimes
referred to as investment
or development costs
Project costs in acquiring &
delivering the enabling outputs
For project & programme
contingency & change budget
Projects dossier
Programme plan
Project business cases
Benefits realization costs Setting up & implementing
measurement, monitoring, &
reporting on benefits realization
Other costs incurred in achieving
the benefits, which can be
attributed to benefits – for
example, compensation packages
for staff
Benefits management
strategy
Benefit profiles
Benefits realization plan

13
10.3.2 COSTS
Business change &
transition costs
Cost of preparing, training,
moving & supporting an
operational unit until new
practices are embedded. This
could include interim operational
resources required to embed the
change
Costs of activities defined in the
Realizing the Benefits element of
the tranche, including the costs of
the BCM & business change
teams.
Programme plan
Resource management plan
Benefit profiles

14
10.3.2 COSTS
Programme
management costs
Some programme roles will be
full-time: for example the
programme office & the
programme manager
Associated costs for these roles &
for programme management
activities: for example office
space, programme tools for
tracking & reporting progress
Contingency budget for dealing
with risk & change
Assurance & review costs
Resource management plan
Information management
strategy
Programme communications
plan
Quality & assurance strategy
Programme plan

15
10.3.2 COSTS
Capital costs Capital costs are normally for fixed
assets which can often be found
under the ‘technology’ heading in
the blueprint. In accountancy
terms the impact of these costs
will often be spread over a number
of years
Blueprint

16
As a minimum, the business case should be reviewed at the end of each tranche to
assess the continued viability of the programme & any need for realignment. In the
UK public sector, such reviews are often undertaken as part of OGC Gateway
reviews. It is good practice to formally review the business case at least every six
months, particularly if tranche ends are spaced over longer periods.
Reviewing the business case should provide answers to the following questions:
• Is the programme (still) affordable – is there sufficient funding?
• Is the outcome (still) achievable – is there a realistic assessment of the
organization’s ability to cope with the scale of change envisaged?
• Does the programme (still) demonstrate value for money – are the benefits & the
costs of realizing them in the right balance?
• Have options been considered – is the programme’s dossier of projects (still) the
appropriate or optimum way of achieving the desired outcome(s)?

17
• Is the programme still justifiable in terms of its ability to meet strategic objectives?
• Is there an up-to-date contingency plan & are there arrangements in place to
ensure that there is sufficient financial cover for risks & uncertainties?

18
Information presented in the business case will serve many purposes during the life
of the programme – all focused on ensuring successful delivery & strategically
aligned outcomes.
The key questions here are:
• To what extent can the programme realize the expected benefits?
• Will changes to the cost-benefit profile (as in the net benefit line) alter the status &
relative priority of the programme in relation to meeting the corporate strategic
objectives?
The business case will be used to assess the impact of:
• Accommodating any strategic change or any changed business driver
• Proposed revisions to the programme’s boundary & blueprint
• Revised benefit & cost estimates from the BCMs & the projects
• Any major new issue identified
• Any significant new risk identified.

19
Delivering the business case should not end with the programme. The SRO should
continue to champion:
• Values & principles that underpinned the change initiative
• Desired outcomes
• Continued leveraging of the benefits after the programme closes.

20
10.6.1 IDENTIFYING A PROGRAMME
10.6.2 DEFINING A PROGRAMME
10.6.3 MANAGING THE TRANCHES
10.6.4 DELIVERING THE CAPABILITY
10.6.5 REALIZING THE BENEFITS
10.6.6 CLOSING A PROGRAMME

21
This is the genesis of the business case. The programme mandate is an input to
Identifying a Programme. It might contain a suggested business case & should at
least provide much of the raw material for outlining one. If the programme mandate is
flawed, this should be revealed during the development of the programme brief. The
programme brief is created in this process & provides an outline business case.

22
This is where the full business case is created & developed, using input from all the
other work undertaken in Defining a Programme. This process provides guidance on
how to develop the business case by iteration so that it presents the optimum way
forward, selected from a range of alternatives.

23
The business case is the key control document. It will need to be updated & reviewed
throughout each tranche to ensure proper control. At the end of each tranche, it is
reviewed, validated & re-accepted. The programme’s plans may need to be refined,
based on lessons learned so far, so the business case may need to be adjusted to
reflect this. At the end of each tranche, as part of the review that takes place, the
business case needs to demonstrate that the programme is still affordable,
outcomes are still achievable & it still represents value for money. The business
case must also continue to be aligned to corporate strategy.

24
There will be individual project business cases as well as the business case for the
programme. The programme’s business case is broader than a project business case
& is more than a summation of the project business cases. It will also include the cost
of business changes required in the programme & additional benefits realization
costs, showing how these integrate with the project outputs to achieve the corporate
strategic objectives. Reporting from the projects to the programme should include the
provision of updated project business cases.

25
Benefits are an important part of the business case, the other parts being cost, time &
risk. If the programme fails to realize its planned benefits, then the business case will
fail to be achieved. Benefits reviews will provide an important input to reviewing the
business case.

26
If all has gone well, the business case will have been achieved. The business case is
finally updated from all the programme plans & the business cases of the constituent
projects. In many programmes there are still benefits to be realized after the
programme has closed. Further updates of the business case may be required.

27
10.7 The key roles
weight good 74.5
Role Area of focus
SRO Answering to the sponsoring group for the successful delivery of the
programme & achievement of the business case
Securing investment for the programme
Ensuring that the business case is controlled & audit trails are in place to
account for changes as the programme develops
Scanning the business horizons surrounding the programme for issues that will
lead to realignment of the programme in some way
Ensuring that the progress of the programme remains aligned withthe business
case
Consulting with the sponsoring group to identify any early-warning indicators of
change that may undermine the business case or cause it to lose strategic
alignment
Initiating independent assurance reviews of business case viability

28
10.7 The key roles
weight good 74.5
Role Area of focus
Programme
manager
Preparing the business case
Supporting the SRO in the ongoing validation & review of the business case
Managing the programme’s expenditure against the overall investment defined
in the business case
Identifying opportunities to optimize the business case

29
10.7 The key roles
weight good 74.5
Role Area of focus
Business
change
manager(s)
(BCM)
Profiling the benefits & dis-benefits & their associated costs
Ensuring that benefits continue to be valid through regular business case
reviews
Ensuring that the full cost of change is being captured in the business case
Identifying operational risks to the business case & ensuring that they are
controlled
Measuring benefits at the start of the programme & tracking throughout to
inform the net benefits
Managing business change costs
Managing benefits realization costs
Realizing the profiled benefits

30
10.7 The key roles
weight good 74.5
Role Area of focus
Program
me office
Supporting the SRO & the programme manager in compiling &
updating the business case
Collecting & maintaining business case information
Facilitating business case reviews

31
11.1 Introduction
11.2 Managing risks in a programme
11.3 Risk management framework
11.4 Managing issues in a programme
11.5 Issue management framework
11.6 Change control
11.7 Configuration management
11.8 Risk & issue management within the transformational flow
11.9 The key roles

32
11.1 Introduction
At any point during a programme, there may be events or situations which can affect
the direction of the programme, the delivery of its outputs & capability, the
achievement of outcomes or the realization of expected benefits. These events or
situations are the risks & issues that the programme has to manage & resolve.
Successful programme management has at its core the need to both manage &
tolerate uncertainty, complexity & ambiguity. Risk & issue management are the
vehicles for achieving this, where:
• A risk is an uncertain event (or set of events) which, should it occur, will have an
effect on the achievement of objectives. This effect need not be detrimental. A risk
can be either a threat (i.e. an uncertain event that could have a negative impact on
objectives or benefits) or an opportunity (i.e. an uncertain event that could have a
favourable impact on objectives or benefits).
• Issues are events that have happened, were not planned & require management
actions. Risks, should they occur, become issues.
The aim of programme risk & issue management is to support better decision-making
through a good understanding of risks & issues & their likely impact.

33
11.2.1 RISK MANAGEMENT STRATEGY
The risk management strategy is created & approved in Defining a Programme, & it
describes an approach to risk management which reflects the programme’s unique
objectives. This guide describes the specific management activities that will be
undertaken within the programme.
The strategy should reflect the organization’s risk policies & process guidance
(where these exist). These may define the risk management process to be followed &
the priorities to be observed by the programme to ensure it is compliant with the
organization’s risk governance arrangements.
Building on these corporate standards, the programme will set its own appetite &
culture for managing its risks in the programme’s strategy documents.
In a portfolio environment, much of the strategy may be prescribed, & a key role of
the strategy is to prescribe to the projects how they will manage their risks.
The risk management strategy should clarify how opportunities will be managed, &
describe how the interface with the benefits management approach will be handled
as defined in the benefits management strategy.

34
11.2.2 RISK APPETITE
Risk appetite is the amount of risk that the organization, or subset of it, is willing to
accept. Understanding corporate risk appetite is essential for a programme to devise
a successful risk management strategy, steer project risk activities & define
aggregation & escalation rules. Properly defined & communicated, risk appetite helps
to insulate a programme from unwelcome surprises & provides it & its projects with
clear tolerances in which to operate.

35
11.2.3 TOLERANCE THRESHOLDS
Thresholds translate risk appetite into a guideline that steers programme & project
behaviour. Thresholds define the exposure to risks on one level that, if exceeded,
requires escalation & reaction from the level above. This applies to projects & their
programme (as well as the programme & the organization to which it reports).
When setting tolerance for projects, it is important that the programme manager
sets tolerance in line with the objectives of the programme. There may be certain
requirements from a project that have no tolerance: for example, risks that may affect
the dependencies on benefits activities. Setting generic tolerance thresholds may
hide aggregating threats from the programme board & senior responsible owner
(SRO). The same applies to operational risks; for example, delays in one area may
have a domino effect across the programme that goes beyond tolerance thresholds,
but they are only discovered when they are triggered.

36
11.2.4 ASSUMPTIONS
When a programme’s business case (or the business cases of the projects within
the programme) is created, ‘assumptions’ are often used to define the boundary of
the programme & provide for uncertainties outside its immediate area of influence.
Assumptions are the result of uncertainty, & the likelihood of a particular event (or
sequence of events) having a result on which the programme is depending. A false
assumption can have a serious effect on the programme, & it is therefore
recommended that programme assumptions are treated as sources of risk; each
should be recorded in the risk register & managed accordingly.
Project assumptions should be reviewed at programme level to see if they should be
viewed as sources of risk to the programme & managed accordingly. The project
should then manage the assumption as a risk.

37
11.2.5 EARLY-WARNING INDICATORS
Risk management needs to be proactive to anticipate potential problems. Early-
warning indicators can be used to provide information on the potential sources of risk,
or as a way of tracking sensitive risks, triggering further corrective actions if
predefined levels are reached. Whilst these early-warning indicators could measure a
number of diverse wide-ranging monitors, they are only of value if they:
• Are measuring valid indicators
• Are reviewed on a regular basis
• Use accurate information
• Reach decision makers & are acted upon.
Early-warning indicators are vital for a programme, as they provide measures that
give advanced warning of trends or events that could adversely affect the
programme’s outcomes. Key early-warning indicators relating directly to the
programme’s objectives might include:

38
11.2.6 RISK REGISTER
The risk register is a repository used to capture information about risks in a
consistent & structured manner. It is created during Defining a Programme; any
existing risks at that point will be described in the programme brief. Each organization
will need to decide on the specific layout of its register. The programme’s risk
management strategy defines in detail the content & purpose of this repository. The
programme’s projects will also maintain their own repositories, & the programme will
coordinate its activities with a separate register. In addition, the risk management
strategy defines how risks are reported & escalated. Finally, the strategy determines
how accountability for certain types of risks, those that pose an aggregated threat on
programme level or span beyond individual projects, will change between the
projects & the programme if required.

39
11.2.7 THREAT & OPPORTUNITY
Most people define risks as threats to the programme, but some risks actually
provide opportunities to improve a programme’s outcomes & benefits. What
constitutes a threat or an opportunity can vary, & the same event can have very
different impacts on individual projects; furthermore, once these threats or
opportunities are aggregated at programme level, the resulting effects change again.
Whether a threat or an opportunity, it is important to remember that there may be one
or more events that will trigger the threat & cause the risk to be realized.
Differentiating between the threat/opportunity & the event will help the programme to
focus its risk response. It may not be possible to remove the threat or opportunity, but
it might be possible to avoid or remove events that will trigger the risk.

40
11.2.8 EVALUATING RISKS
The uncertainty associated with risks is expressed as the probability of their
becoming issues. A risk will potentially impact the programme in a number of ways:
for instance, cost, time & benefits. These may be shown in the form of a probability
impact grid, giving the criteria for each level within the scale, e.g. for very high, high,
medium, low & very low. Probability & impact values can be attributed to these
ratings so that ranking values can be calculated for each cell of the grid.
‘Expected value’ is a way of estimating the financial exposure of risks by discounting
the total cost of their impact against the probability of their occurrence. It is calculated
by multiplying the estimated average risk impact by the estimated probability to give
a weighted risk.

41
11.2.9 RISK AGGREGATION
Individual threats can have an aggregated impact, where the net effect of threats
(and opportunities) changes when they are combined. At project level, a small risk
can have limited impact. But if the risk is combined with other risks in adjacent
projects, it can produce a significant impact at programme level. An identified risk can
be of concern for a project, but there might be an opportunity in another project that
cancels or compensates for the effect. This aggregation is particularly important
when evaluating risks across the programme. Dependencies between risks need to
be taken into account as well as the distinction between threats & opportunities.
At programme level, project & operational risks can therefore:
• Accumulate to a critical mass
• Grow (where the sum of the risks is bigger than the individual parts)
• Reduce (where the sum of the risks is smaller than the individual parts).

42
11.2.10 PROXIMITY
‘Proximity’ reflects the fact that risks will occur at particular times in the future & the
expected value will vary according to when they occur. Whereas an understanding of
a risk’s probability & impact informs management of the priority of a risk,
understanding of a risk’s proximity informs management of its impending urgency.
Knowing the proximity also helps to identify the appropriate response & the required
trigger & timing of the response.

43
11.2.11 PROGRESS REPORTING
Programmes need to monitor the evolution of their overall risk exposure. A progress
report, whether as a separate document or incorporated within other progress
reports, is a useful tool to maintain oversight. Programmes should use progress
reports to monitor overall risk & issue trends across the entire programme, risks at
their own level, aggregated & escalated projects risk, & key project risks if required.
A well-defined & maintained progress report is the main control for programmes to
manage their risks & issues.
The programme’s strategies will define how progress reports are composed. Typical
content of a progress report includes:
• Progress of planned risk management action
• Effectiveness of implemented actions
• Trend analysis of closed & new risks & issues
• Spend against contingencies
• Numbers emerging in the different categories

44
This section describes a risk management framework, which comprises a cycle of
steps that are repeated through the life of the programme & additional activities that
apply to each of the steps.The cycle of steps is:
• Identify
• Assess
• Plan
• Implement.
These steps are supported by activities to:
• Communicate
• Embed & review.

45
11.3.1 COMMUNICATE
Rather than being a distinct element, communication is an activity that is carried out
throughout the whole risk management cycle. Effective communication is key to the
identification of new threats & opportunities or changes in existing risks. Horizon-
scanning in particular depends on the maintenance of a good communications
network, including relevant contacts & sources of information to facilitate the
identification of changes that may affect the programme’s overall risk exposure.
The implementation of risk management is dependent on participation, &
participation, in turn, is dependent on communication. It is important for management
to engage with staff across the programme as well as with wider stakeholders.

46
11.3.2 EMBED & REVIEW
‘Embed & review’ ensures risk management is being appropriately & successfully
handled within the programme & across the organization. It should ensure that the
risk management strategy is being followed.
It looks at each individual step of the framework to determine its contribution to the
overall quality or risk management. The use of health checks & maturity models
support organizational efforts to gain maximum value from investment in risk
management.

47
11.3.3 RISK MANAGEMENT CYCLE

48
11.3.3.1 Identify step
Programme risk management starts with the identification of uncertain events
articulated as threats & opportunities. Thus:
Good practice for a first activity is to explore the programme context: understanding
what are the programme’s objectives & scope, what assumptions have been made,
who the stakeholders are, where the programme fits inside the organization & the
current environment. Knowledge of the context enables the programme to search for
risk methodically & later devise the most appropriate responses.
The second activity is the identification of actual risks, both threats to the
programmes objectives as well as opportunities to overachieve on outcomes &
benefits. Once identified, the risks will be entered into the risk register.

49
11.3.3.2 Assess step
The assessment of risk can be broken down into two activities:
Estimate the threats & the opportunities to the programme in terms of their
probability, impact & proximity
Evaluate the net aggregated effect of the identified threats & opportunities on the
programme.
Evaluation is especially important for programmes where individual smaller project
risks can quickly aggregate to a substantial risk at programme level.
The assessment should also help to form a view of the aggregated level of risk that
the programme is facing as it progresses.

50
11.3.3.3 Plan step
The primary goal of the plan element is to prepare specific management responses
to the threats & opportunities that have been identified, ideally to remove or reduce
the threats & to maximize the opportunities. Attention to this process ensures as far
as possible that the business & its staff are not taken by surprise if a risk
materializes.
For each risk that has been identified & appropriately assessed, the project or
programme has a series of responses available that it can use individually or in
combination to deflect a threat or help to realize an opportunity

51
1.3.3.4 Implement step
The primary goal of the implement element is to ensure that the planned risk
management actions are implemented & monitored as to their effectiveness, &
corrective action is taken where responses do not match expectations.
An important part of this is to ensure that clear roles & responsibilities are allocated,
so that someone is responsible for the management & control of the risk, & that risk
actionees are identified to implement the response action allocated to them. The key
roles are:
Risk owner Responsible for the management & control of all aspects of the risks
assigned to them, including managing, tracking & reporting the implementation of the
selected actions to address the threats or to maximize the opportunities
Risk actionee Responsible for the implementation of risk response actions. They
support & take direction from the risk owner.

52
Issues can occur at any point from the launch of the programme at the beginning of
Identifying a Programme to when the programme closes. Some issues may be
unresolved at the end of the programme, & responsibility for these may need to be
transferred to operational management.
The governance arrangements for managing issues are developed & approved in
Defining a Programme. These are documented in the issue management strategy.
During Defining a Programme, issues are managed according the governance
arrangements that are part of the programme preparation plan, which is produced &
approved in Identifying a Programme.
11.4.1 Issue definition
11.4.2 Issue management strategy
11.4.3 Issue register

53
An issue is a relevant event that has happened, was not planned & requires
management action. The action required may be to fix a problem or to change the
boundary of the programme. An issue generally emerges from one of a number of
sources, for example:
• Constraints identified at the outset of the programme
• Within the programme itself
• In operational areas to be changed by the programme, where these have a
consequential impact on the programme
• From an escalation of a programme’s constituent projects
• As generated by stakeholders
• Other sources external to the programme (e.g. changes to corporate strategy or
conflicts with other concurrent change initiatives)..

54
Issues that occur in a project may need to be escalated if they fall outside the
project’s tolerance levels set by the programme. Issue management in a programme
needs to cover all of these circumstances.
A common cause of overload in a programme is when it tries to manage the project
issues directly & does not effectively manage escalation & delegation. However, the
programme manager does need to be satisfied that the project teams are managing
issues to a satisfactory standard & that the aggregated impact on the programme
from all issues in all its projects is understood & acceptable.
Issues can typically be classified into one of the following three types:
• A previously identified risk that has now materialized & requires appropriate issue
management action
• A request for change to some aspect of the programme, an operation or a project
• A problem affecting all or part of the programme in some way.

55
11.4.2 Issue management strategy
The issue management strategy describes the programme’s approach to issue
management & is similar to the way risk management is described in the risk
management strategy.
The issue management strategy outlines how issues will be identified, categorized,
severity-rated & then managed, & how change control will be applied, & it includes
any specific reference to other strategies that support it.
The issue management strategy should contain clear guidance on how issues will be
managed across the programme, projects & operations. This will require clear routes
through which issues can be escalated to the programme or delegated from the
programme to projects or operational areas.
A key element to be defined by the issue management strategy will be the change
control procedures. One of the dangers faced by a programme is the lack of control
of minor changes that may happen at project or operational levels & which may seem
inconsequential in themselves. These can aggregate & eventually deliver significant
deviation from what is needed to fulfil the requirements defined in the blueprint,
undermining the achievement of benefits (see section 11.6).

56
11.4.3 Issue register
Issues are recorded in the issue register, which is created in Defining a Programme.
Any existing issues at that time will be stated in the programme brief. The issue
register is similar to the risk register & is a repository that focuses on all identified
issues that have occurred; it includes former risks, if these have materialized. The
shape, content & purpose of this register are defined in the issue management
strategy. Appendix A provides a description of a typical issue register.
The programme office should play a central role in building & maintaining efficient,
effective & consistent operation of issue management. The programme office
manages & coordinates the information & support systems, & provides support &
advice on the issue management cycle.

57
This section describes an issue management framework which is similar to the risk
management framework as it describes a cycle supported by ongoing activities. The
issue management cycle comprises five steps:
• Capture
• Examine
• Propose course of action
• Decide
• Implement.
And the ongoing activities are:
• Monitor & control
• Embed & review.

58
11.5.1 Monitor & control
Issue management actions, like other activities in the programme, need to be actively
monitored & controlled. This is to ensure that:
• The resolution can be achieved within the estimates of time & cost
• The impact on the overall risk profile of the programme is not greater than
anticipated
• The impact on the planned capability is acceptable
• Benefits are not adversely impacted more than estimated in the initial assessment
• Progress or changes in other parts of the programme don’t render these resolution
actions inappropriate
• The impact on the organization’s performance is managed.

59
11.5.2 Embed & review
‘Embed & review’ ensures that issue management is being appropriately &
successfully handled within each programme & ultimately across the organization.
It looks at each individual step of the cycle to determine its contribution to the overall
quality of issue management. Health checks & maturity models can be used to
support organizational efforts to gain maximum value from their investment in issue
management.
A key review point for all aspects of managing the programme is at the end of each
tranche. The results from such reviews & the characteristics of the programme for the
next tranche may mean that the issue management strategy needs to be refined.

60
11.6 Change control
Programmes are inherently about delivering change, but they do not work in isolation,
& changes are happening to the environment they are delivering to all the time. This
can result in changing business requirements, reactions to unplanned events or
failures, & loss of stakeholder confidence, all of which can affect the ability of the
programme to deliver its objectives. There is a particular risk that small changes
across a number of projects may conflict, & because of their apparent insignificance
they may pass through unnoticed. The basic steps of change control Capture the
change & define why it is needed
• Allocate a priority so that the urgency is understood
• Assess the impact across the programme
• Analyse the options & test the potential solutions
• Authorize the resolution that is agreed (which could include no action)
• Implement the change & monitor the effects of the change for deviations from what
is anticipated
• Review the effectiveness & update associated documentation.

61
There are five basic processes involved in programme-level configuration
management:
Planning
Identifying
Controlling
Status accounting
Verifying

62
Planning Based on the blueprint & the organization’s approach to configuration
management, decide what level of configuration management is appropriate for the
programme & plan how it will be achieved. The programme will then set out the
requirements for configuration management that all its projects should adopt.
Identifying This includes all of the programme-level configurations of assets created
during the programme & any dependencies. A system for describing configuration
items must be set up.
Controlling Once the programme definition document is agreed, the configuration of
the programme is baselined. Most programmes will change over time, & it is crucial
that any changes to the configuration are properly version-controlled following
procedures described in the information management strategy. Version control also
includes managing all of the programme’s management information. The programme
should set out how dependencies on external assets will be managed in the event of
external assets being revised. Control over an asset passes to business as usual
when that asset is agreed to be no longer the responsibility of the programme.

63
Status accounting This involves maintaining current & historical information
concerned with each configuration, the configuration items (assets) & all
dependencies – those external to the programme as well as inter-project
dependencies.
Verifying This includes auditing the programme to ensure that there is conformity
between the documented configuration & the actual status of products &
configuration items before delivery to operations. The dependencies are also verified
as part of this audit, as these may have moved over time.

64
11.8.1 Identifying a Programme
11.8.2 Defining a Programme
11.8.3 Managing the Tranches
11.8.4 Delivering the Capability
11.8.5 Realizing the Benefits
11.8.6 Closing a Programme

65
11.8.1 Identifying a Programme
Risk management in this early phase of the programme is focused on identifying &
clarifying ambiguity. The programme brief will include an initial set of programme
risks & issues identified so far. It should also include possible response actions.
Emergent programmes will in addition have to deal with current issues & risks
inherited from its pre-existing projects, & consider them thoroughly during the
identification phase. These will also be described in the programme brief.
By the end of Identifying a Programme, the risks & issues should be summarized in
the programme brief. Failure to recognize key risks or issues at this point could have
a serious impact later.
registers need to be reviewed & updated prior to closure.

66
11.8.2 Defining a Programme
The risk management strategy & issue management strategy are created during this
process. They describe the principles, practices, tools & information that the
programme will use to identify, analyse, monitor & control risk & issues. The risk
register & issue register are set up to record risk & issue information & actions
required. The initial risk & issue entries in the programme brief should then migrate
into their appropriate registers.
This process will include collecting any updates for risks & issues already identified,
& capturing new risks & issues. The decision to continue with the programme will be
influenced by the risks & issues that surround the vision, blueprint, benefit profiles,
programme plan & business case, & risk & issue management supports this decision-
making with vital information.

67
11.8.3 Managing the Tranches
Following the definition of the programme, Managing the Tranches implements the
defined governance arrangements for risk & issue management. Active management
of risks & issues continues through every tranche with both risk & issue cycles active,
with an assessment of the management processes effectiveness being part of each
end-of-tranche review. The key focus of the management will be managing the
aggregated risk exposure, monitoring for early-warning indicators of trouble &
maintaining alignment of the programme & any threats to its achievement. The
proactive & pragmatic resolution of issues will help to keep tranches on track. It is
unwise to let issues sit unactioned on the issue register.

68
11.8.4 Delivering the Capability
The programme provides the individual projects with their initial brief. This should
include guidance on risk & issue management, which will pre-determine how a
project will operate & interact with the programme.
Projects have to pay particular attention to the escalation rules established by the
programme & to report any risks & issues that could have potential cross-programme
or aggregated effects. The programme must pay attention to aggregated risk &
issues, as the total impact of all risks & issues in the programme & its projects can be
greater than the sum of their individual parts.
Risks & issues are most likely to be the source of the majority of escalations to the
programme & cascade down to projects during delivery, as they will affect the
achievement of project objectives & the business case.

69
11.8.5 Realizing the Benefits
The purpose of risk & issue management is to help avoid failure. Should any of the
tranches deliver below expectation, then this constitutes an issue for the following
tranches & needs to be managed accordingly.
During the three stages of this process – pre-transition, transition & post-transition –
risk & issue management provides the BCM(s) with the means to anticipate &
manage any deviations from the expected benefits realization progress. Any
unforeseen events or changes in circumstances can pose a risk to benefits
realization.

70
11.8.6 Closing a Programme
Programmes close for two fundamental reasons:
The programme has successfully achieved its set end goals
It is not sensible to continue with the programme because one of several possible
circumstances has occurred.
When a programme is closed prematurely without having achieved its goals, this is
often caused by major issues or risks which the programme cannot effectively
overcome. As soon as it becomes evident that the programme might significantly fail
to achieve the outputs, outcomes or benefits that it was launched to deliver, it is
sensible to consider closing it. Risk & issue management will contribute to the
necessary evaluation of the situation & analysis of possible response options.
Whatever the reason for Closing a Programme, the risk & issue management
strategies & respective registers need to be reviewed & updated prior to closure.

71
11.9 The key roles
weight good 74.5
Role Area of focus
SRO Authorizes the risk management strategy & issue management strategy & its
adjustment, improvement & enforcement
Intervenes to control risks & issues that affect the alignment of the programme
with organizational objectives
Initiates assurance reviews of risk & issue management effectiveness
Ownership of strategic risks & issues, ensuring mitigation actions are dealt with
at the appropriate senior level

72
11.9 The key roles
weight good 74.5
Role Area of focus
Programme
manager
Develops & implements the strategies for handling risks & issues
Designs & manages the risk & issue management cycle
Manages the aggregated level of risks & issues
Assures programme adherence to the risk management principles
Allocates risks & issues as appropriate
Ensures that change control is undertaken by individuals with the correct
authority
Ensures that the impact of individual & aggregated risks is understood by the
relevant stakeholders.
Defines clear rules for escalation, cascade & thresholds
Ownership of programme-level risks & issues
Deploys a consistent language for risk management across the programme &
its projects
Communicates the progress of the resolution of issues in a clear & timely
fashion across the programme
Escalates items that cross programme boundaries to the SRO for resolution
where necessary
Designs & implementation of the configuration management system

73
11.9 The key roles
weight good 74.5
Role Area of focus
Business
change
manager(s)
(BCM
Manages & coordinates the resolution of risks relating to operational
performance & benefits achievement
Ensures that the risk management cycle includes operational risks
Manages risks that impact on business performance & transition
Identifies operational issues & ensures that they are managed by the
programme
Identifies opportunities from the business operations & raises them for inclusion
in the programme
Contributes to impact assessments & change control
Monitors & reports on business performance issues that may require the
attention of the programme during transition

74
11.9 The key roles
weight good 74.5
Role Area of focus
Programme
office
Manages & coordinates the information & support systems to enable efficient
handling of the programme’s risks & issues
Maintains the programme risk register
Maintains the programme issue register
Establishes, facilitates & maintains the risk management cycle
Establishes, facilitates & maintains the issue management cycle
Provides support & advice on the risks & issues to projects
Coordinates risk & issue management interfaces with projects
Maintains the configuration management system
Facilitates the change control steps

75
12 Quality & assurance mgment
12.1 Introduction
12.2 Quality in a programme
12.3 Assurance management in a programme
12.4 Quality & assurance management within transformational flow
12.5 The key roles

76
12.1 Introduction
The purpose of quality & assurance management is to ensure that all management
aspects of the programme are working appropriately & that it stays on target to
achieve its objectives. If a programme does not apply quality & assurance effectively
to its management activities, then it is less likely to achieve its objectives & deliver
the anticipated value & benefits.
Quality & assurance are defined as follows:
Quality is defined as the totality of features & inherent or assigned characteristics of
a product, person, process, service and/or system that bears on its ability to show
that it meets expectations or stated needs, requirements or specification.
Assurance is the systematic set of actions necessary to provide confidence to the
senior responsible owner (SRO) & stakeholders that the programme remains under
control & on track to deliver & that it is aligned with the organization’s strategic
objectives.

77
The programme’s approach to quality is set out in the quality & assurance strategy.
Quality in a programme is about identifying the right things to do, & doing them
correctly. It is principally focused on process effectiveness, much of which is set out
in the programme governance strategies.
12.2.1 QUALITY & THE PROGRAMME MANAGEMENT PRINCIPLES
The programme management principles describe the characteristics of a successful
programme & act as critical success factors that apply to all programmes. Therefore,
application of & adherence to the principles is essential for the programme to achieve
a successful conclusion. To this end, the principles act as the focal point for
establishing the critical things that the programme must do to be successful, & quality
management makes sure that the programme is doing the right things to assure their
achievement.
When planning for quality in the programme, the principles should be at the heart of
the areas to be assured, as they represent the factors that will underpin whether the
programme is successful or not.

78
12.2.2 SCOPE OF PROGRAMME QUALITY
Whereas the programme principles set out the areas that are critical to the success
of a programme, the scope of quality is broader. In this section, eight process areas
are identified that require management review of their effectiveness in supporting the
achievement of the programme objectives.
A number of these processes are covered as part of the MSP governance themes &
associated strategies; however, these are areas of particular importance that can cut
across a number of themes & strategies, which is why they are being emphasized
here in their own right. This is not an exhaustive list, but it provides useful scope for
setting out the programme strategy for quality.
The emphasis is on management for all the topics, because good management
requires good processes to be in place. The one exception is programme
leadership, which is relevant across all the management areas.

79
12.2.2 SCOPE OF PROGRAMME QUALITY

80
12.3.1 ASSURANCE MANAGEMENT PRINCIPLES
If the SRO & stakeholders are to gain confidence that the programme is on
track, then assurance management will have to demonstrate that it has
followed an approach that is: independent of the programme; integrated
across the programme; linked to major decision points; risk-based; & results
in action as necessary. Such an approach should be based on the following
five assurance management principles.
12.3.1.1 Independence
12.3.1.2 Integrated
12.3.1.3 Linked to major decision points
12.3.1.4 Risk-based
12.3.1.5 Action & intervention

81
12.3.1.1 Independence
The expectation is that assurance will have a level of independence from
that which is being assured. Assessors should have no direct line
management of the programme team. They should be disinterested in, &
have no control over, project outcomes or service operations.

82
12.3.1.2 Integrated
Integrated assurance is the planning, coordination & provision of assurance
activities from the start of the programme through to delivery of benefits in a
way which provides greater assurance with less effort. This is achieved
through the provision of an agreed plan which will indicate how assurance
reviews of all types will be scheduled to support decision-making & inform
investment approvals, while avoiding duplication of activities that do not add
value.

83
12.3.1.3 Linked to major decision points
Assurance activity should be planned to support major events, outcomes,
tranche ends or key approval points (e.g. funding decisions) throughout the
end-to-end transformational flow from mandate through to the realization of
benefits.

84
12.3.1.4 Risk-based
Assurance activity should be:
Based on an independent risk assessment
Focused on areas of greatest risks to commercial, legal, regulatory,
investment & performance requirements
Cognizant of specific areas of financial, delivery, technical, social, political,
programme, operational & reputational risks.

85
12.3.1.5 Action & intervention
Assurance is most effective when appropriate follow-up actions are taken to
resolve any serious issues identified through planned assurance activity.
These consequential assurance activities may involve further reviews, e.g.
reviews of action plans, case conferences or more detailed reviews to
ensure that appropriate action has been taken. This process should also
include clear escalation routes that may be used if appropriate to the highest
organizational levels for resolution of issues.

86
This section covers how the quality & assurance management governance theme
is applied in each of the processes in the transformational flow. Quality & assurance
management will accompany a programme throughout its life. As each process in the
flow follows on, a balance needs to be struck between over-engineering solutions &
cutting corners. Quality management provides the yardstick against which to
measure how acceptable the programme’s outcomes will be. Quality assurance
provides a consistent & documented method of checking whether the programme’s
processes are adequate to the task of meeting the targets set on the yardstick.

87
Organizations initiate programmes in support of corporate strategic drivers for
change. It is vital that these drivers are appropriately identified & understood at the
earliest stage. The programme should specify its assurance approach & the critical
success factors within the programme mandate. The programme brief is the first
indication of whether the programme has understood its remit & is setting up to
deliver the quality expected from it. During this phase the SRO & programme board
are appointed – key organizational resources that will influence the viability of the
programme.
There should be independent assurance of the programme brief & the programme
preparation plan.

88
Quality considerations are a key driving force behind this process. Corporate policies
must be investigated & considered when developing the individual strategies. These
strategies define how the programme will manage itself. They describe the
management quality that the programme aspires to.
All the vital, initial directional decisions for the programme are made during this
process. It will become increasingly more difficult to turn around a programme later if
required, & utmost emphasis should hence be placed on quality. There should be an
extensive formal review of the programme prior to approval to proceed into Managing
the Tranches. Consideration should also be given to a review once the blueprint,
benefits & projects dossier have stabilized & the direction & impact are emerging.
It is during this process that the strategies & then plans for both quality & assurance
& for information management are created.

89
Managing the Tranches requires embedding quality in the processes, tools &
techniques that are described in the individual strategies being implemented. Quality
& assurance measures are applied to the programme & regular audits and/or gate
reviews are conducted as planned & appropriate. The production of adequate
information is vital to monitor & control the programme; & communication with
stakeholders becomes key to steering expectations & preparing for benefits
realization.
Assurance reviews must be carried out as scheduled in the quality & assurance plan,
& these should include reviews of the performance of internal & external partners.
The end-of-tranche review provides an opportunity for an extensive formal review
prior to commitment to further investment. Within Managing the Tranches many of
the activities could be review points.

90
Projects are set up to deliver the outputs required to enable programme outcomes.
For this, projects follow their own strict quality regime, focusing on product quality.
Programme quality, focusing on management & outcome quality, needs to assure
that projects deliver products that are adequate to meet the programme’s objectives.
It is during this process that programmes will regularly engage with suppliers.
Appropriate integration of suppliers into the programme organization, clear
definition & management of responsibilities, exchange of information &
communication with suppliers are activities which require the input of quality
management.
The integrated assurance approach should ensure that a regime is in place to cover
the programme & its projects, which is likely to include a gated review process for
the larger projects.

91
During pre-transition there needs to be a focus on assurance that the business is
preparing for & is ready for change during transition; that the transition will be
handled optimally; and, critically, that the post-transition activities to embed the
change & realize the benefits are actually happening.
The focus of quality & assurance reviews tends to be on project & programme
performance. However, a regular cause of failure to achieve benefits is the lack of
readiness of the organization to change; its inadequate review of preparations for
transition; & its inability to re-stabilize & exploit the capability afterwards.

92
Closing a programme engages quality management primarily from a review
perspective. Formal reviews should be set up to look at whether the programme has
achieved its objectives & if not, why not: there may be very good reasons.
Specifically, the strategies & plans for both quality & assurance & for information
management should be reviewed & updated.
More generally, it should ensure that all programme documentation & information is
updated & transitioned in accordance with the information management strategy. It
will give adequate feedback on how corporate policies were applied in the
programme & suggest any improvements if required.

93
12.5 The key roles
weight good 74.5
Role Area of focus
Senior
responsible
owner
(SRO)
Consults with sponsoring group on approach to programme assurance
Ensures that an adequate assurance regime is in place for all aspects of
quality in the programme
Signs off of the quality & information management strategies
Initiates assurance reviews & audits
Maintains focus on the programme management principles

94
12.5 The key roles
weight good 74.5
Role Area of focus
Programme
manager
Develops & implements the quality & assurance strategy, plans & then
coordinates delivery of outputs from the projects that are fit for the purpose
of achieving the desired outcomes & benefits
Develops & implements the information management strategy & plan
Initiates assurance reviews of project & supplier performance
Ensures that lessons learned are implemented

95
12.5 The key roles
weight good 74.5
Role Area of focus
Business
change
manager(s)
(BCM)
Implements transitioning, realizing & reviewing of benefits from the outputs of
the projects
Initiates assurance reviews of business performance & change readiness
Ensures that business change lessons learned are implemented

96
12.5 The key roles
weight good 74.5
Role Area of focus
Programme
office
Establishes & maintains the programme’s quality & assurance plan & ensures
the establishment of the appropriate audit, assurance & review processes for
the programme in accordance with the quality & assurance strategy
Establishes & maintains the programme’s information management plan &
ensures the establishment of the appropriate audit, assurance & review
processes for the programme in accordance with the information
management strategy
Provides information to support assurance reviews

97
13.1 Introduction
13.2 Collaboration with themes & principles
13.3 Structure of the transformational flow chapters

98
13.1 Introduction
MSP programmes are all about delivering transformational change. This part of the
guide looks at how the transformation is achieved through a series of iterative,
interrelated steps. The transformational flow through an MSP programme with the
main processes & key control documents involved in delivering an MSP programme
is below. Each process may require more than one iteration before the next one
begins. This is particularly true for the Delivering the Capability & Realizing the
Benefits processes, as programmes often deliver their change through more than
one tranche.

99
13.1 Introduction
Typically, the programme mandate pulls together the high-level, strategic objectives
of the programme from the organization’s strategic drivers & relevant policies, plus
the outline vision statement. This summary of the objectives is then developed into
the programme brief.
Not all programmes start at the beginning of the process with a strategy/policy-
driven mandate. Some programmes emerge as a result of a better understanding
partway through the project(s) lifecycle :
• The organization may discover a proposed change is bigger & more complex than
originally thought, & decide that it should be converted into a programme to give a
better chance of success.
• It may become apparent that several projects are trying to achieve similar changes
to the same part of the organization, resulting in duplication & conflict. Combining
the projects into a programme may well achieve focus & synergy, solve the
duplication & conflict, & maximize benefits.

100
13.1 Introduction
For emerging programmes, entry to the programme process is now much more than
just a mandate. Consideration needs to be given to what has been achieved so far in
each project, what will continue, & what will need to be stopped.
The approved programme brief is the key input to the process of Defining a
Programme. It provides the basis for development of the:
• Programme outcomes & benefits
• Plans/schedules
• Control framework.
This document requires formal approval by the senior responsible owner (SRO) &
sponsoring group before the programme moves into the next part of the flow,
Defining a Programme.

101
13.1 Introduction
The programme definition document can be used to assemble & summarize all of this
information into one document. Programmes often produce substantial volumes of
information during Defining a Programme, & the programme definition document can
be useful for busy executives who only need an overview. As a form of consolidated
summary, it can help to prepare the sponsoring group so that they are adequately
informed before they are asked to authorize the programme.
The programme management strategies created in Defining a Programme are
established in Managing the Tranches by implementing the associated plan. The
programme definition, governance framework & plans are the basis for Delivering
the Capability & Realizing the Benefits.

102
13.1 Introduction
Early governance arrangements are developed in Identifying a Programme as part of
the programme preparation plan for Defining a Programme, to manage & control the
work in that process. They are developed further in Defining a Programme for
Managing the Tranches. As the programme progresses, especially at the end of
each tranche, it reviews the effectiveness of its governance arrangements & the
continued viability of the programme’s business case. As the programme moves to
later tranches, its characteristics might change. For these reasons, governance
arrangements are often refined as part of the preparation work for the next tranche.
The projects & activities are grouped into tranches. Each tranche delivers a step
change in capability after which benefits realization can be assessed. The activities
of Delivering the Capability & Realizing the Benefits are carried out for each tranche.

103
13.1 Introduction
The end of each tranche provides a major assurance review point at which the
programme can be formally assessed in terms of its progress towards achieving the
desired outcomes & measurable realization of benefits. Whilst all programmes
should have clear vision, the precise route to that vision is often not clear early in the
programme. Early tranches might be dedicated to exploring options & discovering a
successful route to the vision.
A tranche formally comes to an end when the new capability has been delivered,
transition is completed & the outcomes have been achieved. At this point there is
formal authorization to continue with the programme into the next tranche. It also
provides a critical stop/go decision about whether the programme is still valid &
continues to meet the strategic needs of the organization. The programme principles
‘remaining aligned with corporate strategy’ & ‘designing & delivering a coherent
capability’ are particularly relevant at this point.

104
13.1 Introduction
Throughout the programme, monitoring progress & the external environment
provides continual assessment of crucial questions such as
• Are we still on track?
• Are the benefits still achievable?
• Is the business case still valid & relevant?
• Do we need to change anything to realign the programme, based on lessons
learned so far, or because of changes external to the programme, such as
strategy?
Closing a Programme is done after the blueprint is delivered, when the capabilities
required to achieve the vision statement have been implemented, & sufficient
benefits have been realized to:
• Objectively judge whether the programme was successful
• Be confident that the full benefits of the programme will be delivered in the
business-as-usual environment.

105
13.1 Introduction
Further reviews may be required following closure to assess & measure the
continuing realization of benefits. These reviews should be initiated by the business
change managers (BCMs), as the programme team will have been disbanded. If the
programme was part of a corporate portfolio, the portfolio office may take over this
responsibility.
Programmes close for many different reasons that can be considered from the
following six groups:
Planned closure because the programme has completed all planned work within its
scope
External environment changes dramatically & unexpectedly render the programme
invalid & therefore it needs to close prematurely
Strategy changed by the organization for internal reasons, not because of external
environment changes; this renders the programme invalid & therefore it needs to
close prematurely

106
13.2 Collaboration with themes & principles
The governance themes in this section of this guide are used at specific points in the
transformational flow & are illustrated at the end of the governance theme chapters.
Within the transformational flow chapters, the governance themes are regularly
referenced. Integration of the governance themes into the transformational flow is
essential for understanding programme management & delivering effective
programmes.

107
13.3 Structure of the transformational flow chapters
There is a Section or each of the MSP transformational flow processes, with a
diagram at the start of each chapter summarizing inputs, activities, outputs, controls
& roles. Typical responsibilities are summarized in a RACI table at the end of each
chapter. These need to be adapted & extended for each programme.
In the RACI tables, the sponsoring group is only referenced in the Identifying a
Programme section. This is because once the SRO is in place, that person is
accountable for the programme but would be consulting & gaining endorsement
from the sponsoring group on a regular basis.
The RACI tables are a simple way of seeing what level of responsibility each role
has. The headings stand for:
• Responsible
• Accountable
• Consulted
• Informed.

108
14.1 Introduction
14.2 Sponsoring the programme
14.3 Confirm the programme mandate
14.4 Appoint the SRO & programme board
14.5 Produce the programme brief
14.6 Develop the programme preparation plan
14.7 Independent review
14.8 Approval to proceed
14.9 Responsibilities

109
14.1 Introduction
The concept (corporate strategy, initiative, policy or emerging programme) & the
resulting vision that is driving the change generate the programme mandate – the
trigger for initiating the overall programme management process. The signing-off of
the programme mandate allows the Identifying a Programme process to begin, where
the programme brief is developed. Identifying a Programme is typically a short
process, perhaps taking only a few weeks or less, which turns the idea into a tangible
business concept.
The programme brief defines the outline vision, expected benefits, estimates of costs,
timescales & risks, allowing:
• Clarification of what can be achieved, & the desired benefits
• A management decision to be made on whether the programme is desirable &
appropriate
• Commitment to the investment & resources required to proceed to the next
process of Defining a Programme, as set out in the programme preparation plan
• Confirmation that the change should be managed as a programme

110
14.1 Introduction

111
A programme requires initial & ongoing top-level sponsorship to gain & maintain the
necessary commitment to the investment, resources, timescales, delivery &
operational changes that will be involved. Those senior executives who are
responsible for delivering the strategic objectives or policy requirements form the
programme’s sponsoring group. The sponsoring group provides the programme
mandate.
The sponsoring group is made up of those senior executives who:
• Have a strategic interest in the programme
• Have responsibility for the investment decision-making
• Will be significantly impacted by the programme
• Will be required to enable the delivery of the change.

112
Each member of the sponsoring group should:
• Clarify their perspective on the programme & particular interests
• Define the levels of engagement support they will be able to give to the
programme
• Confirm their acceptance of, & commitment to, their roles & the programme.
Undertaking stakeholder analysis is necessary to understand who:
• Will be most impacted by the programme
• Can provide useful input when considering the composition of the sponsoring
group.
The sponsoring group may be formed in any number of ways. It may be that the
senior responsible owner (SRO) has already been nominated & takes a lead in
forming the sponsoring group; alternatively, in some organizations where portfolio
management has been adopted, the sponsoring group may be a corporate portfolio
board, where a number of SROs sit.

113
The programme mandate should articulate to the SRO (and the individuals who
develop the programme brief) the direction, constraints, priorities & aspirations for the
programme. This information sets the scene for a controlled start-up for the
programme & should be confirmed at its outset. The programme mandate will set out
what will constitute success for the programme, identify these items as critical
success factors, & outline the assurance regime that will be adopted to ensure that
the programme achieves these.

114
The programme mandate may be a documented output from corporate strategic
planning or policy development. However, it may not initially exist as a single,
cohesive document. In this case, the information for the programme mandate will
need to be drawn together into a single document derived from:
• Facilitated workshops
• Interviews & discussions with:
• The sponsoring group
• Key stakeholders
• Members of the organization’s executive
• Senior management teams.
The consolidated programme mandate is reviewed & confirmed by the sponsoring
group.

115
The SRO will be personally accountable for the programme’s success. The SRO, a
peer & member of the sponsoring group, should be the individual with the most
appropriate & relevant authority, credibility, experience & skills to lead & direct the
programme.
The individual should be appointed by the sponsoring group at the earliest
opportunity to be a focal point for the programme, providing leadership & direction,
& bringing clarity where possible. It may well be that the SRO is already in place as a
result of an executive decision, so in this case it will be simply a matter of
endorsement.
A specific role definition should be prepared for the SRO, approved by the
sponsoring group, & then the SRO should confirm understanding & acceptance of
the role. Large programmes may impose a workload on the SRO that is too great; in
such cases the SRO can be assisted by other persons with appropriate expertise.

116
This role definition should be included, with the other role definitions, as part of the
organization structure document created during Defining a Programme; however, it is
important that the SRO accepts & has clarity about their brief. This also applies to
other programme board members & those to be appointed later.
The SRO will appoint & chair the programme board, which should be formed now to
give the business early involvement & establish governance. It will undoubtedly
evolve if the work to define the programme moves forward.
The terms of reference for the programme board should be drafted when it is
initiated. See Chapter 4 for details of roles that should be covered by the programme
board & examples of the responsibilities.
A small team may be appointed to assist with producing the programme brief & the
programme preparation plan. It is important to identify & involve the likely
programme manager & business change manager(s) (BCM) during this step if at all
possible; if it is too early for this, then individuals with the skills & knowledge to
perform these roles should be used in these initial stages.

117
14.5 Produce the programme brief
The programme brief provides the formal basis for assessing whether the proposed
programme is viable & achievable. Using the programme mandate, the programme’s
specific objectives, required benefits, potential risks, outline costs & timescales are
defined. Options for delivery can also be developed.
It should restate ‘where we are now’, refining & expanding the input from the
programme mandate. The assumptions about ‘where we will be at a defined point in
the future if we do nothing’ should be re-examined, especially if some time has
passed since the organization’s strategy was approved.
All those involved in the programme will need to gain a summary understanding of
the current change initiatives, identifying:
• Areas of potential overlap that may give rise to duplication or conflict
• Conflicts where activities in one initiative may diminish the outcomes of another
• Gaps where there are no (or insufficient) activities.
• They also need to ensure that all these areas are directly related to the strategic
objectives in the programme mandate.

118
Defining a Programme involves the detailed planning & design of all aspects of the
programme. A programme preparation plan for this work is produced, so that the
sponsoring group are fully aware of, & willing to commit to, the cost, time &
resource that will be required in the next part of the programme.
It is essential to plan sufficient time & resources, & to identify individuals with the right
skills & experience, for the development of a detailed programme definition
document.
At this point in the life of a programme there will be much uncertainty & ambiguity
over the detail of what the programme will involve. Planning sufficient time &
resources for Defining a Programme will help to clarify & reduce this uncertainty &
ambiguity. The programme preparation plan will explain how the governance themes
will be applied to manage the expected complexity of Defining a Programme.

119
During Defining a Programme, specific skills may be required – for example, market
knowledge, procurement, technology or property expertise; in particular, consider the
resources that will be required to develop the blueprint. This requirement should be
identified in the programme preparation plan.
A key element of the programme preparation plan should be an explanation of how
assurance will be applied during the often long & complex Defining a Programme
process, when stakeholder engagement, in particular, will be very important.
The programme preparation plan will set out the governance arrangements,
resources & anticipated timetable for the delivery of the Defining a Programme work.

120
14.7 Independent review
It is highly advisable to conduct an independent formal review of the programme brief
to assess the scope, rationale & objectives of the programme. The review should
assess the extent to which the organization(s) involved have the capacity & ability to
deliver & realize the expected benefits. The reality, impacts, possible mitigations of
identified risks & assumptions should be challenged.
Who will be involved & how the review will be conducted should have been outlined
in the assurance arrangements in the programme mandate. For UK public sector
programmes, this may take the form of an OGC Gateway review 0. The assurance
arrangements for this review should be defined in the programme mandate.

121
The programme brief & programme preparation plan set the context & direction for
the programme during Defining a Programme.
Formal approval of these means that:
• The SRO confirms that the programme meets the business requirements
• The programme board commits to supporting delivery
• The sponsoring group authorizes & commits to resource & support the SRO to
undertake the process of Defining a Programme as specified in the programme
preparation plan.
This approval is based on a confirmed understanding of, & commitment to, the
proposed programme’s vision, & the preliminary view of its expected benefits, risks,
issues, timescales, resources & costs. There must be clear justification for the
investment of resources in the programme, including:
• Estimated benefits outweighing the sum of costs & dis-benefits
• The expected outcomes & end state outweighing the expected risks & challenges.

122
Flow steps Sponsoring
group
SRO Programme
manager
BCMs Programme
office
Sponsoring the
programme
A
Confirm the
programme mandate
A
Appoint the SRO &
programme board
A
Produce the
programme brief
A R R
Develop the
programme
preparation plan
A R R
Independent review A R C C
Approval to proceed A R C C

123
15.1 Introduction
15.2 Establish the infrastructure for Defining a Programme
15.3 Establish the team to define the programme
15.4 Identify & analyse the stakeholders
15.5 Refine the vision statement
15.6 Develop the blueprint
15.7 Develop the benefit profiles
15.8 Model the benefits & refine the profiles
15.9 Validate the benefits
15.10 Design the projects dossier
15.11 Identify tranches
15.12 Design the programme organization
15.13 Develop the governance arrangements
15.14 Develop the programme plan
15.15 Develop & confirm programme business case
15.16 Consolidate the programme definition
15.17 Prepare for first tranche

124
15.1 Introduction
The Defining a Programme process provides the basis for deciding whether to
proceed with the programme or not. This is where the detailed definition & planning
for the programme is undertaken. The programme brief is used as the starting point
for developing the programme definition information in more detail.
The business case & governance for the programme will now be developed. The
governance defines the strategies for quality & assurance, monitoring & control,
information management, stakeholders, risks & issues, benefits & resources. The
various programme approaches are contained in the strategies, & plans & schedules
are developed to provide information on the resources, dependencies & timescales
for delivery of capability & realization of benefits. This framework will be further
developed & applied in Chapter 16 (Managing the Tranches).
The inevitable trade-off between resources, costs, quality, timings & benefits requires
agreement between the sponsoring group & senior responsible owner (SRO). At
the completion of Defining a Programme, formal approval is required from the
sponsoring group & SRO to proceed with the programme.

125
15.1 Introduction

126
15.2 Establish the infrastructure for Defining a Programme
It is important to establish a programme infrastructure at the beginning to give the
team the means to successfully conduct the necessary activities. This infrastructure
might cover items such as:
• Office accommodation
• Configuration management
• Software tools
• Computers & other office equipment.
At this stage in the programme the information volumes are relatively small. As
Defining a Programme progresses, these volumes will increase significantly. Many
documents produced in this process are dependent on information in other
documents.. Document content will be frequently changing as the programme is
designed & prepared. It is essential to have a mechanism to keep these co-
dependent documents synchronized, otherwise the programme team & stakeholders
may be misled. Configuration management facilities & processes provide this control
& are an important tool in establishing an effective infrastructure.

127
15.3 Establish the team to define the programme
The SRO will typically require the support of a small team. The programme
preparation plan produced in Identifying a Programme is used to identify the skills &
resources, & select & appoint the team.
The team will need appropriate skills, knowledge & experience in areas relevant to
the programme & its management. Members of the team may subsequently fulfil
formal roles, such as programme manager or business change manager (BCM),
within the programme organization structure. At this point, specialist skills (for
example, business & market analysis) to help with the construction of the blueprint,
benefits or options analysis should be put in place.
For an emergent programme, careful consideration should be given to making best
use of the resources on the current change initiatives relative to the new demands
that the emergent programme will place on these projects. Some of these resources
may be appropriate for the newly defined needs of this programme & others may be
better deployed elsewhere.
Assurance arrangements should be put in place to support & monitor the direction of
the programme.

128
15.4 Identify & analyse the stakeholders
All the programme’s stakeholders (internal & external) should be identified, together
with their particular interest in the programme. It is also important to identify any
stakeholders who are likely to be worse off as a result of the programme, as their
interests & influence may prevent the programme’s successful outcome. The input of
the BCM is critical to identifying operational stakeholders & engaging at an early
stage those who will have a high impact.
The analysis of stakeholders will identify the various information needs &
communication flows that should be established as part of programme
communications. The results of this analysis are contained in the stakeholder
profilescontaining information such as:
• Stakeholder map
• Impact assessment
• Analysis information.
This work needs to be started at the beginning of Defining a Programme, as the
programme team will need to engage stakeholders in these activities.

129
15.5 Refine the vision statement
The outline vision statement contained in the programme brief is refined into the
programme’s vision statement. It provides the basis for communicating &
encouraging the buy-in & commitment from stakeholders.
The purpose is to communicate the transformed, beneficial future state to the
programme’s wide audience of stakeholders. When any organization goes through
transformational change, different stakeholders will not necessarily understand the
big picture without such a vision statement. The vision statement is written as a future
state (not as an objective, trend or mission, all of which are commonly written
beginning with the word ‘To’).
This is an important step as the feedback from initial stakeholder engagement will
provide information on where the vision can be adapted to meet the needs of
different stakeholders & avoid unnecessary conflict, whilst also making courageous
statements that set the agenda for the programme.

130
Developing the blueprint involves many concepts of organizational design. It may
encompass all dimensions of the organization or business – its cultural aspects as
well as its structure, processes & activities – & how they need to change. Business
analysis & design techniques may also be required to explore fully the opportunities
& options for achieving the capabilities described in the vision statement. There are
typically many options for achieving the required changes, with associated costs &
impacts. Exploring these options & assessing the implications on the investment
required is an important aspect for designing the optimum blueprint for the
programme.
Designing the blueprint to realize the required benefits needs to be balanced against
the costs of realizing those benefits. The programme’s business case is developed in
parallel with the blueprint to ensure consistency across the proposed changes to the
organization, the costs of doing the changes & realization of the benefits being
achievable.
The blueprint, benefits maps, projects dossier & programme plan are designed
together, with the emerging business case acting as the moderator.

131
Some organizations have an overall blueprint for the entire business (sometimes
referred to as the ‘target operating model’). In these contexts, where each
programme is briefed to deliver a discrete part of that corporate blueprint, ensure
that work isn’t duplicated elsewhere.
The gap – the difference between the ‘as-is’ & ‘to-be’ organization – will need to be
analysed. It provides a critical input to designing the projects dossier & programme
plan. The blueprint does not normally need to be expressed in detail. It will be the
responsibility of the projects to develop more detailed designs & specifications to
meet the requirements for the ‘to-be’ model. The programme must take responsibility
for the integration & cohesiveness of the project-level designs, assuring that the
blueprint is achieved.
The first benefits maps can be developed from the first cut of the blueprint. They will
need to be enhanced when estimates of the time & cost are available from the
programme plan. The merging of this information into the business case provides the
control to judge if the developing programme designs are good enough in terms of an
acceptable balance between time, cost, risks & benefits.

132

133
The vision statement & programme brief identify the required benefits from the
programme. Each benefit (and dis-benefit) requires a complete definition, known
as a benefit profile.
The total set of benefit profiles provides a planning & control tool to track progress on
the delivery & realization of the benefits. The benefit profiles will be further refined as
the detailed definition of the programme is developed.
Each benefit needs to have a baseline measurement. As the business prepares to
go through the change cycle, it is important for it to understand its starting point. To
do this it will have to establish KPIs that reflect the overall performance of the
organization at this time. The baseline measurement for the benefit may be drawn
from the ‘as-is’ information in the blueprint; the ‘to-be’ information may include the
performance measure which will indicate that the benefit has been achieved.
These indicators will be tracked to assess the business stability during the lifetime of
the programme & the delivery of benefits resulting from the changes being applied.

134
It is tempting for a programme to select indicators that are directly related to the
outcomes that it will enable. However, it is important that a holistic range of relevant
indicators is used for monitoring. It is no use cutting the costs of products if
customers leave because of poor quality, & it is counterproductive to adopt
mechanistic processes that cause creative staff to become disillusioned & leave.
The following should be considered when selecting benefit measure & performance
baselines:
• Some KPIs may not be suitable for measuring benefits.
• Some KPIs may need to be adjusted as a result of operational changes. The
programme may have an obligation to define new KPIs & provide processes &
tools to support them.
• Current KPIs may need to be supplemented by other measures to assess the
benefits realized.

135
15.8 Model the benefits & refine the profiles
The first benefit profiles for end benefits are initially created from information in the
vision statement & the programme brief. As the blueprint is designed, these can be
extended & refined. Benefits maps are initially modelled (driven by the blueprint) &
then extended by information from the projects dossier & programme plan. The mix
of benefits, dependencies on project outputs, & other benefits becomes clearer.
Benefit profiles are refined as a result.
Having too many benefits defined will increase the cost & complexity of achievement;
using the benefit categories will help to rationalize the benefits & identify the priorities
& coherent ways of grouping them

136
15.9 Validate the benefits
A realistic assessment of the inevitable trade-off between the cost of realizing &
measuring a benefit against the value of having that benefit should be made, in order
to avoid wasting time on trying to realize unrealistic benefits.
Each benefit should represent some aspect of the programme’s desired outcomes.
Benefits that are not linked to strategic objectives may actually be unhelpful.
Furthermore, they may distract from achieving the major benefits.
The first validation of benefits is via the test of the emerging business case.

137
15.10 Design the projects dossier
The vision statement, blueprint, benefit profiles & benefits maps provide the basis for
designing the projects & any other activities necessary to deliver the new capabilities.
These projects & activities form the programme’s projects dossier, which represents
the programme’s approach & describes how it will deliver the future organization, the
operation of which will result in the desired outcomes & benefits. It is used as the
basis for developing the programme plan.
There may be different options for achieving improvements to business operations, in
which case these should be explored in terms of timing, content, risks & benefits.
Some projects & activities may be existing ongoing work that will need to be adopted
into the programme as part of the projects dossier; others may be new initiatives that
will require commissioning by the programme at the appropriate point.

138
15.11 Identify tranches
The outcome(s) described in the vision statement & expressed in the blueprint can
rarely be delivered in a single pass, but will typically be reached through progressive
refinements or step changes in the capabilities of the organization. These step
changes can be used to define the ends of successive tranches, where formal
reviews can be carried out.
The projects & activities in the projects dossier are scheduled together showing their
relative timescales & dependencies. The delivery is built into tranches reflecting the
step changes in capability. It may not be possible to define all of the required
projects fully at this point. Further analysis may be required to complete the scoping
of later projects after the results from early tranches have been assessed.
Early in the programme, the route to the vision is often unclear. Early tranches may
be designed to explore & prove (or disprove) different approaches to achieve the
vision. The most valuable output of these types of early tranches will be the
information that enables the sponsoring group to decide whether to continue with
the programme, & if so, to have confidence that the best route has been identified.
Failure to do this will almost certainly result in significant expenditure being wasted.

139
The organization for directing, managing, controlling & supporting the programme
has to be designed. Successful programme delivery requires sufficient resourcing of
the programme & change management activities. The structure must enable effective
decision-making & efficient communication flows among the various members of the
programme team & stakeholders. The nature & size of the programme will influence
the design of an appropriate programme organization. The structure will need to
integrate with, & operate alongside, the existing management structures of the
organization(s). The programme organization should reflect the management levels
appropriate to the visibility & significance of the programme.
Each role within the organization should be defined with its specific accountabilities,
responsibilities & tasks, together with the skills & competencies required. Individuals
with the appropriate skills & experience to take on these roles should be identified. If
they are not available, a plan for acquiring the resources, internally or externally,
should be developed in the resource management strategy.

140
It is often not possible to assemble all the people required with adequate
competencies from internal resources. This must be addressed, perhaps using those
resources with greater skills & experience to coach & mentor others. This situation
should be identified by the programme & project risk analysis. Where the lack of
skills & experience is significant, this must be reflected in the programme plan, to
allow people sufficient time to learn & develop. It may be necessary to supplement
internal resources with external expertise.

141
Many individuals assigned to programme roles will also have operational
responsibilities. Prioritization of workloads is an important consideration. The work
required of each role needs to be balanced against the time the individual is able to
commit. It is important that there is understanding & agreement between the
programme & line managers about:
• How to allocate resource time (from, to, how long, which days of the week,
percentage of working week etc.) to programme or project work
• Who will manage the resource when working on the programme or project
• How conflict will be resolved
• How time will be tracked & accounted for
It may be necessary to procure external resources for the programme, providing
specialist skills & experience to fulfil some of the roles. It is important to remember
that procurement is typically lengthy, & sufficient time & resources should be planned
for procurement. Routes to procure additional resources include secondment,
contracting, delegation or subcontracting the work, & sharing with other initiatives.

142
15.13 Develop the governance arrangements
The programme management governance strategies should cover how the
programme is going to handle the inevitable complexity & interdependencies, & bring
the different aspects together. These strategies must be designed to integrate with
the corporate governance of the organization where this already exists. They are as
follows:
• Benefits management strategy
• Information management strategy
• Risk management strategy
• Issue management strategy
• Monitoring & control strategy
• Quality & assurance strategy
• Resource management strategy
• Stakeholder engagement strategy

143
15.14 Develop the programme plan
The programme plan is developed by bringing together the information on projects,
resources, timescales, risk, monitoring & control. The amount of information
available & the level of detail required will develop as the programme progresses. An
outline programme plan showing the estimated relative timescales for the projects
should be developed at this stage. It should identify where assurance reviews of
progress & benefits realization can be carried out.
It is perfectly acceptable for the programme plan to incorporate & aggregate the
other plans required to implement the governance strategies into the programme
plan where this is optimal.

144
15.15 Develop & confirm programme business case
The business case will have started to emerge in Identifying a Programme &
it is then developed further. This emerging business case is transformed into the final
business case as the arrangements for managing the programme are developed.
The business case brings together information about the programme covering the
costs, benefits, timings & risks so that the overall value for money & achievability of
the programme can be assessed & appropriate management decisions made about
the viability of the programme.
The business case will need to be further refined as the programme proceeds,
especially at the end of tranches where formal reviews objectively judge the success
(or shortfalls) achieved so far.

145
15.16 Consolidate the programme definition
All of the information produced in Defining a Programme can now be consolidated.
This can be produced as a complete set of information, with an executive summary,
or can just be a summary that references the other detailed documents.
The full set of programme information should now have been produced & should be
under configuration management & change control. These are assembled into
information baselines.

146
15.17 Prepare for first tranche
As the programme now has more clarity about the way forward, it can prepare for the
first tranche(s). It is usually not sensible to prepare in detail for later tranches until
near the end of the first tranche, when there will then be greater confidence about the
programme’s approach to achieving the desired benefits. Activities include:
• Prepare to establish the programme’s governance & organization
• Specify the physical environment & infrastructure required for managing the next
tranche
• Develop plans to establish governance & the organization structure.
Similar preparations need to occur as the programme approaches later tranches

147
The programme definition is assembled & the information produced in Defining a
Programme is summarized & consolidated into one document to enable easy
assimilation by stakeholders. Approval to proceed is a four-stage process:
SRO (and programme board) approves: The complete set of documentation
describing the programme, its governance, plans & business case should be
approved by the SRO as suitable to submit for review & formal sponsoring group
approval & authorization.
Sponsoring group endorses: Formal endorsement is sought from the programme’s
sponsoring group to confirm that the programme is designed to meet their
expectations & requirements.

148
Independent review: Reviews may involve independent assurance scrutiny as
defined in the programme assurance arrangements, such as an OGC Gateway
review. An unbiased objective independent assurance review of the programme may
be a contractual obligation in partnership programmes where several organizations
are sharing the investment & the risk & later hope to share the benefits. These may
be internal assurance reviews or, in the case of UK government, they may
additionally be external assurance reviews.
Sponsoring group authorizes the SRO: The sponsoring group must give its
approval on behalf of the organization to proceed with the programme, including
commitment to the investment required for the programme. In many programmes it is
not possible to clarify total investment requirements at the start. In such cases the
SRO obtains further formal approval from the sponsoring group when more
information becomes available or at the end of further tranches.

149
Flow steps SRO Programme
manager
BCMs Programme
office
Establish the infrastructure
for Defining a Programme
A R I C
Establish the team to
define the programme
A R I C
Identify & analyse
stakeholders
A R C C
Refine the vision
statement
A R C
Develop the blueprint A R C C
Develop the benefit
profiles
A C R C

150
manager
BCMs Programme
office
Model the benefits & refine
the profiles
A C R C
Validate the benefits A C R
Design the projects dossier A R C C
Identify tranches A R R C
Design the programme
organization
A R C C
Develop the governance
arrangements
A C R C

151
manager
BCMs Programme
office
Develop the programme
plan
A R C C
Develop & confirm
programme business case
A R C I
Consolidate the programme
definition
A R C C
Prepare for first tranche A R C C
Approval to proceed A R R R

152
16.1 Introduction
16.2 Establish the tranche
16.3 Direct work
16.4 Manage risks & issues
16.5 Control & delivery of communications
16.6 Undertake audits & assurance reviews
16.7 Maintain alignment between programme blueprint & business strategic objectives
16.8 Maintain information & asset integrity
16.9 Manage people & other resources
16.10 Procurement & contracts
16.11 Monitor, report & control
16.12 Transition & stable operations
16.13 Prepare for next tranche
16.14 End-of-tranche review & close

153
16.1 Introduction
The purpose of the Managing the Tranches process is to implement the defined
programme management governance strategies for the programme, ensure that
the capability delivery is aligned to the strategic direction of the organization, &
enable the release of benefits. This accepts that, as the programme progresses, this
will need to be adapted & refined to assure the effective delivery of the tranches &
the final outcomes.
A key principle of the Managing the Tranches process is to maintain the balance
between the rate of change being offered by the Delivering the Capability process &
the rate of change that the operational areas can cope with. This is managed through
the Realizing the Benefits stage which aligns the programme with the evolving &
changing strategic needs of the organization.
Unlike some of the activities in other processes, which tend to happen in a logical
sequence, the activities in Managing the Tranches may recur or happen concurrently.
Most of the activities are linked to the governance themes & are intended to trigger
the cycles that are defined in Part 2. For example, you do not ‘manage risk & issues’
once: this is a day-to-day activity that occurs throughout the tranche.

154
16.1 Introduction

155
16.2.1 PROGRAMME ORGANIZATION
16.2.2 BUSINESS CHANGE TEAM
16.2.3 PROGRAMME OFFICE
16.2.4 SUPPORT FOR GOVERNANCE
16.2.5 PHYSICAL ENVIRONMENT
16.2.6 COMMUNICATIONS

156
16.2.1 PROGRAMME ORGANIZATION
The organization structure for the programme is now implemented, with the identified
individuals appointed. Each role should have a clearly defined set of responsibilities
that the appointed individual has understood & accepts.
Plans should be put into place for development of the ability, capacity & performance
of the team as the programme progresses.
16.2.2 BUSINESS CHANGE TEAM
The programme team delivers the means to change the operational part of an
organization. The operational functions need to receive & effectively use the
outcomes the programme delivers to achieve the benefits. A business change
team represents the interests of the part of the organization to be changed, & will
ensure that those parts are appropriately involved & thoroughly prepared for the
transition. It will be especially active during transition when operational staff will need
to be supported.

157
16.2.3 PROGRAMME OFFICE
The programme office should as provide an information hub for the programme &
may also have skilled resources able to offer consultancy-style specialist assistance
to the programme management team & the projects. The programme office’s
functions & procedures are established & operated throughout the programme. If the
programme office is dedicated to the programme, its lack of independence means it
cannot carry out audits or similar reviews of the programme. Thus arrangements
need to be established with a different body that is independent of the programme to
provide unbiased assessments.
16.2.4 SUPPORT FOR GOVERNANCE
The various governance strategies define the required arrangements, information &
procedures that need to be put in place. The programme office provides support for
the governance requirements of the programme, to enable the programme team to
easily assess the overall state of the programme. The governance strategy plans
should now be activated to establish the governance. The assurance arrangements
should be put in place to ensure that the programme is under appropriate controls

158
16.2.5 PHYSICAL ENVIRONMENT
The physical programme environment, including buildings, office space, office
facilities & services, should be established, as defined in the resource management
plan.
The technology & tools required to support the programme also need to be acquired
& implemented, & staff trained in their use. Typical tools used to support the
programme include: Planning, estimating & scheduling tools, Risk management,
quality & assurance management, financial management & change control tools,
Document management & record management tools, Configuration management
tools.
16.2.6 COMMUNICATIONS
Now that the programme is moving into delivery, there will need to be activities to
raise awareness of the programme & its impact on the organization in the widest
sense. The programme communications plan defines how the programme will inform
the stakeholders about the programme & gives advice on encouraging feedback. The
required mechanisms are set up.

159
16.3 Direct work
This is a catch-all activity, which covers much of the day-to-day work of the
programme manager. Projects and other activities will need to be started according
to the schedules and plans prepared in the Defining a Programme process. Starting
the projects is managed in the Delivering the Capability process but it is triggered
from here; other programme-level management activities that are carried out in this
process include:
• Appointment of project delivery organizations
• Programme risk workshops
• Programme reporting
• Dealing with project exceptions
• Managing the programme and project teams.

160
16.4 Manage risks & issues
The steps in the risk management and issue management cycles will now be
followed. Risks and issues are actively managed (added, assessed, reviewed,
updated and closed) throughout the programme, and the overall risk and issues
profiles continually monitored.
• Managing risks and issues in a programme has three perspectives:
• The programme’s internal risks and issues
• Those that arise outside the programme (e.g. from a change of strategy) and
those that arise from outside the organization (e.g. change of legislation)
• Risks and issues escalated from the programme’s projects and operational areas.
As well as careful monitoring of the programme and its projects, the programme
manager needs a mechanism to scan the environment external to the programme. It
can be useful to get help with this from those who monitor the external environment
as part of their day-to-day role – for example, legal and marketing staff

161
16.5 Control & delivery of communications
Use the programme communications plan as early as possible by notifying the
stakeholders of the individuals appointed to specific roles on the programme.
Thereafter, the communication activities should ensure that the stakeholders are kept
informed and engaged in the work of the programme, its projects and the benefits
expected.
When stakeholders have received new communications, it is important to check that
they have understood them in the way the programme team intended.
Misunderstanding in programmes can give rise to significant problems.
Communications are intended to generate and maintain support from stakeholders.
Communications, formal and informal, will affect how people feel about the
programme. Stakeholders’ attitudes need to be continually assessed, and any
significant decline in attitude will require attention.
It is essential to ensure that feedback channels between the programme and its
stakeholders are working effectively. Stakeholders will often change during the life of
a programme. The stakeholder engagement strategy will provide guidance on how
to detect stakeholder changes and how to assess new stakeholders

162
16.6 Undertake audits & assurance reviews
The programme must ensure that mechanisms are in place to assess the
performance of its processes and projects. These must be used regularly to ensure
that the actual performance is acceptable. Stakeholders will require reassurance of
this, and may initiate an audit to verify and validate progress and performance so far.
These reviews should be extended to the business operations to ensure that they are
preparing appropriately for transition, and once they have undergone transition to
ensure that the new systems and working practices are being embedded and that the
change is established.
This is the transformational flow activity which triggers the activities in the quality and
assurance plan and the strategic approach to audit and integrated assurance

163
16.7 Maintain alignment between programme blueprint & business strategic
objectives
As an organization’s strategy changes, monitoring arrangements should detect
pending strategy changes. An impact assessment should take place, with the results
fed back to the strategy makers. When corporate strategy changes are approved, the
programme may also need to change (possibly including the blueprint, business case
and other dependent documents) to ensure strategic alignment.
Programmes and their projects sometimes drift off course. Regular assurance of
strategy against the blueprint will be needed to maintain the ongoing alignment of the
programme with the corporate strategy. If the programme becomes significantly out
of alignment with the strategy, the consequential impact on the business case can
render the programme invalid and lead to closure.

164
16.8 Maintain information & asset integrity
As projects are started, information volumes will increase significantly. It is vital that
configuration management is in place to track new items and changes to existing
items. Configuration management plays an important role in supporting issue
management by helping to assess the impact of change requests. These activities
link closely with quality activities, the information management strategy and
information plan.
Configuration baselines should be updated at the end of each tranche.

165
16.9 Manage people & other resources
The resource management strategy defines rules of engagement for acquiring and
using resources.
Resources are often shared across programmes, projects and operational work.
Issues can arise if the resource required is not going to be available. A corporate
portfolio office can be helpful here, as it can provide a complete picture of the
utilization of resources and the status of potentially competing activities.
There are critical points in a programme when careful attention needs to be paid to
managing people. As a tranche end approaches, people typically get concerned as
they are soon going to have to change the way they do their work. It might help, for
example, to provide extra support for staff as they prepare for transition and as they
start to take on their new roles and use new systems.

166
16.10 Procurement & contracts
The resource management strategy identifies the requirements for procurement and
contract management within the programme, which are consequently set up as
defined in the resource management plan. Managing suppliers and maintaining the
alignment of their activities with the overall direction of the programme require
specific management attention and intervention if things go off track. Procurement
and contract management activities must be aligned to corporate policies and
standards, and may require tailoring to suit the particular needs of the programme.
As part of this activity, there should be regular scheduled reviews of suppliers and
their performance against expectation and the contract.

167
Arrangements defined in the monitoring and control strategy are implemented and
should be used to control progress. Regular progress reporting from the projects
informs the formal progress monitoring, which keeps the programme on track.
Monitoring progress may identify problem areas requiring management intervention.
These issues should be escalated and actioned as soon as possible to prevent the
programme losing momentum and moving off track.
This is likely to be the primary focus for the programme board, where much of the
progress will be reviewed and issues considered and resolved.
A key aspect of control is ensuring that the blueprint and the delivery of new
capabilities defined within it remain internally consistent and coherent.
The internal control mechanisms are defined within the governance strategies: the
monitoring and control strategy is particularly relevant.

168
The list summarizes monitoring & control activities that are important enough to
warrant the attention of the senior responsible owner (SRO) & programme board:
• Check that information is complete, timely, accurate and relevant for the control
and decision-making it supports..
• Ensure that decisions are contained in the monitoring and control strategy
• Approve major exceptions from projects
• Approve outcome achievements, accepting deviations
• Approve benefits achievements, accepting deviations
• Deal with benefits realization exceptions
• Deal with capability delivery escalations
• Initiate additional activities that will be required as part of Delivering the Capability
• Authorize exceptional communications activities to address stakeholder issues
• Monitor benefits realization, tracking business performance, benefits
achievements and instigating ad hoc benefits reviews.

169
This is particularly focused on the activities in Realizing the Benefits and the progress
towards benefits achievement. It is a key role of the programme board to maintain
focus on transition and organizational stability whilst maintaining momentum towards
achieving the benefits.
Transition plans prepared earlier in the tranche will be activated when the project
outputs have been combined and tested, the capability is ready for transition and
operations are ready to use them, changing their ways of working. Transition can
sometimes be very disruptive, and these plans may need to be very detailed in order
to minimize the impact on ongoing business operations. Consider providing extra
support to people who may be legitimately concerned at this difficult time.
Transition ends when the outputs are implemented and the new capabilities
established. Measurement of the performance of the current state of operations must
have been completed before transition starts. Performance measures should be
tracked during the preparation and during transition and after to make sure that
operations progress to a stable state and do not drift back to the old ways of working.
Such measures are also important during this period to help minimize dis-benefits
and spot opportunities to realize additional benefits.

170
The start of transition is usually a clearly identifiable event authorized by the SRO.
Moving from transition to a stable state is more of a grey area and requires the
judgement of experienced senior management to agree when the outcomes have
been achieved and the post-transition phase begins.
If everything and everyone are not thoroughly prepared, the change to the new ways
of working will take longer and may be less successful. This can produce undesirable
downsides such that:
• Disruption to operations will be more severe, leading to loss of output and/or
quality
• Improvements resulting from the new operations might be less pronounced, and
delivery of benefits will be reduced or delayed
• Operations may revert to the old ways of working and lose faith in the programme.

171
The SRO and the programme board should provide formal authorization to proceed
into transition, and ensure that appropriate criteria are in place for speeding up or
slowing down the transition rate based on the performance of the organization during
this period. Fall-back and contingency plans should be in place if transition takes
business performance outside the forecasted acceptable deviation.
This control encourages the programme team and business change teams to check
that preparations are adequate, and helps to gain commitment from operational staff,
which will be critical during this period.

172
As the programme progresses, there is increasing clarity about the way forward.
This should occur at the end of each tranche. Changes to the programme’s
approach may now be needed as a result of lessons from the tranche now ending, for
example:
• Learning from what this tranche has achieved to inform the next tranche,
especially where the programme is designed for incremental delivery of change
• Adapting governance and the organization structure
• Different skills and experience might be needed; for example if the nature of the
programme is moving from exploratory to more of a roll-out, this should be
reflected in the resource management plan
• Specifying the physical environment and infrastructure required for managing the
next tranche
• Refining and developing the blueprint, benefits maps, benefit profiles and projects
dossier for the next tranche, building on and complementing the change already
delivered by previous tranches
• Reviewing and refining information baselines

173
The programme’s business case will need to be refined as the plans for the next
tranche(s) unfold. The emphasis, as described in Defining a Programme, is to
consider alternative approaches to develop the best business case. Ideally, the
business case should be improved at each tranche end, with the programme
concentrating on change that is working well and reducing that which is not.
The SRO consults with the sponsoring group, who will authorize the start of the
next tranche.

174
Programme information is updated, refined and maintained as the programme
progresses. In particular, this should be done at the end of each tranche, as
preparations for the next tranche need to be informed about what is working well and
areas that need attention or adjustment. Successive refinements to the blueprint will
highlight any adjustments that may need to be made to the projects dossier to keep
the programme on track. The programme plan and benefits realization plan should be
refined when completion and delivery dates from the projects are known.
The end of a tranche is reached when all the capability for that tranche has been
delivered and transitioned into operational use.
At the end of each tranche there should be a full review to assess the ongoing
viability of the programme and ensure that the delivery options and strategy remain
optimal.
The end-of-tranche review provides a go/no-go decision point for the programme: it
should only be allowed to continue to the next tranche if it is still viable. The SRO is
accountable for ensuring that this review is undertaken formally, but will need
authorization from the sponsoring group to support the recommendations.

175
The programme’s business case, benefits and the benefits management approach
must be reviewed at the end of each tranche. The business change manager(s)
(BCM) should plan for at least one review after the tranche has closed, to assess the
realization of post-tranche benefits. The end-of-tranche reviews may also include a
formal assessment of the effectiveness of the programme management activities,
including considering any programme lessons which have been documented during
the tranche.
It may be useful to consider the assessment of benefits from both an internal and
external perspective. The internal perspective will involve measuring reduction in
costs, for example. The external perspective, for example via a programme audit
function, will involve assessing whether the potential for realization of benefits
remains on track and ensuring that all the possible benefit dependencies are
considered.
If the tranche end has been designed to prove whether hypotheses embedded in the
strategy can work satisfactorily, in order to collect and analyse sufficient benefit
measures to reach a conclusion, there may be a planned delay before the next
tranche starts.

176
manager
BCMs Programme
office
Establish the tranche A R C C
Direct work A R I C
Manage risks & issues A R R C
Control & delivery of
communications
A R R C
Undertake audits &
assurance reviews
A R C I
Maintain alignment
between programme
blueprint & business
strategic objectives
A C R I

177
manager
BCMs Programme
office
Maintain information &
asset integrity
A R C C
Manage people & other
resources
A R C C
Procurement & contracts A R
Monitor, report & control A R C C
Transition & stable
operations
A C R C
Prepare for next tranche A R C C
End-of-tranche review &
close
A R C C

178
17.1 Introduction
17.2 Start projects
17.3 Engage stakeholders
17.4 Align projects with benefits realization
17.5 Align projects with programme objectives
17.6 Governance: manage & control delivery
17.7 Close projects

179
17.1 Introduction
The Delivering the Capability process covers the activities for coordinating and
managing project delivery according to the programme plan. Delivery from the
projects dossier provides the new outputs that enable the capabilities described in
the blueprint. The activities of Delivering the Capability are repeated for each tranche
of the programme.
Delivering the Capability and Realizing the Benefits are distinct processes, but they
do work closely together to harmonize the programme objectives with project delivery
and benefits realization through transition to operations. The Managing the Tranches
process is used for overseeing these two processes, providing the high-level
direction, guidance and control.
This process delivers the capability defined in the blueprint through the projects
defined in the projects dossier. The detail in the blueprint provides the input
requirements for the projects, which adopt the strategic requirements and undertake
detailed specification and design to deliver the outputs that create the capability
needed to achieve the outcomes and deliver the benefits.

180
17.1 Introduction

181
17.2 Start projects
The programme manager is responsible for commissioning the projects within the
projects dossier and should ensure that appropriate individuals are appointed to the
key project roles, such as project executive (or sponsor) and project manager. The
project executive is accountable to the programme board for the project’s successful
completion within specified scope, risk, time, cost and quality parameters. Tolerance
levels should be set to enable the project delivery teams to manage minor deviations
independently from the programme.
As each project is about to begin, the programme manager should ensure that each
project management team fully understands the project brief, its context to the
blueprint, tranches and benefits, and the project management standards that must be
observed, as defined in the monitoring and control strategy. This should include
ensuring that the project manager(s) and project executive(s) understand their
contribution to the blueprint and the benefit(s) their project will deliver, or contribute
towards.

182
17.3 Engage stakeholders
Maintaining the engagement of stakeholders and keeping them informed of progress
and issues are important parts of successful programme management. The
cooperation of stakeholders will be needed, as projects in the programme need
specific input. For example, involving stakeholders in requirements analysis,
reviewing designs, user acceptance-testing etc. will give them a better understanding
of the programme, while ensuring that the project’s outputs are designed to reflect
their needs. Their contribution and input can give them a sense of involvement,
leading to better engagement and a more positive outcome.
The programme manager may need to provide guidance on communication events
at times when projects engage with critical stakeholders, and involve the business
change manager

183
The BCM is responsible for ensuring that the particular benefits relevant to each
project can be realized from implementing the outputs from those projects. When
projects are initiated within the programme, the project briefs should be aligned with
the relevant benefit profiles and the benefits realization plan, and be agreed with the
BCM.
Responsibility for ensuring that the projects deliver capability in alignment with the
benefits realization plan lies with the programme manager.

184
The BCM has a key role to play in:
• The alignment of projects
• Ensuring the inputs, business requirements and time constraints
• Providing expertise from operational staff in assessing designs, prototypes and
similar items
• Considering how well these proposals are likely to work in a full-scale operational
environment.
If there is a business change team, then a member of the team may work alongside
or as part of the project board representing the BCM in the day-to-day decision-
making of the project.
The BCM must sign off that the project outputs will provide the capability to deliver
the outcomes and benefits and that the project plan will deliver the capability in a
timely manner to meet the transition arrangement being planned.

185
17.5 Align projects with programme objectives
Aligning projects with programme objectives is a continual activity throughout the
programme for all its projects. For projects started by the programme, the initial
alignment is achieved via the project brief, and maintained through the reporting line
between the projects and the programme.
The sign-off of the project plan by the programme manager should be based on
assessing whether the proposed outputs and capability meet the strategic
requirements from the blueprint and, if the project continues through more than one
tranche, that the management stages are aligned as closely as possible with the
tranche end to ensure that maximum control can be exercised by the programme on
the direction of the project.
The programme manager would seek to ensure that dependencies that have been
identified are understood and managed effectively.
In emergent programmes there will be projects that are already under way. Their
progress and project information (such as the PID, or project initiation document)
should be reviewed by the programme team. Any required amendments, re-scoping
or re-planning in order to align with the programme’s blueprint, programme plan and
benefits realization plan should be agreed and actioned.

186
Overseeing projects is critical to success. When the programme starts projects, part
of the brief explains the relationship between the project and its programme:
• When and how the project reports to the programme
• Reporting exceptions (including a definition of exceptions with stated tolerances
for time, cost, quality, risk and issues) so that the project knows when
circumstances are beyond its authority
• Acceptable tolerance within which the project can operate.
Governance in this process requires effective links to be formed between the
programme team and the project boards. See Chapter 4 for examples of programme
and project governance structures.

187
17.6.1 MONITOR AND CONTROL PROGRESS
Projects should report in an agreed format to help aggregate the information at the
programme level in line with the monitoring and control strategy. Progress against the
programme’s plans and schedules is monitored and tracked. Any departures (outside
agreed tolerances) from previously published project plans are assessed for impact
on the rest of the programme. The impact of any change within a project or on other
parties within the programme needs to be recognized as early as possible in order to
manage the change carefully. The programme manager will use information from
projects to help update the programme plan

188
The live projects are monitored by focusing on the areas that are key to the
programme, such as:
• Outputs Project outputs meet the requirements of their customers, which could be
the programme itself
• Timely completion Adhering to delivery forecasts, and reporting exceptions as
soon as possible to ensure alignment with the programme plan and other
dependencies
• Estimates, costs and benefits Tolerance-tracking and estimating the contribution
towards benefits realization, reporting exceptions quickly
• Resources Confirming suitability and availability, including supplier performance
• Scope Changes need to be formally managed to avoid insidious scope creep.

189
The programme manager, having initiated projects from the projects dossier, needs
to oversee progress. This includes the following tasks:
• Review projects, and obtain information for benefit reviews and assessments
• Deal with escalations and exceptions from projects
• Manage dependencies and interfaces between projects with particular emphasis
on making sure that projects understand how their outputs need to combine to
achieve the desired outcomes
• Check alignment with the requirements of the blueprint
• Oversee quality with particular emphasis on making sure that project outputs will
work well enough in a full-scale operational environment to achieve the benefits
desired (in conjunction with the BCM).

190
17.6.2 MANAGE RISKS AND RESOLVE ISSUES
The identified risks need to be regularly reviewed and challenged. New risks may be
identified and responses planned or actioned.
As the programme progresses, there will be the inevitable delays, unforeseen
situations and other situations that threaten the programme. The programme
manager is responsible for recognizing and dealing with anything that could affect
the successful delivery of the programme. This may involve escalating issues arising
from individual projects to the senior responsible owner (SRO), liaising with the
BCM(s) or working with the projects to manage risks and resolve issues that could
affect delivery of project outputs, programme outcomes and therefore benefits
realization.
Projects will also identify risks from their own perspective. They must be clear about
when risks need to be managed at a project level and when they should be escalated
to the programme manager (and should then be defined in the risk management
strategy).

191
17.6.2 MANAGE RISKS AND RESOLVE ISSUES
For each project, this guidance on managing risks and issues should be described in
the project brief prepared by the programme manager. For the programme overall,
rules are contained in the risk management strategy and issue management
strategy
Circumstances that should require a project to escalate risks or issues to the
programme manager include situations where:
• Dependent projects or programmes are impacted
• The project does not have sufficient authority for the action required
• The action required will exceed project tolerances for quality, time or cost
• The project does not have the necessary skills or experience and does not have
the authority to acquire them
• The project cannot deliver its outputs in line with the benefits realization plan

192
17.7 Close projects
As each project prepares for closure, there should be a formal delivery of the
project’s outputs to the programme. In order for a project to successfully close all of
its outputs, it must meet the acceptance criteria defined during project start-up,
subject to any formal change control.
It is important that the closing of projects is carefully controlled by the programme
manager. If the combined outputs from projects don’t support effective transition
and don’t enable the required improvement to operational improvement, the expected
benefits may not be realized.
Part of project closure involves the planning of a post-project review to assess the
realization of benefits from the effectiveness of the capability delivered and the
outputs. These reviews should be scheduled to fit into the programme’s review
schedule and may require external independent scrutiny.

193
17.7 Close projects
The process of project closure should include the dissemination of lessons learned
across the programme to share knowledge and experiences with the other projects. It
is often useful for members of the programme team to contribute to project evaluation
review and lessons learned reports where successes and problem areas associated
with the project and its project management process are captured. Throughout the
programme, the projects need to be advised of any issues arising that may impact
on benefit responsibilities. The lessons learned reports may be useful to inform this
activity.

194
manager
BCMs Programme
office
Start Projects A R C C
Engage stakeholders A R C C
Align projects with benefits
realization
A R R C
Align projects with
programme objectives
A R C C
Governance: manage and
control deliver
A R C C
Close projects A R C C

195
18.1 Introduction
18.2 Manage pre-transition
18.3 Manage transition
18.4 Manage post-transition

196
18.1 Introduction
The purpose of the Realizing the Benefits process is to manage the benefits from
their initial identification to their successful realization. The activities cover monitoring
the progress of the projects to ensure that the outputs are fit for purpose and can be
integrated into operations such that the benefits can be realized.
Realizing the Benefits incorporates the planning and management of the transition
from old to new ways of working and the achievement of the outcomes, whilst
ensuring that the operational stability and performance of the operations are
maintained. The activities of this process are repeated as necessary for each tranche
of the programme.
Three distinct sets of activities are covered:
• Manage pre-transition The analysis, preparation and planning for business
transformation
• Manage transition Delivering and supporting the changes
• Manage post-transition Reviewing progress, measuring performance and adapting
to change.

197
18.1 Introduction

198
18.2.1 Establish benefits measurements
18.2.2 Monitor benefits realization
18.2.3 Plan transition
18.2.4 Communicate the change
18.2.5 Assess readiness for change

199
Benefits realization is what the programme is all about. It is important to ensure that
this is made real by the implementation of relevant and reliable measurement
processes. These measures are defined in each of the benefit profiles, and overall in
the benefits management strategy.
18.2.1.1 Source data and set-up reporting
18.2.1.2 Performance baselines

200
18.2.1.1 Source data and set-up reporting
Business performance information will be needed for the current state and during the
life of the programme. Whilst this is defined in benefit profiles, it is now that the actual
collection of data starts, possibly in parallel with the activities in Defining a
Programme. This can be challenging. Therefore, it is sensible to take a pragmatic
approach, incrementally building on the information that is initially available.
Information produced to assist with managing benefits realization should pass the
following tests:
• Currency It is no good using data that is out of date. Ongoing reporting must
capture recent information.
• Accuracy If the information is based on unreliable or volatile data, invalid decisions
may be made. There may be a need to look for a second indicator from another
source to cross-check.
• Relevance Only report relevant information. It should be brief and effective; if there
is too much information critical evidence may be missed.

201
18.2.1.2 Performance baselines
In order to measure the improvements resulting from benefits realization, the ‘as-is’
needs to be measured. Without this, there will be no way of assessing whether the
‘to-be’ measurements indicate an improvement or not. The identification of what
measures are relevant is undertaken during Defining a Programme and details are
recorded in each benefit profile.

202
Throughout the programme, progress is monitored against the business case,
programme plan, benefits realization plan and the blueprint to identify potential
improvements to enhance benefit achievement or opportunities to minimize dis-
benefits. Adjustments may be necessary to deal with a range of events or
circumstances – for example:
• Business operations that will use the project outputs are unstable
• Forward plans are no longer realistic based on experience to date
• External circumstances have changed, affecting the future course of the
programme
• The programme’s objectives have changed or been refocused.

203
Monitoring and collaboration with projects needs to be benefits-focused. This could
include, for example, assessing designs, prototypes and similar items to consider
how well they are likely to work in a full-scale operational environment. This would be
part of answering the big question ‘Will the scale of the improvement be enough to
produce the desired benefits?’
The benefits are managed and controlled throughout the programme with the same
degree of rigour as the projects. Both benefits and costs are of primary importance to
the success of the programme. During the programme, there may be change or
opportunities for improving the benefits, and the benefit profiles will need to be
reassessed and adjusted as necessary.
It is essential for the organization to establish change control in those parts of the
business that are covered by the blueprint and which will have an effect on benefits
realization.

204
18.2.3 Plan transition
Change in an organization needs to be planned and managed carefully. Transition
plans often contain considerably more detail than other parts of the programme plan.
In preparing the plan, consideration should be given to:
• Staff and their working practices
• Information and technology
• Temporary facilities for those managing the transition
• Levels of stakeholder support and engagement in the areas to be changed
• The cultural and infrastructural migration from the old to the new
• Integration with the programme plan to be aware that a tranche end approaches
• Maintaining business operations during transition
• Exit or back-out arrangements should the change fail badly.

205
18.2.4 Communicate the change
This is about taking the affected business areas, operating units and the individuals
themselves through the engagement cycle for the planned changes, to raise
awareness and interest, and to get engagement and involvement.
The programme communications plan provides the basis for effective
communication. The risk register, plans, vision statement, blueprint and benefits
provide key information for the communications required when reviewing and
planning change activities.
Change must be carefully communicated well before actual transition. Late
communication is likely to result in significant resistance.

206
As preparation for implementing the change, it is a critical responsibility of the
BCM(s) and the team involved in change to be fully engaged with the project teams
and the business operations and to immerse them in the change that is coming.
This comes at a point where the project outputs have been or are being delivered to
the BCMs, and they need to make the decision as to whether the capability meets the
needs of the business and that the business is ready to transition. The
recommendation is made by the BCM, but the ultimate decision sits with the SRO,
who remains accountable.
Seeking out other organizations that have been through similar changes will help the
organization to prepare and avoid some of the pain of pioneering change.

207
When assessing capacity of the organization to make the changes, consider the
following:
Recent track record and experience of change & Past experience of implementing
this type of change
Availability of resources to support the change in terms of volume, competency and
experience
How the intended change fits with the organization’s culture and values.
Effectiveness of the supporting systems that could enable change
Skills and mobility of the workforce
Current status of service-level performance to customers and degree of satisfaction
Third-party supplier performance and alignment with change plans
Service management’s ability to support the organization through transition and in its
new operational state.

208
18.3.1 Initiate transition
18.3.2 Establish support arrangements
18.3.3 Enact transition
18.3.4 Review transition
18.3.5 Manage outcome achievement

209
18.3.1 Initiate transition
As the projects approach completion, the relevant business operations need to be
prepared for implementing the outputs from the projects. The transition plan is
reviewed and updated to reflect the activities of transition. These activities need to be
managed into the business environment, ensuring successful take-up of the new
capability whilst maintaining the appropriate levels of business as usual.
The transition may be achieved in a single change to the operations, or it may be
achieved through a series of incremental or modular changes. The transition plan
should provide the route map for implementation.

210
18.3.2 Establish support arrangements
Managing the transition will often require careful consideration of individuals’
personal concerns about their working environment, and what the changes will mean
to them. The transition to achieve the programme’s outcome may also affect
individuals and organizations external to the organization delivering the programme.
Support may be required from HR and system specialists.
To avoid unnecessary disruption, transition often involves very detailed plans. These
transition plans are delivered now, and the BCMs and business change team must
provide clear and concise direction, making and obtaining rapid decisions.

211
Transition can start as soon as:
• All the outputs from projects that are required for this transition are complete,
ready for operational use and the programme has verified through quality
assurance that they will function correctly together
• Operational staff are trained and briefed on their new roles, as well as on any
temporary duties they may perform during transition
• There are no risks and issues outstanding that the new operations are not willing
to take responsibility for
• Contingencies and back-out arrangements are in place should the changes fail
• Temporary transition management arrangements are in place
• The senior responsible owner (SRO), in consultation with the programme board,
has given the approval to start transition.

212
As soon as the start of transition is approved, it is important to verify that staff
understand the role they will play during transition, and that they know how the
management structure for transition will operate.
Transition is the responsibility of the programme, but may well make use of project
team members. Programme and/or project staff should enact the transition plan and
monitor progress, react and adapt to events as they develop, and ensure that stop/go
criteria for aborting the implementation are monitored and action taken where
appropriate.
Monitoring of the performance indicators will be important to assess the overall level
of business stability.

213
18.3.4 Review transition
When the new arrangements are in place, the transition should be reviewed, lessons
documented and any follow-on actions and requirements captured. There should be
broad engagement with the stakeholder community to guide their perception, interest
and support for the programme. This may be a testing time for everyone concerned;
it is therefore important to maintain measured and effective communications.
At this stage the project manager and teams can be disengaged. The process of
embedding the working practices leading to the release of benefits then starts, under
the control of the programme.
New ways of working will inevitably require a settling-down period. The BCM(s)
should ensure that the programme provides sufficient support during this period.

214
18.3.5 Manage outcome achievement
It will take time for outcomes to be fully realized, working practices established and
the business stabilized at the desired new state. When the outcomes have been
achieved, it is critical that this is actively acknowledged through the programme
communications plan.
However, beware of declaring victory too early. It is critical that the business has
stabilized in the new state and the change is fully achieved. There is a danger that if
the programme focus moves on to the next outcome too early, the operations may
regress to the old ways of working without the support and rigour of the programme
processes and procedures.

215
18.4.1 Measure benefits
18.4.2 Remove access to legacy working practices and systems
18.4.3 Respond to changing requirements
18.4.4 Monitor and report benefits realization

216
The benefit profiles define how each benefit will be measured. Reporting on benefits
realized to date should be part of the end-of-tranche review and any other planned
benefit reviews.
If the tranche ending has been designed to prove whether hypotheses embedded in
the strategy can work satisfactorily, there may be a planned delay before the next
tranche starts, in order to collect and analyse sufficient benefit measures to reach a
conclusion.
Starting the next tranche prematurely before clear conclusions have been reached
can significantly increase the programme risk. If the conclusions from benefits
measures indicate that the programme should stop or change significantly, any
projects running may also need to be stopped or changed, and much of the
expenditure so far may be wasted.

217
Key performance indicators that were selected as measures and recorded in the
benefit profiles will form the basis for comparison. It is important that as performance
is monitored the consequences are understood. For example, you may be focused
on headcount reduction, but if there is suddenly an upsurge in resignations or
accidents then the cause and effect will need to be investigated.
It is wise to look at historic averages and seasonal trends to forecast expected
performance averages over the life of the programme.

218
18.4.2 Remove access to legacy working practices and systems
One of the toughest aspects of delivering any change is stopping legacy practices
that are embedded, and removing access to tools and systems that support these old
practices will enable the new ways of working to be established.
The BCM must ensure that old working practices and systems are identified, the
impact of removal is understood and that they are decommissioned as soon as
business stability and resilience has been achieved. This reinforces and supports the
new modus operandi and organizational culture.
This is a critical activity that is often overlooked. If old ways of working remain, there
is a danger that the business will revert to using them once the pressure of the
programme is removed. This, in turn, threatens the sustainability of the improvements
and the realization of the benefits.

219
18.4.3 Respond to changing requirements
As part of embedding the new ways of working, ideas and problems will be
highlighted and recognized. Many of these will not have been foreseen, and it is a
natural part of the programme flow that the programme is able to respond to these
changing requirements.
Once the additional requirements have been quantified, they should be provided to
the programme manager for consideration and inclusion in the projects dossier via
the programme’s issue register, with an impact assessment on the blueprint,
programme plan, benefit profiles and benefits realization plan.

220
18.4.4 Monitor and report benefits realization
Through the transition process, the benefit measures should be monitored and
progress tracked for signs of deviation outside the anticipated parameters. Where the
business performance moves out of tolerance, this should be escalated to the SRO
and the sponsoring group.
Benefit profiles and the benefits realization plan should be updated and released in
accordance with arrangements defined in the benefits management strategy.
BCMs will provide input to benefit reviews when the analysis of benefits measures is
complete and conclusions have been drawn. Benefit reviews can also help the
programme to understand the extent to which key stakeholders have been satisfied
with the improvements.
It is not always possible or necessary for a programme to continue until the end of
the benefits measurement period. If benefits realization results so far provide a clear
indication of the final realization level and operational managers will take on the
responsibilities for completing the measures, the programme can propose that it ends
its responsibility.

221
18.5 Responsibilities - Manage pre-transition
manager
BCMs Programme
office
Establish benefits
measurements
A C R C
Monitor benefits realization A C R C
Plan transition A R R C
Communicate the change A C R C
Assess readiness for
change
A C R I

222
18.5 Responsibilities - Manage transition
manager
BCMs Programme
office
Initiate transition A C R I
Establish support
arrangements
A C R I
Enact transition A C R I
Review transition A C R C
Manage outcome
achievement
A C R I

223
18.5 Responsibilities - Manage post-transition
manager
BCMs Programme
office
Measure benefits A C R C
Remove access to legacy
working practices and
systems
A C R I
Respond to changing
requirements
A C R C
Monitor and report benefits
realization
A C R C

224
19.1 Introduction
19.2 Confirm ongoing support is in place
19.3 Confirm programme closure
19.4 Notify programme is about to close
19.5 Review programme
19.6 Update & finalize programme information
19.7 Provide feedback to corporate governance
19.8 Disband programme organization & supporting functions

225
19.1 Introduction
Programmes tend to last for a significant period, typically years. There is a danger of
allowing the programme to drift on, as if it is part of normal business. The purpose of
the Closing a Programme process is to ensure the end goal of formally recognizing
that the programme is completed. This is when the programme has delivered the
required new capabilities described in the blueprint and has assessed the outcomes
via benefit measures.
Some benefits will have been realized during the running of the programme; others
may not be fully realized until some time after the last project has delivered. Closing a
Programme identifies the need for future assessment of benefits realization outside
the programme as well as a formal review by the programme of those achieved so
far. If there are benefits realization activities which need to continue for a significant
period of time after the capability has been delivered, then it may be impractical to
maintain the whole programme management structure to control these last
activities. It is conceivable that the programme may be closed and this realization
activity managed as a separate piece of work, possibly a project. Alternatively,
responsibility for the post-programme benefits realization activity may be taken on by
the business-as-usual area receiving the benefit or by the corporate portfolio

226
19.1 Introduction
Closure comprises the final assessment of the programme and the decommissioning
of its resources and infrastructure. Programme closure may be scheduled at any
point after the completion of the last project within the projects dossier and the
capability has been delivered. To a large extent, when the programme formally
closes will depend on the amount of support required to ensure that the new
operational environment delivered by the programme is fully embedded. Additionally,
consideration also needs to be given to outstanding benefits realization activities.
Examples of tests for whether a programme can close include:
• Blueprint has been delivered
• Outcomes have been achieved
• Business case has been satisfied (thus far)
• Benefits are self-sustaining
• Last tranche has been completed as per the programme plan
• No risks or issues are outstanding that are unacceptable to operations.

227
19.1 Introduction
It is not always sensible for a programme to continue to its planned end point.
Indications that a programme should be closed prematurely include:
• Evidence so far indicates that the programme does not make good business
sense, and it is not possible to change it sufficiently to produce an acceptable
business case
• The organization is not able to secure adequate funding or sufficient resources to
complete the outstanding work
• External circumstances have changed sufficiently to render the remainder of the
programme irrelevant
• Strategy has been changed by the organization for internal reasons, not because
of external environment changes; this renders the programme invalid
• The 80/20 rule shows that the cost of the remainder of the programme compared
with additional benefits it will realize means that it does not make good business
sense to complete the rest of the programme
• There is evidence that the outcome is being achieved through alternative
actions/events.

228
19.1 Introduction

229
19.2 Confirm ongoing support is in place
Whilst the programme is running, it is able to support and facilitate the overall change
process. The programme can act as a vehicle for resolving disputes and issues that
have arisen during the transition. Careful consideration must be given to how the
business will operate without the support of the programme. For example,
programmes often establish new supply chain relationships, appointing and migrating
to a new operator. When the programme closes, gaps in communications and
processes between the new operator and business operations can emerge because
the programme has been providing the bridge and resolving issues up to this point.
So there may be new post-programme risks that need to be identified and managed.
After closure, the embedded changes must be able to continue with smooth-running
operations and working practices. For programmes where the outcome primarily
affects those external to the organization running the programme, any ongoing
support requirements should be established, separate from the programme, so that
the programme can formally close.
All stakeholders should be informed of programme closure and its outcome.

230
19.3 Confirm programme closure
Programme closure involves formal confirmation that:
• The business case has been satisfied
• All projects have been completed satisfactorily
• Business performance is stable
• Any remaining handover or transition activities required have been defined and
assigned to relevant business operations.
If the programme is being closed prematurely (i.e. before the blueprint has been
achieved), the remaining live projects that are still required by the organization need
to be reassigned to business management or perhaps to another programme.
The senior responsible owner (SRO) will propose closure to the sponsoring group. If
satisfied with the overall outcome, they will endorse the recommendation to confirm
programme closure. If they are not satisfied, they must give clear direction about
further work to be carried out.

231
19.4 Notify programme is about to close
Notify the programme organization, stakeholders and programme office that the
programme is preparing to close. Produce instructions and a timetable for closing
activities and the programme review. For a scheduled programme closure, this
notification should have been built into the programme communications plan already.
For a premature closure, it will require significantly more communication and
stakeholder engagement to ensure that the early closure does not taint the previous
good work of the programme.

232
19.5 Review programme
Throughout the programme, the end-of-tranche reviews will have been monitoring
and measuring benefits realization. As part of Closing a Programme a formal review
should be conducted to assess the delivery of the complete blueprint, realization of
the overall benefits and achievement of the programme’s business case. Benefits
reviews should have already been carried out during the programme, so the final
review may be a consolidation of their findings.
This review should also assess and evaluate the performance of the programme and
its management processes to identify lessons learned that may benefit other
programmes. The review may involve independent external scrutiny, such as a gated
review.
A further review, following programme closure, may be required to provide a
complete assessment of benefits realized as a result of the programme, including
those benefits that may not have been ready for measurement and assessment when
the programme closed.

233
19.6 Update & finalize programme information
Programme information should be reviewed and updated to ensure that any residual
issues, risks and outstanding actions have been dealt with appropriately.
Risks and issues for which operations have agreed to take responsibility are handed
over. Note that the accountability for these remains with the SRO.
The strategies, plans and boundary documents should be reviewed to assess their
effectiveness, appropriateness and what lessons can be learned for future
programmes. Any corporate and legislative governance requirements affecting the
storage of information should be complied with as part of the archiving of documents.

234
19.7 Provide feedback to corporate governance
Programmes initiated to deliver corporate strategic objectives need to provide
feedback to the strategists. No strategies are guaranteed to succeed, and good
feedback from each programme will help the organization to develop more informed
and therefore better strategic decisions. This may be handled via a portfolio office if
one exists.

235
19.8 Disband programme organization & supporting functions
The programme’s infrastructure and management processes are disbanded and
individuals and resources released from the programme. Staff redeployment back
into the organization should be planned in advance. Staff will have updated their
skills as a result of their experiences on the programme, and it is important that this is
reflected in their personal development information. Any contracts used by the
programme should be finalized and closed, or responsibility for continued contract
management handed over to the relevant business management function.

236
manager
BCMs Programme
office
Confirm ongoing support is
in place
A R C C
Confirm programme
closure
A C C I
Nnotify the programme
about the close
A R C I
Review programme A C R I
Update & finalize
programme information
A R C C
Provide feedback to
corporate governance
A R C I
Disband programme
organization & supporting
functions
A R I I

237
18.5 Responsibilities - Manage transition
manager
BCMs Programme
office
Initiate transition A C R I
Establish support
arrangements
A C R I
Enact transition A C R I
Review transition A C R C
Manage outcome
achievement
A C R I

238
18.5 Responsibilities - Manage post-transition
manager
BCMs Programme
office
Measure benefits A C R C
Remove access to legacy
working practices and
systems
A C R I
Respond to changing
requirements
A C R C
Monitor and report benefits
realization
A C R C

MSP 2011 part 2

More Related Content

What's hot (20)

Similar to MSP 2011 part 2 (20)

More from Robert Edward Pinnington (6)

Recently uploaded (20)

MSP 2011 part 2