Sign in

Using PRINCE2 and MSP Together White Paper

White Paper

Using PRINCE2 and MSP Together White Paper

White Paper

  • White Paper
  • Career progression
  • Processes
  • Training
  • MSP

Author  Andy Murray, Director, Outperform

October 29, 2010 |

 20 min read

  • White Paper
  • Career progression
  • Processes
  • Training
  • MSP

PRINCE2 is the Office of Government Commerce’s (OGC) method for managing a project.

Managing Successful Programmes (MSP®) is OGC’s 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.

Project and programme management in 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.

Being managed as a projectBeing managed as a programme
It is a project OptimizedOver-complicated
No clear boundaries, e.g. scope
It is a programmeInter-dependencies are not picked up 
Business is not changed
Benefits are not measured

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.’

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 organization’s strategic objectives. A programme may have a life that spans several years.

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.

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.

The differences between projects and programmes are illustrated in Table 2.2.

CharacteristicsDriven by deliverables
Finite - defined start and finish 
Bounded and scoped deliverables
Delivers product or outcome
Benefits usually realized after project closure
Shorter timescale
Driven by vision of 'end state'
No predefined path
Delivers changes to the business capability
Coordination or products/outcomes
Benefits realized during the programme and afterwards
Longer timescales
Managed focusDetailed specification (of how) 
Control of activities to produce products 
High-level specification (of why/what)
Stakeholder management
Benefit realization
Dependency management
Transition management / change acceptance
Integration with corporate strategies

Approach to integrating PRINCE2 and MSP

Sections 3.1 to 3.3 explain how PRINCE2 can be tailored when working in a programme environment using OGC’s Managing Successful Programmes framework by looking at how to adapt the themes, processes and management products.

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.

Table 3.1 Mapping MSP and PRINCE2 themes for integration

MSP Governance ThemeRelated PRINCE2 Theme


Vision(Affects solution designs and thus plans)
Leadership and Stakeholder engagementOrganization
Benefits realization managementBusiness Case; progress
Blueprint design and delivery

(Affects solution designs and thus plans)

Planning and controlPlans; progress
Business CaseBusiness Case; progress 

Risks and issue managementRisk; change
Quality managementQuality

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:

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

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.

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.

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 programme’s 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.

Image of Figure 3.1 showing a Programme organization structure

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.

Image of Figure 3.2 showing Project organization structure

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
  • 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.

Image of Figure 3.3 showing example of an integrated structure

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.
  • 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 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 Board’s 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 project’s Communication Management Strategy will be derived from the programme’s 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 project’s 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 programme’s design authority may provide advice and guidance to the Project Manager on any quality methods to be used.

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 project’s deliverables are being used by other projects within the programme. Any dependencies to or from the project should be incorporated into the project’s plans.

3.1.5 Risk

The project’s 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 Project’s Configuration Management Strategy will be derived from the programme’s 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 project’s change control procedure will be derived from the programme’s 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 programme’s design authority may be the project’s Change Authority, or a member of it.

3.1.7 Progress

The programme’s monitoring and control strategy may influence the formality, frequency and content of the project’s 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 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 project’s 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 project’s 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 Programme’s 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.

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 Board’s 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 project’s success and is the key decision-maker. The Project Board is not a democracy controlled by votes. The Executive’s 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 project’s 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 project’s 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 project’s 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 project’s 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 Team Manager’ 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.

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

The Executive Guide to Directing Projects: within a PRINCE2 and MSP Environment (TSO, 2009)

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 OGC’s 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 organization’s strengths and weaknesses, prioritize improvement initiatives and measure progress. Andy has used the OGC’s 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.


Sourced by TSO and published on

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.

© Copyright TSO. Reproduction in full or part is prohibited without prior consent from the author.