Msp Blueprint

(1)

This document is for internal use only; no part of this document may be used, modified, deleted or expanded without prior written permission from Cap Gemini Ernst & Young.

Ref. 249193214.doc

MSP example documents

(2)

1.5 REFERENCES...5

BUSINESS MODEL...6

2.1 INTRODUCTION...6

2.2 PROGRAMME LIFE CYCLE...7

2.3 PROJECT LIFE CYCLE...25

DATA AND INFORMATION...51

3.2 ENTITIES...51

ORGANISATION, ROLES AND RESPONSIBILITIES...55

4.1 ORGANISATION STRUCTURE...55

4.2 ROLES, RESPONSIBILITIES AND REQUIRED SKILLS...56

INFORMATION SYSTEMS...65

5.2 PLANNING AND TRACKING...65

SUPPORT SERVICES...67

6.2 HUMAN RESOURCES...67

6.3 TOOLS...67

(3)

This document is the Blueprint for the programme ‘Implementation of a professional project-based working method’, which is part of a ‘Path to Profit’ programme (P2P).

The ‘Path to Profit’ programme aims to improve profitability of the organisation within a short term. The ‘Implementation of a professional project-based working method’ programme should contribute to this objective, however long term effects are not disregarded.

A Blueprint is a description of the way the organisation will deliver the capabilities described in the Vision Statement. The Blueprint document is used to maintain the programme’s focus on delivering the required transformation and benefits during the lifetime of the programme.

In this document the new capabilities are described in terms of the Business Model (MSP and PRINCE2 based), the Data Model, the Organisation, Systems and Infrastructure and finally the Service Support.

(4)

1.1 Purpose of this Document

The purpose of this document is to describe the way the organisation will deliver the capabilities described in the Vision Statement (PPM-ProgM-MSP-002). The document is used to maintain the programme’s focus on delivering the required transformation and benefits during the lifetime of the programme.

1.2 Guide to this Document

This document contains 5 chapters after the introduction:

1. the Business Model (of functions, processes and decision-making operations) is described; 2. the data and information requirements for the transformed organisation are described;

3. the organisation structure, staffing levels, roles and skills for the transformed organisation are described;

4. the information systems, tools, equipment and other facilities required for the transformed organisation are described;

5. the support services, costs, performance, service levels to enable the transformed organisation operate efficiently and effectively.

1.3 Contact Information

Cap Gemini Ernst & Young Nederland B.V. Company Name

Street Address Postal Address Papendorpseweg 100 Post Office Box 2575 3528 BJ Utrecht 3500 GN Utrecht Netherlands Netherlands Telephone Number Fax Number +31 30 689 66 66 +31 30 689 95 42 CGE&Y Contacts

Name Function E-mail

Mr. H.C. ten Zweege Manager CC PM WoW chris.ten.zweege@cgey.nl Mr. H 二十六 N 二十六二十六

二十七 L

(5)

1.4 Signature

Name H 二十六 N 二十六二十六二十七 L

Position Sector General Services

Company Cap Gemini Ernst & Young Nederland B.V.

Date 27 October 2014

Signature

1.5 References

Cap Gemini Ernst & Young, Programme Brief (PPM-ProgM-MSP-001), H 二十六 N 二十六二十六二十七L, 27 October yyyy

Cap Gemini Ernst & Young, Vision Statement (PPM-ProgM-MSP-002), H 二十六 N 二十六二十六二十七 L, 27 October 2014

Office of Government Commerce (OGC), Managing Successful Programmes, First Published 1999 / Fourth Impression 2003, The Stationary Office, London 2003 Office of Government Commerce (OGC), Managing Successful Projects with PRINCE2, Third Edition 2002 / Second Impression 2002, The Stationary Office, London 2002

(6)

This chapter contains a description of the business models of functions, processes and operations, including operational costs and performance levels, of the required ‘future’ state.

2.1 Introduction

The business functions, processes and operations within the scope of the ‘Implementation of a

professional project-based working method’ programme are those related to the Programme Life Cycle (PLC1) or Project Life Cycle (PLC2).

All activities to improve running operations and/or launch new business are performed either within a programme or a project (a programme consists of one or more projects).

Differences between Programmes and Projects

Although there is no formally accepted definition of Programme Management, authoritative views on the subject (such as the UK CCTA) will generally describe it as:

 a coherent control framework for successfully implementing high-impact business strategies to maximise business benefits;

 involving the co-ordinated management and integration of a number of projects and services in a complex, large-scale and diverse environment;

 encompassing, in a complementary manner, change to both business operations and to IT systems which achieves transformation within the organisation;

 characterised by success being dependent on achievement of business benefits, rather than completing deliverables on time and within budget.

A summarised definition of Programme Management is:

 Programme Management is the management of a coherent process of significant business and IT change, across business areas, involving multiple projects and services, to achieve common business aims, where success is measured by realisation of significant business benefits.

It is useful to distinguish between programmes and projects in simple terms through what they deliver:

 programmes deliver a business vision; they are focused on managing change, complexity, and integration and they achieve business benefits measured in tangible and intangible terms

 projects deliver products through a structured life cycle and the resulting deliverables are measured against a specification through a defined acceptance process.

In the end it is decided by senior management, whether the initiative becomes a programme or a project.

In case a programme is started the Programme Life Cycle becomes valid; this is the complex of processes and principles from the idea to start the programme until the programme is closed. In case of a project, the Project Life Cycle becomes active; projects can be started from a programme.

(7)

2.2 Programme Life Cycle

The Programme Life Cycle is the complex of processes and principles from the idea to start the programme until the programme is closed. These 6 MSP processes are implemented at the end of the programme:

The first process, Identifying a Programme is triggered by a need for change in the form of some sort of Programme Mandate, which provides the high level requirements of the programme. A Programme Brief is prepared which defines the aim and envisaged benefits to the organisation.

If the programme appears to be justified and senior management agrees to proceed to the Defining a Programme process then the initial vision is refined into the Vision Statement and the Blueprint prepared. At the same time strategies and procedures are developed for managing people, progress, costs, benefits, risks, issues, quality and communications. The programme is thereby clearly defined and the Sponsoring Group decide whether to formally commit to the programme or not.

(8)

If they give approval to proceed, then the next process, Governing a Programme, is used to appoint individuals to Programme Management and support roles and to set procedures and infrastructure. The programme then runs. The purpose of the process, Managing the Portfolio, is to provide an effective monitoring and management regime for the projects within the programme such that they deliver according to plan. There are links to PRINCE2, the Project Management method.

The programme will deliver new capabilities, services or business operations. The purpose of the process Managing Benefits is to track the specific benefits, which were identified at the start of the programme and drive through the process of realising these benefits throughout the programme and at the end. This process also manages the transition between old and new ways of working.

The activities in Closing a Programme ensure that the programme does not ‘drift on’ and there is a clear focus on achieving the ‘end-goal’.

The processes above are described in detail:

Identifying a Programme

Purpose

The purpose of ‘Identifying a Programme’ is to analyse the Programme Mandate and to structure and formalise the ideas and concepts into a Programme Brief such that:

 the programme can be identified in terms of what must be achieved and what the anticipated benefits for the organisation(s) involved will be;

 management decisions can be made on whether the programme is justified and whether a commitment should be made to proceed to the next process of ‘Defining a Programme’. ‘Identifying a Programme’ is typically a short process, taking only a few weeks to complete.

Activities

The strategic issues facing an organisation will drive the initial scoping of a programme: the programme takes on a range of activities and projects designed to address these strategic issues. In the process ‘Identifying a Programme’ several activities take place:

 accepting the Programme Mandate;

 appointing the Senior Responsible Owner;

 producing the Programme Brief;

 creating the Terms of Reference for Defining a Programme;

 gaining approval to proceed. Accepting the Programme Mandate:

The Programme Mandate defines the overall objectives for the programme and positions the programme within the organisation’s corporate mission, goals, strategies and other initiatives.

(9)

The Programme Mandate is the input for the process ‘Identifying a Programme’; it could be a single cohesive document, but it could also be the result of facilitated workshops or interviews with key members of the organisation(s).

The Programme Mandate should be a short, but clear, management level statement containing the following information:

 what the programme is intended to deliver in terms of new services and/or operational capability;

 how the organisation(s) involved will be improved as a result of delivering the new services/capability;

 how the programme fits into the corporate mission and goals and any other initiatives that are already underway or planned during the lifetime of the programme.

The Programme Mandate represents the high-level business requirements for the programme. Appointing the Senior Responsible Owner

A programme requires top-level sponsorship in order to gain, and maintain, the necessary commitment to the expenditure, resources, timescales, and impact of change, that will be involved. The Sponsoring Group represents those who have a major interest in the programme and who will be its key

stakeholders. Providing the Programme Mandate is the responsibility of the Sponsoring Group. The Senior Responsible Owner has ultimate responsibility for the successful outcome of the programme. The Senior Responsible Owner should be appointed as soon as possible to provide leadership, direction and a focal point for the programme, particularly during the initial planning discussion. The Senior Responsible Owner should be appointed from within the Sponsoring Group. Producing the Programme Brief

The Programme Brief is the first main deliverable of the programme. It provides the basis for a formal management decision whether or not to start with the programme.

The Programme Brief is prepared from the initial information provided in the Programme Mandate and with significant input from the Sponsoring Group and other senior management from the

organisation(s). The Senior Responsible Owner is responsible for preparing the Programme Brief. Creating the Terms of Reference for Defining a Programme

The process ‘Defining a Process’ involves the detailed planning and definition of all aspects of the programme. Terms of Reference for this work should be produced, together with a plan for the amount of resources required and the estimated duration.

Gaining approval to proceed

The Programme Brief and the Terms of Reference and plan for ‘Designing a Plan’, must be formally endorsed and approved by the Sponsoring Group to confirm their understanding of and overall commitment to the programme’s vision, its expected benefits, risks, issues, timescales, resources and costs.

Input, Output, Decisions

Management Information Usage Explanation

(10)

objectives for the programme

Programme Brief Output Provides the basis for deciding whether the programme is justified

Terms of Reference and plan for

‘Defining a Programme’ Output Description of the work needed to develop a detailed definition of the programme Appointment of Senior Responsible

Owner Output Appointed from within the Sponsoring Group

Approval to proceed or stop Decision Formal commitment from the Sponsoring Group to proceed into ‘Defining a Programme’ or stop or consider another course of action

Responsibilities

Role Responsibility

Senior Responsible Owner Responsible for developing the Programme Brief and Terms of Reference for work on programme definition.

Sponsoring Group Provides the Programme Mandate. Responsible for giving formal commitment and approval to proceed with the programme.

Defining a Programme

Purpose

A programme is a major undertaking for most organisations, Inevitably it will mean significant funding and change to the organisation involved.

The activities of ‘Defining a Programme’ provide the detailed information that establishes the definition of the new capabilities and the way they will be delivered:

 how will the programme be managed and run;

 what changes will be implemented within the organisation;

 what benefits will be delivered and when;

 how much it will cost?

The total set of information about the programme is the Programme Definition.

The Programme’s Sponsoring Group must give their approval for the Programme Definition before the programme proceeds. This approval will be conditional on whether the programme presents a sound basis for the investment.

Activities

In the process ‘Defining a Programme’ several activities take place:

 establishing a team to define the programme;

 developing the Vision Statement;

 developing the programme’s Blueprint;

 developing the Business Profiles;

 designing the Programme’s Organisation Structure;

(11)

 identifying and analysing the Stakeholders;

 developing the Communications Strategy and Communications Plan for the programme;

 defining the Benefits Management Strategy and Benefits Plan;

 defining the Quality Management Strategy;

 defining the Risk Management Strategy and developing the Risk Log;

 developing the Programme Plan;

 preparing the programme’s Financial Plan;

 developing the programme’s Business Case;

 gaining approval to proceed.

Establishing a team to define the programme

The Senior Responsible Owner usually requires the support of a small team to help develop the Programme Definition. Members of this team may fulfil formal roles defined in the programme’s organisation structure. In particular the Programme Manager may already be appointed at this time (recommendation).

Developing the Vision Statement

The outline Vision Statement developed in the Programme Brief should be further refined to cover:

 a detailed description of the future business capability;

 details of the operational measures for future costs, performance and service levels that will be achieved.

The Vision Statement is a business-focused definition of what to expect from the transformed organisation, its service levels, costs, and etcetera. The Vision Statement is used to communicate the end-goal of the programme to the stakeholders.

Developing the programme’s Blueprint

The Blueprint defines the structure and composition of the changed organisation that after delivery should exhibit the capabilities in the Vision Statement. The Blueprint is a detailed description of what the organisation looks like in terms of its business processes, people, information systems and facilities and data. It is used to maintain the focus of the programme on the delivery of the new capability. Detailed business analysis and design and design may be helpful to fully explore the opportunities and options for the Blueprint; this work may be carried out as a feasibility study or small project in its own right.

In this process an initial version of the Blueprint is created; the Blueprint is maintained and refined throughout the programme. It should cover the following information:

 business models of the new functions, processes and operations;

 organisation structure, staffing levels, roles and skill requirements necessary to support the future business operations;

 information systems, tools, equipment, buildings, required for the future business operations;

 the data required for the future business operations;

(12)

Developing the Business Profiles

A Benefit Profile defines when a specific benefit can start to be realised following the delivery of a new capability and the requirements for the business operations in order to actually realise that benefit. A Benefit Profile should be developed for each identified benefit (and dis-benefit); the Benefit Profile is derived from the Vision Statement and the Blueprint. To assess the success of benefit realisation, each benefit will also require a mechanism for measuring the improvement as a result of its realisation. Designing the Programme’s Organisation Structure

The organisation structure for managing a programme must enable effective decision-making on the programme and efficient communication flows around the various members of the programme team. What roles can be distinguished in a programme is described in the principle ‘Programme Management Organisation’.

Each role on the Programme Organisation Structure should be defined with the specific responsibilities required, the individuals who will take on these roles and responsibilities should be identified, and the amount of work required for each role needs to be balanced against the amount of time that the individual assigned to that role is able to contribute to the programme.

Designing the Project Portfolio

The Project Portfolio is a list of the projects that together will deliver the capability described in the Blueprint. The projects may be existing, ongoing work that will need to be adopted into the programme, or they may be new initiatives that will require commissioning by the programme at the appropriate moment.

Prioritising the projects into the Portfolio is a major task. The effect on staff and the organisation of delaying or bringing forward a project can be significant. Therefore in this activity an outline schedule showing the estimated relative timescales for the projects should be developed and included into the Project Portfolio.

It is likely not all projects can be identified at this point yet, therefore in this process only the outline Project Portfolio is created; the Project Portfolio is maintained and updated throughout the programme (as part of the Programme Plan).

Projects outside the scope of the programme may conflict with the programme’s objectives. These should be recognised at this point and the potential conflict with the programme defined so that appropriate action can be taken when the programme is formally approved.

Identifying and analysing the Stakeholders

The programme will inevitably affect the working lives of many individuals and groups. Each of these should be identified, together with their particular interest in the programme. It is also important to identify any stakeholders who are likely to be worse off as a result of the programme, as their interest may lie in preventing the programme’s successful outcome.

(13)

The analysis of the Stakeholders will identify information needs and communication flows that should be established as part of the programme communications. A Stakeholder Map is a useful way to capture and manage information about a large number of stakeholders.

It is likely not all stakeholders can be analysed at this point yet, therefore in this process the initial version of the Stakeholder Map is created; the Stakeholder Map is maintained and updated throughout the programme.

The members of the project teams within the programme must be included as stakeholders in the programme.

Developing the Communications Strategy and Communications Plan for the programme The Communications Strategy for the programme should cover information flows outward (from the programme) and inward (into the programme). The programme will need input from various

stakeholders to inform and influence the programme during implementation.

The Communications Plan indicates when, what, how and with whom information flows between the programme and the stakeholders will be established and maintained; in this process the initial version of the Communications Plan is created; the Communications Plan is maintained and updated throughout the programme.

Defining the Benefits Management Strategy and Benefits Plan

The Benefits Management Strategy describes how the programme’s benefits will be managed from initial identification and definition through to delivery and realisation.

The Benefit Profiles are used to develop an overall Benefits Plan, showing how the total set of benefits will be realised during the programme. The full cooperation and support of the Business Change Managers during the identification and planning of these benefits is an important criterion for the ultimate success of the programme.

In this process the initial version of the Benefits Plan is created; the Benefits Plan is maintained and updated throughout the programme (as part of the Programme Plan).

Defining the Quality Management Strategy

The Quality Management Strategy defines the approach the programme will take to ensure that quality is built into the programme’s processes and the Project Portfolio from the outset.

Furthermore the strategy should cover the way quality will be assured in the programme’s deliverables. The Programme Plan should include when assurance activities will be undertaken and by whom. Defining the Risk Management Strategy and developing the Risk Log

The Risk Management Strategy defines how risks to the programme will be identified, analysed, monitored and controlled. Programme risks include the risks from the projects within the Project Portfolio. The programme requires a central Risk Log.

In this process a Risk Log with the initial risks is created. Developing the Programme Plan

(14)

Programme planning is an ongoing process throughout the programme. The Programme Plan is a major control document for the programme.

The Programme Plan is a living document, updated as the programme processes. The Initial Programme Plan, which is created in this process, should contain:

 the list of projects (Project Portfolio);

 the costs associated with each project;

 the benefits expected (Benefit Profiles and Benefits Plan);

 the risks identified (the Risk Log);

 the resources required to manage, support and provide assurance to the programme;

 the overall schedule for the Project Portfolio (in outline). Preparing the programme’s Financial Plan

The initial estimates of costs and expenditure outlined in the Programme Brief need to be fully developed into a detailed Financial Plan for the programme. The Financial Plan provides details of the overall financial management of the programme, including budget information, and how the financial spend on the programme will be managed and controlled, together with a profile of the expected costs and when they will be incurred.

Developing the programme’s Business Case

The Business Case represents the programme’s costs, benefits and risks, so that the overall viability of the programme can be assessed and appropriate management decisions made about whether to continue with the programme or not.

The level of detail required in the Business Case will depend on the particular programme and its business environment.

The Initial Business Case is created in this process. The Business Case is reviewed regularly throughout the programme to confirm the continued relevance and viability of the programme.

Gaining approval to proceed

The Programme Definition must be formally endorsed and approved by the Sponsoring Group to confirm that it meets their expectations and requirements. The programme’s Vision Statement, Blueprint and Business case provide the basement for the endorsement, other documents as the Programme Plan may also be required.

Programme Brief Input Approved by the Sponsoring Group at the end of ‘Identifying a Programme

Programme Definition containing: Output

 Blueprint Output Description of how the new capability will be delivered by the programme

 Vision Statement Output Description of the ‘end-goal’ of the programme

(15)

 Benefit Management Strategy Output Description of how the benefits of the programme will be managed from identification through delivery

 Benefits Plan Output Overall schedule for monitoring when benefits are expected to be realised

 Benefits Profile Output Control Tools for tracking the progress of each benefit and dis-benefit identified

 Risk Management Strategy Output Description of how risks will be identified, assessed and monitored during the programme

 Risk Log Output Central documentation on all known programme risks

 Quality Management Strategy Output Description of how the programme will build quality into its deliverables and processes, and how quality will be reviewed and assessed during the programme

 Financial Plan Output Description of how the programme’s financial management and expenditure control procedures, budgets and projected costs are defined

 Programme Plan Output Description of the major planning and control information about the programme that includes the Project Portfolio

 Communications Strategy Output Description of how the programme will establish and maintain communication flows with all the stakeholders

 Stakeholder Map Output Matrix of stakeholders and their specific interests

 Communications Plan Output Schedule of how the programme will achieve the communication flows required

 Programme Organisation Structure

Output Description of the tailored Organisation Structure for managing the programme

Approval to proceed or stop Decision Formal commitment from the Sponsoring Group to proceed into ‘Establishing a Programme’ or stop or consider another course of action

Senior Responsible Owner Overall responsible for directing the work of defining the programme and for providing the interface with the Sponsoring Group and other

stakeholders.

Programme Definition Team Assistants to the Senior Responsible Owner to define and document all the information about the programme.

Sponsoring Group Endorsement and commitment to the programme.

Governing a Programme

Purpose

The purpose of ‘Governing a Programme’ is to appoint the individuals to the various management and support roles required for the programme and to ensure the procedures, infrastructure and support mechanisms are set-up.

Programmes need co-ordination and manage large quantities of data. An efficient management and support regime will enable management attention to focus on delivering the Blueprint.

(16)

Activities

In the process ‘Governing a Programme’ several activities take place:

 setting up the organisation and people-related elements of the programme;

 setting up the processes and procedures required to manage the programme;

 establishing the benefits measurements processes;

 setting up the infrastructure and tools required to help manage the programme;

 establishing the communications channel.

Setting up the organisation and people-related elements of the programme

The Senior Responsible Owner should appoint the Programme Manager (if not already done in the process ‘Defining a Programme’) and ensure the other individuals identified as part of the organisation structure for the programme are appointed.

The Programme Support Office is established by appointing the necessary personnel to administer the programme’s document management system, provide support for the programme’s planning and management processes, and provide management information on the status and progress of the programme.

Any training needs for the individuals appointed are identified and appropriate training courses scheduled.

The Stakeholder Map may be updated at this point.

Setting up the processes and procedures required to manage the programme

Procedures are defined that will be implemented and managed by the Programme Support Office using existing or tailored corporate standards if available.

The Programme Support Office procedures should include:

 configuration management, covering all deliverables;

 planning, defining the content and level of detail required for the plans;

 tracking and reporting, including mandatory project planning;

 communications management;

 quality management;

 risk management;

 issues management, both the issue log and issue management;

 resource management, covering resource selection and allocation. Also programme standards are set up and confirmed:

 Human Resource policies;

 technology standards;

 procurement and contract management standards;

 general business practices.

(17)

The programme must be able to measure the benefits achieved as a result of delivering the new

capability. The Benefit Profiles define how the benefit will be measured. The mechanism for measuring the benefits should be set up so that the ‘before state’ can be captured as well as the improved situation achieved as a result of the programme.

(18)

Setting up the infrastructure and tools required to help manage the programme

Tools to support the Programme Support Office functions need to be acquired and implemented such as:

 websites;

 planning and scheduling tools;

 estimating tools.

Establishing the communications channel

The Communications Strategy defines the mechanisms the programme will use to inform the stakeholders about the programme and to encourage feedback into the programme. The required mechanisms are set up for communicating to all identified stakeholders in the programme. It is useful to begin using the programme’s communication channels by providing details to the stakeholders of all individuals appointed to specific roles on the programme as early as possible.

Benefit Management Strategy and Benefit Profiles

Input Description of how measurement mechanisms are set up and the ‘before state’ metrics are established

Risk Management Strategy and

Risk Log Input Description of how document management and control mechanisms are established Quality Management Strategy Input Description of how document management and control

mechanisms are established

Programme Plan Input Description of the major planning and control information about the programme that includes the Project portfolio Communications Strategy and

Stakeholder Map

Input Description of how the programme will establish and maintain communication flows with all the stakeholders Programme Organisation Structure Input Description of the tailored Organisation Structure for

managing the programme used to appoint and train personnel Programme Support Office tools

and procedures Output Tools and procedures that will be managed and controlled by the Programme Support Office Issues Log Output Log used to capture and assess issues raised at the

programme level Programme standards, policies and

procedures

Output Standards, policies and procedures established by the Programme Support Office

Senior Responsible Owner Appointment of the Programme Manager and ensuring the other roles for managing the programme are appointed.

Programme Manager Responsible for establishing the Programme Support Office and the programme’s procedures and standards.

(19)

Managing the Project Portfolio

Purpose

The delivery from the projects within the Project Portfolio provides the organisation with the new capabilities defined in the Blueprint.

The purpose of ‘Managing the Project Portfolio’ is to provide an effective monitoring and management regime for the projects so that their benefits are delivered according to the Programme Plan.

The activities of this process are repeated as necessary for each trance of projects.

Activities

In the process ‘Managing the Project Portfolio’ several activities take place:

 delineating the project;

 scheduling the project;

 refining the Programme Plan;

 starting up the project;

 monitoring the progress;

 closing the project;

 communicating. Delineating the project

The projects within the Project Portfolio are scoped and defined. This means that for new projects a Project Brief is developed and for existing projects the project documentation is reviewed and possibly these projects are re-scoped to align them with the Blueprint.

The objective is for each project to have a clear scope and boundary and a measurable definition of its required deliverables. For each of these projects within the Project Portfolio the following should be identified:

 brief description of the deliverable;

 dependencies on other projects;

 target delivery date;

 cost profile;

 resource profile;

 Benefit Profile(s).

The Dependency Network is developed, showing how each project’s inputs and outputs are related to each other (see the principle ‘Programme Planning and Control’).

Scheduling the project

The projects are grouped into tranches (see the principle ‘Programme Planning’) and the deliverables scheduled into the Programme Plan.

The projects are scheduled by considering all their interfaces with other projects and any opportunities for sharing or pooling resources.

(20)

Each tranche should complete at an identifiable point such as that the programme can demonstrate delivery of some of the expected benefits. ‘Early wins’ often help the programme achieve stronger commitment and support.

It may be useful to schedule a formal Programme Benefits Review at some of these points to assess the success or failure of the benefits identification, management and realisation processes and make any adjustments necessary.

The end of each tranche also provides a management control point for assessing the continued viability of the programme’s Business Case. Therefore a formal decision-point must be scheduled, on which a decision may be taken whether to proceed with the next tranche, or suspend the programme to allow for realignment or redesign, or abandon the programme and reallocate the resources on the remaining projects.

Refining the Programme Plan

Any appropriate tolerances against the time and cost variances are built into the Programme Schedule and the Programme Plan is refined.

The Programme Plan is updated as the programme progresses with actual completion and delivery dates for the project

Starting up the project

The Programme Manager is responsible for commissioning projects within the Project Portfolio and should ensure the appropriate individuals are appointed to the Project Board. The Project Board is ultimately accountable to the programme for the successful completion of the project within specified time, costs and quality parameters.

As each project begins, the Programme Manager discusses the Project Brief with the Project Management Team.

The Programme Support Office provides assistance to the projects in the development of their plans and reporting mechanisms to the programme: Each Project Plan should include a schedule of regular progress reporting to allow tracking of the projects against a Programme Plan.

Monitoring progress

Progress against the Programme Plan is monitored and tracked, using information provided by the projects. Project Reports should align with the information held at the programme level.

Any deviations from the project plans are assessed for impact on the rest of the programme, and the impact of any change within a project on the rest of the programme is managed.

Monitoring is based on (at least):

 deliverables (customer expectations, quality);

 time completion;

 risks;

(21)

As the programme progresses, and at least at the end of each tranche, the programme’s documentation is updated and maintained.

Closing the project

The process of closure is supported, reflecting any lessons learned across subsequent projects. The project teams are assisted in the closure of their projects, including the hand-over of the deliverables or outcome. The Post Project Reviews should be scheduled to fit into the Programme Benefit Review process.

Communicating

Throughout the running of the programme, it is vital to maintain communications across the projects and with the various stakeholders.

Blueprint Input The Blueprint is updated and refined as the programme progresses

Programme Plan Input The Programme Plan is updated with the detailed schedule of projects and refined as the programme progresses

Benefit Profiles Input The Benefit Profiles are updated and monitored as the programme progresses

Lessons Learned Reports Output The Lessons Learned Reports from the projects are

distributed across the remaining projects within the Portfolio Project Briefs Output Project Briefs are used for commissioning new projects

within the Project Portfolio

Risk Log Input Log used to monitor risks associated with project delivery, updated as projects deliver

Progress Reports Input Project Reports are used to monitor progress and to update the Programme Plan and Blueprint

End of Tranche Review Decision End of Tranche Review is a management decision to proceed, re-align or potentially abandon the programme

Communication Plan Input The Communication Plan is updated as the programme progresses

Sponsoring Group Input at major decision points on the programme, such as End of Tranche Reviews

Senior Responsible Owner Ongoing decision-making for the programme and advising the Programme Manager

Programme Manager Responsible for the overall progress of the Project portfolio and monitoring against the Programme Plan and Blueprint

Business Change Manager Responsible for ensuring the projects’ deliverables can be readily integrated into the operational areas concerned so that benefit realisation can be achieved

Programme Support Office Operating the programme information management system and providing advice and support to the Programme Manager Advise to projects on planning and reporting

(22)

Project Board Delivery of project to the programme

Managing Benefits

Purpose

The programme will deliver new capabilities, services or business operations.

The purpose of ‘Managing Benefits’ is to track the specific benefits that were identified at the start of the programme and drive through the process of realising benefits from the new capabilities, service or operations in measurable terms.

This process requires the management of the transition between the ‘old’ and ‘new’ ways of working.

Activities

In the process ‘Managing Benefits’ several activities take place:

 monitoring benefits;

 measuring benefits;

 communicating;

 realising benefits;

 managing a transition;

 updating the Blueprint. Monitoring benefits

The project teams are briefed on their benefit responsibilities and reporting requirements for the programme.

Throughout the programme, progress against the Programme Plan is reviewed and delivery of the Blueprint tracked, to identify changes to benefits achievement. The Benefits Profiles and Benefits Plan are adjusted to reflect any such changes; adjustments may be identified from a range of different events, such as:

 projects are not progressing to plan;

 the business operations that will use the project’s deliverables are unstable;

 forward plans are no longer realistic based upon experience to date;

 external circumstances have changed affecting the future course of the programme;

 the perception of the programme’s objectives has changed. Measuring benefits

The Benefits Management Strategy and the individual Benefit Profiles define how each benefit will be measured. Measuring benefits should focus on assessing the improvement in performance of the business operations (comparing ‘before’ and ‘after’).

Communicating

It is vital to maintain communications across the projects and with the various stakeholders about the benefits expected from the programme.

(23)

As each project approaches its closure, the quality of the outcome and its fitness for purpose are confirmed.

Not every project within the Project Portfolio will deliver outcomes directly contributing to the

Blueprint. Some projects are providing pre-requisites for other projects; by definition these projects are not directly linked to benefits realisation.

Managing a transition

The relevant business operations are prepared for delivery of the project’s outcome and the project’s handover to the business operations facilitated.

Performance measurement of the relevant business operations should be established, to assess improvements made as a result of the delivery change.

Updating the Blueprint

As a new capability is delivered into the business operations, the Blueprint and Benefits Plan should be updated to reflect the change and assess any impact on future benefits realisation.

Benefit Profiles Input The Benefit Profiles are updated to reflect changes Programme Plan Input The Programme Plan is used to monitor the progress Progress Reports and Lessons

Learned Reports Input The Progress Reports and Lessons Learned Reports from the projects are used to identify the impact on benefits Benefits Plan Input The Benefits Plan is used to monitor progress and updated to

reflect achievements Improvements to the business

operations Output Improvements as a result of delivery of new capability are measured Blueprint Input The Blueprint is used to identify which business operations

will realise the benefits and then updated to reflect the change

Senior Responsible Owner Responsible for the resolution of conflicts and approval of changes affecting the course of the programme

Programme Manager Responsible for the adjustments of the Project Portfolio to optimise benefits delivery, and for updating and maintaining programme documentation

Business Change Manager Responsible for delivering the projects’ outcomes into the business and realisation of the benefits by business operations

Closing a Programme

Purpose

Programmes tend to last for a longer period, and naturally then there is the danger of allowing the programme to become part of ‘normal’ business.

(24)

The purpose of ‘Closing a Programme’ is to ensure the focus on achieving the end-goal of the programme, formally recognising when the programme has completed its portfolio of projects and delivered the required new capability defined in the Blueprint.

Benefits have been delivered and realised along the way; however the majority of major business benefits may not be fully realised until some time after the last project has delivered its outcome. This process identifies the need for future assessment of benefit realisation as well as a review of those achieved so far.

Activities

In the process ‘Closing a Programme’ several activities take place:

 confirming the project closure;

 reviewing programme benefits;

 updating and finalising programme documentation;

 disbanding Programme Management and support functions;

 informing stakeholders. Confirming the project closure

The programme confirms that all projects within the portfolio have been formally closed, and the remaining activities have been defined and assigned to the relevant business operations.

If the programme is being closed prematurely (before the Blueprint is achieved), the remaining live projects that are still required by the organisation need to be reassigned to business management or to another programme.

Reviewing programme benefits

A formal Programme Benefits Review should be conducted to assess the performance of the

programme and identify lessons learned that may benefit other programmes. This review should include an assessment of the management processes of the programme itself, as well as the level of

achievement of the Blueprint, and the benefits that already have been realised.

A further review should be scheduled for an appropriate point after closure of the programme: the Post Programme Review. This review should assess the success of the programme’s entire benefits

realisation process, including those benefits that may not have been ready for measurement and assessment when the programme closed. The Post Programme Review should be scheduled when the transformed organisation has reached a steady state.

Updating and finalising programme documentation

Programme documentation should be reviewed to ensure that any issues, risks and outstanding actions have been attended to appropriately.

Disbanding Programme Management and support functions

The programme’s infrastructure and management processes are disbanded including releasing

individuals from their appointed roles. Any contracts used by the programme are finalised and closed or the responsibility for the contracts handed over to business management.

(25)

Informing stakeholders

Programme closure is confirmed with the Senior Responsible Owner and programme sponsors. All stakeholders need to be informed of programme closure and should be provided with relevant information about the programme’s outcome, the new procedures and operations and any other relevant changes to the organisation that were delivered by the programme.

All programme documentation Input All programme documentation is reviewed and formally closed and filed

Confirmation of Programme

Closure Output The Confirmation of Programme Closure is a formal notification to the stakeholders of programme closure Programme Benefits Review Output The Programme Benefits Review is an assessment of the

programme itself and the benefits delivered so far. A planned date for the Post Programme Review should be set during this review

Senior Responsible Owner Chairperson of the Benefits Review and responsible for the release of personnel from the Programme Management team, and for the sign-off for programme closure

Sponsoring Group Responsible for the sign-off for programme closure and release of the Senior Responsible Owner

Programme Manager Responsible for the closure of the programme documentation and disbanding the programme infrastructure

Business Change Manager Responsible for the assessment of achievement of benefits realised at this point and establishing ongoing performance measures

(26)

2.3 Project Life Cycle

The Project Life Cycle is the complex of processes and principles from the idea to start the project until the project is closed. As a result of the programme these 8 PRINCE2 processes are implemented: 1. SU Starting up a Project

2. IP Initiating a Project 3. DP Directing a Project 4. CS Controlling a Stage

5. MP Managing Product Delivery 6. SB Managing Stage Boundaries 7. CP Closing a Project

8. PL Planning

The processes are described below in detail:

Starting up a Project

Overview

The work of the process is built around the production of three elements:

 ensuring that the information required for the Project Brief is available;

 designing and appointing the Project Management Team;

 creating the Initiation Stage Plan.

The objective of the process is to enable a controlled start to the project by ensuring that:

 all the necessary Project Management authorities exist for undertaking the project;

 sufficient information is available to formalise the terms of reference for the project;

 individuals are appointed who will undertake the work required in Project Initiation and/or will take significant Project Management roles in the project;

 the work required for Project Initiation is planned;

 the organisation that will host the project team is informed of the existence and implications of the new project.

The process begins by receiving from some external source the definition of a problem or opportunity, which the project has to satisfy. ‘Project Mandate’ is a term used for whatever information comes in to trigger the project, be it a Feasibility Study or details on the back of an envelope. The closer the quality of information in the Project Mandate can get to the ideal described in the Product Outline for the Project Mandate, the easier the start-up process will be.

If the project is part of a programme, the programme should provide the Project Brief and appoint some, if not all, members of the Project Board, thus reducing the work required in this process. The target work location is informed of the impending project, and requests are made for any appropriate logistical support required to carry out Project Initiation. An additional input, which will help with the creation of both the Initiation and Project Plans, is the Project Approach, explaining the way in which it is intended that the end products of the project are to be produced.

(27)

Activities

An overview of the process, its steps and major products per step, is given below:

Project Mandate Input The trigger for the project Project Board Executive and Project

Manager Appointments Output Agreed job definitions for the Executive and Project Manager Project Management Team

Structure Output The basis of discussion with the other appointees and with senior management Agreed job Definitions Output Roles tailored to the project and the individual

(28)

Update Project Management Team

Structure Output Appointed and confirmed Project Management Team

Risk Log Output Blank log ready to record risks

Project Brief Output Submission to the Project Board as part of the justification for initiation

Project Approach Output This forms part of the Project Plan description within the Project Initiation Document and is an input to Planning Quality (IP1) and the Planning process (PL)

Draft Initiation Stage Plan Output An essential product to gain approval to perform Project Initiation. The Plan for the Initiation Stage should be discussed informally with the Project Board. The asurance and support roles identified will help with creation of the plan

Corporate or Programme

Management. Appointing the Business Executive and Project Manager Business Executive (and Project

Manager) Designing and appointing the Project Management TeamPreparing the Project Brief Project Manager Preparing the Project Approach

Preparing the Initiation Stage Plan

Initiating a Project

Overview

A successful project should observe the following principles:

 a project is a finite process with a start and end;

 all parties must be clear on what the project is intended to achieve, why it is needed, how the outcome is to be achieved, and what their responsibilities are in that achievement so that there can be genuine commitment to the project;

 well-managed projects have an increased chance of success.

Following these principles will ensure that the project can be successfully scoped and managed to its completion. Initiating a Project (IP) is aimed at laying down the foundations for the fulfilment of the principles described above. An overview of the process, its steps and major products per step, is given below:

The purpose of Initiating a Project is to draw up a Contract in the form of a Project Initiation Document, so that there is common understanding of:

 the adequacy of reasons for doing the project;

 what key products the project will deliver;

 how an when these will be delivered and at what cost;

 the scope of what is to be done;

 any constraints which apply to the product to be delivered;

(29)

 who is to be involved in the project decision making;

 how the quality required will be achieved;

 what Risks are faced;

 how the project is to be controlled;

 the next commitment the Project Manager is looking for (the next Stage Plan).

This information can be agreed as informally as the Project Board and Project Manager wish. The Project Manager should always document the understanding, however small the project, and get it signed by the Project Board, even if this is one person. People’s recollection of a verbal agreement can differ weeks, or even days, later. In formal terms the objectives of Initiating a Project are to:

 document and confirm that an acceptable Business Case exists for the project;

 ensure a firm and accepted foundation to the project, prior to commencement of the work, via the creation of the Project Initiation Document;

 enable and encourage the Project Board to take ownership of the project;

 enable and encourage the Project Board to make a decision on whether the project is viable, and to agree to the commitment of resources to the first stage of the project;

 provide the baseline for the decision-making processes required during the project’s life;

 ensure that by carrying out Initiation in an organised manner, the investment of time and effort required by the project is made wisely, taking account of the risks to the project;

 monitor progress of Initiating a Project (IP) against the plans for the Initiation Stage.

Activities

(30)

Project Brief Input This document should contain the overall approach to quality and the top-level project quality criteria. These are refined and expanded during this process.

Customer & Suppler QMS Input Standards with which projects must comply

Project Approach Input To establish the most appropriate approach to quality, there is a need to know how the projects work is to be approached as this could have a fundamental effect on the methods and resources

Risk Log Update Risks identified in the log may affect the Project Plan Project Quality Plan Output This will contain the results of Planning Quality (IP1) and

will be an element of the Project Initiation Document output from Assembling a PID (IP6)

(31)

production is the prime reason for carrying out the process Business Case Output Extract from the Project Brief and update with the latest

(more detailed) information

Communication Plan Output Identify all communication paths, frequency, methods and reasons

Project Conditions Output This will form part of the Project Initiation Document Issue Log Output Created in readiness to record all Project Issues

Quality Log Output Created in readiness to record all details of quality checks Project Filing Structure Output Part of the Project Initiation Document

Lessons Learned Report Output A blank report ready to record aspects of Project Management which go well or badly

Project Initiation Document Output Final end product of Assembling a PID (IP6) and of Initiation

Project Manager Preparing the Project Quality Plan Preparing the Project Plan Preparing the Business Case Preparing the Communication Plan Preparing the Project set up

Assembling the Project Initiation Document

Directing a Project

Overview

Senior Project Management staff that have the authority and responsibility for defining what is required from the project, authorising the funds for the project, committing the resources and communicating with external interested parties, will typically delegate day-to-day charge of the project to a Project Manager. However, they must exercise overall control and take the key decisions. It is also important that levels of authority and decision-making processes are clearly identified.

Directing a Project runs from after the start-up of the project until its closure and includes the work to:

 authorise the initiation of the project;

 provide management direction and control throughout its life;

 liaise with corporate and Programme Management;

 confirm project closure.

This process is aimed at the level of management above the Project Manager, that is the Project Board. The Project Board manages by exception, that is, it monitors via reports and controls through a small number of decision points. There should be no need for other ‘progress meetings’ for the Project Board. The Project Manager will inform the Project Board of any exception situation. There needs to be a flow of information from the Project Board to corporate or Programme Management during the project. The objectives of Directing a Project are to:

 ensure the ultimate success of the project judged by;

(32)

 delivery to agreed time, cost and quality parameters;

 manage the identified risks to the project;

 ensure the effective management of all people and resources concerned with the project;

 commit the required resources;

 make decisions on any changes when requested by the Project Manager;

 provide overall direction and guidance throughout the project;

 make decisions on exception situations;

 ensure that the project and the products remain consistent with business plans and the external environment;

 ensure that the necessary communications mechanisms are in place;

 sponsor appropriate external communication and publicity about the project.

This process covers the direction of the project throughout its life cycle. The Project Board proactively manages the project’s response to the external environment. Within the project the Project Board should manage by exception. The Project Board members are normally busy executives with a range of responsibilities, and demands on their time should be kept to a minimum, while fulfilling their responsibilities to the project. The key responsibilities are:

 overall directional decision making;

 resource commitment.

Where the project is part of a programme, the authority to direct the project is delegated to the Project Board by the Senior Responsible Owner. Where decisions are required which are outside the defined authority of the Project Board, these must be referred to the Senior Responsible Owner for a decision. The key processes for the Project Board are predominantly event-driven and target the Project Board members to a small number of key decision points, plus informal discussions where required. These key processes break into four main areas:

 Initiation (starting the project off on the right foot);

 Stage Boundaries (commitment to further work after checking results so far);

 Ad Hoc Direction (monitoring progress, providing advice and guidance);

 Project Closure (confirming the project outcome and bringing the project to a controlled close).

Activities

(33)

Job Definitions Input Details of job responsibilities Project Management Team

Structure Input Details of who is to be involved in the management of the project Project Brief Update Contains the What and Why of the project and is the

document that specifies the Project Boards terms of reference Draft Initiation Stage Plan Update The work to be approved

Project Start-up Notification Output Request for logistics support

Authorisation to Proceed Output The approved plan for the Initiation Stage Draft Project Initiation Document Input The document to be approved

Next Stage Plan Input Validation of the next part of the Project Plan Approved Project Initiation

(34)

Next Stage Plan or Exception Plan Input Plan for which the Project Manager is seeking approval Product Checklist Input Summary list of major products to be produced by the plan

with key dates

Updated Project Plan Input To allow the Project Board to Review the whole project status

Updated Business Case Input To allow the Project Board to check that the project is still justified

Project Initiation Document Input Used to provide a baseline against which to assess the advisability of any deviations

Project Management Team changes

(included with Stage Plan) Input To allow the Project Board to ratify any appointment changes Updated Risk Log Input Check that the risks are still acceptable

End Stage Report Input Report of stage just completed. Helps assessment of current situation. (There would not be one of these for the Initiation Stage).

Request for authorisation to proceed Input Usually a stage approval form for the Project Board to sign Authorisation to Proceed Output Authorisation to proceed with the submitted plan. During

Project Initiation the Project Board decides how formal or informal it wishes the approval to be. The Project Board, of course, has the authority to reject the plan. It may ask for a re-submission or decide to close the project.

Progress Information Output The Communication Plan may indicate the need to advise an external group of progress

Highlight reports Input Regular feedback on progress from the Project Manager Exception Report Input Early warning of a deviation. May trigger the creation of an

Exception Plan

Request for Advice Input Situations where a decision is needed which is beyond the authority of the Project Manager

Information to and from external sources

Two-Way Either feedback from a Project Board request or new information, which affects the direction of the project. Communication Plan Input Details the interested parties

Corporate or Programme

Management Reports Output Feedback on project progress

Exception Plan request Output Request in reaction to the inputs noted above Premature close Output Closing the project before its expected end

Project Initiation Document Input Used as the baseline against which to assess how far the project deviated from its initial basis. Also contributes some of the information against which to judge the success of the project.

Operational and maintenance

acceptance Input Confirmation that the final product can be used and supported

Project Closure Recommendation Input Assurance from the Project Manager that everything has been done.

End Project Report Input More information on which to judge the success of the project.

(35)

Follow-on Action

Recommendations Approval Recommendations for all pending issues and other future actions Post Project Review Plan Approval Suggested plan for assessing the achievement of project

benefits. Ratified by the Project Board to be passed on to the people responsible for carrying it out.

Lessons Learned Report Approval Project lessons that have been learned which might be useful to pass on to other projects

Project Closure Notification Output Notification that facilities and support can be withdrawn

Project Board Authorising Initiation Authorising Project

Authorising a Stage or Exception Plan Giving ad hoc directions

Confirming Project Closure

Controlling a Stage

Overview

Once a decision has been taken to proceed with work, and resources have been committed, the Project Management Team must be focused on delivery within the tolerance laid down. This means controlled production of the agreed products:

 to stated quality standards;

 within cost, effort and time agreed;

 ultimately to achieve defined benefits. To achieve this success, the project must:

 focus management attention on delivery of the stage’s products or outcomes;

 focus the resources used during the stage towards this end;

 keep the risks under control;

 keep the Business Case under review;

 carefully monitor any movement away from the direction and products agreed at the start of the stage to avoid ‘scope creep’ and loss of focus.

This process handles day-to-day management of the project. It is started after approving the Stage Plan in Authorising a Stage or Exception Plan (DP3). It describes the work of the Project Manager.

Controlling a Stage (CS) drives Managing Product Delivery (MP), the interfaces being the authorisation of a Work Package any specified reports and the return confirmation that the Work Package has been completed satisfactorily.

The objectives of Controlling a Stage (CS) are to:

 deliver the right products;

 ensure that quality is achieved as planned;

(36)

 correctly direct and conduct work on products;

 properly direct and utilise resources;

 update plans with actual data, enabling progress to be checked against the plan;

 correctly cost resource usage;

 correctly manage any deviations from Stage or Project Plans;

 inform all interested parties about project progress in a timely manner;

 ensure that projects are stopped or re-directed if the reasons for setting them up have been invalidated by internal or external events.

Central to the ultimate success of the project is the day-to-day control of the work, which is being conducted. Throughout a stage this will consist of a cycle of:

 authorising work to be done (CS1);

 monitoring progress information about that work (CS2 and CS9);

 watching for changes (CS3 and CS4);

 reviewing the situation and triggering new work authorisations (CS5);

 reporting (CS6);

 taking any necessary corrective action (CS7).

If changes are observed which are forecast deviations beyond agreed tolerances, Escalating Project Issues (CS8) covers the activities of bringing the situation to the attention of the Project Board. Other factors, which must be borne in mind, are that:

 the current stage contains work and involves resource expenditure which have been authorised by the Project Board. It is therefore important to give the Project Board feedback on progress against its expectations;

 all individual items of work in a stage should be authorized;

 project work can be adequately controlled only against a plan;

 if the project is to be successful, the Project Manager and Project Board must react quickly to changes and deviations from the agreed Stage Plan.

Activities

(37)

(38)

Stage or Exception Plan Input New work from Stage Plan, either expected or as an outcome of Taking Corrective Action (CS7). The Stage Plan may need to be updated by Assessing Progress (CS2) in minor areas such as a result of discussions between the Project Manager and the Team Manager during Authorising a Work Package (CS1)

Product Description(s) Input Description of the required product(s) including quality criteria

Proposed Work Package Input Details of the work required, including dates and information on any constraints

Work trigger Input Corrective actions

Authorisation to proceed Input Authorisation by the Project Board to proceed with the Stage Work Package Output Formal handover of responsibility for the detailed conduct of

the work and delivery of any products from the Project Manager following agreement with the Team Manager Plan adjustments Output Any adjustments after negotiation with the Team Manager Checkpoint Reports Input Flows of information, either written or verbal depending on

the need for formality. The information will cover current status against plan

Quality Log Input Confirmation, or otherwise, from the Team Manager(s) that the work and products have been produced to the quality standard specified

Work Package Status Input To update the Stage Plan

Stage Plan Update Updated with actual data to date and forecasts

New Project Issues Input Any Issues being raised against the project from whatever source, to be logged in the Issue Log and the type of Project Issue to be decided

Issue Log Update Repository of all Project Issues and their status

Business Case Input Reference back to the Business Case to evaluate the impact of the Project Issue

Stage Plan Input One of the bases for impact analysis Project Plan Input To check if the issue affects the project

Issue Log Update A list of all outstanding Project Issues and their status, updated with impact analysis information

Risk Log Update Current risks which may be affected by an Issue. To be updated if any action is recommended which will affect a risk or generate a new one

Issue Log Input This product will show the current situation regarding all Project Issues. These may be needed for reference when deciding on appropriate action to deal with them

Risk Log Input This product shows the current understanding of the problems and threats to the project