Msp Blueprint

© Copyright 2014, Cap Gemini Ernst & Young Nederland B.V.

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.

MSP Blueprint

MSP Blueprint - example

Ref. document.doc

MSP example documents

MANAGEMENT SUMMARY .........................................................................................................III

INTRODUCTION..................................................................................................................................4

1.1 PURPOSE OF THIS DOCUMENT..........................................................................................................4 1.2 GUIDE TO THIS DOCUMENT.............................................................................................................4 1.3 CONTACT INFORMATION..................................................................................................................4 1.4 SIGNATURE......................................................................................................................................5 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.1 INTRODUCTION...............................................................................................................................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.1 INTRODUCTION...............................................................................................................................65 5.2 PLANNING AND TRACKING............................................................................................................65

SUPPORT SERVICES.........................................................................................................................67

6.1 INTRODUCTION...............................................................................................................................67 6.2 HUMAN RESOURCES......................................................................................................................67 6.3 TOOLS............................................................................................................................................67 6.4 OTHER DEPARTMENTS: PURCHASING, FINANCE, COMMUNICATIONS, HUMAN RESOURCES.........67

Management Summary

III

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.

iv

Management Summary

III

5

Introduction

1

1.1 Purpose of this DocumentThe 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 DocumentThis 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 InformationCap Gemini Ernst & Young Nederland B.V.

Company Name

Street Address Postal AddressPapendorpseweg 100 Post Office Box 25753528 BJ Utrecht 3500 GN UtrechtNetherlands Netherlands

Telephone Number

Fax Number

+31 30 689 66 66 +31 30 689 95 42

CGE&Y Contacts

Name Function E-mailMr. H.C. ten Zweege Manager CC PM WoW [email protected]. H.C. ten Zweege Author of document [email protected]

6

Introduction

1

1.4 Signature

Name H.C. ten Zweege

Position Sector General Services

Company Cap Gemini Ernst & Young Nederland B.V.

Date 28 October 2014

Signature

1.5 ReferencesCap Gemini Ernst & Young, Programme Brief (PPM-ProgM-MSP-001), H.C. ten Zweege, 28 October yyyy

Cap Gemini Ernst & Young, Vision Statement (PPM-ProgM-MSP-002), H.C. ten Zweege, 28 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

7

Business Model

2

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

8

Business Model

2

2.2 Programme Life CycleThe 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.

9

Business Model

2

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

1

Business Model

2

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 OwnerA 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 BriefThe 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 ProgrammeThe 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 proceedThe 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 Programme Mandate Input The trigger for the programme, that defines the overall

objectives for the programmeProgramme Brief Output Provides the basis for deciding whether the programme is

justifiedTerms of Reference and plan for Output Description of the work needed to develop a detailed

1

Business Model

2

‘Defining a Programme’ definition of the programmeAppointment 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 ResponsibilitySenior 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; designing the Project Portfolio; 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;

1

Business Model

2

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 programmeThe 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 StatementThe 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 BlueprintThe 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; costs, performance and service levels for the support required for the future business operations.

Developing the Business ProfilesA 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.

1

Business Model

2

Designing the Programme’s Organisation StructureThe 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 PortfolioThe 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 StakeholdersThe 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.

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.

1

Business Model

2

Developing the Communications Strategy and Communications Plan for the programmeThe 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 PlanThe 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 StrategyThe 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 LogThe 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 PlanProgramme 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;

1

Business Model

2

the overall schedule for the Project Portfolio (in outline).

Preparing the programme’s Financial PlanThe 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 CaseThe 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 proceedThe 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.


Management Information Usage Explanation Programme Brief Input Approved by the Sponsoring Group at the end of ‘Identifying

a ProgrammeProgramme 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 Business Case Output Description of the costs, risks and benefits of the programme 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

1

Business Model

2

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

Responsibilities

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

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

1

Business Model

2

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

Establishing the benefits measurements processesThe 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.

1

Business Model

2

Setting up the infrastructure and tools required to help manage the programmeTools 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 channelThe 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.


Management Information Usage Explanation 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

Responsibilities

Role ResponsibilitySenior 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.Programme Support Office Acting to establish the support tools and infrastructure for the programme.

1

Business Model

2

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

2

Business Model

2

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 PlanAny 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 projectThe 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 progressProgress 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; estimates (remains to be done).

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

Closing the project

2

Business Model

2

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.

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


Management Information Usage Explanation Blueprint Input The Blueprint is updated and refined as the programme

progressesProgramme Plan Input The Programme Plan is updated with the detailed schedule of

projects and refined as the programme progressesBenefit Profiles Input The Benefit Profiles are updated and monitored as the

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

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

within the Project PortfolioRisk Log Input Log used to monitor risks associated with project delivery,

updated as projects deliverProgress Reports Input Project Reports are used to monitor progress and to update

the Programme Plan and BlueprintEnd of Tranche Review Decision End of Tranche Review is a management decision to

proceed, re-align or potentially abandon the programmeCommunication Plan Input The Communication Plan is updated as the programme

progresses

Responsibilities

Role ResponsibilitySponsoring Group Input at major decision points on the programme, such as End of Tranche

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

ManagerProgramme Manager Responsible for the overall progress of the Project portfolio and

monitoring against the Programme Plan and BlueprintBusiness 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

Project Board Delivery of project to the programme

2

Business Model

2

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

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

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

2

Business Model

2

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


Management Information Usage Explanation Benefit Profiles Input The Benefit Profiles are updated to reflect changesProgramme Plan Input The Programme Plan is used to monitor the progressProgress 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

Responsibilities

Role ResponsibilitySenior Responsible Owner Responsible for the resolution of conflicts and approval of changes

affecting the course of the programmeProgramme 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.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.

2

Business Model

2

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 closureThe 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 benefitsA 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 documentationProgramme documentation should be reviewed to ensure that any issues, risks and outstanding actions have been attended to appropriately.

Disbanding Programme Management and support functionsThe 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.

Informing stakeholdersProgramme closure is confirmed with the Senior Responsible Owner and programme sponsors.

2

Business Model

2

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.


Management Information Usage Explanation All programme documentation Input All programme documentation is reviewed and formally

closed and filedConfirmation 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

Responsibilities

Role ResponsibilitySenior 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

2

Business Model

2

2.3 Project Life CycleThe 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 Project2. IP Initiating a Project3. DP Directing a Project4. CS Controlling a Stage5. MP Managing Product Delivery6. SB Managing Stage Boundaries7. CP Closing a Project8. 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.

Activities

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

2

Business Model

2


Management Information Usage Explanation Project Mandate Input The trigger for the projectProject 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 individualUpdate Project Management Team Structure

Output Appointed and confirmed Project Management Team

2

Business Model

2

Risk Log Output Blank log ready to record risksProject Brief Output Submission to the Project Board as part of the justification

for initiationProject 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

Responsibilities

Role ResponsibilityCorporate 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 ApproachPreparing 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; any constraints which apply to the project; who is to be involved in the project decision making; how the quality required will be achieved; what Risks are faced;

2

Business Model

2

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


3

Business Model

2


Management Information Usage Explanation 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 complyProject 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 PlanProject 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)

Project Plan Output This is the ultimate Deliverable from the process and its

3

Business Model

2

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

(more detailed) informationCommunication Plan Output Identify all communication paths, frequency, methods and

reasonsProject Conditions Output This will form part of the Project Initiation DocumentIssue Log Output Created in readiness to record all Project IssuesQuality Log Output Created in readiness to record all details of quality checksProject Filing Structure Output Part of the Project Initiation DocumentLessons Learned Report Output A blank report ready to record aspects of Project

Management which go well or badlyProject Initiation Document Output Final end product of Assembling a PID (IP6) and of

Initiation

Responsibilities

Role ResponsibilityProject Manager Preparing the Project Quality Plan

Preparing the Project PlanPreparing the Business CasePreparing the Communication PlanPreparing the Project set upAssembling 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; the ability of the results of the project to deliver the business benefits set out in the Business Case;

3

Business Model

2

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


3

Business Model

2


Management Information Usage Explanation Job Definitions Input Details of job responsibilitiesProject 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 approvedProject Start-up Notification Output Request for logistics supportAuthorisation to Proceed Output The approved plan for the Initiation Stage

Draft Project Initiation Document Input The document to be approvedNext Stage Plan Input Validation of the next part of the Project PlanApproved Project Initiation Document

Output Base lined after approval by the Project Board for later measurement against actual achievement.

3

Business Model

2

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

with key datesUpdated Project Plan Input To allow the Project Board to Review the whole project

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

justifiedProject Initiation Document Input Used to provide a baseline against which to assess the

advisability of any deviationsProject 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 acceptableEnd 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 signAuthorisation 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 ManagerException Report Input Early warning of a deviation. May trigger the creation of an

Exception PlanRequest for Advice Input Situations where a decision is needed which is beyond the

authority of the Project ManagerInformation 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 partiesCorporate or Programme Management Reports

Output Feedback on project progress

Exception Plan request Output Request in reaction to the inputs noted abovePremature 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.

Customer Acceptance Input Confirmation that the customer accepts the products

3

Business Model

2

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

Responsibilities

Role ResponsibilityProject Board Authorising Initiation

Authorising ProjectAuthorising a Stage or Exception PlanGiving ad hoc directionsConfirming 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; deliver products on time and to cost within agreed tolerance; correctly direct and conduct work on products;

3

Business Model

2

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


3

Business Model

2

3

Business Model

2


Management Information Usage Explanation 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 actionsAuthorisation to proceed Input Authorisation by the Project Board to proceed with the StageWork 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 PlanStage 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 analysisProject Plan Input To check if the issue affects the projectIssue Log Update A list of all outstanding Project Issues and their status,

updated with impact analysis informationRisk 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

Project Plan Input Data to check if any stage problem (or potential change)

3

Business Model

2

would have an impact on the project plan)Stage Plan Update The latest information regarding progress on the work

currently in hand, or completed since the process was last conducted or since the Stage Plan provides the baseline against which progress is measured, and against which the meeting of the stage tolerances is measured. The product will be updated with any minor amendments

Plan Deviation Output The information to be passed to Taking Corrective Action (CS7)

Stage Status Information Output The information that goes forward to Reporting Highlights (CS6)

Stage End Notification Output Trigger for Managing Stage Boundaries (SB)Notification of Project End Output Trigger for Closing a Project (CP)Project Issue Output Trigger plus information for Escalating Project Issues (CS8) Work trigger(s) Output Trigger(s) plus information for Authorising a Work Package

(CS1)

Stage Plan Input Information on products delivered and the status of schedule and budget

Plan revisions Input Plan revisions resultling from consideration of corrective action

Checkpoint Reports Input Information about progress on the project against planRisk Log Input Have any risks changed?Issue Log Input Information about any potential problems which need to be

brought to the attention of the Porject BoardCommunication Plan Input Identification of interested parties who may need information

at this timeHighlight Report Output Information formatted as required by the Project BoardCommunications to interested Parties

Output Content as defined in the Communication Plan

Plan deviation Input The plan problem which requires corrective actionIssue Log Input This contains details of any Project Issues, Requests for

Change or Off-specifications that could be causing deviations from plan

Risk Log Update The change in a risk may be causing the corrective action and its status may need updating with details of the action taken

Stage Plan Update Amended with the implications of the corrective action selected

Work trigger Output Corrective ActionRequest for Advice Output Request for advice on corrective action

Project Initiation Document Input This baseline allows comparison of any change against original expectations

Stage Plan Input Updated with the actuals so far, this shows the likely impact on the stage of the deviation in question

Business Case Input The latest version allows examination for impact of the Issue on the Business Case

4

Business Model

2

Project Plan Input This indicates the project status and the overall affect of any deviation

Issue Log Input Details of the change(s) which may have caused the exception situation

Risk Log Input Details of the risk exposure which may have caused the escalation

Project Board Response In and out May pass on to Producing an Exception Plan (SB6)Exception Report Output Description of the exception situation, its impact, options,

recommendation and impact of the recommendation

Approved Work Package Input Signed-off confirmation that the Work Package is complete and acceptable

Work Package status Output To update the Stage plan

Responsibilities

Role ResponsibilityProject Manager Preparing the Work Packages

Updating the Stage PlansUpdating the Risk LogUpdating the Issue LogIssuing Notifications (Stage End, Project Closure)Preparing Highlight ReportsIssuing Requests for AdvicePreparing Exception ReportsSigning Off Work Packages

Managing Product Delivery

Overview

Managing Product Delivery allows a controlled break between Project Manager and product creation/provision by Suppliers.

The Supplier may not be using PRINCE2, so this is a statement of the required interface between the Team Manager and the PRINCE2 method being used in the project.In many projects the Project Manager will allocate work directly to the individual who is to do the work and combine this process with the authorisation of the Work Package.

The objectives of this process are to allow a Team Manager to: agree work with the Project Manager; get it done; hand it back to the Project Manager.

Where external Suppliers are involved, the acceptance of Work Packages will be affected by the terms of their contract.

The Team Manager ensures that planned products are created and delivered by a team to the project by: making certain that work on products allocated to the team is effectively authorised and agreed;

4

Business Model

2

accepting and checking authorised Work Packages; ensuring that work conforms to any interfaces identified in the Work Package; creating a Team Plan for the work; ensuring that the work is done; ensuring that work progress and forecasts are regularly assessed; ensuring that completed products meet quality criteria; obtaining approval for the completed products.

Activities



Management Information Usage Explanation Work Package Update Package put together by the Project Manager in Authorising

a Work Package (CS1) for the Team Managers agreement. May be revised in coming to an agreement

Team Plan Update Details of the Work Package are added to the teams workload

Risk Log Update The Team Manager adds any risks identified in the Team Plan to the log

Authorised Work Package Output Work Package checked and agreed by the Team Manager

Authorised Work Package Input Work agreed with the Project ManagerTeam Plan Update Record allocation, planned effort, actual effort and progress,

4

Business Model

2

plus any modifications required.Quality Log Update Details of checks carried out on the product to ensure

conformance to quality standards, are added to the logCheckpoint Reports Output Progress reports to the Project Manager at the frequency

defined in the Work PackageCompleted Work Package Output Confirmation that the Work Package is complete and

acceptable

Completed Work Package Input Details of the work agreed with the Project ManagerApproved Work Package Output Products approved as defined in the Work Package

Responsibilities

Role ResponsibilityTeam Manager Agreeing the Work Packages

Preparing Checkpoint ReportsCompleting Work PackagesIssuing Notifications Completed Work Packages

Managing Stage Boundaries

Overview

Projects, whether large or small, need to be focused on delivering business benefit, either in their own right or as part of a larger programme. The continuing correct focus of the project should be confirmed at the end of each stage. If necessary, the project can be re-directed or stopped to avoid wasting time and money.

Before the end of each stage except the final one the next stage is planned, together with a review and update of the Business Case, risk situation and overall Project Plan.There could well be changes of personnel and management, necessitating changes to the Project Management Team.There is also a requirement to re-visit the Project Quality Plan and project approach to check whether they need changing or refining.The steps of this process will also be used when creating an Exception Plan.

The objectives of the process are to: assure the Project Board that all products in the current Stage Plan have been completed as defined; provide the information needed for the Project Board to assess the continuing viability of the

project; obtain authorisation for the start of the next stage, together with its delegated tolerance margins; record any information or lessons which can help later stages of this project and/or other projects.

The stage immediately post-Initiation is normally approved at the same time as the Project Initiation Document. In that case this process would need customising for that situation.

Activities


4

Business Model

2

4

Business Model

2


Management Information Usage Explanation Issue Log Input May contain information that affects the next stageCurrent Stage Plan Input The results of the current stage may affect the planning of the

new stage activities.Project Brief Input Contains the what and why of the project and is the

document that specifies the Project Boards terms of referenceTrigger for the next Stage Plan Input Invokes Planning a Stage (SB1) to produce next Stage PlanProject Management Team Structure

Update This should be updated with any changes for the coming stage

Project Plan Update Provides the major products of the stage and a high-level estimate of its duration and resource needs

Risk Log Update Update with any new or changed risks revealed by the coming Stage Plan

Draft next Stage Plan Output Produced by this process

Current Stage Plan Input The results of the current stage may affect the project planning

Next Stage Plan Input The extra detail in the Stage Plan may reveal the need to modify the Project Plan

Project Approach Update Events may have occurred which modify the approachProject Quality Plan Update Quality results so far may show the need to adjust the PlanProject Plan Update Revised in the light of actuals from the current stage and the

forecast of the next Stage Plan. Also updated to reflect any changed or extra products sanctioned by the Project Board.

Project Plan Input Have any changes to the Project Plan been made which affect the Business Case

Issue Log Input Are there any new Issues that threaten (or could improve) the Business Case?

Risk Log Input Are there any new risks that threaten the Business Case?Next Stage Plan Input Does anything in the next Stage Plan affect the Business

Case?Exception Plan Input If the Managing Stage Boundaries (SB) process has been

triggered by an exception situation, does the Exception Plan affect the Business Case?

Business Case Update Revised to account for any changes to the project that may affect it

Project Plan Input Have any changes to the Project Plan been made that affect the risks?

Next Stage Plan or Exception Plan Input Does the new plan contain any new or changed risks?Risk Log Update Has anything changed?Issue Log Update Are there any new issues that are caused by (or could

improve) the new risks?

Current Stage Plan Input Contains information about the products, cost and dates of the current stage

Issue Log Input Identifies the Issues raised during the stage

4

Business Model

2

Risk Log Input Source of information about the status of current risksQuality Log Input Information about the Quality activities and results from the

teams that produced productsCommunication Plan Input May contain a requirement to send information to an external

interested party at this time.Next Stage Plan Input Data for the End Stage Report Lessons Learned Report Update Updated with any new lessonsRequest for authorisation to Proceed

Output This may be formal or informal according to the projects situation

End Stage Report Output Performance of the stage against plan Exception Plan Output Alternative to the next Stage Plan

Current Stage Plan Input This is the plan from which the deviation has occurred and which will define the tolerances and the extent of the deviation. It can also be used to extrapolate what will happen if the deviation were allowed to continue

Issue Log Input This may contain details of the reasons for the project or stage going into exception

Exception Report Input This warning should have been sent to the Project Board at the first indication of a probable deviation. It is the trigger for the start of this process.

Risk Log Update What is the impact of the deviation and Exception Plan on the risks?

Exception Plan Output The product of this process, a plan which replaces the current stage plan

Responsibilities

Role ResponsibilityProject Manager Preparing the Next Stage Plan, End Stage Report

Preparing the Exception PlanUpdating the Project Approach, Project Quality Plan, Project Plan, Business Case, Issue Log, Risk Log

Closing a Project

Overview

One of the defining features of the project is that it is finite; it has a start and an end. If the project loses this distinctiveness, then it loses its effectiveness over purely operational management approaches.

So a clear end to the project: is always more successful than the natural tendency to drift into operational management. It is a

recognition by all concerned that either the operational regime must now take over, or the products from this project become feeds into some subsequent project, or into some larger programme or the current project has run its course;

helps achieve business objectives by avoiding waste and by providing a useful opportunity to take stock of achievements and experience;

4

Business Model

2

provides an opportunity to ensure that all unachieved goals and objectives are identified, so that they can be addressed in the future.

Preparation for closing the project is triggered by the approaching end of the final stage of the project. All the Closing a Project processes may be done in parallel or at least with considerable overlap.

The method of Closing a Project has to be tailored to suit the needs of the particular project. For example, if the project is part of a programme or a series of projects, this may affect how some of the fundamental principles, such as follow-on actions, are handled. The project may be closely connected with a subsequent project and may have been planned ahead that way. All the results of the first project feed into the subsequent one with no need to be concerned about maintenance, operation or other follow-on actions. If the project has delivered an intangible product, for example to bring about a change in philosophy, then the objective of ensuring operation and support arrangements are in place may not be appropriate.

The following is an illustrative list of aims of the process to close the project. According to the type of project, they may not all be required: ensure that the objectives or aims set out in the Project Initiation Document have been met; confirm fulfilment of the Project Initiation Document and the Customer’s satisfaction with the

products; provide formal acceptance of the products; ensure that all expected products have been handed over and accepted by the Customer or relevant

subsequent project; ensure that arrangements for the support and operation of project products are in place (where

appropriate); if the project has been closed prematurely, document what has been achieved and recommend the

way forward; identify any recommendations for follow-on actions; capture lessons resulting from the project; prepare an End Project Report; plan any Post Project Review required; notify the host location of the intention to disband the project organisation and resources.

The process covers the Project Manager’s work to wrap up the project either at its end or at premature close. Most of the work is to prepare input to the Project Board to obtain its confirmation that the project may close.The Project Initiation Document is examined to check the actual results of the project against the original (or as modified by the Project Board) expectations. All planned products should have been approved and delivered to the Customer or be ready for hand-over.

The Project Manager prepares an End Project Report, which comprehensively evaluates the actual project outcome versus that envisaged in the Project Initiation Document.There may be a number of Project Issues, which were held over by the Project Board. These may lead to new projects or enhancements to the products of the current project during its operational life. The Project Manager sorts these out into appropriate follow-on actions.

4

Business Model

2

The Lessons Learned Report, which has been developed during the project, is now completed and made available outside the project.

The host location is notified that the provided resources will no longer be required and release dates are given.

Activities



Management Information Usage Explanation Project Initiation Document Input Statement of the projects acceptance criteriaIssue Log Input Check that all project issues have been closed or transferred

to follow-on actions.Product Status account Input Confirmation from Configuration Management records that

all products are approved Premature Close Direction Input Instruction from the Project board to close the project before

its expected endNotification of Project End Input The trigger from stage monitoring that the normal end of the

project is nearCommunication Plan Input Identification of any other interested party who needs to

knowCustomer acceptance Output Confirmation that the customer accepts the productsOperational & Maintenance Output Confirmation that the product can be operated and supported

4

Business Model

2

acceptanceProject Closure Notification Output Notice to the host location that the project is about to close,

so that plans can be made to disband and redeploy any provided Project Support Services

Draft Communication to interested parties

Output Notification to other parties, to be approved by the Project board

Project files Archive Preserve the project records for project auditors or other enquiries

Issue Log Input Un-actioned Project Issues will form the basis of any follow-on actions

Business Case Input This will reveal benefits whose achievement cannot be measured and will therefore need a Post Project review

Risk Log Input Check for any risks to the operational use of the end-product(s)

Post Project Review Plan Output Suggested plan for a Post Project review for ratification by the Project Board

Follow-on Action Recommendations

Output Recommendations for further work which the Project Board must direct to the appropriate audience for attention

Issue Log Input The reasons for Off-Specifications may provide lessons for future projects.

Risk Log Input What risks were considered and what happened to them may provide lessons for future projects

Quality Log Input This may indicate whether the quality policy and procedures were adequate. Statistics of the number of quality checks made and the errors found are also useful to a quality assurance function

Project Initiation Document Input Original statement of project objectives, scope and constraints

Lesson Learned Report Update This should be an ongoing document from the start of the project, completed with relevant notes

End Project Report Output Evaluation of the management, quality and technical performance of the project and achievement of objectives as defined in the Project Initiation Document

Responsibilities

Role ResponsibilityProject Manager Confirming the customer acceptation

Archiving the Project FilesPreparing the Post Project Review PlanPreparing the Follow-on Action RecommendationsPreparing the End Project Report

4

Business Model

2

Planning

Overview

Effective Project Management relies on an effective planning and control process. Even small projects require planning.

Planning provides all personnel involved in the project with information on: what is required; why it is required; how it will be achieved and by whom, using what specialist equipment and resources; when events will happen.

Product-based planning is a key component of PRINCE2 and provides a comprehensive approach to effective planning. It is the method, which enables the Project Manager to: define what the project has to deliver; provide definitions of success to the people working on the project via measurable statements of the

quality required; objectively monitor and control progress.

Planning is a repeatable process, and plays an important role in other processes, the main ones being: Planning an Initiation Stage (SU6). Planning a Project (IP2). Planning a Stage (SB1). Producing an Exception Plan (SB6).

Planning is also an iterative process. There will be a series of loops through the planning steps as extra information becomes available or adjustments are made.

In PRINCE2, plans are produced on the basis that: plans are constructed by identifying the final products required, all requisite intermediate products,

and then the activities and appropriate resources necessary to deliver them; plans should cover management and quality needs as well as the Customer’s products; there should be assurance that all activities are thought through in advance and to a level consistent

with the control requirements identified in the Project Initiation Document.

PRINCE2 provides a product-based start to the planning activity and a planning framework, which can be applied to any type of project. This involves: establishing what products are needed; describing the products and their quality criteria; determining the sequence in which each product should be produced and any dependencies.

After these initial steps, the normal steps of planning are used: deciding when the activities should be done and by whom; estimating how much effort each activity will consume; estimating how long the activities will take; agreeing what quality control activities and resources are needed;

5

Business Model

2

calculating how much the overall effort will cost; producing the budget from the cost of the effort plus any materials and equipment which must be

obtained; assessing the risks contained in the plan; identifying the management control points needed.

Activities


5

Business Model

2


Management Information Usage Explanation Project Approach Input The approach may impact on the number of stages and plan

levels required.Project Quality Plan Input The contents of plans, level of detail and monitoring needs,

will be affected by the Project Quality PlanCompany Planning Standards Input These may identify the planning and estimating tools and

methods to be usedProject Brief (or PID) Input Scope of the work to be plannedResource Availability Input The start and end dates of resource availability, and the

amount of time they are available in this period are requiredRisk Log Update Any new risks should be addedPlan Design Output A statement of the planning approach, levels of plan, tool set

to be used and major monitoring methodsProduct Breakdown Structure Output A hierarchical table of all the products required to be created

in the planProduct Descriptions Output A description of each product plus its quality criteriaProduct Checklist Output A draft list of major products of the planProduct Flow Diagram Output A diagram showing the sequence in which the products

should be producedList of Activities Output All the activities required to produce the productsActivity Dependencies Output Any dependencies between the activities in the above listActivity Estimates Output Estimated activities are passed to the scheduling processSchedule Output A list of activities and their allocated resources plus the dates

over which the activities will take placeCompleted Plan for Approval Output For approval of the Project Board

Responsibilities

Role ResponsibilityProject Manager Designing the Plans

Preparing the Product Breakdown Structure, Product Descriptions, Product Checklist, Product Flow Diagram, List of Activities, Activity Dependencies, Activity Estimates, ScheduleUpdating the Risk LogPreparing the Plans

5

Data and Information

3

This chapter describes the data and information required for the future business operations, together with details of how existing data and information will be changed or redeveloped to provide the necessary requirements for the ‘future’ state.

3.1 IntroductionThe data and information within the scope of the ‘Implementation of a professional project-based working method’ programme is the data related to the Programme Life Cycle (PLC1) or Project Life Cycle (PLC2). Therefore this data is the programme and project data that needs to be managed to guarantee a professional project-based way of working: planning data (in schedule and budget).

Tools for managing project and programmes rely a set of more or less common entities. Below all relevant entities are listed: Organisation; Programme and Project; Resources; Rates; Deliverable; Activity; Financial data; other.

3.2 Entities

Organisation

The first entity is Organisation. Organisational Units are used primarily to be able to aggregate data on different levels. Often organizations occur in multiple instances; for example one for the departments as a supplier of resources, and a separate one for cost centres. The relations between the Organisational Units are usually displayed as an Organisation Breakdown Structure (OBS): a hierarchy in the organisation to define the location of an entity (for instance human resource or project).

Programme and Project

The second entity is: Programme and Project. Programmes contain one or more projects; (projects may contain one or more subprojects;) projects contain one or more deliverables; deliverables contain one or more activities (effort).

Furthermore important are: Milestones (identifying the end of a set of activities); Gates (identifying the start of a set of activities).

These gates and milestones are often used to synchronise dependencies between projects or with other events outside the scope of a single project (such as external milestones or 3rd party work packages).

General attributes:

5


3

Attribute DescriptionProject NameProject ID Unique Project IDDescriptionActive Check if project is completed or cancelledSub Project ID Unique ID of sub project

Management attributes:Attribute DescriptionManager Name Project Manager’s nameStart Expected project start dateFinish Expect project completion date or leave blankPriorityApproved Check if project is approvedClosed Check when project is completed or cancelledOpen for Time Entry Check indicated that actual data can be captured against projectBudget In time, money.Planned Effort Aggregated planned total effort from all activities and of projects (in case of a

programme)Actual Effort Aggregated actual effort from all activities and of projects (in case of a

programme)

Resource

The next entity is: Resource. Resources are the persons allocated to the programme or project.

General attributes:Attribute DescriptionFirst Name First NameMiddle Name Middle Name if applicableLast Name Last NameDisplay Name Format is “First Name Last Name”Resource ID Unique Resource IDEmail AddressEmployment Type Contractor or EmployeeDate of Hire Date resource started with company. If resource is a contractor this date

should be the Start date of the first engagement.Date or Termination Date resource left. For contractors, this should be the expected end date of

their current engagementManager Browse to System Users to identify Manager

Management attributes:Attribute DescriptionRole Resource roleCategory Employee Affiliation (e.g.; AS)Availability Default Availability for resource in Hours per Day. Default is 6.5 hrs/day for

employees and 8 hrs/day for contractors.Open for Time Entry Check if Resource can enter time against a project

5


3

Skills Used for finding the right employee (resource management)

Contact attributes:Attribute DescriptionCompanyJob TitleStreet 1Street 2Street 3CityStatePostal CodeCountryHome Phone NumberWork Phone NumberMobile Phone NumberFaxPagerURL Can link to external web page

Some tools allow for the allocation of roles that represent a give type of resource for as long as the specific person is not yet known.

Rates

The next entity is: Rates. Often, rates vary in time so rates are often registered in a matrix structure where rates can vary dependent on factors such as time (overtime), contracts et cetera.

Deliverable

The next entity is: Deliverable.

General attributes:Attribute DescriptionDeliverable nameDeliverable ID Unique IDDescriptionStatus Open, completed, …PredecessorsSuccessorsProject

Activities

The next entity is: Activities. Activities mean effort that contributes to the realisation of deliverables. General non-project related hours (such as illness, holidays, or departmental meetings) must considered as well.

General attributes:

5


3

Attribute DescriptionActivity nameActivity ID Unique IDDescriptionEffort Estimated effortStatus Open, completed, …PredecessorsSuccessorsDeliverableResourceTime spent

Financial

Financial information can be managed in a Project Management tool or in the existing financial system. Transaction types typically are: Labor; Material; Equipment; Expense (for instance travel and lodging).

Depending on the way financial information is processed, additional characteristics need to be registered to allow for passing data to other applications.

Other entities

Other entities that are often managed: other resources (e.g. hardware); capital; suppliers.

5

Organisation, Roles and Responsibilities

4

This chapter contains a description of the organisation structure, staffing levels, roles and skill requirements necessary to support the future business operations. Any necessary changes to organisational culture, style, or existing structures and personnel may also be included.

4.1 Organisation StructureThe next figure shows the core programme roles and functions and how they relate to each other. In the next paragraph the roles are described and the generic responsibilities for each, along with the skills that the individuals fulfilling them will need.The application of a Programme Management regime should not automatically impose the need for additional management resources. The Programme Management roles and responsibilities should be regarded as ‘natural’ that as much as possible are expansions of existing responsibilities.

5


4

4.2 Roles, Responsibilities and Required SkillsThese primary roles should not be merged together; each focus on specific aspects of the programme. Depending on the size, complexity and significance of the programme, some of the responsibilities may be assigned to further specific roles, such as Quality Manager or Communications Manager.

Programme Sponsorship

Programme sponsorship means making the investment decision and providing top-level endorsement of the rationale and objectives for the programme. Sponsorship also means continuing senior management commitment to promoting and supporting the changes introduced by the programme, and championing the implementation of the new capabilities delivered by the programme to ensure that the expected benefits are realised and the desired outcomes achieved.The programme’s sponsors are key stakeholders and form the Sponsoring Group for the programme. The Sponsoring Group represents those senior managers who are responsible for the investment decision, defining the direction of the business and establishing frameworks to achieve the desired objectives. They must take the lead in establishing the values and behaviours required by the change effort, often ‘leading by example’. Without the commitment and direct involvement of senior management, a transformational change is unlikely to progress very far. The life of a programme, and the period of transition in particular, is a time of uncertainty. Many normal procedures, reporting relationships and responsibilities may no longer apply. All members of the Sponsoring Group must take the lead in establishing a style of leadership appropriate to the organisation and the nature of the change. In most change situations there will need to be increased emphasis on motivation of staff, promotion of team-working, empowerment at all levels, encouragement of initiatives, and recognition of appropriate risk-taking.

The specific responsibilities of the Sponsoring Group will include: providing the Programme Mandate and investment decision; creating an environment in which the programme can thrive; endorsing, advising and supporting the Senior Responsible Owner; providing continued commitment and endorsement in support of the Senior Responsible Owner at

programme milestones; approving the progress of the programme against the strategic objectives; providing visible leadership and commitment to the programme at communication events; confirming successful delivery and sign-off at the closure of the programme.

Senior Programme Responsible

The Senior Responsible Owner has overall accountability for the programme, together with personal responsibility for ensuring that it meets its objectives and realises the expected benefits. The individual who fulfils this role should be a peer member of the Sponsoring Group and must be empowered to direct the programme and take decisions. They must have enough seniority and authority to provide leadership to the programme team and take on accountability for delivery.

The Senior Responsible Owner is ultimately accountable for the success of the programme and is responsible for enabling the organisation to exploit the new environment resulting from the programme, meeting the new business needs and delivering new levels of performance, benefit, service delivery,

5


4

value or market share. The title of ‘Senior Responsible Owner’ can be replaced by the term Programme Director.

The responsibilities of the Senior Responsible Owner role include: owning the vision for the programme and being its ‘champion’, providing clear leadership and

direction throughout its life; securing the investment required to set up and run the programme, and fund the transition activities

so that the desired benefits are realised; providing overall direction and leadership for the delivery and implementation of the programme,

with personal accountability for its outcome (this should be an important measure of their individual performance);

being accountable for the programme’s governance arrangements by ensuring the programme, including its investment, is established and managed according to appropriate requirements and quality;

being responsible for key programme information, including the Programme Brief and the Business Case;

managing the interface with key senior stakeholders and ensuring that interfaces and communications with all stakeholders are effective;

managing the key strategic risks facing the programme; maintaining the alignment of the programme to the organisation’s strategic direction. Evolving

business needs and emerging issues that impact the programme will undoubtedly arise. The Senior Responsible Owner is responsible for ensuring that such issues are addressed appropriately;

ensuring that the organisation and its staff are managed carefully through the process of change, that the results are reviewed and assessed objectively, and that adjustments are made as necessary;

commissioning and chairing reviews both during the programme and following programme closure that formally assess the programme’s:o continued alignment with its objectives;o capability of delivery;o measurable achievement of benefits;

managing and supporting the Programme Manager.

Appointing a Senior Responsible Owner:The Senior Responsible Owner must have the seniority for the responsibilities and accountabilities the role involves. Even though they may only be involved in the day-to-day activities of the programme on a part-time basis, they must be proactive and visible as the driving force behind the programme.

Programmes require strong leadership and decision-making skills. However, different types of programme require different styles of leadership. For example, programmes involving significant internal change for staff will have different issues from those focused on external change. The appointment process should ensure that the experience, character and personality of the individual appointed to the Senior Responsible Owner role are right for the programme.

The Senior Responsible Owner needs to be able to combine realism with openness and the clarity of expression to communicate the programme’s vision effectively.

In addition, the Senior Responsible Owner must:

5


4

be able to give purpose and direction to the programme and take strategic decisions; lead by example and focus on delivery; build productive relationships across the programme team and have access to, and credibility with,

key stakeholders.

Programme Manager

There is a fundamental difference between the delivery of a new capability and actually realising measurable benefits as a result of using that capability. This difference is reflected in the complementary roles of Programme Manager and Business Change Manager. The Programme Manager is responsible for delivering the capability; the Business Change Manager is responsible for realising the resultant benefits by embedding that capability into business operations. The individuals appointed to each role must be able to work in close partnership to ensure that the right capabilities are delivered and that they are put to best use.

The role of Programme Manager is responsible for leading and managing the setting up of the programme through to delivery of the new capabilities and realisation of benefits. Managing a programme is not simply a line management function overseeing the delivery of a number of projects. The Programme Manager role involves proactive interventions and decision-making to ensure that the programme stays on track.

Programmes do not usually have a clear path towards a well-defined goal. Therefore, they can rarely be managed using traditional approaches. The Programme Manager is responsible for co-ordinating and monitoring the work of the programme in an uncertain environment.Successful delivery will depend on the effective management of issues, conflicts, priorities, communications and personnel. The Programme Manager will need the ability to work positively with the full range of individuals and groups involved in the programme.

The Programme Manager is responsible, on behalf of the Senior Responsible Owner, for successful delivery of the new capability. The role requires the effective co-ordination of the projects and their interdependencies, and any risks and other issues that may arise. In most cases, the Programme Manager will typically work full-time on the programme, as the role is crucial for creating and maintaining enthusiasm.

As the programme is implemented, changes to policy, strategy, or infrastructure may have an impact right across the Project Portfolio, or outside the programme. The Programme Manager is responsible for the overall integrity and coherence of the programme, and develops and maintains the programme environment to support each individual project within it – typically through the Programme Support Office function.

The responsibilities of the Programme Manager role will also include the following: planning and designing the programme and proactively monitoring its overall progress, resolving

issues and initiating corrective action as appropriate; defining the programme’s governance framework; ensuring the integrity of the programme – focusing inwardly on the internal consistency of the

programme; and outwardly on its coherence with infrastructure planning, interfaces with other programmes and corporate technical and specialist standards. This particular aspect may be

6


4

allocated to a separate dedicated role (often referred to as ‘business or technical design authority’ or ‘strategic architect’) particularly on large, complex programmes;

managing the programme’s budget on behalf of the Senior Responsible Owner, monitoring the expenditures and costs against benefits that are realised as the programme progresses;

facilitating the appointment of individuals to the project delivery teams; ensuring that the delivery of new products or services from the projects meets requirements and is

to the appropriate quality, on time and within budget, in accordance with the Programme Plan and programme governance arrangements;

ensuring maximum efficiency in the allocation of resources and skills within the Project Portfolio; managing third-party contributions to the programme; managing the communications with stakeholders; managing the dependencies and interfaces between projects; managing risks to the programme’s successful outcome; initiating extra activities and other management interventions wherever gaps in the programme are

identified or issues arise; reporting progress of the programme at regular intervals to the Senior Responsible Owner.

Once projects become established, the role of Programme Manager focuses on monitoring interdependencies between projects and changes within the Project Portfolio. The day-to-day management and delivery of the projects will be carried out by the designated project teams.

Throughout the programme, the Programme Manager provides the ongoing ‘health check’ of the programme by reassessing whether the projects continue to meet the programme’s objectives and continue to use available funds and resources efficiently. This requires the timely management of exceptions, slippage and conflicting priorities.

Appointing the Programme Manager:The individual appointed to the role of Programme Manager must have the necessary seniority to be able to take on the responsibilities required of the role. The Programme Manager must have strong leadership and management skills, and may well have a Project Management background. The balance of skills required in the Programme Manager often changes as the programme develops: the person with the skills to set up a programme is not necessarily the right one to drive through its implementation.The Programme Manager must understand the wider objectives of the programme, have credibility within the programme environment and be able to influence others. They must be able to develop and maintain effective working relationships with other members of the Programme Management Team, senior managers, the project teams and third-party service providers involved in the management and operations of the programme.

The Programme Manager should also have: effective leadership, interpersonal and communication skills; the ability to command respect and to create a sense of community amongst the (often disparate)

members of the project teams; a good knowledge of techniques for planning, monitoring and controlling programmes; a good knowledge of Project Management approaches such as PRINCE2; a good knowledge of budgeting and resource allocation procedures;

6


4

sufficient seniority and credibility to advise project teams on their projects in relation to the programme;

the ability to find ways of solving or pre-empting problems.

Business Change Manager

The delivery of change will not happen on its own. The outputs required from projects need to be defined and targeted, based on the contribution they will make to realising benefits and achieving outcomes.The role of Business Change Manager has responsibility for benefits definition and management throughout the programme. More than one individual may be required to fulfil this role – exactly how many will depend on the number of business areas targeted for benefits realisation.

To realise benefits, the programme must be closely integrated with mainstream business activities. It is only when changes become ‘business as usual’ that the benefits will be realised. The Business Change Manager role is key to providing the ‘bridge’ between the programme and the business operations since the individual(s) will be an integral part of the business operations.

The Business Change Manager role represents the Senior Responsible Owner’s (and hence the Sponsoring Group’s) interests in the final outcome of the programme, in terms of measurable improvements in business performance.

Where substantial change in business operations is required, the individual(s) appointed to the role of Business Change Manager will be responsible for creating the new business structures, operations and working practices.

Business Change Managers should have appropriate responsibility and authority within the business areas within which change will take effect and benefits will be realised.

The role of Business Change Manager is primarily benefits-focused. The Business Change Manager role is responsible, on behalf of the Senior Responsible Owner, for defining the benefits, assessing progress towards realisation, and achieving measured improvements. This need to define and realise benefits in terms of measured improvements in business performance means that the Business Change Manager role must be ‘business-side’, in order to provide a bridge between the programme and business operations. This bridge between the business and the programme is represented by the dotted line relationship between the Business Change Manager and the Senior Responsible Owner in the figure above.

On many programmes, change will affect different parts of the organisation. In such situations there should be a team of Business Change Managers, one for each business area.

The Business Change Manager role will include the following responsibilities: ensuring the interests of the Sponsoring Group are met by the programme; obtaining assurance for the Sponsoring Group that the delivery of new capability is compatible with

realisation of the benefits;

6


4

working with the Programme Manager to ensure that the work of the programme, including the scoping of each project, covers the necessary aspects required to deliver the products or services that will lead to operational benefits;

working with the Programme Manager to identify projects that will contribute to realising benefits and achieving outcomes;

identifying, defining and tracking the benefits and outcomes required of the programme; identifying and implementing the maximum improvements in business operations (both extant and

newly created) as groups of projects deliver their products or services into operational use; managing the realisation of benefits, and ensuring that continued accrual of benefits can be

achieved and measured after the programme has been completed; establishing and implementing the mechanisms by which benefits can be realised and measured; taking the lead on transition management; ensuring that ‘business as usual’ is maintained during the

transition and the changes are effectively integrated into the business; preparing the affected business areas for the transition to new ways of working; potentially

implementing new business processes; optimising the timing of the release of project deliverables into business operations.

As the programme progresses, the Business Change Manager is responsible for monitoring outcomes against what was predicted.

Appointing the Business Change Manager(s):The individual, or individuals, appointed as Business Change Manager(s) should be drawn from the relevant business areas. Suitable individuals are likely to have ongoing operational responsibilities within their business areas. Their participation in the programme should be an integral part of their normal responsibilities, to enable changes resulting from the programme to be firmly embedded in the organisation.

Business Change Managers require detailed knowledge of the business environment and direct business experience. In particular, they need an understanding of the management structures, politics and culture of the organisation(s) involved in the programme. They also need management skills to co-ordinate personnel from different disciplines and with differing viewpoints. They need effective marketing and communication skills to sell the programme vision to staff at all levels of the business.Business Change Manager(s) should also have change management skills and enough experience to be able to bring order to complex situations and maintain focus on the programme’s objectives.

Knowledge of certain management techniques may also be useful, for example: business change techniques, such as business process re-engineering; benefits identification, modelling and management techniques.

Programme Support and Project Support Staff

Programmes are major undertakings, often affecting large numbers of people and organisations and generating a substantial volume of information. The nerve centre and information hub of a programme is the Programme Support Office. All information, communication, monitoring and control activities for the programme are co-ordinated through the Programme Support Office.

6


4

The Programme Support Office may be dedicated to supporting a single programme, or it may support a number of programmes. The level of resourcing for the Programme Support Office will vary depending on the size and capabilities of the organisation. For example, with appropriate expertise, the Programme Support Office may be a ‘centre of excellence’ for all programmes and projects within the organisation, providing specialist expertise and facilitation across the programme and its projects. In many cases, the manager of the Programme Support Office will also act as deputy to the Programme Manager.

The Programme Support Office can provide some aspects of assurance for the programme. However, it is important to have an independent assurance function in addition to any internal assurance function.The core function of the Programme Support Office is to provide an information hub for the programme. This will typically involve the following: tracking and reporting:

o tracking measurements;o reporting progress;

information management (websites are useful tools for providing these facilities):o holding master copies of all programme information;o generating all necessary quality management documentation;o maintaining, controlling and updating programme documentation;o establishing and maintaining the index to an electronic library of programme information;

financial accounting: o assisting the Programme Manager with budget control for the programme;o maintaining status reports on all projects in the programme;

risk and issue tracking:o analysing interfaces and critical dependencies between projects and recommending appropriate

actions to the Programme Manager;o maintaining the list of stakeholders and their interests;

quality control: establishing consistent practices and standards adhering to the programme governance arrangements, including project planning, reporting, change control, analysing risks and maintaining and updating the Risk Register for the programme;

change control:o registering changes for subsequent investigation and resolution;o monitoring items identified as requiring action;o prompting timely actions;o reporting on whether required actions have been carried out.

The Programme Support Office may be sufficiently resourced to provide additional expertise across the programme, for example: providing a strategic overview of all programmes and interdependencies, and reporting upward to

senior management; providing consultancy-style support to project delivery teams at initiation and throughout the

lifecycle of the programme; ensuring a common approach is adopted and sharing good practice; carrying out health checks and advising on solutions during the lifetime of the programme and

individual projects, for example, facilitating workshops involving project teams, stakeholders and members of the programme team.

6


4

Resourcing the Programme Support Office:The Programme Support Office should add value to the programme through the knowledge, experience and skills of its staff. The following attributes are worth considering when making Programme Support Office appointments: proven track record in programme/Project Management and implementation; expertise in programme/Project Management methodologies and processes; active experience in risk management; Business Case and appraisal skills; interpersonal skills; communication skills at all levels.

Programme Support Offices and Project Offices may be combined where it is a sensible use of resources to have the same team providing both functions.

6

Information Systems

5

5.1 IntroductionThis chapter contains a description of the Technology, IT systems, tools, equipment, buildings and accommodation required for the future business operations together with details of reuse of existing infrastructure or implementation of new infrastructure to support the ‘future’ state.

The information systems within the scope of the ‘Implementation of a professional project-based working method’ programme are the systems supporting the Programme Life Cycle (PLC1) or Project Life Cycle (PLC2).Typically these systems are primarily planning and tracking applications. Other tools that may be required are: document management tool (to manage all project/programme related information); workflow management tool (primarily to support review and approval processes); configuration management tool (to maintain a clear view and the right version of each deliverable

individually and as a whole); intranet and e-mail (communication); reporting tools.

Currently these applications are not used within the organisation.

5.2 Planning and TrackingBelow the infrastructural aspects for planning and tracking applications are listed.

Server environment

The following environments are typically required:1. production environment to support operational Programme and Project Managers, Resource

Managers and time writers;2. Quality Assurance environment for intake and regression testing;3. training environment for classical education and/or e-learning;4. development environment for template development;

In most cases, the production environment (1) is physically separated from the other environments (2-4) to isolate the production environment from mishaps that might occur in the other environments. Usually, in large organisations, these implementations are based on a large SQL database configuration to offer a central database for all data.

Client set-up

Typically 2 clients are used:1. for time writing, a browser client is available on the desktop of every potential project participant.

Such a client requires minimal configuration and is easy to roll out to many users;2. Programme and Project Managers will need to have a specific client called workbench to be

installed on the desktop. This workbench supplies the full functionality for planning, scheduling and tracking. Typically, more training and support is needed here to be able to use such a tool to its full potential.

6

Information Systems

5

Network

In case of organisations that have multiple site / locations (in one country or in multiple countries), an organisation wide network is required if projects/programs run across multiple sites (which is usually the case).

Backup

For development, test and training, a cold backup of the database is usually made daily. For production database a daily hot backup is scheduled during off-peak hours.

Interfaces

Ultimately, interfaces may be required between the tool and existing applications (such as HR systems and financial systems) to transfer project lifetime information. When and what should be included in this interface is installation specific.

6

Support Services

6

6.1 IntroductionThis chapter contains a description of the support services required for the future business operations, together with details of how the existing support services will be changed to provide the necessary requirements for the ‘future’ state.

The support services within the scope of the ‘Implementation of a professional project-based working method’ programme are the services delivered related to the Programme Life Cycle (PLC1) or Project Life Cycle (PLC2). These support services are delivered by: Human Resources; tools.

Furthermore support services of other departments are mentioned briefly in as much as they relate to the PLC’s.

6.2 Human ResourcesThe human resources include Programme Managers, Project Managers and members of the Programme Support Office.The support services from the human resources are adequately described in chapters 2 Business Model, and 4 Organisation, Roles and Responsibilities.

The staff is recruited from the personnel currently already active in the change processes. They will be assessed on their skills and experience, and trained according to their subsequent personal education plan (as will be realised during one of the projects within the programme).As stated before, the application of a Programme Management regime should not automatically impose the need for additional management resources. The Programme Management roles and responsibilities should be regarded as ‘natural’ that as much as possible are expansions of existing responsibilities.

Although the roles and responsibilities for the Programme Support Office are described, one issue has not been mentioned yet. The Programme Support Office is responsible for the maintenance of all products for the PLC: procedures, tools and templates. All products regarding the PLC’s are available via the intranet.

6.3 ToolsThe tools are listed in the paragraph chapter 5 Information Systems.The support services from the tools are adequately described in chapter 5 Information Systems.

These tools are new to the organisation. They need to be used by all involved in programmes and projects in the new situation (training will take place during one of the projects within the programme).

6.4 Other Departments: Purchasing, Finance, Communications, Human ResourcesSome departments will play a role in the processes from the PLC’s:

6

Support Services

6

Purchasing

The Purchasing department is involved in the PLC’s whenever contractors are hired, equipment (hardware/software) is bought or hired, or whenever projects are contracted out. Therefore Purchasing are informed and consulted whenever these situations occur, and the activities required from Purchasing are planned. The Purchasing department is identified as a major stakeholder and included in the Communication Plan.

Purchasing needs to be aware of the implemented organisation structure and of the valid Programme Management Processes; and Purchasing needs to adapt their procedures and plans to the situation.

Finance

The Finance department is involved in the PLC’s as the Business Case is imbedded in the PLC processes and it is the Finance department that: validates the Business Case (recommendation); validates the Benefit Realisation.The Finance department is identified as a major stakeholder and included in the Communication Plan.

Finance needs to be aware of the implemented organisation structure and of the valid Programme Management Processes; and Finance needs to adapt their procedures and plans to the situation.

Communications

The Communications department is involved in the PLC’s as it assists the Senior Responsible Owner and the Programme Manager in communicating the results of the programme to the outside world. Also the Communications department plays a role in programme (and project) internal communications (for instance maintenance of the intranet). The Communications department is consulted when creating the Programme Plan.

The Communications department is aware of the implemented organisation structure and of the valid Programme Management Processes, and works accordingly.

Human Resources

The new organisation and the new tasks and responsibilities have consequences for the entire HR structure. New job descriptions, functions et cetera are created. Therefore the HR department is a major stakeholder in the programme, and is consulted when creating the Programme Plan.

6

Documents

Msp Blueprint