Using PRINCE2 and MSP Together

Andy Murray, Director, Outperform

White Paper
October 2010

The Stationery Office 2010

2
Using PRINCE2 and MSP Together

Contents
1

Purpose of this White Paper

Project and programme management context

Approach to integrating PRINCE2 and MSP

3.1 Themes

3.2 Processes

3.3 Management products

Appendix A Roles

Appendix B References

10

About the author

10

Acknowledgements 10
Trademarks and statements

10

Further information

10

The Stationery Office 2010

Using PRINCE2 and MSP Together 3

1 Purpose of this White Paper

PRINCE2TM is the Office of Government Commerces (OGC)
method for managing a project.
Managing Successful Programmes (MSP) is OGCs framework
for managing programmes.
Although both are from OGC, they have been written on the
basis that they can be used independently of each other that
is, a project using PRINCE2 may not exist in a programme
environment nor indeed within a programme that is using
MSP. Likewise, MSP does not assume that the projects it is
responsible for are using PRINCE2.
The good news is that when PRINCE2 and MSP are used
together, various activities and documentation are no longer
required. The bad news is that some integration work is still
needed to ensure they work together well.
This White Paper discusses what is required in order to use
PRINCE2 and MSP together. It is written from the project
perspective and it assumes that the reader is already familiar
with PRINCE2.

2 Project and programme

management context
Before deciding how to use PRINCE2 and MSP together it is
important to determine whether what you are working on is a
project or programme.
It is very easy to get into academic debates about projects
versus programmes. The key test is whether having a project or
programme adds value when managing the day-to-day work.
Remember, it is not a question of scale large projects may not
necessarily be programmes. Likewise, programmes do not need

to be large for the work to benefit from being managed as a

programme. The implications of using the wrong approach to
manage a project or programme are illustrated in Table 2.1.
So how do you decide? Let us look at the definitions from
PRINCE2 and MSP.
A project is a temporary organization that is created for
the purpose of delivering one or more business products
according to an agreed Business Case.
PRINCE2
A programme is a temporary flexible organization
structure created to coordinate, direct and oversee the
implementation of a set of related projects and activities
in order to deliver outcomes and benefits relating to an
organizations strategic objectives. A programme may
have a life that spans several years.
MSP
Clearly, there are similarities between projects and
programmes both are temporary and seek to achieve
benefits for the sponsoring organization. But there are also
important differences.
The key distinction is that a project typically produces or changes
something (its products) and is then disbanded. Although the
purpose of a project is to deliver changes that will ultimately
realize Business Case benefits, it rarely exists long enough to
ensure that the benefits are fully delivered. The benefits are
likely to be accrued after the project is completed. Moreover,
many projects are enablers; that is, their products will not
deliver business benefits directly but must be augmented by
other activity to produce these benefits. For example, the
construction of a hospital building is not sufficient in itself: the
medical, nursing and administrative services, equipment and
systems must be in place before the healthcare benefits can
be achieved.

Table 2.1 Choosing the right method

It is a project

Being managed
as a project

Being managed
as a programme

Optimized

Over-complicated
Over-governed
No clear boundaries, e.g. scope

It is a programme

Interdependencies are not picked up

Optimized

Business is not changed

Benefits are not measured

The Stationery Office 2010

4
Using PRINCE2 and MSP Together

Programmes are typically established to coordinate the work

of a set of related projects, to manage the outcomes and to
realize the aggregate benefits. They are often established when
organizations decide to transform their operations or services
from their current state to an improved target end state.
The functions at the programme level tend to be less focused
on delivering specialist products but rather on coordinating
the efforts of the various projects so that the resulting
transformation is effectively integrated.

3.1 Themes
The structure of MSP is very similar to that of PRINCE2; both
have a set of themes. Table 3.1 maps the relationship between
the MSP governance themes and the PRINCE2 themes.
As shown in Table 3.1, the MSP governance themes often
reflect the themes in PRINCE2, so many of the disciplines can
be consolidated at the programme level to reduce duplication at
project level and improve consistency.

The differences between projects and programmes are

illustrated in Table 2.2.

Use the following management strategies described in the MSP

governance themes to define consolidated approaches across the
programme, so that less definition is required at project level:

3 Approach to integrating
PRINCE2 and MSP

Benefits management strategy

Information management strategy
Issue resolution strategy
Monitoring and control strategy
Quality management strategy
Resource management strategy
Stakeholder engagement strategy.

Sections 3.1 to 3.3 explain how PRINCE2 can be tailored when

working in a programme environment using OGCs Managing
Successful Programmes framework by looking at how to adapt
the themes, processes and management products.

Table 2.2 Comparing projects and programmes

Projects
Characteristics

Driven by deliverables
Finite defined start and finish
Bounded and scoped deliverables
Delivers product or outcome
Benefits usually realized after
project closure
Shorter timescale

Management focus

Detailed specification (of how)

Control of activities to produce
products

Programmes
Driven by vision of end state
No predefined path
Delivers changes to the
business capability
Coordination of products/outcomes
Benefits realized during the
programme and afterwards
Longer timescale
High-level specification
(of why/what)
Stakeholder management
Benefit realization
Dependency management
Transition management/change
acceptance
Integration with
corporate strategies

The Stationery Office 2010

Using PRINCE2 and MSP Together 5

Table 3.1 Mapping MSP and PRINCE2 themes for integration

MSP governance theme

Related PRINCE2 theme

Organization

Organization

Vision

(Affects solution designs and thus plans)

Leadership and stakeholder engagement

Organization

Benefits realization management

Business Case; progress

Blueprint design and delivery

(Affects solution designs and thus plans)

Planning and control

Plans; progress

Business Case

Business Case; progress

Risks and issue management

Risk; change

Quality management

Quality

This leads to a number of benefits:

Project initiation overheads are reduced by work completed

at programme level (such as Business Cases and strategies for
risk, change and quality management)

Project documentation follows standards set at the

programme level, improving consistency

Consistent standards result in better communication and

information management. They also facilitate the use of
software support tools where necessary (reporting
dashboards, risk, issue and change control support tools, etc.)

Some functions should logically be shared across projects

(examples are configuration management, continuous
improvement, the evaluation of lessons learned,
performance analysis).
Sections 3.1.1 to 3.1.7 review the integration implications for
each of the PRINCE2 themes of Business Case, organization,
quality, plans, risk, change and progress.

Benefits will be defined, tracked and managed by the

programme management team and any benefit reviews
relating to the project will be part of the programmes benefits
realization plan.

3.1.2 Organization
Projects and programmes are a people thing. No amount of
good planning or control will overcome not having the right
people involved in the project and programme in the first place.
MSP organization structure
MSP defines a programme organization structure, shown in
Figure 3.1. This comprises a Sponsoring Group, Programme
Board, Senior Responsible Owner (SRO), programme manager,
one or more business change managers, representatives of
corporate functions as necessary (for example, human resources,
finance), the lead supplier and the Project Executives of the
projects within the programme. See Appendix A for details of
each of these roles.

3.1.1 Business Case

The programme will define the standards that the project will
need to use when developing the Business Case.
The project Business Case will be aggregated into the overall
programme Business Case and therefore it is likely to be
reduced in content. It may comprise just the details of the
budget, a list of benefits (and the benefits tolerance), and
a statement as to how the project is contributing to the
programme blueprint, with the justification aspects of the
project Business Case sitting in the programme Business Case.
In some cases, the Business Case might be produced and
maintained by the programme and even exist in detail prior to
initiating the project.

PRINCE2 organization structure

PRINCE2 defines a project organization structure, shown in
Figure 3.2. This comprises a Project Board, Project Executive,
Senior Users, Senior Suppliers, Project Assurance, Project Manager,
Project Support and Team Managers. See Appendix A for
details of each of these roles.
The integrated structure
The programme and project organization structures need to be
integrated such that:

There are clear lines of responsibility from top to bottom (that

is, everyone is accountable to someone)

Duplication is avoided
The Stationery Office 2010

6
Using PRINCE2 and MSP Together

Sponsoring Group
focus on investment and
strategic alignment

Senior
Responsible
Owner

Programme Board
focus on driving
the programme
forward

Senior business
management

Business
Change
Manager(s)

Programme
Manager

Supporting
functions

Projects
Figure 3.1 Programme organization structure

Senior User

Executive

Senior Supplier

Project Board
Change
Authority

Project
Manager

Project
Assurance

Project
Support
Team
Manager

Team
Manager

Team
Manager

Figure 3.2 Project organization structure

Reports and reviews are efficient (for example, four projects

within a programme have common Project Board members
and by aligning stage boundaries they meet collectively to
conduct end stage assessments for all four projects as part of
a programme review).
An example of an integrated structure is shown in Figure 3.3.
When designing the integrated organization structure, the
following may be useful to consider:

The SRO for a programme may additionally take on the

Project Executive role for key projects within the programme.
Some organizations appoint SROs to direct large, freestanding projects. In this case the SRO simply takes the
PRINCE2 Project Executive role.
The Stationery Office 2010

There is a direct relationship between the programme level

role of the business change managers and the Project Board
roles of Senior Users, so Business Change Managers may also
act as Senior Users at project level.

Depending on the nature of the project and the expertise of

the person concerned, a Business Change Manager might
also act as a Project Executive.

Programme managers may also act as Project Board

members. However, this is not always appropriate. The
Programme Manager may not have the required line
authority to supervise the people acting as Senior Users and
Senior Suppliers (who normally do have senior line

Using PRINCE2 and MSP Together 7

Senior
Responsible
Owner
Business Change
Manager
A

Business Change
Manager
B

Programme
Support

Programme
Manager

Design
Authority

Programme Board
Senior
User

Senior
Supplier

Executive
Project Board

Combined
Role

Change
Authority

Project
Manager

Senior
Supplier

Combined
Role
Combined
Role

Project
Assurance

Team
Manager

Team
Manager

Team
Manager

Figure 3.3 Example of an integrated structure

management positions). Also, a Programme Manager may

not have the authority to commit key resources, which is a
crucial requirement for the Senior User and Supplier roles.

MSP advises that the Project Executives for the major

projects in the programme might also be included as
members of the Programme Board, to ensure strategic
alignment and promote integration.

Another role often found at this level is that of quality

manager, responsible for quality assurance and continuous
improvement in the programme. The role can be valuable for
analysing performance metrics and lessons learned,
supporting standards and processes and carrying out audits
and health checks. Alternatively, quality management may
be a function of the sponsoring organization.

The provision of specialist support at programme level should

result in significant benefits at project level; for example,
improving performance, consistency and quality by providing
process support, templates for project documentation and/or
specialist support for planning. However, there is sometimes
the risk that programme office functions can undermine the
authority and accountability of Project Boards and Project
Managers; for example, by imposing inflexible standards and
constraining the scope for tailoring. There is a balance to be
struck between flexibility at project level and consistency
across the programme. Project Board members should be
alert to the danger of unnecessary inflexibility and use their
influence to avoid it.

Where there is common Project Board membership across all

the Project Boards it may be useful to disband this layer of
management altogether and simply have those people on
the Programme Board. This means that the Programme
Board becomes responsible for the Project Boards
responsibilities (and in PRINCE2 terms for the Directing a
Project process).
Stakeholder engagement
Another aspect of the organization theme to consider is
stakeholder engagement. The projects Communication
Management Strategy will be derived from the programmes
stakeholder engagement strategy, with communications
being controlled and scheduled as part of the programme
Communications Plan. Stakeholder analysis for the project
may be performed by the programme, or the programme may
require the project to take a lead with certain stakeholder
groups with which it has good engagement.

3.1.3 Quality
The projects quality management strategy is derived from that
of the programme.
Quality assurance and quality control activities may be carried
out by members of the programme management team.
The programmes design authority may provide advice and
guidance to the Project Manager on any quality methods to
be used.
The Stationery Office 2010

8
Using PRINCE2 and MSP Together

3.1.4 Plans
Any specific standards that the project planners should use will
be described in the programme monitoring and control strategy.
The project planning activity in the Design the Plan process will
ensure that such standards and tools are adopted by the project.
The programme office may have dedicated planners that can
help the Project Manager prepare and maintain the Project Plan
and Stage Plans.
The programme dependency network will detail how each
projects deliverables are being used by other projects within
the programme. Any dependencies to or from the project
should be incorporated into the projects plans.

3.1.5 Risk
The projects Risk Management Strategy will be derived from
that of the programme.
This will include defining a common set of risk categories, risk
scales (for probability, impact and proximity), any risk evaluation
techniques (such as expected monetary value), the projectlevel risk tolerance and the mechanisms to escalate risks to the
Programme Board.
A key consideration here is that project personnel may identify
programme-level risks and programme personnel may identify
project-level risks. It is important that risks are documented in
the risk register at the level in the extended organization that is
most capable of managing them.

3.1.6 Change
The Projects Configuration Management Strategy will be
derived from the programmes information management
strategy. The information management strategy defines how
interfaces between projects should be maintained (for example,
so that any changes within this project that may affect one or
more other projects are captured and escalated).
The projects change control procedure will be derived from
the programmes issue resolution strategy. This will define how
scope or delivery changes that take the project out of tolerance
or affect the programme benefits or programme plan are
escalated to the Programme Board.
The programmes design authority may be the projects Change
Authority, or a member of it.

3.1.7 Progress
The programmes monitoring and control strategy may influence
the formality, frequency and content of the projects reviews
and reports, and any project management standards that are to
be complied with.
Project-level time and cost tolerances will be defined by
the programme.
The number and length of management stages will be
influenced by the programme plan so that end stage
assessments align to other programme-level milestones (for
The Stationery Office 2010

example, the end of a tranche). It may even define a set of

standard management stages that all projects within the
programme comply with, such as common stage gates.

3.2 Processes
Within MSP, the Delivering the Capability process within
Managing the Tranches is entirely focused on starting,
monitoring and closing projects within the programme. This
process does not need to be tailored when working with PRINCE2.
The PRINCE2 process most affected by working in a programme
will be Starting Up a Project. The Starting Up a Project process
will be undertaken almost entirely by the programme. The
programme will appoint the Project Executive and Project
Manager, review previous lessons, design and appoint the
Project Management Team and probably prepare the Project
Brief. The Project Manager, however, will be responsible for
preparing the initiation Stage Plan. In this context, it is not so
much that the Starting Up a Project process is not done, just
that it is mainly done by the programme.
The Directing a Project process will be affected if the
integrated organization structure collapses Project Boards
into the Programme Board. It may be that some of the Direct
a Project processes are run for multiple projects by a common
Project Board.
The Managing a Stage Boundary and Closing a Project
processes may be affected if the programme is undertaking the
responsibilities for benefits reviews.

3.3 Management products

Confusingly, there are numerous management products that
exist at both the project and programme level; for example,
a Risk Register. When in a programme environment it may
be desirable to pre-fix the management product with the
project and programme to distinguish the difference. Another
consideration is to make the project- and programme-level
document templates look very different in style so that it is
immediately obvious at which level they apply.
Consideration should be given as to whether the projects
logs and registers will be maintained locally to the project or
centrally by the programme. You should decide, for example,
whether there is a single Risk Register, administered by the
programme office for the programme level risks and all the risks
for each project within the programme, or whether each project
should maintain its own risk register. If the latter is chosen,
the projects Risk Management Strategy should define how
programme-level risks that are identified and captured by the
project are promoted to the programme risk register. Likewise,
the Programmes Risk Management Strategy should define
mechanisms for project risks that are identified and captured at
the programme level to be demoted to the project Risk Register.

Using PRINCE2 and MSP Together 9

Appendix A Roles
Programme management roles
The Sponsoring Group is the driving force behind the
programme and appoints the Senior Responsible Owner
(SRO). It is the group of senior managers responsible for the
investment decision, for interpreting the strategic direction of
the business, and for ensuring the ongoing alignment of the
programme to that strategic direction.
The SRO is the single individual with overall responsibility for
ensuring that a programme meets its objectives and delivers
the projected benefits. It is likely that the SRO will appoint the
Project Executive.
The Programme Boards prime purpose is to drive the
programme forward and deliver the outcomes and benefits.
Members will provide resource and specific commitment to
support the Senior Responsible Owner who is accountable for the
successful delivery of the programme. The Programme Board is
appointed by, and reports to, the Senior Responsible Owner.
Programme Assurance is responsible for building confidence
in the sponsoring organization(s) by ensuring that all aspects of
the programme are being managed properly.
The Programme Manager is responsible for the set-up and
day-to-day management and delivery of the programme on
behalf of the SRO.
The Business Change Manager is responsible for benefits
management, from identification through to realization. The
aim is to ensure that the new capabilities delivered by the
projects in the programme are properly implemented and
embedded in the sponsoring organization(s), so Business
Change Managers often have long-term line management
responsibilities for realizing benefits. Usually, there will be more
than one business change manager for a programme in order
to manage impacts in different parts of the organization (or in
different organizations). It is sometimes advisable to establish a
change team to support the Business Change Managers and
contribute specialist business change skills.
A programme office is the information hub and standards
custodian for the programme and its delivery objectives.
Programme offices take different forms depending on the
programmes and organizations that they support.
Programmes vary considerably in terms of scale and complexity
and MSP suggests that a number of other governance roles
should be considered and established, if necessary. These may
or may not be included as members of the Programme Board:

Design authority to provide strategic-level governance and

specialist advice (such as in the IT or construction context)

Programme accountant (or finance manager) to manage

compliance with corporate accounting procedures and
support for Business Case development

Benefits realization manager to support the business

change managers (who often also carry line responsibilities)
with specialist expertise in this field

Procurement manager as many programmes include a

high proportion of procurement activity

Risk manager with specialist expertise in this field.

Project management roles
The Project Board is responsible for the overall direction and
management of the project within the constraints set out by
corporate or programme management.
The Executive is ultimately accountable for the projects success
and is the key decision-maker. The Project Board is not a
democracy controlled by votes. The Executives role is to ensure
that the project is focused throughout its life on achieving its
objectives and on delivering a product that will achieve the
forecasted benefits. The Executive has to ensure that the
project gives value for money, ensuring a cost-conscious
approach to the project, balancing the demands of the business,
user and supplier.
The Senior User (or users) is responsible for specifying the
needs of those who will use the projects products, for user
liaison with the project management team and for monitoring
that the solution will meet those needs within the constraints of
the Business Case in terms of quality, functionality and ease of
use. The role represents the interests of all those who will use
the projects products (including operations and maintenance),
those for whom the products will achieve an objective, or those
who will use the products to deliver benefits.
The Senior Supplier (or suppliers) represents the interests
of those designing, developing, facilitating, procuring and
implementing the projects products. This role is accountable
for the quality of products delivered by the supplier(s) and is
responsible for the technical integrity of the project.
Project Assurance is responsible for monitoring all aspects of
the projects performance and products independently of the
Project Manager. Project Assurance is not just an independent
check, however. Personnel involved in Project Assurance are
also responsible for supporting the Project Manager by giving
advice and guidance on issues such as the use of corporate
standards or the correct personnel to be involved in different
aspects of the project, such as quality inspections or reviews.
The Change Authority is the person or group to which the
Project Board may delegate responsibility for the consideration
of requests for change or off-specifications. The Change
Authority may be given a change budget and can approve
changes within that budget.
The Project Manager is the single focus for day-to-day
management of a project. This person has the authority to run
the project on behalf of the Project Board within the constraints
laid down by the Project Board. In a PRINCE2 environment the
Project Manager role should not be shared.
The Stationery Office 2010

10
Using PRINCE2 and MSP Together

The Team Managers primary responsibility is to ensure

production of those products allocated by the Project Manager.
The Team Manager reports to, and takes direction from, the
Project Manager.

Acknowledgements

Project Support is the responsibility of the Project Manager.

If required, the Project Manager can delegate some of this
work to a Project Support role: this may include providing
administrative services or advice and guidance on the use of
project management tools or configuration management.

Appendix B References

Our White Paper series should not be taken as constituting

advice of any sort and no liability is accepted for any loss
resulting from use of or reliance on its content. While every
effort is made to ensure the accuracy and reliability of the
information, TSO cannot accept responsibility for errors,
omissions or inaccuracies. Content, diagrams, logos and jackets
are correct at time of going to press but may be subject to
change without notice.

The Executive Guide to Directing Projects: within a PRINCE2 and

MSP Environment (TSO, 2009)

Copyright TSO. Reproduction in full or part is prohibited

without prior consent from the author.

Sourced by TSO and published on

www.best-management-practice.com

Managing Successful Programmes (TSO, 2007)

Managing Successful Projects with PRINCE2 (TSO, 2009)

About the author

Andy Murray is a Chartered Director and PRINCE2 Registered
Consultant, having worked in the field of projects and
programmes for over 15 years.
He is currently a director of Outperform UK Ltd, an Accredited
Consultancy Organization (ACO) licensed to consult in the
OGCs best practice trilogy of PRINCE2, MSP and M_o_R.
Andy was an early adopter of PRINCE2 back in 1997, and has
been helping organizations implement and gain value from
PRINCE2 ever since. He has helped implement PRINCE2 in
numerous organizations in more than a dozen countries.
Andy has been using maturity models as a consulting
aid for more than five years, since they help diagnose
an organizations strengths and weaknesses, prioritize
improvement initiatives and measure progress. Andy has used
the OGCs PRINCE2 Maturity Model (P2MM) and Portfolio,
Programme and Project Management Maturity Model
(P3M3) as means both to benchmark organizations via
the APM Group assessment process and to define
improvement plans.
Andy was the co-author of Improving Project Performance
Using the PRINCE2 Maturity Model (P2MM), published by TSO
in 2007. He was also the lead author of Managing Successful
Projects with PRINCE2, published by TSO in 2009.

The Stationery Office 2010

Trademarks and statements

M_o_R is a Registered Trade Mark of the Office of Government
Commerce in the United Kingdom and other countries.
MSP is a Registered Trade Mark of the Office of Government
Commerce in the United Kingdom and other countries.
The OGC logo is a Registered Trade Mark of the Office of
Government Commerce in the United Kingdom.
P3M3 is a Registered Trade Mark of the Office of Government
Commerce in the United Kingdom and other countries.
PRINCE2 is a Trade Mark of the Office of
Government Commerce.
The Swirl Logo is a Trade Mark of the Office of
Government Commerce.

Further information
Further information is available at:
www.best-management-practice.com
www.ogc.gov.uk
www.outperform.co.uk