PRINCE2 is the AXELOS’s method for managing projects whilst Managing Successful Programmes (MSP®) is also an AXELOS framework but for managing programmes. Managing Successful Programmes (MSP) is a best-practice framework for delivering complex programmes in accordance with long term strategies. MSP was first released in 1999 in recognition of the need for greater links between an organization’s longer-term strategy, objectives and goals and the projects being undertaken by that organization. The third, version of MSP was released in 2007 and demonstrated a significant advance in the maturity of programme management by expanding on the original concepts and introducing new tools and techniques. In 2011 (current) another update was made primarily around the qualification scheme. As MSP is not prescriptive, it can be adapted to suit an organization’s individual needs. Whether an organization is national or global, or in the private or public sector, there is no limit to the size of programme it can be applied to. It works on both smaller and larger scales. MSP warrants strong leadership and a solid system of management and control. This is done through clear definitions of roles and responsibilities and excellent lines of communication. Additionally, stakeholder and employee engagement is established and maintained throughout the course of a programme. MSP provides a common framework in which all individuals can work, with particular focus on clear communication between departments. MSP helps to analyse initiatives to form succinct projects while providing the methodology to make each project a success.
Why would an Organization want to use MSP?
MSP is designed to support change within an organization or in the wider community. So MSP should be of interest to any organization which is undertaking change. This includes:
• Organizations that are merging, or going through an acquisition
• Government agencies rolling out new legislation
• Organizations developing and launching new products
• Partnerships that are developing a new facility
What are the benefits of using MSP to an organization?
MSP is a pragmatic approach to programme management which ensures a strong leadership and governance structure is established and maintained. The emphasis is on Stakeholder Engagement and Benefits Realization Management. MSP has been implemented in the public and private sectors because it provides a number of benefits to the organizations undertaking programmes, including:
- Provides a common framework for all parties to work within - including the Client, Contractors and stakeholders
- Strong emphasis on the identification and realization of measurable benefits
- Strong Stakeholder Engagement focus ensuring that stakeholders have the opportunity to participate at the key times throughout life of the programme
- Clear communication links between the delivery team and the operational teams who will take ownership of the finished products
- Good governance is a significant part of the framework and is instituted throughout the programme
- MSP provides a method for managing the complex relationships between the interested parties in a significant, long term change initiative. MSP provides individuals with skills and techniques not usually familiar to project managers thus providing them with another tool to add to their professional toolkit.
Although both are from AXELOS, 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 (let alone MSP) nor indeed within a programme that is using MSP. Likewise, MSP does not assume that the projects it is responsible for are using PRINCE2. However,
The structure of MSP is very similar to that of PRINCE2; both have a set of themes. Table below maps the relationship between the MSP governance themes and the PRINCE2 themes. As shown in the Table, 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. 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:
Programme Governance arrangement is provided through the creation and management of –
• Benefits management strategy
• Information management strategy
• Issue resolution strategy
• Monitoring and control strategy
• Quality management strategy
• Resource management strategy
• Stakeholder engagement strategy.
At a project level there are 4 –
1. Risk management strategy
2. Quality management strategy
3. Communication management strategy4. Configuration management strategy
MSP governance theme
Related PRINCE2 theme
(Affects solution designs and thus plans)
Leadership and stakeholder engagement
Benefits realization management
Business Case & progress
Blueprint design and delivery
(Affects solution designs and thus plans)
Planning and control
Plans & progress
Business Case & progress
Risks and issue management
Risk & change
Quality and Assurance management
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, and performance analysis).
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.
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 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. .
PRINCE2 organization structure
PRINCE2 defines a project organization structure, shown in below. This comprises a Project Board, Project Executive, Senior Users, Senior Suppliers, Project Assurance, Project Manager, Project Support and Team Managers.
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 below.
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 these layers 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).
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.
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.
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.
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 project level 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.
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.
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.
Processes (PRINCE2) / Transformational Flow Processes (MSP)
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.
PRINCE2 Management Products and their purpose (summary)
Benefits Review Plan
A Benefits Review Plan is used to define how and when a measurement of the achievement of the project’s benefits, expected by the Senior User, can be made.The plan is presented to the Executive during the Initiating a Project process, updated at each stage boundary, and used during the Closing a Project process to define any post-project benefits reviews that are required.The plan has to cover the activities to find out whether the expected benefits of the products have been realized and how the products have performed when in operational use.Each expected benefit has to be assessed for the level of its achievement and whether any additional time is needed to assess the residual benefits.
A Business Case is used to document the justification for the undertaking of a project, based on the estimated costs (of development, implementation and incremental ongoing operations and maintenance costs) against the anticipated benefits to be gained and offset by any associated risks. The outline Business Case is developed in the Starting up a Project process and refined by the Initiating a Project process. The Directing a Project process covers the approval and re-affirmation of the Business Case. The Business Case is used by the Controlling a Stage process when assessing impacts of issues and risks. It is reviewed and updated at the end of each management stage by the Managing a Stage Boundary process, and at the end of the project by the Closing a Project process.
A Checkpoint Report is used to report, at a frequency defined in the Work Package, the status of the Work Package.
Communication Management Strategy
Configuration Item Record
To provide a record of such information as the history, status, version and variant of each configuration item, and any details of important relationships between them. The set of Configuration Item Records for a project is often referred to as a configuration library.
A Configuration Management Strategy is used to identify how, and by whom, the project’s products will be controlled and protected. It answers the questions:
Configuration Management Strategy
- How and where the project’s products will be stored
- What storage and retrieval security will be put in place
- How the products and the various versions and variants of these will be identified
- How changes to products will be controlled
- Where responsibility for configuration management will lie.
A Daily Log is used to record informal issues, required actions or significant events not caught by other PRINCE2 registers or logs. It acts as the project diary for the Project Manager. It can also be used as a repository for issues and risks during the Starting up a Project process if the other registers have not been set up. There may be more than one Daily Log as Team Managers may elect to have one for their Work Packages, separate from the Project Manager’s Daily Log.
End Project Report
An End Project Report is used during project closure to review how the project performed against the version of the Project Initiation Documentation used to authorize it. It also allows the:
- Passing on of any lessons that can be usefully applied to other projects
- Passing on of details of unfinished work, ongoing risks or potential product modifications to the group charged with future support of the project’s products in their operational life.
End Stage Report
An End Stage Report is used to give a summary of progress to date, the overall project situation, and sufficient information to ask for a Project Board decision on what to do next with the project. The Project Board uses the information in the End Stage Report in tandem with the next Stage Plan to decide what action to take with the project: for example, authorize the next stage, amend the project scope, or stop the project.
An Exception Report is produced when a Stage Plan or Project Plan is forecast to exceed tolerance levels set. It is prepared by the Project Manager in order to inform the Project Board of the situation, and to offer options and recommendations for the way to proceed.
A Highlight Report is used to provide the Project Board (and possibly other stakeholders) with a summary of the stage status at intervals defined by them. The Project Board uses the report to monitor stage and project progress. The Project Manager also uses it to advise the Project Board of any potential problems or areas where the Project Board could help.
The purpose of the Issue Register is to capture and maintain information on all of the issues that are being formally managed. The Issue Register should be monitored by the Project Manager on a regular basis.
An Issue Report is a report containing the description, impact assessment and recommendations for a request for change, offspecification or a problem/concern. It is only created for those issues that need to be handled formally. The report is initially created when capturing the issue, and updated both after the issue has been examined and when proposals are identified for issue resolution. The Issue Report is later amended further in order to record what option was decided upon, and finally updated when the implementation has been verified and the issue is closed.
The Lessons Log is a project repository for lessons that apply to this project or future projects. Some lessons may originate from other projects and should be captured on the Lessons Log for input to the project’s strategies and plans. Some lessons may originate from within the project – where new experience (both good and bad) can be passed on to others via a Lessons Report.
The Lessons Report is used to pass on any lessons that can be usefully applied to other projects. The purpose of the report is to provoke action so that the positive lessons become embedded in the organization’s way of working, and that the organization is able to avoid any negative lessons on future projects.A Lessons Report can be created at any time in a project and should not necessarily wait to the end. Typically it should be included as part of the End Stage Report and End Project Report.It may be appropriate (and necessary) for there to be several Lessons Reports specific to the particular organization (e.g. user, supplier, corporate or programme). The data in the report should be used by the corporate group that is responsible for the quality management system, in order to refine, change and improve the standards. Statistics on how much effort was needed for products can help improve future estimating.
A plan provides a statement of how and when objectives are to be achieved, by showing the major products, activities and resources required for the scope of the plan. In PRINCE2, there are three levels of plan: project, stage and team. Team Plans are optional and may not need to follow the same composition as a Project Plan or Stage Plan. An Exception Plan is created at the same level as the plan that it is replacing. A Project Plan provides the Business Case with planned costs, and it identifies the management stages and other major control points. It is used by the Project Board as a baseline against which to monitor project progress. Stage Plans cover the products, resources, activities and controls specific to the stage and are used as a baseline against which to monitor stage progress. Team Plans (if used) could comprise just a schedule appended to the Work Package(s) assigned to the Team Manager. A plan should cover not just the activities to create products but also the activities to manage product creation – including activities for assurance, quality management, risk management, configuration management, communication and any other project controls required.
- Understand the detailed nature, purpose, function and appearance of the product
- Define who will use the product
- Identify the sources of information or supply for the product
- Identify the level of quality required of the product
- Enable identification of activities to produce, review and approve the product
- Define the people or skills required to produce, review and approve the product.
Product Status Account
Project Initiation Documentation
The purpose of the Project Initiation Documentation is to define the project, in order to form the basis for its management and an assessment of its overall success. The Project Initiation Documentation gives the direction and scope of the project and (along with the Stage Plan) forms the ‘contract’ between the Project Manager and the Project Board. The three primary uses of the Project Initiation Documentation are to:
1. Ensure that the project has a sound basis before asking the Project Board to make any major commitment to the project
2. Act as a base document against which the Project Board and Project Manager can assess progress, issues and ongoing viability questions
3. Provide a single source of reference about the project so that people joining the ‘temporary organization’ can quickly and easily find out what the project is about, and how it is being managed.
Project Product Description
The Project Product Description is a special form of Product Description that defines what the project must deliver in order to gain acceptance. It is used to:
- Gain agreement from the user on the project’s scope and requirements
- Define the customer’s quality expectations
- Define the acceptance criteria, method and responsibilities for the project.
The Product Description for the project product is created in the Starting up a Project process as part of the initial scoping activity, and is refined during the Initiating a Project process when creating the Project Plan. It is subject to formal change control and should be checked at stage boundaries (during Managing a Stage Boundary) to see if any changes are required. It is used by the Closing a Project process as part of the verification that the project has delivered what was expected of it, and that the acceptance criteria have been met.
Quality Management Strategy
A Quality Management Strategy is used to define the quality techniques and standards to be applied, and the various responsibilities for achieving the required quality levels, during the project.
A Quality Register is used to summarize all the quality management activities that are planned or have taken place, and provides information for the End Stage Reports and End Project Report. Its purpose is to:
- Issue a unique reference for each quality activity
- Act as a pointer to the quality records for a product
- Act as a summary of the number and type of quality activities undertaken.
Risk Management Strategy
A Risk Management Strategy describes the specific risk management techniques and standards to be applied and the responsibilities for achieving an effective risk management procedure.
A Risk Register provides a record of identified risks relating to the project, including their status and history. It is used to capture and maintain information on all of the identified threats and opportunities relating to the project.
A Work Package is a set of information about one or more required products collated by the Project Manager to pass responsibility for work or delivery formally to a Team Manager or team member.
MSP Management Products and Purpose (summary)
Used to define each benefit (and dis-benefit) and provide a detailed understanding of what will be involved and how the benefit will be realized.
Benefits Management Strategy
Defines the approach to realizing benefits and the framework within which benefits realization will be achieved.
Illustrates the sequential relationship between benefits.
Benefits Realization Plan
Used to track realization of benefits across the programme and set review controls.
Used to maintain focus on delivering the required transformation and business change.
Used to validate the initiation of the programme and the ongoing viability of the programme.
Information Management Plan
Sets out the timetable and arrangements for implementing and managing the information management strategy.
Information Management Strategy
Describes the measures, systems and techniques that will be used to maintain and control programme information.
Issue Management Strategy
Used to describe the mechanisms and procedures for resolving issues.
Used to capture and actively manage programme issues.
Monitoring and Control Strategy
Defines how the programme will apply internal controls to itself.
Description of the management roles, responsibilities and reporting lines in the programme.
Used to assess whether the programme is viable and achievable.
Programme Communications Plan
Sets out the timetable and arrangements for implementing and managing the stakeholder engagement strategy.
Programme Definition Document
A document that is used to consolidate or summarize the information that was used to define the programme.
Used to describe the required outcomes from the programme, based on strategic or policy objectives.
Used to control and track the progress and delivery of the programme and resulting outcomes.
Programme Preparation Plan
A plan that details how Defining a Programme will be undertaken.
Provides a list of projects required to deliver the blueprint, with high-level information and estimates.
Quality and Assurance Plan
Sets out the timetable and arrangements for carrying out the quality and assurance strategy.
Quality and Assurance Strategy
Used to define and establish the activities for managing quality across the programme.
Resource Management Plan
Arrangements for implementing the resource management strategy.
Resource Management Strategy
Used to identify how the programme will acquire and manage the resources required to achieve the business change.
Risk Management Strategy
Defines the programme approach to risk management.
Used to capture and actively manage the risks to the programme.
Stakeholder Engagement Strategy
Used to define the framework that will enable effective stakeholder engagement and communication.
Used to record stakeholder analysis information.
Used to communicate the end goal of the programme; could be seen as providing an external ‘artist’s impression’ of the desired future state.
Author - Vijayakumar Reddy, CTO & Lead Trainer, A2A IMTCS Pvt. LTD.
© Copyright 2015 A2A - IMTCS. All rights reserved. www.iimtcs.in
The Swirl logo is a trade mark of AXELOS Limited.
MSP® is a Registered Trade Mark of AXELOS Limited.
Copyright © AXELOS Limited 2009 & 2011. Reproduced under license from AXELOS