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 best part of it is that when PRINCE2 and MSP are used together, various activities and documentation are no longer required due the excellent integration provision that they both together offer. The bad part or the tough area of it is that some integration work is still needed to ensure they work together well given a particular organizational context. This paper discusses at a high level what is probably required in order to use PRINCE2 and MSP together. It is written primarily from the project team’s perspective and it therefore assumes that the reader is familiar with PRINCE2 in a way.

 

MSP excellently if not absolutely complements Kotter’s eight-stage change management model (below)

 

 

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

Approach to Integrating PRINCE2 and MSP 

Themes

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 strategy

4. Configuration management strategy

 

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 and Assurance 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, and performance analysis).

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.

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 below. 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 Figure 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).

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.

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.

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.

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

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. 

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.

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.

Management Products

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. List of all management products of PRINCE2 and MSP are shown below.

 

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.

Business Case

 

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. 

 

Checkpoint Report 

A Checkpoint Report is used to report, at a frequency defined in the Work Package, the status of the Work Package.

Communication Management Strategy 

A Communication Management Strategy contains a description of the means and frequency of communication to parties both internal and external to the project. It facilitates engagement with stakeholders through the establishment of a controlled and bi-directional flow of information.

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.

Configuration Management Strategy 

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: 

 

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

Daily Log 

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. 

Exception Report

 

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.

Highlight Report 

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.

Issue Register 

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.

Issue Report 

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.

Lessons Log 

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.

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.

Plan

 

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. 

 

Product Description 

A Product Description is used to:

 

• 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

The Product Status Account provides information about the state of products within defined limits. The limits can vary. For example, the report could cover the entire project, a particular stage, a particular area of the project, or the history of a specific product. It is particularly useful if the Project Manager wishes to confirm the version number of products.

Project Brief

A Project Brief is used to provide a full and firm foundation for the initiation of the project and is created in the Starting up a Project process. In the Initiating a Project process, the contents of the Project Brief are extended and refined in the Project Initiation Documentation, after which the Project Brief is no longer maintained.

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.

Quality Register

 

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.

Risk Register

 

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.

Work Package

 

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)

Benefit Profile

 

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. 

 

Benefits Map

 

Illustrates the sequential relationship between benefits.

Benefits Realization Plan

 

Used to track realization of benefits across the programme and set review controls.

Blueprint

 

Used to maintain focus on delivering the required transformation and business change.

Business Case

 

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.

Issue Register

 

Used to capture and actively manage programme issues.

Monitoring and Control Strategy

 

Defines how the programme will apply internal controls to itself.

Organization Structure

 

Description of the management roles, responsibilities and reporting lines in the programme.

Programme Brief

 

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.

Programme Mandate

 

Used to describe the required outcomes from the programme, based on strategic or policy objectives.

Programme Plan

 

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.

Projects Dossier

 

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.

Risk Register

 

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.

Stakeholder Profiles

 

Used to record stakeholder analysis information.

Vision Statement

 

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. 

PRINCE2® is a Registered Trade Mark of AXELOS Limited.

MSP® is a Registered Trade Mark of AXELOS Limited.

Copyright © AXELOS Limited 2009 & 2011. Reproduced under license from AXELOS