SlideShare a Scribd company logo

Understanding PRINCE 2®

Guy Demoulin, profile picture
Guy Demoulin

This document provides background information on the origins and development of the PRINCE 2 project management methodology. It discusses how PRINCE 2 originated from the PROMPT methodology, which was developed in the 1970s to provide a structured approach to managing IT projects. It then describes how the UK government adopted and enhanced PROMPT as its standard project management methodology, renaming it to PRINCE. Subsequent developments led to the creation of PRINCE 2, which is now the UK government's standard for managing projects.

Business
1 of 280
Downloaded 395 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
Ken Bradley’s Understanding PRINCE 2® PRINCE is a Registered Trademark of CCTA
Ken Bradley’s Understanding PRINCE 2 ISBN 1 902192 00 1 Published by: SPOCE Project Management Limited Homelife House Oxford Road Bournemouth, Dorset BH8 8EZ Telephone & Fax: 01202-780740 Switchboard: 01202-319987 E-Mail: enquiries@spoce.com Information: www.spoce.com PRINCE is a Registered Trademark of CCTA © Ken Bradley 1997 First Published October 1997 Revised and reprinted February 1999 All rights reserved by the copyright holder and the licensee. No part of this publication may be reproduced in any material form (including photocopying and/or storage in any medium by electronic means and whether or not transiently or incidentally to some other use of this publication) without the written permission of the copyright holder identified above, except in accordance with the provisions of the Copyright Designs and Patents Act 1988. Applications for the copyright holder’s written permission to reproduce any part of this publication should be addressed to the publisher at the address above. 2
Ken Bradley’s Understanding PRINCE 2 Dedication This book is dedicated to the many clients and friends who over the past two decades have put their trust and key projects into my hands, often for just the first few critical weeks of life and sometimes for support from cradle to grave. Thanks also go to the “SPOCETTES” Carol and Livia who have used their charm and charisma to ensure that this project was delivered on time, to the agreed plan and only marginally over budget! Ken Bradley What Others Say About This Book “An excellent companion to the CCTA PRINCE 2 Reference Manual. The many clear diagrams and supporting text answer the questions What should I do now? – and Why?” Martin Shepherd ICL HR Consultancy “This book provides a comprehensive and practical exposition of the PRINCE 2 Method and truly lives up to its title. Ken Bradley’s practical experience of managing projects, together with his understanding of the needs of Project Managers, whether new to the profession or old hands, gleaned from many years of providing consultancy and training is evident through the techniques and best practice tips that abound in this publication.” Dave Rose, Principal Consultant Project Management Devon IT Services 3
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 LIST OF CONTENTS Foreword ................................................................................................................................... 13 Who This Publication Is Intended For ......................................................................................... 13 Origins Of The PRINCE 2 Method .............................................................................................. 17 The PROMPT Methodology ........................................................................................................ 17 Government PROMPT................................................................................................................ 17 The Standard PROMPT Lifecycle ............................................................................................... 18 PROMPT Organisation - Stage Managers................................................................................... 18 PROMPT Planning..................................................................................................................... 19 The Enhancement Project And PRINCE...................................................................................... 19 PRINCE 2 And Other Developments ........................................................................................... 20 Introduction To PRINCE 2.......................................................................................................... 25 Benefits Of PRINCE 2 ................................................................................................................ 25 The Structure Of A PRINCE 2 Project......................................................................................... 26 The Key Elements Contained In PRINCE 2 ................................................................................. 28 The PRINCE 2 Processes............................................................................................................ 29 The PRINCE 2 Components:....................................................................................................... 30 The PRINCE 2 Techniques.......................................................................................................... 32 The Organisation Component ..................................................................................................... 33 The Project Board ...................................................................................................................... 34 The Project Manager.................................................................................................................. 35 The Team Manager..................................................................................................................... 35 Project Resources And (Specialist) Teams................................................................................... 36 Project Assurance....................................................................................................................... 36 Project Support .......................................................................................................................... 37 The Project Support Office.......................................................................................................... 37 Summary Of The Organisation Component ................................................................................. 37 5
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Planning.................................................................................................................... 38 Products Or Deliverables And Related Activities........................................................................ 38 Planning For The Delivery Of Specialist Products ...................................................................... 40 Resource Planning & Reporting.................................................................................................. 41 Quality Planning -BS/EN/ISO9001 ............................................................................................. 42 Tolerance And Planning ............................................................................................................. 43 The Controls Component ............................................................................................................ 44 Management Controls ................................................................................................................ 44 Project Initiation ........................................................................................................................ 44 End Stage Assessment (ESA)....................................................................................................... 45 Mid Stage Assessment (MSA) ...................................................................................................... 45 Tolerance ................................................................................................................................... 46 Project Closure .......................................................................................................................... 47 Highlight Reports ....................................................................................................................... 48 Stages......................................................................................................................................... 48 Business Benefits And Risk Management..................................................................................... 49 Planning For Quality.................................................................................................................. 50 Quality Controls - Quality Review............................................................................................... 50 Change Control.......................................................................................................................... 52 Configuration Management ........................................................................................................ 52 Filing Arrangements................................................................................................................... 53 Software Support For PRINCE 2 ................................................................................................ 53 Following This Introduction........................................................................................................ 54 PRINCE 2 Organisation - Introduction ....................................................................................... 57 Responsibilities In A PRINCE 2 Controlled Project.................................................................... 58 The Project Board ...................................................................................................................... 58 The Executive Role ..................................................................................................................... 59 The Senior User Role.................................................................................................................. 59 6
Ken Bradley’s Understanding PRINCE 2 The Senior Supplier Role ............................................................................................................ 59 Responsibilities Of The Project Board Members.......................................................................... 59 The Project Assurance Function ................................................................................................. 60 Delegation Of Day-To-Day Project Assurance ............................................................................ 61 The Project Manager.................................................................................................................. 61 Team Manager(s) ....................................................................................................................... 62 Responsibilities Of The Team Manager....................................................................................... 63 Team Managers And Technical Stages ........................................................................................ 64 Project Support .......................................................................................................................... 64 Customer:Supplier Environment ................................................................................................. 65 Developments On The PRINCE 2 Theme..................................................................................... 66 The Supplier Project Board ........................................................................................................ 67 Customer: Supplier Steering/Co-Ordinating Group..................................................................... 68 Customer: Supplier Project Manager.......................................................................................... 69 Customer:Supplier - Project Support .......................................................................................... 69 Organising The Managing Of Programmes................................................................................. 69 Programme Board, Programme Manager & Programme Support ............................................... 70 User/Customer Group In A Programme Context ......................................................................... 71 Individual Project Boards In A Programme Context.................................................................... 71 Project Support & Programme Assurance................................................................................... 71 Programme And Project Resources............................................................................................. 72 Other Structures Based On PRINCE 2 ........................................................................................ 72 PRINCE 2 Organisation - Summary........................................................................................... 74 Planning - Introduction & Overview ........................................................................................... 76 Project Level Plans..................................................................................................................... 77 Product Breakdown Structure ..................................................................................................... 78 Product Flow Diagram ............................................................................................................... 80 PERT Network............................................................................................................................ 81 7
Ken Bradley’s Understanding PRINCE 2 The PERT Logic Network & The Timed Network......................................................................... 81 Earliest Start Gantt Plan ............................................................................................................ 82 Resource Smoothing ................................................................................................................... 82 Project Gantt Plan...................................................................................................................... 84 Project Resource Reporting ........................................................................................................ 84 Graphical Summary.................................................................................................................... 85 Earned Value Analysis................................................................................................................ 86 Risk Analysis .............................................................................................................................. 87 Measuring The Business Benefits ................................................................................................ 88 Project Plan Text........................................................................................................................ 89 Management Stage Plans............................................................................................................ 89 Team Plans ................................................................................................................................ 91 Individual Plans ......................................................................................................................... 91 PRINCE 2 Planning - Summary .................................................................................................. 91 Introduction To Controls ............................................................................................................ 94 Management Controls ................................................................................................................ 94 The Project Initiation Meeting .................................................................................................... 95 Project Initiation & The Project Initiation Document (PID) ........................................................ 96 End Stage Assessment (ESA)....................................................................................................... 96 Attendees At An End Stage Assessment........................................................................................ 97 End Stage Assessment Agenda .................................................................................................... 97 Mid Stage Assessment (MSA) ...................................................................................................... 98 Tolerance ................................................................................................................................... 99 Project Closure ........................................................................................................................ 102 Highlight Reports ..................................................................................................................... 102 Checkpoint Reports .................................................................................................................. 103 Stages....................................................................................................................................... 103 Management & Technical Stages .............................................................................................. 107 8
Ken Bradley’s Understanding PRINCE 2 Management Stages.................................................................................................................. 108 Updating The Business Case..................................................................................................... 108 Technical Stages....................................................................................................................... 109 Handling The End Of A Management Stage .............................................................................. 109 Stages - Summary ..................................................................................................................... 110 Risk Management - Introduction ............................................................................................... 113 Risk Ranges & Risk Factors...................................................................................................... 114 Updating The Risk Analysis ...................................................................................................... 115 Modifying The Risk Analysis Checklist ...................................................................................... 116 PRINCE 2 &BS/EN/ISO9001.................................................................................................... 123 Quality Management ................................................................................................................ 123 Customer Quality Expectations................................................................................................. 124 Quality Aspects For Suppliers & Sub-Contractors..................................................................... 124 Quality Management - Summary............................................................................................... 125 Configuration Management - Introduction ................................................................................ 129 Configuration Management Techniques .................................................................................... 129 CM Activities............................................................................................................................ 130 Change Control - Introduction.................................................................................................. 135 Project Issue............................................................................................................................. 135 Off Specifications ..................................................................................................................... 136 Request For Change ................................................................................................................. 136 Change Control Forms And Documentation.............................................................................. 136 Change Control - Summary ...................................................................................................... 137 Introduction To Processes ......................................................................................................... 141 The Processes........................................................................................................................... 141 The PRINCE 2 Process Model .................................................................................................. 142 Major Processes And Processes ................................................................................................ 143 Structure Of The Individual Process Models.............................................................................. 145 9
Ken Bradley’s Understanding PRINCE 2 Individual Process Summary Models........................................................................................ 147 Starting Up A Project (SU) - Introduction ................................................................................. 151 SU1 - Appointment Of A Project Board Executive And A Project Manager ................................ 152 SU2 & SU3 - The Project Management Team ............................................................................ 153 SU5 - The Project Approach: .................................................................................................... 156 SU6 - The Initiation Stage Plan................................................................................................. 157 Starting Up A Project - Summary .............................................................................................. 158 Initiating A Project (IP) - Introduction ...................................................................................... 163 The Project Initiation Document ............................................................................................... 163 IP1 - Planning For Quality ....................................................................................................... 165 IP2 - Planning A Project........................................................................................................... 166 IP3 - Refining The Business Case & Risks................................................................................. 168 IP4 - Setting Up Project Controls.............................................................................................. 169 Project Board Controls ............................................................................................................. 169 Project Manager/Team Controls: .............................................................................................. 170 IP5 - Set Up Project Files ......................................................................................................... 171 IP6 - Assembling The Project Initiation Document .................................................................... 173 Approach To Assembling Or Producing The PID....................................................................... 174 Initiating A Project (IP) - Summary........................................................................................... 175 Directing A Project (DP) - Introduction .................................................................................... 181 Management By Exception........................................................................................................ 182 DP1 – Authorising Initiation..................................................................................................... 183 DP2 – Authorising A Project..................................................................................................... 184 DP3 – Authorising A Stage Or Exception Plan.......................................................................... 185 Approval Of Exception Plans .................................................................................................... 186 DP4 – Giving Ad-Hoc Direction ............................................................................................... 188 DP5 – Confirming Project Closure............................................................................................ 189 Summary Of The DP Process .................................................................................................... 191 10
Ken Bradley’s Understanding PRINCE 2 Controlling A Stage (CS) - Introduction .................................................................................... 197 CS1 – Authorising A Work Package .......................................................................................... 199 CS2 – Assessing Progress ......................................................................................................... 200 CS3 - Capturing Project Issues ................................................................................................. 202 CS4 - Examining Project Issues ................................................................................................ 203 CS5 - Reviewing Stage Status.................................................................................................... 204 CS6 - Reporting Highlights....................................................................................................... 205 CS7 - Taking Corrective Action ................................................................................................ 207 CS8 - Escalating Project Issues................................................................................................. 208 CS9 - Receiving A Completed Work Package ............................................................................ 209 Summary Of The Controlling A Stage Process........................................................................... 210 Managing Product Delivery (MP) - Introduction ....................................................................... 215 MP1 - Accepting A Work Package............................................................................................. 217 MP2 - Executing A Work Package............................................................................................. 218 MP3 - Delivering A Work Package............................................................................................ 219 Managing Stage Boundaries (SB) - Introduction ....................................................................... 223 Exception Plans........................................................................................................................ 224 SB1 - Planning A Stage............................................................................................................. 225 SB2 - Updating A Project Plan ................................................................................................. 226 SB3 - Updating A Project Business Case................................................................................... 227 SB4 -Updating The Risk Log..................................................................................................... 228 SB5 - Reporting Stage End........................................................................................................ 229 SB6 - Producing An Exception Plan.......................................................................................... 231 Summary Of The Managing Stage Boundaries Process.............................................................. 232 Closing A Project (CP) - Introduction ....................................................................................... 237 CP1 - Decommissioning A Project ............................................................................................ 239 CP2 - Identifying Follow-On Actions ........................................................................................ 241 CP3 – Project Evaluation Review............................................................................................. 242 11
Ken Bradley’s Understanding PRINCE 2 Summary Of The Closing A Project Process.............................................................................. 243 Planning (PL) - Introduction.................................................................................................... 247 PL1 - Designing A Plan ............................................................................................................ 249 PL2 - Identifying, Defining And Analysing Products.................................................................. 250 PL3 - Identifying Activities And Dependencies .......................................................................... 252 PL4 - Estimating....................................................................................................................... 253 PL5 - Scheduling ...................................................................................................................... 254 PL6 - Analysing Risks............................................................................................................... 255 PL7 - Completing A Plan.......................................................................................................... 256 Summary Of The Planning (PL) Process ................................................................................... 257 PRINCE 2 Filing Technique - Introduction ............................................................................... 261 The Management File ............................................................................................................... 261 Physical Filing Considerations ................................................................................................. 266 Quality Review Technique - Introduction .................................................................................. 269 Quality Assurance And Quality Control .................................................................................... 269 What Is A Quality Review?........................................................................................................ 269 Quality Reviews - Formal And Informal .................................................................................... 270 People Involved ........................................................................................................................ 270 The Quality Review Steps......................................................................................................... 271 Step 1 - Preparation ................................................................................................................. 271 Step 2 - The Review Meeting .................................................................................................... 272 Step 3 - Follow-Up Of Review Meeting ..................................................................................... 273 Summary Of The Quality Review Technique.............................................................................. 274 Index ........................................................................................................................................ 277 12
Ken Bradley’s Understanding PRINCE 2 FOREWORD This publication is based on the PRINCE 2 Project Management Methodology. It has been produced to help anybody involved in a PRINCE 2 controlled project to understand the approaches used in the Method. This re-print incorporates the additional material included in the new manual – “Managing Successful Projects with PRINCE 2” published in October 1998. The book aims to fill the gaps present in the PRINCE 2 Method – in order to do this certain assumptions have been made and these are based upon my own experience and understanding of the practical use of PRINCE. I hope you will not only find this publication of practical use in managing your projects but will also enjoy reading and learning from it. If you have any questions or observations about the content of this publication, please contact me at SPOCE Project Management Limited direct at (UK +44) 01202-780740 (Telephone & fax) or E-Mail KGB@spoce.com Ken Bradley February 1999 Who This Publication Is Intended For PRINCE 2 is the UK Government standard for managing large projects and has been widely adopted as the standard for project management for all types of projects within the private and public sectors. PRINCE 2 was officially launched on 1 October 1996. The book is aimed at Project Managers, project management staff, and anyone needing to organise, plan and control an undertaking using a structured project management approach. Although primarily a summary and interpretation of the PRINCE 2 project management method, this publication provides an excellent start point for anyone wishing to understand the principles and use of structured project management in any activity. It is also an invaluable aid for anyone wishing to take the CCTA/APMG PRINCE 2 examinations. 13
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 1 UNDERSTANDING THE BACKGROUND TO THE PRINCE METHODOLOGY 15
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Origins of the PRINCE 2 Method The PRINCE Methodology is a development of the PROMPT Methodology (Project Resource Organisation Management Planning Technique) originally formulated in the mid 1970s. A private sector company, Simpact Systems Limited, evolved the PROMPT Methodology to provide a suitable framework within which to manage the strategy, feasibility study, development and support of Information Technology systems through a structured project management approach. The PROMPT Methodology The PROMPT Methodology comprised five major components: ♦ PROMPT I - Strategic Planning ♦ PROMPT II - System Development ♦ PROMPT III - Operations, Maintenance and Enhancement ♦ QSTAR Quality Assurance ♦ PROMPT Software Support Tools (The PROMPT Aids). Government PROMPT In the early 1980s, the UK Government published a requirement for a project management method to improve the management and control of government IT projects. Many different methods were proposed and evaluated, and the contract to license the use of the Method was awarded to Simpact Systems Limited. CCTA (Central Computer and Telecommunications Agency) acting for the UK Government commissioned some changes in the basic methodology. Chief amongst these was the incorporation of the quality assurance aspects into the PROMPT II Methodology to provide a product that was to become referred to as “Government PROMPT”. Although CCTA licensed all the PROMPT Methodology, PROMPT II was the only element fully implemented. The belief was that Government Departments were already well supported in the production of strategic plans, and that maintenance and enhancement aspects would be easily handled providing development systems were properly supported by development and quality assurance documentation. PROMPT II was therefore considered to be the key ingredient for success. Government PROMPT, incorporating PROMPT II principles only was introduced into the major UK Government Departments in Spring 1983. 17
Ken Bradley’s Understanding PRINCE 2 The Standard PROMPT Lifecycle Government PROMPT had a number of deficiencies from the start; for instance, a pre- defined lifecycle provided the backbone for a PROMPT II project, but this caused some problems with its view that IT projects broke down into standard stages of work addressing Initiation, Specification, Design, Development, Installation, and Operation. Many projects did not conform to this formula and inconsistencies were encountered. Initiation Specification Design Development Installation Operation The PROMPT II “Planning” Stages The PROMPT II “Action” Stages Figure 1: The PROMPT Standard Six Stage Lifecycle PROMPT Organisation - Stage Managers The PROMPT II Method made no mention of Project Managers, instead relying on a series of Stage Managers, each responsible for a pre-defined stage within the standard six stage lifecycle. The philosophy was that this left the way open to appoint the most appropriate individual to manage each Stage of the project. The Specification Stage managed by a User/Customer, the Design Stage by a Designer/Analyst, the Development Stage by a Technical Programmer and the Installation and Operation Stages by User/Customers. The Initiation Stage was typically managed by someone with sufficient technical expertise to understand and plan the whole of the project. 18
Ken Bradley’s Understanding PRINCE 2 Senior Management - Strategic Direction The Project Board Senior User Senior Technical Executive Assurance Stage 2 Manager Stage 4 Manager Stage 6 Manager Specification Development Operation Stage 1 Manager Stage 3 Manager Stage 5 Manager Initiation Design Installation Work Direction Administrative Support Project Assurance Team Project Resources & Development Teams * Business Assurance Co-ordinator * Technical Assurance Co-ordinator * User Assurance Co-ordinator Figure 2: The PROMPT Organisation Structure PROMPT Planning The Government PROMPT Methodology also made no mention or use of Critical Path Analysis, which was used extensively in major projects. In practice these omissions did not cause real problems as training courses and consultancy support filled the gaps. However the methodology was perceived as being not quite complete, or indeed, relevant to many projects. The Enhancement Project and PRINCE During 1987, CCTA determined to update the Methodology by reflecting the actual usage of PROMPT II and by introducing modern project management ideas. These elements were Product-based planning, formal Project Initiation procedures, a Project Manager role, sharper focus on Quality Management, and Open Life-cycle planning. Leading consultancy companies in project and quality management were contracted to work with the PROMPT User Group and CCTA to incorporate the changes. 19
Ken Bradley’s Understanding PRINCE 2 CCTA were keen to place the enhanced method into the public domain, as an open method, in order to enable suppliers of major IT systems (and their component parts) to adhere to consistent standards when fulfilling UK Government contracts. The overall objective was to provide a high-level of consistency throughout government projects and to improve project management generally. Meanwhile, LBMS (Learmonth & Burchett Management Systems) a major management consultancy company, who had developed SSADM (Structured Systems Analysis and Design Methodology) under a CCTA contract, had acquired the PROMPT products and name from Simpact Systems (which had ceased its commercial operations) and was licensing the methodology successfully to the public and private sectors. LBMS obviously could not agree to an enhanced version of PROMPT II being placed in the public domain in direct competition with their own proprietary method, and negotiations provided that the enhanced method be re-named PRINCE (Projects in Controlled Environments) to meet this point. PRINCE was introduced in April 1989 with full documentation and formal entry into the public domain in January 1990. The PRINCE Methodology is now the UK Government Standard for managing major projects. It has been widely adopted by private sector companies both for use in government projects, and in many cases for their own internal use. CCTA, with its collaborative partners (The Association for Project Management Group, IBM UK Limited, and The Stationery Office) continues to pursue the acceptance of PRINCE as “best practice” project management within the UK, Europe and worldwide. PRINCE 2 and Other Developments PRINCE 2 has now been developed, funded by CCTA and following extensive consultation with users and organisations over a two year period. PRINCE 2 is “Process- driven” (ie “what” and “why” but little in the way of “how”) addresses a wider base of projects (IT and non-IT), Programmes of Work, Smaller Projects, Customer:Supplier: issues and introduces changes to the PRINCE version 1 Organisation component. PRINCE 2 was formally launched by CCTA in London on 1 October 1996. CCTA are working in collaborative partnership with a number of organisations (IBM (UK), The Stationery Office and the Association for Project Management Group) to promote PRINCE. One of the partners, IBM (UK) Limited, has developed a software support product based on their existing Process Integrator application, which provides a full PRINCE 2 Environment, enabling the launch of specific software for planning, word- processing and other office applications. The package is particularly useful for managing the myriad of project documentation that has to be created, updated, tracked and managed during the life of a project. With PRINCE 2, CCTA has launched an accreditation and certification scheme providing a vehicle for assuring users of PRINCE 2 that training and consultancy providers are registered as competent and that training courses reflect a common syllabus with examinations and certification at its conclusion. 20
Ken Bradley’s Understanding PRINCE 2 CCTA continue to support and develop the PRINCE 2 Method and a contribution is levied from all those taking the APM Group Professional Examinations and registering as trained PRINCE 2 Practitioners. Future plans include companion volumes covering the “softer” aspects of project management (leadership, delegation, appraisal etc) and Programme Management, Risk Management, including examinations on these topics. Further information can be obtained from CCTA Information Services on telephone: (UK +44) (0)1603 704787 21
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 2 UNDERSTANDING THE BASICS 23
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Introduction to PRINCE 2 PRINCE (PRojects IN Controlled Environments) is a structured method for effective management of any size or type of project. It is the standard method for use in UK Government Departments and is widely used in the private sector, NHS and Local Government. A growing number of overseas Governments and multi-national companies have adopted the method, or integrated it within their existing project management approaches. The Method is being promoted actively by the APM Group (APMG) as a “Best Practice” project management approach. Benefits of PRINCE 2 There are a number of benefits to be gained from introducing and using a structured approach to project management; among the benefits of using PRINCE 2 are that it: ♦ identifies management, technical (specialist) and quality Products or Deliverables and helps ensure that they are produced on time and to budget; ♦ focuses attention on the quality of Products or Deliverables; ♦ separates the management and technical/specialist aspects of Organisation, Planning and Control; ♦ facilitates control at all levels; ♦ makes the project’s progress more visible to management; ♦ provides a communication medium for all staff working on the project; ♦ ensures that work progresses in the correct sequence; ♦ involves senior management in the project at the right time and in the right place; ♦ allows the project to be stopped and, if required, re-started completely under management control, at any time in the project’s life; ♦ is in the Public Domain and requires no license fee; ♦ has a well established User Group dedicated to the support, promotion and strengthening of the method. 25
Ken Bradley’s Understanding PRINCE 2 The Structure Of A PRINCE 2 Project Within a PRINCE 2 project environment, each project which is undertaken must: ♦ address all the processes concerned with establishing an effective project management environment; ♦ have a stated business case indicating the benefits and risks of the venture; ♦ demonstrate a properly defined and unique set of Products or Deliverables; ♦ have a corresponding set of activities to construct the Products or Deliverables; ♦ identify appropriate resources to undertake the activities; ♦ have a finite life-span; suitable arrangements for control; ♦ identify an organisation structure with defined responsibilities; ♦ include a set of Processes with associated techniques which will help plan and control the project and bring it to a successful conclusion. A PRINCE 2 project is divided into a number of Management Stages, each forming a distinct unit for management purposes. Like the project, a Stage is driven by a series of Processes, has a defined set of products and activities, a finite life-span, control elements, and an organisational structure. The delivery of these products, to the agreed quality standards, marks the completion of the Management Stage. PRINCE 2 defines: ♦ the organisation of the project and its stages; ♦ the processes which drive the undertaking; ♦ the structure and content of the project plans; ♦ basic project management techniques; ♦ a set of controls which ensure that the project is proceeding to plan. These, together with the products of the project and the activities which produce them, the project business case, all encompassed within a Quality Management framework, make up the PRINCE 2 environment. All products of a PRINCE 2 project are filed within a defined structure - the "Configuration". Management, Specialist and Quality Products are identified and filed separately. The PRINCE 2 framework provides the flexibility to set stage boundaries which are appropriate to the needs of the project. Management Stage boundaries are chosen according to: 26
Ken Bradley’s Understanding PRINCE 2 ♦ the sequence of production of Products/Deliverables; ♦ the grouping of Products into self-contained sets or associated Processes; ♦ natural decision points for review and commitment of resources; ♦ the risks and business sensitivity of the project; ♦ the completion of one or more discrete Processes. The project stages correspond to the steps in the natural project life-cycle towards the eventual outcome. Thus the stage boundaries are normally defined to correspond to the completion of the major Products to be built and key decisions concerning commitment of resources that need to be made. Whatever the nature of the project, it is advisable to define one or more planning and/or definition processes in the early part of the project's life. PRINCE 2 provides two Processes to cater for this - “Starting Up A Project (SU)” (where the early foundations for decision support are laid) and “Initiating A Project (IP)” (where senior management are invited to commit to the undertaking and a baseline is produced. The project is triggered by a “Project Mandate” which might take any form from an informal request by a sponsor to a formal recommendation from a report. PRINCE 2 recognises that few projects will be undertaken entirely in isolation. The outputs from one project may be used as input by another project. There may be other dependencies between projects, such as the use of shared resources. PRINCE 2, therefore, provides a mechanism for defining the boundary of a project and its relationship to other projects. A high-level context diagram is a useful mechanism for defining these relationships. Key User Groups Current System Business Processes Cleaned Data The Project Under Development Bullet List of the Main Functions to be produced, developed or bought-in Information Parts Requisitions MIS Project Central Logistics Project Figure 3: Scoping Diagram showing Inputs and Outputs for the Project The Scoping Diagram illustrated above is particularly useful when planning and managing a Programme of Work where individual projects inter-relate with each other and it is necessary to ensure that expected outputs from individual projects are anticipated and planned for. When all individual project Context Diagrams are assembled to complete the 27
Ken Bradley’s Understanding PRINCE 2 programme “jigsaw” it will be apparent which outputs and inputs do not match, and appropriate action can be taken by the Programme Director/Manager. The Key Elements Contained In PRINCE 2 To understand the content of the PRINCE 2 Project Management Method, the following model showing the key elements should be studied: ORGANISATION STANDARDS & APPROACHES; BUSINESS STANDARDS & ETHICS QUALITY MANAGEMENT SYSTEM (QMS) (ISO9001) TECHNIQUES COMPONENTS PROCESSES * Product-Based Planning * Organisation * Starting Up A Project (SU) - Product Breakdown - Structure & Role Descriptions - Product Description * Initiating A Project (IP) - Product Flow Diagram * Planning - Products, Activities, Resources * Directing A Project (DP) * Quality Reviews * Controls * Controlling A Stage (CS) - Preparation, Review, - Management, Team, Quality Follow-up * Managing Product Delivery (MP) * Stages - Management & Technical Stages * Managing Stage Boundaries (SB) * Change Control - Capture, Logging, * Management of Risk * Closing A Project (CP) Assessment, Decision - Risk Assessment & Management * Planning (PL) * Quality in a Project Environment * Project Filing Structure - Quality Requirements & Response - Management File THE BUSINESS CASE - Specialist File * Configuration Management * Business Benefits - Quality File - Tracking Products & Documentation + Existing Organisation * Change Control RISK MANAGEMENT Techniques already used - Capture & Assessment * Risk Analysis & Actions within the host organisation * Risk Management PRINCE 2 SOFTWARE SUPPORT ENVIRONMENT EXPERIENCE, BEST PRACTICE, COMMONSENSE Figure 4: Summary Model of the PRINCE 2 Method The PRINCE 2 methodology applies three key elements to each project and to the Management Stages within a project. These are summarised in the above Model and described, briefly, in the following tables. The three elements are the Processes which drive the project management, Components and Techniques, which are used by each of the Processes to effect the management of the project. 28
Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Processes DESCRIPTION REF EXPLANATION Starting Up A Project SU Establishes the Objectives and Approach to the Project; Set up the Project Management Team; Plans for the Initiation Process. This is a pre- project Process, which looks to answer the question “do we have a worthwhile and viable project?” before asking for commitment of resources to set up a project environment. Initiating A Project IP Plans the whole Project in terms of its Products, Activities, Resource Usage and Quality; Sets the baseline for the Business Benefits & Risks. Directing A Project DP Provides Authorisation for work to be carried out and Resources to be committed. Authorisation for Project Initiation and Project Closure and, in some cases, its premature termination. The Process is “owned” by the Project Board – the ultimate authority for the Project - accountable for its overall success. Controlling A Stage CS The basic day-to-day project management Process - authorising work to create or change Products (or Deliverables), collecting and reflecting “actuals”, assessing progress and reporting to senior management. Capturing proposed changes and errors and escalating these, where appropriate to management. Managing Product Delivery MP The main “workshop” for the project where the majority of resources are consumed. This Process is where the Products of the Project are created. Progress reports (Checkpoint Reports) are provided to the Project Manager. Quality Review and Delivery of Products occurs here. Managing Stage Boundaries SB Reporting on the achievements of the Current Management Stage and the impact on the overall Project Plan and Business Case. Planning the Next Stage (Products, Activities, Resource Usage). Putting together Exception Plans when the Management Stage has suffered a significant departure from its approved plan. Closing A Project CP Preparation for closing the Project in an orderly way. Customer sign-off, preparation of an End- Project Report and identification of Lessons Learned and Follow-on Recommendations. Planning for a Post-Project Review. Planning PL Used by all the other Processes - a common-to- all Process featuring the design of the plan and its creation. 29
Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Components: DESCRIPTION USED EXPLANATION BY Organisation SU Organisation Structure + Role Descriptions. SB Predominantly used in the “Starting Up A Project” Process where the Executive and Project Manager are appointed in the first Process, and the Project Management Team is designed and appointed. The Project Management Team is reviewed at the end of each Management Stage within “Managing Stage Boundaries”. Planning SU All Processes use the Planning Component. The IP Initiation of the project is planned during CS “Starting Up A Project”; the project itself is MP planned in “Initiating A Project”; Stage plans SB are prepared in “Managing Stage Boundaries”; CP and Product planning is carried out in PL “Controlling A Stage” and “Managing Product DP Delivery”. Follow-on actions, including preparation of a Post-Project Review Plan are put together in “Closing A Project”. “Directing A Project” uses the approved plans throughout to confirm the required progress. Controls SU All the Processes use the Controls Component. IP The “control” Processes which make particular CS use of this Component are “Initiating A Project” MP (which sets up the overall project control SB structure); “Controlling A Stage” (which uses CP Checkpoint Reports to capture progress, and PL records actual usage of resources. Highlight DP Reports are used to inform the Project Board of progress); “Managing Product Delivery” generates Checkpoint Reports for control purposes. Stage approval is handled by “Managing Stage Boundaries” where Management Stages are approved via End Stage Assessments. This Process also uses Exception Reporting and Planning to control significant departures from plan. “Directing A Project” is the Process within which overall authorisations are made; this Process uses the key controls of End Stage Assessment, Tolerance, Project Initiation and Project Closure. 30
Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Components (Continued) Stages IP Management Stages provide the key control for SB the Project Board and are mainly used by CS “Directing A Project” when authorising DP commitment for expenditure. Technical Stages often overlap and run in parallel; Management Stages may not. The key control Processes use Management Stages in planning and control of the project. Management of Risk SU Risk Analysis is carried out initially in “Starting IP Up A Project” when the Project Brief is created. SB This is refined in “Initiating A Project” where DP the Business Case for the project is established. The Risk Analysis is updated during “Managing Stage Boundaries” to provide the basis for decision support for the Project Board when they review the project at the End Stage Assessment in “Directing A Project”. No specific risk analysis tools or techniques are recommended. Management of risk has close ties with the Business Benefits which are measured and presented as the Business case for the project. Both the Business Case and the Risk Analysis are up-dated, minimally, at the end of each Management Stage. Quality In A Project SU The Customer’s Quality Expectations are first Environment IP identified in “Starting Up A Project” and quality CS aspects are planned in “Initiating A Project”. MP When the project is approved, “Controlling A PL Stage” and “Managing Product Delivery” enable specific Quality Criteria to be set for each Product or Deliverable via Product Descriptions described in the “Planning” Process. Configuration IP Configuration Management addresses the proper Management CS safeguarding and management of Products or MP Deliverables and their associated documentation. CP “Initiating A Project” sets up the Project Files and “Controlling A Stage” and “Managing Product Delivery” executes the Configuration Management arrangements. Project Files are archived in “Closing A Project” mainly for audit purposes. Change Control CS Managing proposals for change is an important aspect of project management and the Process “Controlling A Stage” is where such proposals are captured. 31
Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Techniques DESCRIPTION EXPLANATION Product-Based Planning A “Product Breakdown Structure” which identifies the Products or Deliverables to be produced during the project. A “Product Description” for each Product identified in the Product Breakdown Structure, which defines and specifies each Product; a key feature of the Product Description is the Quality Criteria used to ensure that the Product is indeed a “Quality Product” that conforms to its requirements. A “Product Flow Diagram” which shows the relationship that each Product has with others and external entities; the Product Flow Diagram must “balance” with the Product Breakdown Structure. Quality Review Technique Used for measuring a Product or Deliverable against its published Quality Criteria. PRINCE 2 recognises Informal Quality Reviews (typically “Desk Checks”, Tests or Visual inspections) and Formal Quality Reviews (which are more structured “Walkthroughs” of a Product or Deliverable). Formal Quality Reviews comprise three distinct Phases - Preparation, The Review Meeting and Follow-Up. Change Control Every project must be able to accommodate changes required by the customer or anyone else who has an interest in the project’s outcome. All suggested changes, identified errors and departures from the agreed Specification must be captured as “Project Issues, logged, analysed for technical, customer and business impact, and a decision made on whether to accept or reject the Issue. Project Filing A suitable filing structure is suggested; this comprises a “Management File” made up of one Project File and a series of Stage Files - one for each of the Management Stages of the project. A Specialist File housing the documentation relating to the technical aspects of the project and a Quality File housing the Quality Review documentation and the Project Issues complete the structure. More on the PRINCE 2 Processes The eight major Processes state the minimum content that can be expected to be found in a PRINCE 2 compliant project. Exactly how the Processes are addressed within any project is the responsibility of the organisation’s senior management, represented by the Project Board, and the Project Manager, but the method requires that each of the eight Processes is reflected within the project one way or another. All the Processes link to Components and Techniques some of which are described within 32
Ken Bradley’s Understanding PRINCE 2 the method. It is anticipated that most organisations will already be using some specific Techniques and might wish to incorporate additional Components reflecting their business environment and culture. PRINCE encourages this where they provide value to the management decision making process. Each Process is defined in the following terms: ♦ The Fundamental Principles that underpin the Process; ♦ The Context within which the Process operates; ♦ An Overview of the Process; ♦ Responsibilities identifying accountability for the Process; ♦ The Information Needs required for the Process to function effectively; ♦ The Key Criteria which will influence the success or failure of the Process; ♦ Hints and Tips for carrying out the Process in the best way. ♦ Major Processes have an additional “Scalability” heading to help with scaling down each Process for smaller, lower risk projects, where this is required by senior managers. The Process-based approach is a powerful feature in PRINCE 2 and is the area which most differentiates it from version 1 of the method. The flexibility of the method is, however, underlined by allowing implementing organisations to choose their own destiny in terms of identifying how to meet the requirements of any given Process. In most organisations already operating successful project management systems there will be little need to make changes to the way they are operating, provided effective project management procedures are already in place. The Organisation Component The organisation and effective use of people assigned to manage a project needs to be considered from the view point both of the specialist skills they bring to the project and their individual personalities. Responsibilities need to be defined within a team structure to ensure that management is both efficient and responsive, and that individuals understand exactly what is expected of them. Within PRINCE 2, responsibilities are defined in terms of roles, rather than individual’s jobs. Assignment of roles to individuals is a decision for each Project Board to take in the light of organisational circumstances, and the same individual may be assigned to more than one role, or to different roles at different stages of the project. Three roles/interests must always be represented on any PRINCE 2 project – Business, User, and Supplier. 33
Ken Bradley’s Understanding PRINCE 2 Corporate or Programme Management The Project Board Senior User Senior Supplier Executive Project Assurance Project Manager Project Support Team Manager Team Manager Team Manager Project Resources & Teams Figure 5: The PRINCE 2 Organisation Structure The Project Board Every PRINCE 2 project will have a Project Board appointed. The Project Board is the ultimate authority for the project and is normally appointed by Corporate or Programme Management to take overall responsibility and control of a PRINCE 2 project. The Project Board consists of three senior management roles, each representing major project interests. ♦ Executive: appointed by Corporate/Programme Management to provide overall project guidance and assessment throughout. The Executive represents the interests of the Customer and the Business and has overall responsibility for the project. ♦ Senior User: representing users (and, where appropriate, Customers) of the outcome or the major products from the project. ♦ Senior Supplier: representing areas which have responsibility for providing the specialist “know-how” and/or committing Supplier resources for the solution. The Senior Supplier might be drawn from an external, commercial, organisation or from internal sources responsible for delivering the specialist “End Product” to the customer (or a mixture of both). 34
Ken Bradley’s Understanding PRINCE 2 There is a requirement within the Method to have a Project Board function and this cannot be eliminated or delegated (although the terminology may be changed to suit the organisation’s culture, for example “The Project Authority”). The Project Board’s accountability for Project Assurance cannot be delegated although the day-to-day work of Project Assurance can if Project Board members do not have the time or expertise to carry out the tasks involved. The Project Manager A Project Manager will always be appointed to assume day-to-day responsibility for planning and management of the project throughout all its Management Stages. The Project Manager takes direction from the Project Board and is responsible for managing, on behalf of the Project Board, the Processes, planning and delivery of Products for the project, on-time, within budget, meeting the specialist/technical and quality criteria agreed with the Project Board. As with the Project Board, the role of Project Manager is a required role within the Methodology and cannot be shared, delegated or eliminated. The Team Manager In a large or complex project, one or more Team Managers may be assigned the responsibility for ensuring that the products of one or more particular Technical, or Specialist, Stages of work are planned, controlled and produced on schedule, to the defined and agreed quality standards, and within budget. Project Manager Project Support Team Manager Team Manager Team Manager Project Resources & Teams Figure 6: Project Manager and Team Manager Relationships The Team Manager role is optional and will only be present in large projects or where the Project Manager lacks the specialist skills to plan and control specific parts of the project. 35
Ken Bradley’s Understanding PRINCE 2 Project Resources and (Specialist) Teams The Project and/or Team Manager have responsibility for Teams of specialist staff, tasked to carry out the activities and produce the Products of the stage. The team organisation, responsibility definitions and the allocation of these responsibilities to individuals will depend upon the size and nature of the project and the skill mix available. PRINCE 2 recognises the need to establish Team Manager roles where appropriate; Project Assurance PRINCE 2 separates the Project Assurance function from the Project Support function. The Project Board have responsibility and accountability for Project Assurance. Depending on the size, scope, risk and profile of the project, and their own knowledge, skills and time available, they may choose to delegate responsibility for overseeing day to day Project Assurance to others within the organisation. However, accountability for Project Assurance rests with the Project Board and they are not able to delegate this. Project Assurance may not be delegated to the Project Manager or to Team Managers. The Project Board Senior User Senior Supplier Executive User Assurance Specialist Assurance Business Assurance Project Assurance Figure 7: Project Board and Project Assurance Functions Although not specifically separated out in the PRINCE 2 Method, Project Assurance can be found in two distinct forms: ♦ External Assurance to confirm that the project is following overall and corporate standards (eg the published Quality Management System, or particular accounting conventions) and the organisation can be expected to have an audit function already in place to check these aspects. ♦ Internal Assurance to verify that the project is delivering Products or Deliverables that meet the agreed Quality Criteria and that internal project standards are being followed. Internal Assurance is ultimately the responsibility of the Project Board. 36
Ken Bradley’s Understanding PRINCE 2 Project Support Within PRINCE 2, Project Support, on a formal basis, will only exist where there is a perceived need for it. A Project Manager may well find that the Project Board see no scope for any administrative support, and that any day-to-day assistance might need to be on an “ad-hoc” basis. Project Manager Project Support Figure 8: Project Manager and Project Support Relationships Where a project does warrant the appointment of a Project Support function, the individual(s) selected will report directly to the Project Manager. Incidental support for the Team Managers, where appointed, and Team resources will normally form part of Project Support’s responsibilities. The Project Support Office A Project Support Office might well evolve in a Programme or multi-project environment, to support a number of individual projects. The methodology supports the possibility of a transition from several Project Support individuals to a central Project Support Office where the number of projects under development warrants it. The resultant Project Support Office will be able to provide a centre of expertise for all project management aspects within the organisation/site, effectively delivering an internal consultancy service where required by Project Board members, Project Managers and project team members. Summary of The Organisation Component In the final analysis, it is the people who are responsible for the management of the project and the creation of its deliverables who have its success in their hands. Clear definition of responsibilities and a tenacious commitment to achieving agreed goals will always be the predominant factor in success. The PRINCE 2 Method must always be tuned to suit the implementing organisation’s existing standards, business approaches, culture and people; the latter two are arguably the most important. 37
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Planning Estimating, planning and re-planning are constant and key activities when managing any project. PRINCE 2 provides a structure for preparing and maintaining plans at appropriate levels throughout the life of a project. Plans are prepared for the Project as a whole, for each stage within the project and, optionally, for the teams’ work within each Management Stage. There is also an Exception Reporting and Planning process to handle divergences from the original plan. The PRINCE 2 method include a Technique for Product-Based planning incorporating Activity planning, Resource reporting and Quality planning. Products or Deliverables and Related Activities PRINCE 2 provides a set of planning techniques which give structure to the project. The key to PRINCE 2 planning is the identification and definition of the Products required. From this comes an analysis of the work (ie the activities) required to generate these products, and the sequencing of the work. PRINCE makes a distinction between Management Products and Activities, Specialist Products and Activities, and Quality Products and Activities. This is partly because these are usually the concern of different groups of people, but also to ensure that management activities are not overlooked in planning and estimating. The Plan Text provides a high-level, overall view of Plan the plan, summarising its key features Text Product Identifying the Products/Deliverables that will be Breakdown produced by the Project. The Products will be categorised Structure under the headings of “Specialist”, “Management”, and “Quality” Products. Describing the Products/Deliverables that will be Product produced by the Project. There is a prescribed format Descriptions for Product Descriptions Describing the relationships that exist between Product each Product/Deliverable, and external entities. Flow Diagram PERT or Showing the relationships that extist between the Activities that will be undertaken Activity to create the Products identified in the Product Breakdown Structure. Network Gantt Derived from the PERT Network, this shows when Activities are or planned to start and end. Major Review points (End Stage Timescale Assessments) are also shown on this plan. Plan Figure 9: PRINCE 2 Plans Structure 38
Ken Bradley’s Understanding PRINCE 2 Management activities are concerned with planning, monitoring and reporting the work of the project, in both normal and exceptional situations. They produce Management Products in the form of plans, reports and other control documents. Management activities include the planning and control of all specialist activities on the project. Although influenced by the specialist content, a similar pattern of management tasks can be expected to be present in any PRINCE 2 project. Conversely, the Specialist activities undertaken by a project are determined entirely by the scope and objectives of the project. The Specialist activities describe the work needed to produce the Specialist Products required from the project. The Specialist Products required by the user/customer are identified and defined at the start of the project by the Project Manager and accepted by the Project Board. Additional Specialist Products may be defined by the strategy appropriate to a particular Management Stage of the project; specialist activities may also be prescribed by an organisation’s own particular technical strategy. PRINCE 2 therefore acknowledges the need for flexibility in the selection and definition of Specialist activities and the corresponding Products. Completed Feasibility Study Management Products Specialist Products Quality Products MP01 - Project Initiation Document MP02 - Stage Plans FS 01 - Business review MP03 - Lessons Learned Log FS02 - Problem Definition QP01 - Product Descriptions MP04 - Risk Log FS03 - Options Identified & Agreed QP02 - Quality Review Documentation MP05 - Business Case FS04 - Options Appraised QP03 - Project Issues Log MP06 - Product Checklist FS05 - Selected Option Agreed QP04 - Quality Log MP07 - Highlight Reports FS06 - Final Report QP05 - Configuration Management MP08 - Project Start Notification MP09 - Project End Notification MP10 - Project Filing Structure The Technical Management Standard for the Project The Project Management The Quality Management Standard for the Standard for the Project Project Figure 10: Management, Quality and Specialist Products (For A Typical Feasibility Study) Quality activities may be performed by anyone who is able to make a contribution to the Product under review. Individuals within the project and host organisation as well as people external to the organisation are all appropriate. Quality activities must be planned for early in the life of the project. The PRINCE 2 Product planning techniques require every project to be described and 39
Ken Bradley’s Understanding PRINCE 2 defined in terms of its Products or Deliverables. This is a very effective way to ensure full understanding of what is required and to ensure that, as far as possible, all resource consuming activities are related to one or more required Products. Planning for the Delivery of Specialist Products PRINCE 2 Plans are concerned with the Products to be delivered and with the activities necessary to ensure that these Products emerge on time and to the required quality standards. The project Products are identified as a first step in Product-Based Planning; definition of each product (via the PRINCE Product Description) allows its make-up and quality requirements to be documented and properly understood. A Product Breakdown Structure illustrates the hierarchical make-up of the complete set of project products and a Product Flow Diagram provides a view of the relationship each product has with others, within and outside of the project. FS01 Solution Providers Strategy Plan Business Review FS02 Problem Definition FS03 Options Identified & Agreed FS04 Options Appraised FS06 FS05 Final Report Selected Option Agreed Figure 11: Product Flow Diagram (For A Feasibility Study) The Project Timescale or Gantt Plan charts the major activities of the project. It is usually derived from the PERT (Programme Evaluation and Review Technique) or Activity Network which shows the relationships that exist between project activities. It is used in conjunction with a Project Resources Report to monitor progress on the project as a whole. It also addresses planning requirements related to Quality Control and Configuration Management. A Stage-level Gantt (or time-scale) Plan shows the products, activities and quality controls for each stage of the project. The Stage-level Gantt Plan is produced and approved at the end of the previous stage (the plan for the first stage is prepared with the project plan). 40
Ken Bradley’s Understanding PRINCE 2 Additional, lower-level Gantt Plans can be expected to exist in most projects, to give a detailed breakdown of particular major activities These are termed “Team Plans”. Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Figure 12: Gantt Plan (Time-scale Plan) Lower level Plans (or Individual Work-to Lists), if required, are derived from the Stage and Team Plans to allocate detailed activities (and Products/Deliverables) to particular members of a Specialist Stage Team. Although this level of plan is not formally included in PRINCE 2 they may be utilised if the size and/or complexity of the project requires their production. Resource Planning & Reporting Resource requirements are concerned with managing the funding and effort resources of the project. Specific resource plans are not produced for PRINCE 2 controlled projects, as the method assumes that a software planning tool will be used. Where this is the case, relevant reports on planned and actual resource usage can be drawn from the Project Plan in the form of a “Resources Report” as and when required. Where a software support tool for planning is not in use (for example in the case of a low cost, short duration, low risk project) the format for a resources plan or report shown in figure 13 may be of use. Even where a software planning tool is in use, the presentation of the information might well benefit by adopting the format shown in figure 13 as it reflects the type and level of information required by the Project Board in reaching a suitable business decision. It is the decision-support information about the requested commitment of resources that is of most use to Project Board members in reaching their decision to start or continue with the project and careful thought must be given as to the most appropriate presentation of the data. 41
Ken Bradley’s Understanding PRINCE 2 Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual EFFORT (Staff Weeks) Skill Types Customers Engineers IT Analysts Others COSTS (£K) Skill Types Customers Engineers IT Analysts Others Equipment Fixed Price Elements Total Stage Costs Total Project Costs Figure 13: Typical Project Resources Report (or Plan) The standard Resources Report drawn from any software-driven Project Plan will identify the type, amount and cost of the resources required by the project related to each Management Stage of the work. It will also identify equipment, building, and fixed-price costs associated with the project. The intention is to provide a complete resource and financial picture of the undertaking. A more detailed Resources Report, at Management Stage Level identifies the resources required by the particular stage. It defines the budget required by the stage and is used to report actual expenditure and resource usage against plan More detailed Resource Plans at the Team Level will be produced when required, to plan and control a particular major activity, and the associated team work-plans and Products. Quality Planning - BS/EN/ISO9001 Action must be taken at project planning time (within the “Initiating A Project (IP1)” Process) to ensure that the project can deliver its Products to the required quality standards (the Customers Quality Expectations) required by the customer. Quality Criteria must be defined and agreed, and incorporated into a Product Description for each major Product identified; a Project Quality Plan must be defined, published and adopted; Quality Review procedures must be established and staff trained; review activities must be properly resourced. Whatever action is proposed to build quality into the project, the measures must be consistent with any published Quality Management System (QMS) that is already in effect. PRINCE 2 has been designed to comply with the BS/EN/ISO9001 Quality Management Standard and the method contains a section relating its content to each section of the ISO Standard. BS6079, the Project management Standard, is also reflected within PRINCE 2. ISO9001, BS6079 and PRINCE 2 are all Process-driven; the foundation for quality and 42
Ken Bradley’s Understanding PRINCE 2 effective, modern project management is therefore integral and inherent in PRINCE 2. The results of the quality planning activity must be integrated into the timescale and resource plans at each level. Just as quality must be built into the Products, so must quality control be built into the plans. Project Plan (Mandatory Plan) Stage Plan Stage Plan Stage Plan Team Team Team Team Team Team Plan Plan Plan Plan Plan Plan Project Resources Report (Effort, Costs, Equipment, Direct Costs) Figure 14: PRINCE 2 Planning Levels - Project, Stage & Team ♦ The Project Level plan (required) sets the overall quality approach for the entire project. It defines the standards to be followed and the quality criteria for the major products. It also identifies external constraints that may apply to the project, such as a specific Configuration Management Method. ♦ The Stage Level plan (required) identifies the quality criteria, methods and review guidelines for each Product produced during the stage. ♦ A Team plan (optional) might be required for specific individual activities such as carrying out interviews within a particular user/customer area. The Project Manager is responsible for deciding whether any plans below stage-level are required; this decision will be endorsed by the Project Board at the Project Initiation or End-Stage Assessment meeting. Tolerance and Planning The Project Board Executive sets tolerances for Stage Plans. These define the limits of time-scale and cost (or sometimes effort) within which the Project Manager can operate without further reference to the Project Board. Tolerance is variable and will be assigned to each Management Stage to reflect the respective business risk, but a general rule of 43
Ken Bradley’s Understanding PRINCE 2 thumb is that Time Tolerance of plus/minus 1 week and Cost Tolerance of plus/minus 10% is about right. An Exception Report and, subsequently, if required by the Project Board, an Exception Plan, is produced in situations where costs or time-scales are forecast to be exceeded beyond the tolerances set by the Project Board. The Exception Report describes the cause of the deviation from plan and its consequences and recommends corrective action to the Project Board. Once considered and approved by the Project Board at a Mid-Stage Assessment (MSA), the Exception Plan replaces the re- mainder of the current Stage Plan. The Controls Component Regular and formal monitoring of actual progress against the approved plan is essential to ensure the timeliness, cost control and quality of the system or undertaking being developed. PRINCE 2 provides a support structure of Management and Product-oriented controls to monitor progress, supported by a reporting procedure which enables re- planning or other appropriate corrective action to be taken. Management Controls PRINCE 2 provides a structure of management controls to be applied throughout the project. These controls cover all aspects of project activity and, at the highest level, allow the Project Board to assess project achievement and status prior to committing further expenditure. Controls are applied through measuring the progress towards production of a set of pre-defined outputs (Products or Deliverables). The overall structure of Management Controls is defined during the project Initiation Stage (“Initiating A Project (IP4)” Process) to ensure that the project is set up with clear Terms of Reference, incorporating agreed and measurable Objectives and an adequate management control structure. Project Initiation To document a firm foundation and to provide a positive start to the project, ensuring that the terms of reference, objectives, plans and controls, business risks, benefits and financial return, organisation structure and job definitions are clearly defined, published, understood and agreed. This Management Product is very important to the project and is the result of two Processes - the pre-project “Starting Up A Project (SU)” and “Initiating A Project (IP)”. The key output is the Project Initiation Document (PID) which, when approved by the Project Board, is a “frozen” document used to baseline the project. 44
Ken Bradley’s Understanding PRINCE 2 End Stage Assessment (ESA) This is a required management control and occurs at the end of each stage. It typically consists of a formal presentation to the Project Board of the current project status, and reviews the overall business case (benefits and risks). The approval of the proposed plans for the next stage is also obtained. Project Board approval, with agreement by all the members, must be obtained before the project can proceed to the next stage. “Managing Stage Boundaries” Process •Up-date the Plans for Stage 1; •Up-date the Project Plans; •Up-date the Business Case (Benefits & Risks); •Prepare the Plans for Stage 2 Stage 1 - Planning & Definition Stage 2 - Design & Contract End Stage Assessment (ESA) “Directing A Project” Process •Review the Outcome of Stage 1; •Review the Project Plans; •Review the Business Case (Benefits & Risks); •Preview the Plans for Stage 2. •Endorse the Project & Approve continuation of the project up to the next End Stage Assessment. Figure 15: Handling End Stage Assessments Mid Stage Assessment (MSA) This Project Board control is held only to review a significant deviation from an approved Management Stage Plan and to approve an Exception Plan produced, at the request of the Project Board, following an Exception Report. An Exception Report is produced by the Project Manager to alert the Project Board as soon as it is apparent that a significant departure from the approved plan is forecast. The Exception Report records what has happened to cause the “significant departure” from the approved plan, the impact on the Management Stage, overall Project and its Business Case. The plan will also recommend appropriate action to take the project to the end of the Stage and, where possible, recover the situation. 45
Ken Bradley’s Understanding PRINCE 2 “Controlling A Stage” Process •Deviation from approved Stage Plans Forecast; •Exception Report Created - Reasons; Impact; Options; •Direction from Project Board .... Create an Exception Recommendation; Plan; “Managing Stage Boundaries” Process •Produce an Exception Plan Stage 1 - Planning & Definition Stage 2 - Design & Contract Mid Stage Assessment (MSA) “Directing A Project” Process •Consider theException Plan an unscheduled Mid Stage at •Review the Problems with Stage Assessment. 1; •Review the Impact on the Project Plans; •Review the im[pact on the Business Case (Benefits & Risks); •Preview the revised Plans for the remainder of the Stage. •Endorse the Project & Approve continuation the Stage up to the next End Stage of Assessment. Figure 16: Handling Mid Stage Assessments Tolerance The measure of a “significant departure” is that the Tolerance stated by the Project Board at the beginning of the management stage has been, or is likely to be, exceeded. Tolerance may be thought of as the scope that the Project Manager has been granted by the Project Board to move away from the approved Management Stage Plan without needing to report the variance. Tolerance is not time and money to be spent but should be thought of as “trigger” figures which help keep the Management Stage (and the Project Manager) within “tolerable” bounds. Responsibility for Tolerance stems from the Project Board, with the Executive having responsibility for setting Management Stage Tolerance with the Project Manager. The Executive is also responsible for ensuring that an overall Tolerance is set for the project by Corporate or Programme Management and that it is suitably recorded in the Project Brief during “Starting Up A Project (SU)”. Tolerance should always be set in terms of both time and cost, as over-concentration on just one aspect will imbalance the overall project resulting in an unexpected and unpredicted time or budget slippage. 46
Ken Bradley’s Understanding PRINCE 2 Plus 10% Tolerance £110K £100K Planned Delivery & Total Cost o Cost £90 Minus 10% Tolerance £80K £70K £60K £50K Plus 1 Week Tolerance £40K £30K Minus 1 Week £20K Tolerance £10K Time 2 4 6 8 10 12 14 16 18 Weeks STAGE PLAN Figure 17: Tolerance - plus/minus 1 week; plus/minus 10% Standard Tolerance in PRINCE 2 is measured in terms of Time (Schedule) and Cost. There are other types of Tolerance which may be applied; these include Tolerance on Quality, Technical Conformance, Scope, and Risk. The level of Tolerance is decided by the Project Board and set by the Executive following recommendations by the Project Manager. Tolerance is most usually applied to a Management Stage but is also be applied at Project level (set by Corporate or Programme Management) and Product level (set by the Project Manager in specific Work Packages). Project Closure A final review of the project's work is held, usually (but not necessarily) in the form of a Project Board meeting. This is similar to a stage assessment but relates to the entire project rather than a single stage. The objective is to ensure that all the project Products/Deliverables have been satisfactorily delivered to their stated quality standard and that the project documentation is complete. A review of the project management standards and approaches used by the project will be carried out within the “Closing A Project (CP)” Process and a Lessons Learned Report produced for consideration by the Project Board. The Lessons Learned Report records what has been learned from using the PRINCE 2 project management and quality management standards for the project and is created during the “Initiating A Project” 47
Ken Bradley’s Understanding PRINCE 2 process and “populated” as the project progresses (at the end of each Management Stage); it will eventually be sent to the organisation’s manager responsible for quality. Recommendations will also be made for Follow-on Actions to record and trigger further work which is recommended following the closure of the project. Follow-on Actions will usually be derived from any outstanding Project Issues, shown on the Issues Log. A Post-Project Review Plan, to enable the organisation to check the actual realisation of benefits after the project’s output has been operating for a while (perhaps 9-12 months following hand-over), will be prepared and authorised by the Project Board. Highlight Reports The Project Board is kept informed of the progress of the Management Stage (and the project) against the approved plans via regular, time-related Highlight Reports. These are prepared by the Project Manager and are usually provided monthly, although their frequency will always be agreed with the Project Board. Highlight Reports are usually sent through the post or by e-mail; the objective is to remove the need for unnecessary time-related Project Board meetings which consume the Project Board members’ valuable time, while still keeping them abreast of significant developments. The format for Highlight Reports will typically include: ♦ a statement of the progress made during the last (usually monthly) period; ♦ a statement of problems during the last period, and how they were handled; ♦ confirmation of the Activities and Products to be worked on during the next period; ♦ a statement of the financial and schedule situation for the overall project and the current Management Stage. Some organisations specify that Highlight Reports should be kept to one side of A4 (or its equivalent). Where the project is part of a Programme of work, separate Project and Programme Highlight Reports will normally be produced. Stages Stages are partitions of the project with decision points at their conclusion, and sometimes during their life. PRINCE 2 differentiates between “Management Stages” (which equate to the commitment of resources by the Project Board and a decision to continue with the project and authority to spend) and “Technical Stages” which comprise sets of technical activities leading to a stated and required Product. 48
Ken Bradley’s Understanding PRINCE 2 Technical Stages Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Review of Management Stage at Project Closure End Stage Assessment (ESA) Figure 18: Management & Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned and managed by Team Managers who report to, and take direction from, the Project Manager. Management Stages will always run in series. In figure 18, some of the Technical Stages have been planned to run in parallel. Of course, in a smaller project these might well be described as “Technical Activities”; in medium to larger projects, the Activities will often combine to provide the Technical Stages under the immediate control of a Team Manager. In only the most exceptional circumstances will authority be given for work to commence on the next Management Stage before all the Products of the current Management Stage is completed. Business Benefits and Risk Management PRINCE 2 places emphasis on the Business Benefits for the project; they are described by the Method as “…the driving force behind the project …”. The purpose of the PRINCE 2 Business Case is the identification and measurement of the Business Benefits and the continued review of them as the project progresses through its Management Stages. Closely associated with the Business Benefits are the Risks that the project faces; essentially the risks divide into two main areas: ♦ Business Risks relating to threats associated with the project not delivering products capable of achieving the claimed and published Business Benefits (eg legislative changes, market changes, environmental issues). 49
Ken Bradley’s Understanding PRINCE 2 ♦ Project Risks which are concerned with the ability to deliver the project’s outcome within the required time and cost requirements (eg failure of third party suppliers, skills shortages, technical problems). The Method does not specify any particular way of measuring Business Benefits or assessing Risks but whatever the chosen approach, PRINCE 2 requires the Business Case and Risks to be updated on a regular basis - minimally at the end of each Management Stage. This provides the Project Board with sufficient, up to date, information on which to base their decision to continue with the project. Planning For Quality PRINCE 2 presumes that the project will be managed under the umbrella of a published Quality Management System (QMS) conformant to ISO9001. If such a QMS is not present the Method compensates by specifying that quality must be planned from the outset. Planning Quality takes place in the “Initiating A Project (IP)” Process and the resultant Project Quality Plan is incorporated into the Project Initiation Document (PID) and used throughout the project. The Process provides the following: ♦ it establishes a Quality regime for the project; ♦ it defines the overall project quality criteria and assurance arrangements to be employed by the project; ♦ it establishes the approach to control of change during the project. Responsibility for planning quality lies with the Project Manager, working in close association with those responsible for quality (ie the Quality Manager). Quality Controls - Quality Review Quality controls are applied to specific products rather than to the overall output of a stage or project. The aim is to identify and correct errors as early as possible in the development process. They will usually take the form of a formal or informal quality review, whichever is specified in the Product Description. 50
Ken Bradley’s Understanding PRINCE 2 Activity (shown on the Gantt or Timescale Plan) consuming Resources (Time/Effort/Funding) Product Description The Product •Composition •Quality Criteria Quality Review •Type of Check Checking the Product against •People Required the Quality Criteria published in the Product Description Figure 19: The Product Description & Quality Review Relationship Quality control may take many forms from a visual inspection, through a test programme, to a formal meeting. These are all Techniques and PRINCE 2 describes some, but not all that might be available - the selection of appropriate Techniques is left to the implementing organisation. However, one of the most powerful Techniques is the Quality review which has been successfully used in a wide variety of projects for a number of years. The Formal Quality Review has three distinct steps: ♦ Preparation - where the Product or Deliverable is measured against the Quality Criteria contained in the Product Description, and Error Lists are created by selected Reviewers who are able to make a suitable contribution. ♦ Review - where the Product or Deliverable is “walked-through” by its Producer and an agreed list of Follow-up Actions is agreed. The Reviewers who prepared the original Error Lists attend this Review. ♦ Follow-up - where the identified faults, errors, omissions and inconsistencies in the Product or Deliverable are fixed, agreed and signed-off. At each Quality Review, appropriate Supplier and user/customer staff are designated to examine a Product to ensure that it is complete and correct; these “appropriate resources” are identified in the Stage-level Plan and the corresponding Product Description. The Product is reviewed against defined quality criteria contained within the Product Description, which assures its technical integrity and its compliance with user or customer requirements; It is thereafter an “Approved Product “subject to formal change control procedures. If any subsequent changes are made to Approved Products, there should always be a reference back to the original Product Description to determine whether a corresponding change needs to be made. This procedure applies to informal quality reviews (for example a test, visual inspection, or desk-check) and to formal quality reviews where 2-3 reviewers meet with the author of the product under the chair of a suitably senior person to “walk-through” the product. 51
Ken Bradley’s Understanding PRINCE 2 Change Control Unplanned situations relating to changes to one or more Products need to be captured as “Issues” relating to the project. Originator Raises A * Good Ideas * Errors Project Issue (Request for Change * Departures From Agreed Specification or Off-Specification) * Resource Changes * Specification Changes Sent to Project Support Copy returned Notify Originator to confirm receipt Project Issues Log Logged byProject Support Project Issues Log Up-dated Reviewed by Project Manager * Slippage/Budget Changes, exceeding Tolerance or affecting other projects within the Programme = Decision by Project Board (Exception Report) OR .... *Changes Within Tolerance = Decision by Project Manager and action taken to implement the change. Figure 20: Suggested Procedure For Controlling Changes Examples of this are good ideas that project team members identify, resource changes, errors discovered in a finished product, and departures from the agreed specification. Because the situation is unplanned, it needs to be recorded and action agreed, in order to contain the impact and prevent wider divergence from plans. Issues are best handled within the framework of a formal Configuration Management scheme. An Issue will be raised to cover any situation which needs to be addressed within the project and to a large extent is a “catch-all” for many unforeseen incidents; for example, where no agreement can be reached on the outcome of a Quality Review, am Issue will be raised to alert the Project Manager. Configuration Management A Configuration Management Method (CMM) controls the development of products by providing a formal mechanism for labeling products, their development status, and the relationship between them. PRINCE 2 does not define or recommend a specific CMM but emphasises the need for a suitable system and clearly states that the presence of suitable arrangements for Configuration Management is not optional. 52
Ken Bradley’s Understanding PRINCE 2 Configuration Management can be particularly useful in tracking back problems with delivered, signed-off Products which fail to perform as expected in operation; identification of the developer or supplier is vital to ensure that problems are tracked back to source and appropriate action taken. Filing Arrangements PRINCE 2 contains a recommended filing structure which implementing organisations may find useful as a start point. Where existing filing arrangements are in force, or where organisations wish to arrange things differently, this may be done without conflicting with the Method. Files Project File Stage File(s) Specialist File Quality File Organisation Organisation Configuration Items Product Descriptions Plans Plans Configuration Log Quality Checks Business Case Control Documents CI Locations Project Issues Risk Log Daily Log Off-Specifications Project Issues Log Control Documents Correspondence Quality Log Product Checklist Product Checklist Lessons Learned Report Figure 21: The PRINCE 2 Suggested Filing Structure Software Support for PRINCE 2 In partnership with CCTA, the owners of the PRINCE Methodology, IBM (UK) have developed a support tool called “The PRINCE 2 Environment”. This tool provides a complete electronic support function which enables the Project Manager (or Project Support) to keep track of the many project documents that are created during the life of the project and to launch any application that is needed to manage the project. Typical applications will be project planning tools, word-processing and spreadsheets; both applications and associated files can be launched, modified and saved. The PRINCE 2 Environment also contains the full PRINCE documentation and “skeletons” for the creation of the Project Initiation Document. Users can add extra options and incorporate their existing documentation to supplement the basic material supplied with the PRINCE 2 Environment. An alternative – The Launch Pad – is available from SPOCE Project Management Limited, providing similar functionality to the PRINCE 2 Environment. An evaluation copy can be downloaded from web site www.spoce.com 53
Ken Bradley’s Understanding PRINCE 2 Following This Introduction The introduction to PRINCE 2 in this Chapter should be sufficient for the “incidental user” or senior manager to understand the basics of the Method. The rest of this book provides further information on PRINCE 2 and explores each topic in more detail. Although the Method is “Process-Driven” and the eight Processes use the Components and Techniques, the recommended starting point to understand what is going on within a PRINCE 2 project is the Components. The remaining Chapters deal with the PRINCE 2 Components, explaining their composition and progresses through Processes to Techniques, adding value to the basic descriptions in the PRINCE 2 Manual. 54
Ken Bradley’s Understanding PRINCE 2 Chapter 3 UNDERSTANDING THE ORGANISATION COMPONENT 55
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Organisation - Introduction Project organisation and staffing is the key to the successful management of any project. If the project staff have the right leadership, the appropriate technical competence, have the will to make the venture successful, and understand exactly what is expected of them, then the project will have an excellent chance of success. Corporate or Programme Management The Project Board Senior User Senior Supplier Executive Project Assurance Project Manager Project Support Team Manager Team Manager Team Manager Project Resources & Teams Figure 22: The Suggested PRINCE 2 Organisation Structure At the top of the organisation structure there will normally be a strategy body (PRINCE 2 identifies this as Corporate or Programme Management) responsible for interpreting the overall objectives of the organisation into working arrangements, systems or other outcomes. In private-sector organisations this body might well be the Board of Directors. The PRINCE 2 organisation model assumes a Customer:Supplier environment within which the project management components, processes and techniques will operate. The structure assumes there will be a customer who will state and define the requirement, pay for the project and use the outcome, and a supplier who will provide the necessary experience, skills and know-how to create the End Product for the customer. This model is used for all PRINCE 2 controlled projects - the supplier might be an external private sector company or an internal division of the purchasing organisation - the approaches used are similar. The main emphasis within the PRINCE 2 organisation component is concentration on direction, management, control and communication. The method provides a flexible framework which is capable of being mapped onto any organisation with the minimum of disruption, and which provides the template to achieve the key outputs. 57
Ken Bradley’s Understanding PRINCE 2 Within any PRINCE project organisation, at least three interests must be represented: ♦ Business Interests - ensuring that the eventual output of the project meets (and continues to meet) a stated business need while at the same time representing good value for the time, money and other resources expended. ♦ User Interests - specifying the desired outcome and ensuring that the project actually delivers what is required. Essentially representing the interests of those who will use the outcome to deliver the business benefits. ♦ Supplier(s) Interests - providing the necessary knowledge, skills, equipment and resources to produce the outcome in accordance with the specification and acceptance criteria. There will often be internal and external specialist suppliers working co- operatively on the project. Responsibilities in a PRINCE 2 Controlled Project The PRINCE 2 Method provides guidelines for the responsibilities that can be expected to be placed on individuals working within the PRINCE environment. These are presented in the form of Role Descriptions which should be used as input to discussions to secure the final definition of the roles and responsibilities for all members of the Project Board and the Project Management Team. Tuning the role descriptions is best carried out in three passes: ♦ Step 1 - Tune the role descriptions to suit the specific project (they should already have been tuned to reflect the organisation’s culture, standards and requirements); ♦ Step 2 - Modify the resultant role descriptions to suit the individual filling the role - ask why that particular individual has been chosen for the role - what specifically does he/she bring to the project; ♦ Step 3 - Discuss each tuned role description with the individuals concerned and secure their agreement and commitment to their organisational role. Following this simple three-step process will help secure the commitment of the Project Board members and Project Management Team. Taking the role definitions directly from the PRINCE 2 manual is not recommended. The Project Board The Project Board is the overall authority for the project, having specific ownership for the process “Directing A Project” and responsibility for delivering the required outcome or End Product. It is the ultimate project authority and is responsible for the initiation, direction, review and eventual closure of the project. To meet this function, Project Board members must have the authority required to commit resources and to initiate new work. These are the prime selection criteria for Project Board members. The Project Board comprises, as a minimum, representatives from the following three functional areas: 58
Ken Bradley’s Understanding PRINCE 2 The Executive Role: Overall Responsibility: to be ultimately responsible for the project, supported by the Senior User and Senior Supplier. The Executive has to ensure that the project is delivering value for the time, effort, costs and resources being invested, confirming a cost-conscious approach to the project, balancing the demands of the Business, User and Specialist Provider Organisations. The Executive will normally chair the Project Board meetings, owns the Business Case, represents the Customer’s interests and has final responsibility for the project. The Senior User Role: Overall Responsibility: Responsible for the specification of User needs, user liaison with the project team, the integrity of the desired outcome of the project and for monitoring that the solution will meet those needs within the constraints imposed upon the project. The role represents the interests of all those affected by the outcome and the Products arising from the project. The Senior User role commits User resources and monitors Products against the stated and agreed requirement. This role will often involve more than one person to represent all the user interests. The User and Customer roles will sometimes be represented by the same individual or group of people. The Senior Supplier Role: Overall Responsibility: Representing the interests of those designing, developing, facilitating, procuring and implementing the project Products. The Senior Supplier role must have the authority to commit or acquire the (specialist) supplier resources required. In some projects, more than one person may be required to represent the interests, and commit the resources, of the supplier. Responsibilities of the Project Board Members The PRINCE 2 Manual (Appendix C) provides lists of responsibilities for each of the above roles. These are split between the Specific Responsibilities and the Assurance Responsibilities for each of the identified roles. The role definitions must be adapted to suit the organisation, project and individual tasked with the responsibility. The three functional roles comprising the Project Board should not be interpreted as a requirement for three individuals. In smaller projects, for example, two functional roles may be combined in one person (although in normal circumstances it is not advisable for the Project Board to be reduced to less than two individuals). In other circumstances several individuals may take on a single functional role (eg where a number of user areas are being served by the eventual outcome of the project). 59
Ken Bradley’s Understanding PRINCE 2 The Project Assurance Function PRINCE 2 separates the Project Assurance function from the Project Support function. Accountability for assuring the project always resides with the Project Board and cannot be delegated; the day to day tasks involving the assurance function may, however, be delegated to appropriate individuals. There are two types of Project Assurance that can be expected to be found within a project - External and Internal. External Assurance & Audit Function Standards - Quality - Financial - Technical Project Board Assurance Function Project Assurance Function - Business - User - Supplier - Business Project Management Function - User Project Manager Project Support - Supplier Team Managers Project Team Members - Product Creators Figure 23: The Levels of Assurance ♦ External Assurance concerns itself with the assurance that the project is performing in accordance with overall standards and approaches either published or recognised in some way by the organisation. Examples might be that the project is conforming to the BS/EN/ISO9001 Quality Management Standard or following Accounting Conventions laid down by a professional body or within legislation. Invariably some form of audit will already be present within the organisation to verify that these standards are being followed. ♦ Internal Assurance is ultimately the responsibility of the Project Board. Examples of Internal Assurance are verifying that the Products/Deliverables output by the project conform to their agreed Quality Criteria; that they perform in accordance with the User’s statement of requirement; that schedule and cost budgets are being met; and that the Business Case (Business Benefits) and Risks remains viable. 60
Ken Bradley’s Understanding PRINCE 2 Delegation of Day-to-Day Project Assurance Although accountability for Project Assurance rests with the Project Board it might well be impractical for the individual members to carry out the tasks involved personally (because of lack of time or lack of expertise). Each Project Board member may, therefore, enlist help from other sources to actually perform the day-to-day Project Assurance function on their behalf. It is important to note, however, that this responsibility is only delegated - the Project Board retain full accountability. Delegation of the assurance function may be to any number of individuals, although the numbers must obviously, be sensible. The selection of appropriate people for the assurance roles is also important - the assurance function must be independent of the Project Manager and it is not appropriate for any of the assurance function to be delegated to the Project Manager or Team Manager(s). In practice, an existing Quality Manager or Project Support Office might be used to carry out either or both Internal Assurance and External Assurance - responsibility for getting it right rests with the Project Board (and ultimately with the Executive Member). The Project Manager All projects need a focal point to plan, control and oversee the day to day work and to co-ordinate the total effort. The Project Manager fulfills this role. PRINCE 2 requires that all projects under the control of the Methodology have a Project Manager. The prime responsibility of the Project Manager is: ♦ to ensure that the project as a whole produces the required products, to the required standard of quality, and within the specified constraints of time and cost. The Project manager is also responsible for the project producing a result which is capable of achieving the benefits defined in the Project Initiation Document. The Project Board Senior User Senior Supplier Executive User Assurance Specialist Assurance Business Assurance Project Assurance Assurance Project Manager Figure 24: The Project Manager’s Relationship with the Project Board In any PRINCE 2 project, there might also be one or more Team Managers to assist the Project Manager to plan, manage and control a specific Technical Stage. It is the 61
Ken Bradley’s Understanding PRINCE 2 responsibility of the Project Manager to direct and co-ordinate the efforts of all Team Managers. Team Managers will usually be appointed to plan and control particular specialist areas, where the Project Manager lacks the detailed knowledge and/or experience and/or resources directly under his/her control to carry through the specific tasks required. A selection of the main tasks for the Project Manager is as follows: ♦ Overall planning for the total project; ♦ Motivation and Inspiration; ♦ Drive the project towards a successful outcome; ♦ Liaison with other related/associated projects; ♦ Liaison with Programme Management for related projects; ♦ Define responsibilities for each Specialist Team Manager; ♦ Report to and take direction from, the Project Board; ♦ Present regular Highlight Reports for the Management Stage (and the impact on the overall project) to the Project Board. The Project Manager role is essential for large, complex, high-profile, high-risk, undertakings and may be supported by one or more specialist Team Managers. Team Manager(s) The Team Manager is an optional role and may be expected to exist on large, high risk projects. Where appointed the Team Manager is responsible for the day-to-day management of the specialist work package activities and products under his/her control. Typically, but not necessarily, a Team Manager will have line responsibility for a specific specialist team appointed to be responsible for a discrete part of the project; for example the supplier of key technical equipment, or a building contractor might be appointed as a Team Manager for part of the customer’s project. In such circumstances it is quite normal that the Team Manager is also the supplier’s Project Manager. The Team Manager works to the defined and agreed plans for the stage products and activities and reports to the Project Manager. Team Managers may also be appointed where the project is large and the Project Manager requires some experienced support at the management level. Also where there are pressing geographical reasons, a Team Manager might well be nominated to implement a particular part of the solution within a geographic region. 62
Ken Bradley’s Understanding PRINCE 2 The options described above are not exhaustive and Project Managers and their respective Project Boards should use imagination and creativity to determine where and when to make the best use of this PRINCE 2 role. Project Manager Team Manager Team Manager Team Manager Project Resources & Teams Figure 25: The Team Manager’s Relationship with the Project Manager Responsibilities of the Team Manager The prime responsibility of the Team Manager is: ♦ to ensure production of those Products defined by the Project Manager to an appropriate quality (ie conforming to the Product’s Quality Criteria agreed within the Product Description), in a time-scale and at a cost acceptable to the Project Manager and the Project Board. The Team Manager reports to and takes direction from the Project Manager. The Team Manager will work with the Project Manager to define responsibilities for the team members and provide plans, guidance, motivation and inspiration. All suggested changes relating to the Products which are the responsibility of the Team Manager, raised informally or as Project Issues will be routed through the Team Manager for recommendation or decision on further action. The Team Manager will work closely with his/her teams, providing advice and guidance and taking decisions. The Team Manager will attend (and usually run) Checkpoints and raise Checkpoint Reports for the Project Manager at the frequency agreed in the Work Package, and may help the Project Manager to provide the regular Highlight Reports to the Project Board. Project Support may be used by the Team Manager where this is acceptable to the Project Manager. At the discretion of the Project Manager, Project Support will provide administrative assistance freeing the Team Manager from the day to day administration, and enabling provision appropriate support and guidance to the team members. In some cases, Project Support may act as a “Scribe” at Quality Reviews to help with the 63
Ken Bradley’s Understanding PRINCE 2 administration and recording of this important control. Team Managers and Technical Stages PRINCE 2 draws a distinction between Technical Stages and Management Stages. A Team Manager will take responsibility for one or more discrete Technical Stages of the project. Technical Stages relate to the delivery of specific portions of the final solution (or End Product) for the project and there may well be a number of Technical stages, each under the control of a different specialist Team Manager, running within one or more Management Stages. The Management Stages provide the basis for a series of major milestones during the life of the project and represent the points in time when the Project Board will, at an End- Stage Assessment (ESA) decide whether the project should go forward, be “frozen” for a period of time, existing work be “re-visited”, or the whole project aborted. Management Stages allow the Project Board to control the commitment of resources to the project and provide authority to spend; they are also described by the Method as “partitions of the project with decision points”. Project Support The Project Support function on a formal basis within a PRINCE 2 project will only exist where there is a need for it. Its existence is driven by the needs of an individual project (and Project Manager). In general, the kind of support provided will be administrative help to the Project Manager and the Team Managers where these are appointed. Where organisations already have a Project Support Office in place, there need be no change, although there will need to be a clear distinction drawn between the services provided to the Project Manager by the Project Support Office staff and any Project Assurance function they might be performing on behalf of the Project Board. The Project Support prime function is: ♦ to provide administrative support and assistance to the Project Manager and the Specialist Team Managers. Project Support may also provide support to the Team Members in terms of advice and the interpretation of the project management, quality and technical standards. Project Support responsibilities comprise (among others as specified and agreed with the Project Manager) the following: ♦ Administer Change Control; ♦ Set up and maintain the Project Files; ♦ Establish Document Control Procedures for the Management Products; 64
Ken Bradley’s Understanding PRINCE 2 ♦ Compile, copy and distribute all Management Products; ♦ Collect Actual Performance Data and Forecast Data, and update the Plans; ♦ Administer the Quality Control Processes; ♦ Administer Project Board Meetings; ♦ Assist with the compiling of reports; ♦ Configuration Management activities. ♦ Performing the “Scribe” role at Formal Quality Review Meetings. The selection of appropriate Project Support personnel (either for the direct support of the project or through the creation of a Project Support Office) is important to the overall success of the project. Typical knowledge and skills necessary for this key position might include, among other areas: ♦ A broad understanding of estimating techniques (especially those used by the Organisation); ♦ specialist knowledge and competence with the organisation’s chosen software support tool, and other project management software support tools such as those for Risk Assessment and Management; ♦ any other specialist knowledge that might be needed to support and reflect the organisation’s existing standards, approaches and professional ethics and approaches; ♦ administrative approaches relating to the organisation’s own filing and related configuration approaches; ♦ planning and scheduling principles knowledge and expertise; ♦ good communication and interpersonal skills; ♦ a pro-active approach! Customer:Supplier Environment A suitable organisation structure for Customer:Supplier projects is included in the PRINCE 2 manual and shown in figures 26 and 27. PRINCE 2 assumes that the project will be a joint venture between a Customer and a Supplier, who might be an internal or external supplier of the specialist portion of the project. 65
Ken Bradley’s Understanding PRINCE 2 Customer Project Supplier Project Board Board I Customer Account Manager I Senior User I Supplier Skill Management I Executive I Senior Supplier Project Board •Executive •Senior User •Senior Supplier Figure 26: The PRINCE 2 Customer:Supplier Organisation Structure Figure 26 is as far as the PRINCE 2 Manual takes the Customer:Supplier Environment – a full view of the typical Customer:Supplier Organisation Environment to be found in a PRINCE 2 managed project is illustrated in figure 27 below. Customer Organisation Supplier Organisation Customer Project Board Supplier Project Board The Project Board (Joint Representation from Customer & Supplier Project Boards) Customer Supplier Project Manager Project Manager Customer Supplier Team Manager Team Manager Customer Supplier Resources Resources Figure 27: Comprehensive View of the Customer:Supplier Organisation Environment Developments On The PRINCE 2 Theme A similar structure has been used successfully by customer and supplier organisations for a number of years; it is similar to that proposed by PRINCE 2 as a suitable start-point, but 66
Ken Bradley’s Understanding PRINCE 2 has a few modifications which provide an alternative but compliant option. This model (figure 28) provides a practical approach to handling the day-to-day communication linkages between the respective Project Managers and their respective teams, and the higher level exchanges between each Project Board and has been used as an organisational basis for private sector companies Local Government; Central Government and NHS Trusts. A key element is to ensure that the customer and supplier organisations have an opportunity to take the necessary commercial and business decisions within the privacy of their own management organisations, but with the facility to meet to iron out difficulties and problems on a “without prejudice” basis. The Supplier Project Board Supplier senior management will always need to represent the interests of their customers if the eventual business outcome is to be satisfactory to all parties involved. Reflecting the “partnership” approach, it is tempting to include a User/Customer representative on the Supplier Project Board. This approach is, however, flawed as the PRINCE Methodology places overall and ultimate responsibility and authority for the project in the hands of the Project Board with consensus agreement. A “real” User/Customer representative at this level within the project will always be placed in an invidious position, especially in times of trouble when hard decisions have to be made about the possibility of re-defining the project deliverables or re-negotiating the contract price or terms and conditions, where the Customer‘s only realistic stance can be “no comment” - indecisive and certainly not recommended at Project Board level! A similar situation occurs where a Supplier is asked to provide a representative for a Customer’s Project Board. Although commitment of the Supplier’s resources will be able to be achieved, in times of difficulty where a specialist solution appears not to be working in the way the Customer had expected, the supplier representative always experiences a conflict over whose interests should be protected. The solution, endorsed by practical experience, is for the Supplier to provide representation from internal resources such as a Customer Account Manager to speak for the customer and to ensure that, at the highest level within the project, due account is taken of the customer’s position. For the customer, where there is an unwillingness to have a Senior Supplier from the organisation they have contracted with on the Project Board, specialist technical expertise for the project may be bought-in from outside if there is no specialist expertise already resident or available from within. Such an appointment carries with it the disadvantage that the individual(s) concerned are unable to commit the necessary technical resources, but this is relatively easily remedied through the contract arrangements. Establishment of a Steering/Co-ordinating Group (possibly evolving into a Joint Project Board) will help smooth the path for communication between all the senior managers responsible for the project. 67
Ken Bradley’s Understanding PRINCE 2 Customer: Supplier Steering/Co-ordinating Group Each individual Project Board will be primarily responsible for the management of the project within its own organisation, but there is also the need to meet on a regular basis to discuss issues and to enable communication at a senior level. The Steering/Co-ordinating Group (or Joint Project Board) pulls together all interested parties at Project Board, Project Manager and, if appropriate, Project Assurance levels so that key decisions can be made. Customer Organisation Supplier Organisation Project Board Senior Management (Project Board Equivalent) Steering/Co-ordinating Group (Joint Representation from Customer & Supplier Project Boards) Customer Supplier Project Manager Project Manager Customer Supplier Team Manager Team Manager Customer Supplier Resources Resources Figure 28: The Customer & Supplier Management Structures It is important to focus on the purpose of each meeting of the Steering/Co-ordinating Group The objective is to provide a joint forum for decision making, the exchange of “positive” views and the clarification of any issues. Progress and project status will be the subject of separate arrangements (typically monthly Highlight Reports). Within a contractual environment, it will always be advisable to set up each meeting with the proviso that any discussions, views and agreements reached within the Liaison/Steering Group forum will always be “without prejudice to the agreed terms and conditions of the contract”. Failure to do this might well result in an unwillingness to enter into constructive debate and to provide mutually constructive suggestions to avoid or repair problems. 68
Ken Bradley’s Understanding PRINCE 2 Customer: Supplier Project Manager The supplier will always appoint someone to take responsibility for day-to-day management of the project - the Supplier Project Manager. The communication lines between the Customer Project Manager and the Supplier Project Manager are the strongest ties between the two parties. This is reinforced where the Customer Project Manager regards the Supplier Project Manager as a (specialist) Team Manager within the customer project. The Project Manager will normally come from the Customer organisation and will take on responsibility for managing the total project. This is because the Supplier’s role in the overall scheme of things is usually restricted to supply and installation of equipment. There are many other vital component parts which must derive from the Customer project - examples are the Specification, Business Design, Testing, Training etc. Customer:Supplier - Project Support Project Support may or may not exist on either side, but for major projects some form of support will be established for the Project Manager. The communication links between the support functions will be the regular reports (typically Highlight Reports) and resolution of day-to-day queries between the customer and supplier project teams. It is not envisaged that there will be any formal communication between customer and supplier team members as this will always be routed through the Project Managers or Project Support. Organising The Managing Of Programmes Most projects will have inter-relationships with other undertakings within and outside the host organisation. In larger, longer term and high risk projects, there will be a conscious effort to break the overall initiative into a series of smaller, more manageable projects, each under the overall direction of a Programme Board. The organisational aspects of programmes of work are straightforward and reflect the basic principles of the PRINCE Methodology. The actual arrangements and structure will vary with each programme and will need to reflect the local approaches, culture and, if appropriate, contracts. The PRINCE 2 manual provides a suggested structure which should always be considered as a suitable start point. The following model (Figure 29) has formed the basis for a number of successful programmes and provides a near alternative for consideration: 69
Ken Bradley’s Understanding PRINCE 2 Steering Corporate Management Group Programme Board Representation from User/Customer, Supplier Function & Business Function Customer Programme Support Group Programme Manager + Project Support Project Board - 1 Project Board - 2 Project Board - 3 Project Manager Project Manager Project Manager Programme/Project Resources (some common; someowned by one project) Figure 29: Alternative Programme Management Organisation Model Programme Board, Programme Manager & Programme Support The Programme Board will appoint a Programme Manager to oversee the delivery of the overall initiative. The Programme Manager may be a member of the Programme Board, although this is not necessary or recommended. Support to the Programme Manager is provided by Programme Support who are also responsible for the overall programme integrity and the correct use of the organisation’s project management and quality management standards. They will also, therefore, take on the day to day role of Programme and individual Project Assurance on behalf of the Programme Board members and individual Project Board members. Accountability for Programme and Project Assurance remains, of course, with the individual roles on the respective bodies. Quality Assurance is normally a separate function and vested in the Quality Manager; the appointment of a joint Programme/Quality Assurance function role is the responsibility of the Programme Board. To avoid large numbers of individuals on Programme Boards, it is often convenient to establish a Steering Group which is strictly speaking outside the project boundary. Such a group may meet as frequently or infrequently as deemed to be appropriate and the membership need not be limited. 70
Ken Bradley’s Understanding PRINCE 2 The Steering Group will be kept fully informed of the progress of the programme and will be invited to contribute to the overall direction of the initiative. The group will not, however, be responsible for decision making within the programme - this vests absolutely in the Programme Board, devolved as appropriate to the Programme Manager, Individual Project Boards and Individual Project Managers. User/Customer Group In A Programme Context Programmes of work often imply the need to address a large customer base and this is catered for by having a separate Customer Group. This group will provide the Senior User/Customer on the Programme Board and the Senior User for each of the individual Project Boards. Each individual Project Board Senior User is responsible for appointing any necessary user/customer liaison resource, possibly coupled with assurance responsibilities, within the project management team. Individual Project Boards In A Programme Context The individual Project Boards operate exactly as they would within a standard PRINCE 2 project. The members are overall responsible for delivery of the project(s) they own. They will meet at appropriate event-related times to review the project and to approve its continuation and commit the resources. Each individual Project Board will comprise a Senior User/Customer representative, a Supplier representative, and an Executive/Business representative. As mentioned above, the User/Customer Group will provide the Senior User. The Programme Manager is best positioned to chair each Project Board and represent the business interests of the overall programme and the host organisation. The individual Project Board Supplier representative will be assigned/appointed by the Senior Supplier on the Programme Board. Project Support & Programme Assurance Each individual Project Manager may be assisted by a Project Support function if this is deemed to be necessary given the size, scope and complexity of the project and the experience of the Project Manager. Project Support will keep the project plans up to date and on a regular basis, usually monthly, will provide a summary of status and progress to Programme Support who will use this information to up-date the overall programme plan for the Programme Manager. A Programme Highlight Report will be prepared and sent from the Programme Manager to each member of the Programme Board. Assurance for the whole programme of work and for individual projects will primarily be the responsibility of Programme Support whose 71
Ken Bradley’s Understanding PRINCE 2 authority devolves from the Programme Manager. Typically (but not necessarily) the Programme Board will meet on a time related basis, possibly every 6-8 weeks, depending entirely on the sensitivity, risk or profile the programme has within the organisation. Programme And Project Resources These are often shared over all projects and identification, use and monitoring of the resource pool is an important aspect of managing a programme of work. It is all too easy for each individual project to plan to use the same resources to the full extent of their availability, thus ensuring over-utilisation and consequent slippage of the whole programme. This can be avoided by the use of a suitable software planning tool which allows sub-project or roll-up planning. Other Structures Based On PRINCE 2 The PRINCE 2 organisation structure principles may be used to form the basis of a variety of different projects. For example, many organisations are involved in Concurrent Engineering or Rapid Application Development projects; a suitable PRINCE 2 compliant structure has been produced and is included on the next page (Figure 30). The model as presented is straightforward and conforms, generally, to the requirements of PRINCE 2, with an owner with ultimate authority (The Project Board) reporting to Corporate Management to ensure that the development project resides within the overall strategy for the organisation, reflecting corporate objectives. The Project Team is totally enclosed within the project structure, with separate Team Managers responsible for the discrete stages of the work. The project is under the direction of a Project Manager, exercising management control on a day to day basis through the Team Managers and through Project Support, as the Project Manager may be expected to be fully involved with the development, testing and installation of the emerging end-product. Products will be passed forward within the organisation to the succeeding Team Manager, and in some circumstances passed back for re-work. 72
Ken Bradley’s Understanding PRINCE 2 Corporate Management Project Board & Project Assurance Project Manager Specification, Analysis Project Support & Design Team & Administration Team Manager Development Team - User/Customer - Analyst Team Manager - Design Implementation & User Resources - Programmer Testing Team - Analyst - Design Team Manager Resources - User/Customer - Analyst Resources Project Resources Figure 30: Rapid Application/Concurrent Engineering Organisation Model Project Support will provide an important co-ordination function within this type of project. Typical tasks will include: ♦ setting up regular (possibly 4-6 meetings between Team Managers and the Project Manager every day); ♦ up-dating the Project Plan to show actual progress and expenditure profiles; ♦ initial preparation of Highlight Reports for the Project Board; ♦ liaison with any Project Assurance appointees to ensure that organisational standards are being observed; ♦ incidental support to the Team Managers; ♦ provision of a communications centre for the whole project. Quality Assurance imposes a discipline from the Corporate level through a published Quality Management System and Project Assurance remains the responsibility of the Project Board, although this may be delegated (but not to anyone within the Concurrent Engineering/Rapid Application Development team). 73
Ken Bradley’s Understanding PRINCE 2 It should be stressed that the organisation structure shown does not form part of the PRINCE 2 Method but is included to illustrate how the principles within the method may be easily adapted to reflect organisational needs. PRINCE 2 Organisation - Summary The key points within the PRINCE 2 Organisation Component are: ♦ Corporate or Programme Management appoints the Project Board, who have overall and ultimate responsibility for the successful delivery of the project. Initially the Executive member is appointed (Process SU1) along with the Project Manager. ♦ The Project Board endorse the Project Management Team designed and initially appointed by the Project Manager and Executive within the SU Process. ♦ The Project Manager is responsible for day to day planning and control, helped where appropriate by one or more of Team Managers. Project Support might be provided where the Project Board believe this would help. ♦ The Project Board members may choose to delegate some or all of their Project Assurance responsibilities, but accountability will always reside within the Project Board, and ultimately with the Executive. ♦ Project Support provide administrative support (and sometimes technical help) to the Project Manager and, where appropriate, to the Team Manager(s). ♦ Project Assurance will always be a separate entity to Project Support. ♦ A Project Support Office might well address both support and assurance functions, but these would need to be assigned to separate individuals within the Project Support Office. ♦ Products and documents must be properly stored and safeguarded, and a suitable Configuration Management System must be in force to make these arrangements; Project Support will usually be responsible for the operation of the Configuration Management System - the Project Manager is responsible for its integrity, which will be audited by Project Assurance on behalf of the Project Board. 74
Ken Bradley’s Understanding PRINCE 2 Chapter 4 UNDERSTANDING THE PLANNING COMPONENT AND PRODUCT-BASED PLANNING TECHNIQUE 75
Ken Bradley’s Understanding PRINCE 2 Planning - Introduction & Overview The PRINCE 2 Method does not prescribe any particular type of plans which must be used on a project. The principles of “Product Based Planning” are incorporated in the method within the “Techniques” section and the overall assumption is that some form of software support planning tool will be used. The exact form and layout of the plans is left for the implementing organisation to decide, probably influenced strongly by whatever software planning tool is currently in use. There will typically be up to 3 planning levels within a PRINCE 2 project, although there is no limitation on the number of levels which might be utilised. Typical levels of plan are: ♦ Level 1: Project Plans ♦ Level 2: Stage Plans ♦ Level 3: Team Plans ♦ plus Exception Plans where there has been a significant departure from the approved plans and some re-planning must be done to recover the situation. Individual Plans assigning particular Products and their associated work packages to members of the project team might also be utilised if this is appropriate. Project Plan (Mandatory Plan) Stage Plan Stage Plan Stage Plan Team Team Team Team Team Team Plan Plan Plan Plan Plan Plan Project Resources Report (Effort, Costs, Equipment, Direct Costs) Figure 31: Levels of Plan In PRINCE 2 Plans at Levels 1 and 2 are necessary for effective planning of a major project – both the Project Plan and the Stage Plan are mandated in the Method. 76
Ken Bradley’s Understanding PRINCE 2 Project Plans may provide sufficient detail for the early stage plans to be incorporated within them. Plans at the lower Levels are optional but will usually be necessary to produce in order to gain full understanding of the undertaking and to exercise effective control at team level. The plan structures at all levels (including the Exception Plans, which are intended to replace the plan which it has been necessary to up-date) are similar in content and structure; at team level for the individual, if these are used, the only plan needed will be a simple Gantt Chart or Activity List covering either one or two elapsed weeks. This type of plan is often available as a standard output from the planning support software. The Plan Text provides a high-level, overall view of Plan the plan, summarising its key features Text Product Identifying the Products/Deliverables that will be Breakdown produced by the Project. The Products will be categorised Structure under the headings of “Specialist”, “Management”, and “Quality” Products. Describing the Products/Deliverables that will be Product produced by the Project. There is a prescribed format Descriptions for Product Descriptions Describing the relationships that exist between Product each Product/Deliverable, and external entities. Flow Diagram PERT or Showing the relationships that extist between the Activities that will be undertaken Activity to create the Products identified in the Product Breakdown Structure. Network Gantt Derived from the PERT Network, this shows when Activities are or planned to start and end. Major Review points (End Stage Timescale Assessments) are also shown on this plan. Plan Figure 32: The PRINCE 2 Plan Package Project Level Plans Construction of PRINCE plans should normally be on a top-down basis; this will provide a logical and controlled descent into detail and will help to identify any grouping of Products and associated activities that might usefully be treated as a separate sub-project. In some cases, however, it will be appropriate to work at the stage level in order to provide a realistic picture of the total development. The more detailed activities will then need to be grouped to provide an overall view at the project level. 77
Ken Bradley’s Understanding PRINCE 2 Product Breakdown Structure The start-point will be to give consideration to the design of the plan (how many levels, the general approach to planning, the most suitable software support tool to use, involvement of external support services etc). As the initial step, a list of Products to be produced during the project must be created. These Products will be at the Project level and must be identified by the Project Manager and the appropriate Team Manager where appointed. The resultant list should then be critically reviewed with the Project Management Team in the light of what is known about the proposed project, to produce an agreed list of high-level Products to be produced. This is known as a Product Breakdown Structure and contains a list of the Specialist Products, Management Products, and Quality Products associated with the project. Management Information System Management Products Specialist Products Quality Products MP01 - Project Initiation Document SP01 - User Specification QP01 - Product Descriptions MP02 - Stage Plans SP02 - Logical Design QP02 - Quality Review Documentation MP03 - Lessons Learned Log SP03 - Physical Design QP03 - Project Issues Log MP04 - Risk Log SP04 - Contract QP04 - Quality Log MP05 - Business Case SP05 - Hardware QP05 - Configuration Management MP06 - Product Checklist SP06 - Software MP07 - Highlight Reports SP07 - Communications MP08 - Project Start Notification SP08 - Integrated System MP09 - Project End Notification SP09 - Technically Tested System MP10 - Project Filing Structure SP10 - User Accepted System SP11 - Trained Staff SP12 - Test Products The Project Management The Quality Management Standard for the The Technical Management Standard for the Project Standard for the Project Project Figure 33: Specialist, Management & Quality Products Each Product must be supported by a Product Description which addresses the following: ♦ Product Title & Identification; ♦ Purpose; ♦ Composition; ♦ Derivation; 78
Ken Bradley’s Understanding PRINCE 2 ♦ Format & Presentation; ♦ Allocated To; ♦ Quality Criteria; ♦ Type of Quality Check Required; ♦ People or Skills Required for Reviewing/Testing the Product. The above headings may be added to but must not be omitted in order to secure PRINCE 2 compliance. Product Descriptions form a significant part of the Quality Plan for the project and are fundamental to its successful outcome. For these reasons Product Descriptions must not, in any circumstances be omitted from any PRINCE controlled project. SP01 - User Specification User Requirements Enhancements Functional Data Short/Medium Long Requirements Requirements Term Term Strategies Education Testing Cut-Over Fall-Back Strategy Strategy Strategy Strategy Technical User Testing Testing Module System Testing Testing Figure 34: Example Product Breakdown Structure For The “User Specification” Product Every PRINCE 2 project will have at least one Product identified (the End Product) and defined in terms of a published and baselined Product Description. Baselining of a Product Description will take place when the plan it relates to is baselined (agreement by the Programme Director/Executive (for Programme Plans), the Project Board (for Project Plans) and the Project Manager (for Team Plans)). A Product Description, once approved and base-lined, may only be changed via the Change Control procedure. 79
Ken Bradley’s Understanding PRINCE 2 Product Flow Diagram A Product Flow Diagram may then be drawn showing how the various products identified are derived, one from another and from external Products and Entities. This helps to confirm that all the Products that need to be produced have, in fact, been identified; all Products in the Product Flow Diagram must balance with those in the Product Breakdown Structure, and each must be supported by a Product Description. Feasibility Study SP01 - User Specification Users/Existing System Potential Suppliers SP02 - Logical Design SP03 - Physical Design SP04 - Contract SP12 - Test Products SP05 - Hardware SP07 Communications SP06 - Software SP08 - Integrated System SP09 - Technically Tested SP11 - Trained Staff System SP10 - User Accepted System Figure 35: Product Flow Diagram The Product Flow Diagram helps set a basic approach and chronology for the completion of the Products. Stage beginnings and endings, and candidates for sub-project groupings can also be determined from this diagram, although the final timings of Management Stage endings will not be able to be made until later when the Gantt Plan (or Timescale Plan) has been produced. Construction of the Product Flow Diagram helps the project planners to appreciate the overall approach and strategy that underpin the project. Any "missing" Products will be more easily identified (these must of course be incorporated into the Product Breakdown Structure and defined within Product Descriptions). Less than obvious linkages between Products will be more clearly apparent at the time the Product Flow Diagram is drawn, and the successive iterations will help to hone the overall approach to a more realistic shape. Another useful function of the Product Flow Diagram is the help it gives in identifying Activities for inclusion in the activity plans. 80
Ken Bradley’s Understanding PRINCE 2 * Interview Users * Produce Specification Users/Existing System SP01 - User Specification Review FS Produce Business (Logical) Design Feasibility Study SP02 - Logical Design * Extract Test Data * Clean Data Produce Business (Logical) Design * Produce Test Schedule SP03 - Physical Design SP12 - Test Products * Prepare & Issue Tenders * Produce Tender Evaluation Criteria * Unit Testing * Assess Offers & Select Supplier * Suite Testing * Issue Contract * Produce & Agree Program Designs * Write Programs (& Fixes) SP04 - Contract SP06 - Software Figure 36: Product Flow Diagram With Activities Identified The Activities identified on the Product Flow Diagram are sometimes referred to as “Transformations” reflecting that they provide the means of transforming one or more Products into another. PERT Network The PERT Network is a basic tool in project management; its full designation is “Programme Evaluation & Review Technique” and the information to produce it may be derived from the Product Flow Diagram. Alternative names for the PERT Network are “Critical Path Network”, “Critical Path Method”, and “MIST - Minimum Irreducible Sequencing Technique”. The Product Flow Diagram defines the data flow and relationships between Products to be produced, and the PERT Network defines the activities needed to create each Product. The PERT Logic Network & The Timed Network The Logic Network shows the activities needed to produce each Product and establishes the dependency relationship between activities. The Timed Network provides additional information on the elapsed time to be taken for each activity and allows the total project cycle time to be predicted. The Timed Network will also provide information on start and finish times, critical paths, sub-critical paths and float. 81
Ken Bradley’s Understanding PRINCE 2 3 7 10 10 4 14 50 Review The 60 Prepare Board Strategy Plan Position Paper 5 2 12 12 2 16 0 3 3 3 2 5 11 5 16 16 2 18 10 Appoint The 20 Appoint The 30 Design & Appoint 40 Produce The PB Executive Project Manager The Project Team Project Brief 0 0 3 9 6 11 11 0 16 16 0 18 Earliest Start Time (EST) Duration Earliest FinishTime 3 8 11 (EFT) 70 Plan The 0 3 3 Project Approach 10 Appoint The 3 0 11 PB Executive 0 0 3 Latest Start Time Total Float Latest Finish Time (LST) (LFT) Figure 37: PERT Network - Timed And Logic Diagram Earliest Start Gantt Plan Using the information on earliest start and finish times from the Timed Network, an Earliest Start Gantt Plan can be produced. This chart will provide the basis for Project Board approval. But first some tuning/resource smoothing has to be carried out. Earliest Start Time Earliest Finish Time Latest Finish Time Activity Total Float Figure 38: Creating The Earliest Start Gantt Plan Resource Smoothing The Timed Network will have assumed unlimited resources were available and concentrated solely on the underlying logic of the relationship between activities. This 82
Ken Bradley’s Understanding PRINCE 2 does not, of course mean that any number of people are available to the project, but that those that are assigned to the project are assumed to be able to work at any time (even to the extent of carrying out simultaneous multiple activities. Un-smoothed Gantt Plan (Earliest Start) Produce Plan Id Sources Prepare Docs Prepare I/Vs Appointments Interviews Resource Smoothed Gantt Plan (With Stage Reviews) Produce Plan Id Sources Prepare Docs Prepare I/Vs Appointments Interviews Management Management Management Stage 1 Stage 2 Stage 3 Figure 39: Creating The Resource Smoothed Gantt Plan The Earliest Start Gantt Plan will clearly show overlapping activities where resource usage will be over-stretched. To inject reality into the plan it will be necessary to smooth the resources. Although not dealt with in the methodology, resource smoothing is an essential feature of project planning. Resource smoothing is best carried out using a software support package (such as Microsoft Project (MS Project), Project Manager’s Workbench (PMW), or Primavera), initially, and then tuning "by hand". Full manual resource smoothing is a time consuming and tedious task involving many iterations and modification of both the Time- scale/Bar Chart and the underlying Timed Network. After smoothing, the resource usage may still be excessive, or the end date for the project may have slipped back too far to be acceptable to the sponsor. In these cases it will be necessary to reconsider the logic of the Timed Network and to plan for overlaps of activity that would enable more effective use of resources and bring forward the delivery forecast. Such action will invariably increase the risks to the project and will need to be properly assessed and documented for a decision by the Project Manager or Team Manager and subsequent endorsement by the Project Board. 83
Ken Bradley’s Understanding PRINCE 2 Project Gantt Plan The Gantt Plan is the result of the resource-smoothed earliest-start bar chart. and provides a view of the Products related to the envisaged time-scales for the total project, readily showing where "clusters" of Products will be ready and thus point to natural Stage beginnings and endings. The Project level Gantt Plan has the End Stage Assessment control symbols added in, at appropriate key decision and resource commitment points and is then ready for approval by the Project Board. Initiate Specify Design Build Test Train Hand-over Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Closure End Stage Assessment (ESA) Figure 40: Gantt Plan With End Stage Assessments Added Project Resource Reporting A Project Resource Report provides a summary of the Effort and Cost of that effort on a Stage-by-Stage basis. A separate Resource Plan is not specifically required by PRINCE 2, as the Method presumes that a software planning tool will be in use and any resource information required will be able to be drawn from the Project Plan and presented in whatever format is required. Information on the planned use of resources (and the subsequent record of actual usage) is an essential element of decision support for management and should not be omitted without good reason. In projects where a software support tool is not being utilised, it may be produced by taking a copy of the Project Gantt Plan and creating a "Transfer Sheet" for each resource type. The transfer sheet provides a statement of the resource usage against each activity for the whole project; the planned effort usage for each stage is totalled and transferred to the Project Resource Plan. 84
Ken Bradley’s Understanding PRINCE 2 Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual EFFORT (Staff Weeks) Skill Types Customers Engineers IT Analysts Others COSTS (£K) Skill Types Customers Engineers IT Analysts Others Equipment Fixed Price Elements Total Stage Costs Total Project Costs Figure 41: Resources Report (or Plan) The resource effort on the Project Resource Plan is then converted to resource cost by reference to capitation or charge-out rates. Direct costs (for purchase of equipment etc) is also added, as is the cost of any purchases for the development. The aim is to capture the total, true costs of the project. When all the costs have been identified on the Project Resource Plan, they are cumulated in order to provide input to a Graphical Summary of the overall project. Graphical Summary This plan is not a stated or required part of the PRINCE 2 Method, but is useful to know about as it enables the project plans to be summarised on a single sheet in a graphical format. It summarises the planned expenditure using the vertical axis to illustrate costs and the horizontal axis for time. At the project level it is acceptable to show a cumulative summary of each stage's planned costs , although the Project Board may require a more detailed analysis. If this is required, the Project Resource Plan should be re-drawn to show information at a similar level as it is important that all plans should be consistent with each other. 85
Ken Bradley’s Understanding PRINCE 2 Cost Stage £110K £18K .... Stage £92K £58K .... Stage £34K Stage £14K .... £20K £20K .... Management Management Management Management Stage 1 Stage 2 Stage 3 Stage 4 Time Product Ready Specification Business Design Agreed Design Contract Completed System Tested System Trained Staff Pilot Handover Initial Support Complete Customer Acceptance Project Close-Out Quality Reviewed Work Finished Work Started Work Package Agreed Figure 42: Graphical Summary Of The Plans A useful feature on the Graphical Summary is the inclusion of delivery slots for major Products. This information provides essential technical progress data and enables the Project Board to assess the actual achievement against actual spend when reviewing the plans at the end of each stage. The headings used in the Graphical Summary to show the status of each Product may be used in conjunction with the Product Checklist. This document has planned and actual dates inserted to show progress of Products. It is most useful at Management Stage level but is also produced at Project level. Earned Value Analysis An extension to the Graphical Summary is the Earned Value Analysis chart. This technique takes performance measurement a step further, enabling a clear measurement of the project work accomplished and more disciplined forecasts of the likely task and Product completion dates and associated costs. The concept of Earned-Value Analysis is not incorporated into the PRINCE 2 Method, but is being used increasingly and may be expected to be included in a subsequent revision. Earned Value replaces the traditional practice which only compares Actual Cost with Actual Progress and is based on assigning a value to the achievement of project work. Ideally achievement is measured in terms of Milestones and Major (ie Product-level) Products delivered. 86
Ken Bradley’s Understanding PRINCE 2 Cost £200K Time Now Predicted Revised Cost Projection of Planned Predicted Cost Actual Costs Cost Over-Run £110K Actual Cost Original Planned Cost Predicted Schedule Value Earned Over-Run Time Initial Support Complete Product Ready Specification Business Design Agreed Design Contract Completed System Tested System Trained Staff Pilot Handover Customer Acceptance Project Close-Out Quality Reviewed Work Finished Work Started Work Package Agreed Figure 43: Earned Value Analysis The value is usually monetary but can be expressed in any appropriate unit such as staff hours or days. The value to be earned when a specific Milestone or Major Product is achieved is based on the planned cost of achieving the Milestone. For example, if the plan showed that £100,000 was required to achieve a specified Milestone/Project Product, £100,000 worth of Earned Value would be credited to the Project Manager (as “owner” of the Product”) when achievement of the Product was demonstrated (ie that the Product had successfully met all its Quality Criteria). Again, it is worth emphasising that the plans described above, the Graphical Summary and the Earned Value Analysis plan are not requirements of PRINCE 2, but are useful vehicles for illustrating project situations to the Project Board and other senior managers. Risk Analysis Risk analysis must be carried out in a structured manner. A Risk Analysis should always be completed at Project Initiation and up-dated, minimally, when preparing for each End Stage Assessment/Project Board meeting. PRINCE 2 requires that a Risk Log be kept to record the (hopefully reducing) risks faced as the project progresses. The risk analysis provides a complementary part of the Business Case for the Project and will be summarised in the Project Plan Description. 87
Ken Bradley’s Understanding PRINCE 2 The risk analysis will address other issues, of course, (eg staff turnover; project management expertise, third party suppliers etc) but if time is to be saved by the compression of time-scales by overlapping naturally dependent activities, this presents a very real risk to the success of the undertaking and may well involve some nugatory expenditure. For these reasons the implications of resource smoothing at this point in planning must be seriously considered. Measuring The Business Benefits When all the resource usage and cost information has been assembled, the Project Business Case can be created (“Initiating A Project”) or reviewed (“Managing Stage Boundaries”). Year 0 1 2 3 4 5 Costs: (10 0 ) (20) (20) (20) (40) (30) Benefits: 0 40 80 10 0 10 0 10 0 CashFlow: (10 0 ) 20 60 80 60 70 Cumulat ed: (10 0 ) (80) (20) 60 120 190 Discount Factor (@6 %) 1.00 .94 .8 8 .83 .78 .74 Discount ed Cash Flow (10 0 ) 19 53 66 47 52 Cumulat ed DCF (10 0 ) (81) (28) 38 85 137 Figure 44: Simplified Business Benefits - Costs:Benefits Analysis & Investment Appraisal A high-level Business Case would normally have been produced during the Feasibility or Preliminary Study, based upon information contained in the organisation's Strategic Plan. This initial business case would have been subsequently refined and, following approval by Corporate or Programme Management, passed with the Project Mandate to the Project Manager for formal Start-up and, following approval at the Project Initiation Meeting, the Initiation of the project. The main elements of the Business Case are the reasons for the project, and a Benefits and Costs Statement. An optional Costs:Benefits Analysis and Investment Appraisal may also be created to measure the Business Benefits of the project’s outcome. If thought to be necessary a Sensitivity Analysis may also be produced. A Risk Analysis and proposals arising from it, recorded in the Risk Log, is also closely linked to the PRINCE Business Case. Essentially all costs are fed into the model and all tangible benefits added in. The result will be a Cash-flow for the project. This is then discounted by the appropriate rate (currently 6% in Government, but often higher within the private sector) and the Dis- counted Cash Flow identified. The areas of main interest are: 88
Ken Bradley’s Understanding PRINCE 2 ♦ the point at which the project starts showing a positive return ♦ the overall return on the investment in the project (the Net Present Value). Where a full Cost:Benefits Analysis and Investment Appraisal is not required by the Project Board, a narrative statement of the Benefits should be produced. This lists all the anticipated benefits but does not attach any specific financial value to them. Project Plan Text The plans described are used for the overall control of the project and provide a summary of the planned work and expenditure. To initiate the project (and to approve each successive Management Stage) the Project Board will require a document which ties the complete plan package together and describes the approach and general philosophy. This document is the Plan Text (also known as the Plan Description, Plan Narrative or Executive Summary) and will be mainly a narrative summary with the plans described above attached as appendices. The Plan Text typically contains the following information: ♦ the plan pre-requisites (what must be in place in order for the plan to work - eg staff recruited, users assigned, equipment installed and building work completed); ♦ the plan assumptions (the bases upon which the plans has been constructed - eg staff rates, discount factors used etc); ♦ the plan risks (the specific areas of risk that have been identified and must be closely monitored - eg overlapping activities, staffing concerns etc); ♦ the overall time-scale for the project and how it has been achieved; ♦ the impact of resource usage on this project on other projects, undertakings etc. ♦ the return on the investment and the overall business case related to project viability. Management Stage Plans The Management Stage Plan package has a similar structure and its production follows a similar path to the Project Plan package. The Stage Plans are produced in the “Managing Stage Boundaries (SB)” Process. Short horizon, limited commitment, planning is a fundamental feature of PRINCE. The aim is to provide an overall view of the likely project profile (via the Project Plan package) with a succession of short term limited commitments for the sponsor (via the Management 89
Ken Bradley’s Understanding PRINCE 2 Stage Plan documentation). The structure of the PRINCE 2 Stage Plan package is as follows: ♦ Stage Product Breakdown Structure - listing all the Stage Products to be produced. Product Descriptions must also be available (or produced) for all Stage Products. ♦ Stage Product Flow Diagram - listing the Products to be produced during the stage and the derivation paths. ♦ Stage Timed PERT Network - showing the Earliest Start/Finish Times, Float and overall project timings. ♦ Stage Gantt Plan - This plan relates specialist activities against time-scales (typically on a week-by-week basis) and summarises the level of control (frequency of Checkpoints, Quality Reviews and another meetings required by the Project Board). ♦ Stage Resources Report- summarises the resource effort and costs for the stage. Where there is no software support package in use, a Stage Resource Plan should be provided to identify the effort and costs to be approved by the Project Board. It is produced by taking the Stage Gantt Plan and creating a Transfer Sheet for each resource. The Stage Resource Plan is usually constructed on a week-by-week timescale and, in any case, must match the Stage Gantt Plan. ♦ Optional Stage Graphical Summary - provides a graphical view of the time:cost: achievement for the stage. This might be supplemented or replaced by and Earned Value Analysis Plan. ♦ Stage Plan Text - ties together and summarises the above plans and will essentially cover the stage plan pre-requisites, assumptions and risks. This narrative might be incorporated into the Project Plan Description. Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Start-Up Project Brief Project Approach PID Interview Users Produce Spec Outline Design Final Design Agree Design Figure 45: Stage Plan Derived From The Project Plan 90
Ken Bradley’s Understanding PRINCE 2 Team Plans Team Plans will usually (but not necessarily) be required for all but the smallest of projects. They drop the Stage Plans down to an increased level of detail in much the same way that the Stage Plans reflect an increased level of detail of the Project Plans. Team plans are optional within the PRINCE 2 Method and where they are produced they will normally be prepared by the Team Manager within the “Managing Product Delivery (MP)” Process, based on the authorised Work Package in consultation with the Team Members and agreed with the Project Manager. The Team Plan Package, where produced, will be related to a specialist team working on a specific Product or set of Products or they might be aimed at an individual working within the project. Team Plans will often reflect the work to be carried out in a Technical Stage within a Management Stage of the project. Individual Plans Individual Plans (sometimes referred to as Work-to Lists) are not required within PRINCE 2 but may, at the Project Manager/Team Manager’s discretion, be drawn up for individuals working on specified Products. The Individual Plans, where used, will be derived directly from the Detailed Gantt Plan and will form the basis for discussion of progress at the regular (usually weekly, but at the regularity agreed within the authorised Work Package) Checkpoints. The Individual Plan may comprise a detailed Bar Chart/Gantt Chart, Activity List, or might only identify start and finish dates and Activity Status for specific Products. PRINCE 2 Planning - Summary There is a need within any project to produce plans in sufficient detail to derive understanding of the way that objectives are to be achieved. In the final analysis, control can only be exercised at the level that is enabled by the plans. If a project is planned only at a high level then detailed control cannot be effected. The recommended approach is to plan in detail to get a full understanding of what is involved and then to select an appropriate level of control based on what is known about the project. 91
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 5 UNDERSTANDING THE CONTROLS COMPONENT 93
Ken Bradley’s Understanding PRINCE 2 Introduction To Controls The main mission of any project management method is to enable management at all levels to exercise control over what has been planned and approved. The approved plans reflect what is required to be achieved and the structure of controls enables managers to reach informed decisions about committing resources and giving approval to proceed. Regular and formal monitoring of actual progress against the approved plan is essential to ensure the timeliness, cost control and quality of the system or undertaking being developed. PRINCE 2 provides the essential support structure of Management and Product-oriented controls to monitor progress, supported by a reporting procedure which enables re-planning or other appropriate corrective action to be taken. PRINCE 2 controls fall into three main categories – Management Controls, Quality Controls and Configuration Controls; the latter two are covered in separate Chapters in this book. Management Controls Most PRINCE 2 management controls are “event-based”; this facilitates management- by-exception and helps reduce the overall cost of project control by limiting managers’ effort to occasions when decisions are really needed. PRINCE 2 provides a structure of management controls to be applied throughout the project. These controls cover all aspects of project activity and, at the highest level, allow the Project Board to assess project achievement and status prior to committing further expenditure. Controls are applied through measuring the progress towards production of a set of pre-defined outputs (Products or Deliverables). The overall structure of Management Controls is defined at Project Initiation (IP4) to ensure that the project is set up with clear Terms of Reference, incorporating agreed and measurable Objectives and an adequate management structure. Controls are applied at Project Board, Project Manager and Team Manager levels. Configuration control and Quality control is exercised by the Project Manager and Team Managers. The main Project Board controls are: ♦ The Project Initiation Meeting (establishing whether there is a worthwhile and viable project); ♦ Project Initiation & the Project Initiation Document (PID) (fixing a baseline for the project); ♦ End Stage Assessment (ensuring the project is still viable and authorising progress to the next Management Stage through the approval of the next Management Stage Plan); 94
Ken Bradley’s Understanding PRINCE 2 ♦ Tolerance (providing time and cost margins within which the Project Manager has discretion to deviate from the approved plan without seeking authority from the Project Board); ♦ Mid-Stage Assessment (where significant deviations from the approved plans are considered and an Exception Plan approved); ♦ Project Closure (authorising close-down of the project after ensuring that all the project’s Products have been delivered to the required quality standards and that customer acceptance has been obtained); ♦ Highlight Reports (regular, normally time-based, reports from the Project Manager to Project Board members to keep them informed of the progress and status of the current Management Stage); The Project initiation Meeting The pre-project Process “Starting Up A Project (SU)” seeks to answer the question “Do we have a worthwhile and viable project?”. Creation of the Project Brief, Risk Log, Project Approach, Initiation Stage Plans, Organisation Structure and Role definitions contribute to answering this question and formal acceptance that there is a worthwhile project on offer is confirmed by the Project Board at the Project Initiation Meeting (PIM). There is no real need to hold a formal meeting for all projects but the formality that a meeting provides will be appropriate for major investments. The PIM is a control function of “Authorising Initiation (DP1)” which sits in the “Directing A Project (DP)” Process. The “official start” of the project occurs following this approval which enables the Project manager and team to begin to create the elements of the Project Initiation Document (PID) during the required Initiation Stage of the project. • Project Brief • Risk Log Initiation Stage 2 • Project Approach • Organisation Stage • Initiation Stage Plan Project Initiation End Stage End Stage Assessment Meeting Assessment Do we Have A Worthwhile& The Project Initiation viable Project? Document Provides The End Stage Report the Project Baseline confirms the result of the last Stage and reports on the overall project viability. It also contains the plans for the next Stage. Pre-Project ........ The Project Lifecycle ......................... Figure 46: Pre-Project and the Project Initiation Meeting 95
Ken Bradley’s Understanding PRINCE 2 Project Initiation & the Project initiation Document (PID) Project Initiation ensures a firm foundation and provides a positive start to the project, ensuring that the terms of reference, objectives, plans and controls, business risks, benefits and financial return, quality plans, organisation structure and job definitions are clearly defined, published, understood and agreed. Every organisation using PRINCE 2 as the basis for its project management standards should create, agree and publish a suitable specification for its content and quality criteria – this will normally take the form of a Product Description and a suitable start-point is the outline contained in Appendix A17 of the PRINCE 2 Method manual. This Management Product is very important to the project and is the result of two Processes - “Starting Up A Project (SU)” and “Initiating A Project (IP)”. The key output is the Project Initiation Document (PID) which, when approved, is a reference document used to Baseline the project. The PID is used throughout the project as a reference back to the original intentions and management objectives. During the “Closing A Project” Processes, the PID is used to reference the original Acceptance Criteria and secure Customer Acceptance (CP1), and to provide the statement of the original project objectives, scope and constraints for creation of the End Project Report. End Stage Assessment (ESA) This is a mandatory management control and occurs at the end of each stage. It typically consists of a formal presentation to the Project Board of the current project status, and reviews the overall Business Case and risks. The vehicle used for this is the End Stage Report. “Managing Stage Boundaries” Process •Up-date the Plans for Stage 1; •Up-date the Project Plans; •Up-date the Business Case (Benefits & Risks); •Prepare the Plans for Stage 2 Stage 1 - Planning & Definition Stage 2 - Design & Contract End Stage Assessment (ESA) “Directing A Project” Process •Review the Outcome of Stage 1; •Review the Project Plans; •Review the Business Case (Benefits & Risks); •Preview the Plans for Stage 2. •Endorse the Project & Approve continuation of the project up to the next End Stage Assessment. Figure 47: Handling End Stage Assessments The approval of the proposed plans for the next stage is also obtained. Project Board 96
Ken Bradley’s Understanding PRINCE 2 approval, with agreement by all the members, must be obtained before the project can proceed to the next stage. Attendees at an End Stage Assessment The attendees at an End Stage Assessment will be as follows: The Project Board members (attendance should not be delegated to someone else except in exceptional circumstances; where a Project Board member finds it necessary to send a representative rather than attend personally, the representative must be empowered to take decisions on behalf of the Project Board member. Frequent delegation of attendance should provoke the Executive to consider replacement of the non-attending Project Board member). The Project Manager (the Project Manager is not a member of the decision-making Project Board but must attend to report to the Project Board and to take direction). Project Assurance (to confirm that project management standards are being observed and that “all is well” with the project. This function is essentially one of “reassurance”). Project Support (to take care of the administrative arrangements and record the End Stage Assessment). In addition to the above, the Project Board and Project Manager may invite any other person or representative of any organisation who may be able to assist in the Project Board’s decision making process. These might include Team Managers, Team Members, Policy Advisors, Suppliers and Sub-Contractors. ESA Agenda Although PRINCE 2 does not specify a specific agenda for running ESAs, the following suggested agenda will help in preparing for this important Project Board control: Item 1: Introductions (if external people are present for the first time). Item 2a: Project Manager’s Report on the Current Management Stage. Item 2b: Project Assurance report on the Current Stage. Item 2c: Discussion, Questions and Acceptance of Project Manager’s Report. Item 3a: Project Manager’s Report on the Overall Project: - Project-Level Products – Added/Removed. - Timescale – Current/Forecast to Completion/Variation + Reasons. - Costs/Effort – Current/Forecast to Completion/Variation + Reasons. Item 3b: Project Assurance report on the Overall Project and Projections. Item 3c: Discussion, Questions and Acceptance of Project Manager’s Report. 97
Ken Bradley’s Understanding PRINCE 2 Item 4a: Project Manager’s Report on the Business Case & Risks: - Business Case – Original/Current/Forecast/Variations + Reasons. - Risks – Original/Current/Forecast/Variation + Reasons. - Risk Log –Entries Removed; New Entries. Item 4b: Project Assurance report on the Business Case & Risks. Item 4c: Discussion, Questions and Acceptance of Project Manager’s Report. Item 5a: Project Manager’s Proposals for the Next Management Stage. Item 5b: Project Assurance comments on the Proposals for the Next Stage. Item 5c: Discussion, Questions and Acceptance of Project Manager’s Proposals. Item 6: Discussion, Questions on Overall Situation. Agreement on Future Actions. Item 7: Any Other Project Related Business (eg External Information Which Impacts on the Project’s Future). Item 8: Project Board Formal Sign-off of the Current Stage and Commitment to the Current View of the Project Plan, Business Case and Risks. Acceptance of the Next Management Stage Plans. + Thanks and Close. Remember, the information to prepare the Project Board for the End Stage Assessment will be contained in the End Stage Report, prepared in the “Reporting Stage End (SB5)” Process which is part of “Managing Stage Boundaries (SB)” Major Process. Mid Stage Assessment (MSA) This Project Board control is held only to review a significant deviation from an approved Management Stage Plan and to approve an Exception Plan produced, at the request of the Project Board, following an Exception Report. An Exception Report is produced by the Project Manager to alert the Project Board as soon as it is apparent that a significant departure from the approved plan is forecast. The Exception Report records what has happened to cause the “significant departure” from the approved plan, the impact on the Management Stage, overall Project and its Business Case. The plan will also recommend appropriate action to take the project to the end of the Stage and, where possible, recover the situation. 98
Ken Bradley’s Understanding PRINCE 2 “Controlling A Stage” •Deviation from approved Stage Plans Forecast; Process •Exception ReportCreated - Reasons; Impact; Options; Recommendation; •Direction from Project Board .... Create an Exception Plan; “Managing Stage Boundaries” •Produce an Process Exception Plan Stage 1 - Planning & Definition Stage 2 - Design & Contract Mid Stage Assessment (MSA) “Directing A Project” •Consider the Exception Plan at an unscheduled Mid Stage Assessment. Process •Review the Problems with Stage 1; •Review the Impact on the Project Plans; •Review the im[pact on the Business Case (Benefits & Risks); •Preview the revised Plans for the remainder of the Stage. •Endorse the Project & Approve continuation of the Stage up to the next End Stage Assessment. Figure 48: Handling Mid Stage Assessments The Exception Report may be triggered by a number of different events, sometimes without much advance warning, but in most cases a deteriorating situation will be known by the Project Manager and observed by Project Assurance. Where Project Assurance become aware of a Management Stage in decline an immediate report must be made to the appropriate Project Board member (or the Executive). The Project Manager should provide advance warning to the Project Board members via the Highlight Report – it is most important to “come clean” and not attempt to disguise or hide the situation in the hope that something will happen to improve matters – it invariably won’t happen! Where appropriate the Project Manager should advise the Project Board members informally (by telephone, e-mail, internal memorandum etc) rather than wait for the next formal report. Tolerance The measure of a “significant departure” is that the Tolerance stated by the Project Board at the beginning of the management stage has been, or is likely to be, exceeded. Standard Tolerance in PRINCE 2 is measured in terms of Time (Schedule) and Cost. There are other types of Tolerance which may be applied; these include Tolerance on Quality, Technical Conformance, Scope and Risk. Tolerance need not necessarily be equal – for example, it may be appropriate to set differential Tolerance of +0 and –4 weeks, coupled with cost Tolerance of +£10K and -£30K depending on where priorities lie. 99
Ken Bradley’s Understanding PRINCE 2 Plus 10% Tolerance £110K £100K Planned Delivery & Total Cost o Cost £90 Minus 10% Tolerance £80K £70K £60K £50K Plus 1 Week Tolerance £40K £30K Minus 1 Week £20K Tolerance £10K Time 2 4 6 8 10 12 14 16 18 Weeks STAGE PLAN Figure 49: Tolerance - plus/minus 1 week; plus/minus 10% The level of Tolerance is decided by the Project Board following recommendations by the Project Manager. Tolerance is exercised mainly for a Management Stage but is also appropriate at Project and Team Levels. Project Tolerance is set by Corporate/Programme Management. The Executive member of the Project Board is responsible for ensuring that Project Tolerance has been established and recorded in the Project Brief. If at any time Project Tolerance is forecast to be exceeded it is the responsibility of the Executive to report to Corporate/Programme Management and to obtain new direction (possibly re-baselining the project and establishing new Project Tolerance levels). (Management) Stage Tolerance is agreed by the Project Board and set by the Executive. Stage Tolerance is always set within the context of the Project Tolerance – the Project Board do not have any discretion to exceed Project Tolerance without authority from Corporate/Programme Management. Where Tolerance is forecast to be exceeded the Project Manager will convey this to the Project Board via an Exception Report which will typically be followed up by an Exception Plan; alternatively, the Project Board may decide to prematurely close the project. Product Tolerance will usually be recorded in the Work package agreed between the Project Manager and the Team Manager responsible for the Products addressed by the Work Package. Product Tolerance will be agreed in “Accepting A Work Package (MP1)” and used as part of the basis for Checkpoint Reporting in “Executing A Work Package (MP2)”. Obviously, Product Tolerance must not, individually or collectively, exceed the approved Stage Tolerance. 100
Ken Bradley’s Understanding PRINCE 2 Premature Termination of Project CS8 1: Exception Report Escalating Project Issues DP4 Giving Ad-Hoc Advice 2: Exception Plan Request) CS1 - Authorising A DP3 Work Package Authorising A Stage or Exception Plan 4: Authorisation SB6 To Proceed Producing An Mid-Stage Exception Plan Assessment 3: Exception Plan Figure 50: Summary of the PRINCE 2 Exception Procedure Tolerance is a major control for the Project Board, which allows its members to focus on exceptions rather than be swamped with information about work which is proceeding to plan. Similar benefits also accrue for Corporate/Programme Management who are able to leave responsibility for the project to the Project Board, sure in the knowledge that any major departures will be brought to their attention. Similarly for the Project Manager who, by setting Product Tolerance with Team Managers/Suppliers, can direct attention to those areas of the project which do need additional support. Project Assurance has a vital role to play here in assuring the Project Board (and the Project Manager for Individual Products) that all is “set fair”. Approving An Exception Plan As mentioned above, the Mid Stage Assessment (MSA) in PRINCE 2 is held only to approve an Exception Plan, following the raising of an Exception Report. Obviously, MSAs will not be planned in advance and will only be held exceptionally. If the duration of a proposed Management Stage is deemed to be too long to be acceptable to the Project Board, then the Stage should be broken into more than one Management Stage with an End Stage Assessment at each new break. The Mid-Stage Assessment control is not appropriate for breaking up long duration Stages. Neither is the MSA intended to be the vehicle for “incidental progress meetings” held by the Project Board; the PRINCE 2 Method makes no provision for such meetings. The End Stage Assessment and the Mid-Stage Assessment are decision-based meetings and major Project Board controls to ensure that all work being undertaken has the support and overt approval of the key managers. 101
Ken Bradley’s Understanding PRINCE 2 Project Closure This provides a final review of the project's work is held, usually (but not necessarily) in the form of a Project Board meeting. This is similar in structure to an End Stage Assessment but relates to the entire project rather than a single stage. The objective is to ensure that all the project Products/Deliverables have been satisfactorily delivered to their stated quality standard and that the project documentation is complete. A review of the contribution made by the project management standards and approaches used by the project will be carried out within the “Closing A Project (CP)” Process and a Lessons Learned Report produced for consideration by the Project Board. The Lessons Learned Report records what has been learned from using the PRINCE 2 project management and quality management standards for the project and is first created during the “Initiating A Project – Setting Up Project Files (IP5)” process and “populated” as the project progresses; it will eventually be sent, via Corporate/Programme Management to the organisation’s manager responsible for quality. Recommendations will also be made by the Project Manager for Follow-on Actions to record and trigger any further work recommended following the closure of the project. Recommended Follow-on Actions will usually be derived from any outstanding Project Issues, recorded on the Issues Log and from recommendations impacting on operational and maintenance of the delivered outcome. Highlight Reports The Project Board is kept informed of the progress of the Management Stage (and the project) against the approved plans via regular, time-related Highlight Reports. These are prepared by the Project Manager using information derived from Checkpoint Reports and following a review of the status of the Management Stage. They are usually provided monthly, although their frequency will always be decided by the Project Board. Highlight Reports are usually sent through the post or by e-mail; the objective is to remove the need for unnecessary time-related Project Board meetings which consume the Project Board members’ valuable time, while still keeping them abreast of significant developments. The format for Highlight Reports will typically include: ♦ a statement of the progress made during the last (usually monthly) period; ♦ a statement of problems during the last period, and how they were handled; ♦ confirmation of the Activities and Products to be worked on during the next period; ♦ a statement of the financial and schedule situation for the overall project and the current Management Stage. Some organisations specify that Highlight Reports should be kept to one side of A4 (or its equivalent) and this makes very good sense. 102
Ken Bradley’s Understanding PRINCE 2 Where the project is part of a Programme of work, separate Project and Programme Highlight Reports will normally be produced and special attention must be paid to reporting on interfaces with associated projects. It is always good practice to agree a common format for Highlight Reporting where a Programme Director (or Project Board responsible for a number of projects) has responsibility for assessing Programme progress. A graphical representation is a useful medium for achieving a common reporting structure, especially in a Programme environment where the Programme Director may prefer to have a regular, time-based meeting where individual project Managers present their Highlight Report Summaries in short time units. A suitable format which can be adapted for this purpose is the Graphical Summary/Earned Value Analysis plan described in the “Understanding Planning” Chapter in this book. Checkpoint Reports Progress on the work of a Team against the agreed Work Package is the subject of the Checkpoint Report. Typically a Checkpoint Report will be created following a Checkpoint (meeting) in the “Managing Product Delivery Process – Executing A Work Package (MP2)”. Its format and frequency will be agreed in “Accepting A Work Package (MP1)” and it will generally mirror the information contained in the Highlight Report to ease the task of reporting. The Checkpoint Report is used to up-date the Management Stage Plans with “actuals” to date and will ultimately be used as an input to the Highlight Report to inform the Project Board of progress made. Stages Stages are partitions of the project with decision points at their conclusion, and sometimes during their life. PRINCE 2 differentiates between “Management Stages” (which equate to the commitment of resources by the Project Board and a decision to continue with the project and authority to spend) and “Technical Stages” which comprise sets of technical activities leading to a stated Product. 103
Ken Bradley’s Understanding PRINCE 2 Technical Stages Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Review of Management Stage at Project Closure End Stage Assessment (ESA) Figure 51: Management & Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned and managed by Team Managers who report to, and take direction from, the Project Manager. Management Stages will always run in series. In the above diagram, the Technical Stages have been planned to run in parallel. Of course, in a smaller project these might well be described as “Activities”; in medium to larger projects, the Activities will often combine to provide the Technical Stages. In only the most exceptional circumstances will authority be given for work to commence on the next Management Stage before all the Products of the current Management Stage is completed. 104
Ken Bradley’s Understanding PRINCE 2 Chapter 6 UNDERSTANDING THE STAGES COMPONENT 105
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Introduction Stages are partitions of the project with decision points at their conclusion and, sometimes, during their life. Management & Technical Stages PRINCE 2 differentiates between “Management Stages” (which equate to the commitment of resources by the Project Board and a decision to continue with the project and authority to spend) and “Technical Stages” which comprise sets of technical activities leading to a stated Product. Technical Stages Initiate Specify Design Build Test Train Hand-over Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Closure Project Board Review of Management Stage - End Stage Assessment (ESA) Figure 52: Management and Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned and managed by Team Managers (within the “Managing Product Delivery (MP1)” Process) who report to, and take direction from, the Project Manager. Management Stages, on the other hand, will always run in series; they will overlap only in exceptional circumstances and always only with the prior agreement of the Project Board. In the above diagram, the Technical Stages have been planned to run in parallel. Of course, in a smaller project these might well be described as “Activities”; in medium to larger projects, the Activities will often combine to provide the Technical Stages. In only the most exceptional circumstances will authority be given for work to commence on the 107
Ken Bradley’s Understanding PRINCE 2 next Management Stage before all the Products of the current Management Stage is completed. Management Stages Each PRINCE 2 controlled project will contain at least two Management Stages - one (the Initiation Stage) for planning the project and the other containing the “action” portion, or implementation of the project. Management Stages enable the Project Board to control the release of funding for the project and provide the major control for the project. This is known as “Limited Commitment”. Approval of each Management Stage commits the effort, cost and time resources contained within the Next Stage Plan (prepared in the “Managing Stage Boundaries (SB)” Process). Project Board approval to each Management Stage is given in the context of endorsing continuation of the overall project. The important thing here is that Project Board members understand that the estimates of effort, cost and time within the Project Plan are “soft” estimates only and certainly not cast in stone. The originally approved Project Plan will be embodied in the approved Project Initiation Document which will have been “frozen” at the time it was formally approved (in “Authorising A Project (DP2)” Sub-Process) at the conclusion of the “Initiating A Project (IP)” Process. Each Management Stage will culminate in an End Stage Assessment (ESA), at which point the following options will be open to the Project Board: ♦ Continue into the Next Stage; ♦ Re-visit part (or all) the Current Stage; ♦ “Freeze” the project for a finite or an indeterminate period; ♦ Abort the project. The Project Board should not treat lightly any proposal to commence the next Management Stage before all the Products of the Current Stage are complete. Exceptionally the Project Board may agree to this but the practice is dangerous and may well result in nugatory expenditure. Updating The Business Case At the conclusion of each Management Stage, the Business Case must be reviewed and updated. Specifically this will mean up-dating the statement of Business Benefits to confirm that the project remains on track to achieve them. Where the Business Benefits are supported by a Cost:Benefit Analysis, this must be re-assessed and the results reported to the Project Board. 108
Ken Bradley’s Understanding PRINCE 2 The Risk Assessment must also be reviewed and the Risk Log updated, minimally at the completion of each Management Stage. Technical Stages Technical Stages are quite different from Management Stages in that they will invariably be planned to run in parallel, within one or more Management Stages. This saves time within the Management Stage and enables the best use to be made of the available resources. Initiate Specify Design Build Test Train Hand-over Management Management Management Stage 1 Stage 2 Stage 3 Start-Up Project Brief Project Approach PID Interview Users Produce Spec Outline Design Final Design Agree Design Management Stage 1 Figure 53: Creating The Stage Plan From The Project Plan In most major projects, Technical Stages will be present, planned and controlled by Team Managers working directly for the Project Manager. Typically Technical Stages will address specific specialist areas of the project such as Work Packages placed with Suppliers under the cover of formal contracts. There will, however, also be room for Technical Stages for discrete parts of the project being undertaken by internal resources, such as the creation of the Specification for the project’s outcome, as illustrated in the diagram. This work will best be planned and managed by a customer or user. Handling The End Of A Management Stage Handling Management Stage endings is a straightforward task once the basic principles of PRINCE 2 planning and control are properly understood. The main feature to bear in 109
Ken Bradley’s Understanding PRINCE 2 mind is that as Management Stages must not run in parallel, some degree of planning for the next Management Stage must be included within the current Management Stage. PRINCE 2 planning allows any combination of activities to be planned and executed provided authority for the work is obtained from the Project Board. It is, therefore, quite acceptable to be working on Products which will be delivered in the next Management Stage provided approval and authority has been given. This enables Management Stages to “butt” against each other and avoids the need to stop work on the project while Project Board members assess the content of the End Stage Report, updated Project Plans, updated Business Case, and the Next Stage Plans. Work, Effort & Cost “at risk” “Natural” Stage End Time needed for the Project Board to review the papers & prepare for End Stage Assessment Stage 1 Stage 2 Figure 54: Handling Management Stage Endings The approach does mean that a risk is being taken that, should the project be terminated at the End Stage Assessment, some nugatory costs would have been incurred - but this risk is well worth taking. If, as is likely, the Project Board is unwilling to accept up to two weeks’ delay to the project at every Management Stage end, this approach is the only real alternative. Failure to plan for Management Stage endings will inevitably put pressure on the Project Manager to undertake some preliminary work on the next Management Stage without formal authority to do so, and this must be avoided. Stages - Summary Management Stages are key control components within a PRINCE 2 project. Adequate review procedures must be established to ensure that commitment of effort and funding resources is fully under the control of the Project Board. 110
Ken Bradley’s Understanding PRINCE 2 Chapter 7 UNDERSTANDING THE RISK MANAGEMENT COMPONENT 111
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Introduction PRINCE 2 places stress on the need for a strong and visible Business Case with the Business Benefits and Risk Management being key features within this concept. No specific techniques are suggested by the Method, although there are some pointers to commonly available packages which will help, especially in the identification and management of risk. The risks perceived for any individual project will be summarised by the Project Manager at the time of Project Initiation, and will be reviewed and up-dated at each Project Review. For many small, low risk projects it will be acceptable to provide only a narrative statement of the perceived risks. However for higher profile, higher value, contentious projects a more formal risk assessment may be required by the Project Board. Version 1 of the PRINCE Methodology referred to a Risk Analysis Checklist, originally put together by CCTA at the request of the User Group. This Checklist has been modified, added to, and adjusted by SPOCE Project Management over a number of years and client implementations, and is reproduced on the following pages. An Excel Spreadsheet containing the Risk Analysis Checklist is available, upon request, from SPOCE Project Management Limited (Telephone UK (+44) (0)1202-780740). It provides a simple and structured way to identify the main risk areas for the project. It should not be regarded as a definitive statement of the precise risks faced by the project but rather as an indicator of the areas that are more likely than not to cause problems! The Risk Analysis Checklist expresses the project manager’s feelings about the likely risks faced A completed example of the Risk Analysis Checklist is included at the end of this Chapter. The final score derived from the Risk Analysis will provide guidance for the proposals put forward by the project manager. Any score in excess of 15 should be extracted and proposals made to the Project Board for reducing or managing the risk. A suggested format for risk management proposals recorded in a Risk Log is as follows: Description of the Risk Risk Score Comment on the Risk Proposals The Project Manager has 21 The Project Manager has many Proposal 1: only limited experience of on-going responsibilities which The Project Manager to managing a major project are expected to take up much attend a Project Mgt. of this type. time and effort (about 4 days training course. each week). He also has no The Project Manager is previous experience of planning Cost: £2,000 also responsible for 3 or managing a project of this other mainstream projects size and scope. Proposal 2: being developed concurrently Buy in an experienced Project Management consultant to advise the Project Manager and provide support during the first two weeks of the project. Cost: £4,000 Figure 55: Risk Log 113
Ken Bradley’s Understanding PRINCE 2 Risk Ranges & Risk Factors The risk factors of 2.00 and 2.60 within the Checklist relate to the assessed risk for the project recorded in column (b) which is always rated on a scale of 0.10 to 4.00. The norm for this scale is 2.00; any higher assessment would point to a higher than norm risk and any lower assessment points to a lower than norm risk. 2.00 “Norm Risk” Higher Risk Recommended “Norm” Range 0.10 1.00 3.00 4.00 Lower Risk 2.00 “Norm Risk” Figure 56: The Risk Management Analysis Ranges Applying a risk factor of 2.00 to the assessed weighting in column (e) provides a comparative figure to that obtained when multiplying the weighting by the assessed risk (column (e) x column (b), placed in column (f)). Therefore, if the result of applying the risk factor of 2.00 to the weighting column (e), is less than that calculated for column (f) then the particular component (or the whole assessment) indicates a higher than norm risk for the project as a whole. Conversely, if the application of the 2.00 factor to the assessed weighting (column (e) results in a higher score than that calculated for the total score in column (f), then the component (or overall assessment) indicates a lower than norm risk. The selection of a factor of 2.60 as the threshold for a “very high risk” project is somewhat arbitrary, based on experience and actual situations. The factor may be reduced or increased as experience with project risk within an organisation is gained. The risk Analysis Checklist includes a simple calculation for identifying the risk factor for the project. Regular assessment should indicate a downward movement in the calculated risk factor as the project progresses towards its conclusion. Any consistent upward movement should be investigated and reported to the Project Board Executive. 114
Ken Bradley’s Understanding PRINCE 2 (b) (e) (f) (e) x 2.00 (e) x 2.60 2 x 4 = 8 8 10.4 (higher than 8 = LOW RISK) 2 x 5 = 10 10 13.0 (higher than 10 = LOW RISK) 2 x 6 = 12 12 15.6 (higher than 12 = LOW RISK) 2 x 7 = 14 14 18.2 (higher than 14 = LOW RISK) 3 x 4 = 12 8 10.4 (lower than 12 = HIGH RISK) 3 x 5 = 15 10 13.0 (lower than 15 = HIGH RISK) 3 x 6 = 18 12 15.6 (lower than 18 = HIGH RISK) 3 x 7 = 21 14 18.2 (lower than 21 - HIGH RISK) TOTALS: 44 110 88 114 Figure 57: Summary of the Impact of the Risk Scores & Weightings In the example, if the assessed total score (column (f)) of 110 is less than 88 (having had the 2.00 “norm” Risk Factor applied), the overall assessment of risk is LOW. If the assessed total score (column (f)) of 110 is greater than 114 (having had the threshold 2.60 Risk Factor applied), the overall assessment of risk is VERY HIGH. Updating the Risk Analysis Where a formal risk assessment is carried out, the project will be re-appraised, minimally, at each review of the project (in “Managing Stage Boundaries (SB)” Process) and a log of the overall score maintained. The Risk Analysis should also be up-dated and logged at regular intervals (possibly weekly) for the first 4 to 6 weeks of the project following approval of the PID, especially where the initial risk factor is in excess of 2.20. 115
Ken Bradley’s Understanding PRINCE 2 Risk Factor Score Very High Risk 2.60 = 114 2.50 = 110 2.40 = 105 High Risk At Project 2.30 = 101 Initiation 2.20 = 97 At End of 2.10 = 92.4 Stage 1 Moderate Risk 2.00 = 88 At End of Stage 2 Low Risk Continuous Risk Assessment by the Project Manager Figure 58: Reducing Level Of Risk As The Project Progresses Modifying The Risk Analysis Checklist The best results will be achieved where the Risk Analysis Checklist is modified to reflect the business, culture and types of project which predominate within the implementing organisation. It will be noted that the Risk Analysis Checklist is particularly relevant to the initiation of projects and contains comparatively little assessment of the on-going control and management of the project. It may well be that amendments to the standard checklist would benefit from focusing on the control aspects. 116
Ken Bradley’s Understanding PRINCE 2 STANDARD RISK ANALYSIS CHECKLIST The Risk Factors which affect the probability that the project will be completed on time and within the agreed time and budget, and will deliver a quality-compliant End Product arise from six sources - Project Management, The Project Staff, The Nature of the Project, The Maturity of the Development/Supplier Organisation (Internal and External Suppliers), The Customer and the Contract, and Third Party Suppliers. The project risks associated with each of these Elements are itemised and estimated below in the form of statements typifying Low and High Risk on either side of a scale of 0.10 to 4.00. The “norm” range used is 1.00 to 3.00 and values outside this norm have only been used exceptionally and an explanation is provided. The assessed risk score under column (b) has been multiplied by the weighting factor inserted under column (e) to provide a total risk score (rounded) for each question posed. Individual risks scoring in excess of 15 have been extracted to a Risk Log recording the identified risks & proposed actions. A Risk Factor for the project has been calculated and this will provide a Baseline for measurement of movements in the project risk. A Risk Factor of 2.00 is the neutral measurement, greater than 2.0 indicates an increasing project risk; lower indicates a reducing project risk. (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight Project 1 Full time, experienced 3.00 Part time, inexperienced 5 to 7 7 21 Managem Project Manager Project Manager ent 2 Customer Management 3.00 Inexperienced Customer 4 to 6 5 15 experienced and likely Management - little to be active participation expected Project 3 Customer staff likely to 2.30 Little Customer staff 3 to 6 3 7 Staff be supportive and fully involvement expected and involved in the project little contribution 4 High standard of 1.50 Wide span of supervision 4 to 6 4 6 supervision & narrow and control expected to be span of control in the poor project team 5 Good quality project 1.50 Inexperienced project team 6 to 8 6 9 team, experienced with lacking the key skills the right skills 6 Staff assigned full time 3.00 Staff have many other 3 to 6 5 15 to the project responsibilities 7 Low turnover of project 2.00 High turnover of project 4 to 7 7 14 staff staff 8 Staff experienced at 1.8 No experience of Quality 4 to 6 6 11 Quality Reviews Reviews among staff 9 An organisational 2.20 Staff take little interest in 4 to 6 6 13 commitment to quality achieving a Quality exists Culture 117
Ken Bradley’s Understanding PRINCE 2 (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight Nature of 10 Typical project with a 2.20 A project lifecycle that has 4 to 6 5 11 the straightforward a number of inter technical Project lifecycle relationships 11 The project has no, or 2.30 Pioneering new 6 to 8 5 12 few novel features approaches are being tried out in the project 12 Equipment being 2.10 Equipment is untried and 4 to 6 5 10 installed by the project its use in uncertain is well known, tried and tested 13 Current main 3.00 Significant impact on 3 to 5 5 15 operations will be only current main operations by minimally affected by the project the project 14 The Requirements are, 2.00 Requirements are 3 to 6 5 10 or will be, well (expected to be) poorly established and well understood, documented documented by the and presented by the Customer Customer 15 Little or no 2.60 Extensive modification 3 to 6 5 13 modification needed to needed to existing existing technical technical standards will be standards needed 16 Little project work is 2.80 Other project work is 3 to 6 5 14 being undertaken being carried out in currently parallel with this project 17 There is little 2.80 There is a dependence on 3 to 7 6 17 dependence on development facilities development facilities which are outside the not under the control of control of the project team the project team 18 Project duration is less 2.60 Project duration is longer 2 to 5 4 10 than 6 months or there than 6 months or there is a is only a small number high number of workdays of workdays required 19 There is little or no 3.00 There is a mandatory 4 to 7 6 18 constraint on the completion date stated by completion date the Customer 20 Plans and estimates are 3.00 Plans and estimates are 4 to 7 6 18 (will be) based on (will be) based on reliable data from unreliable data - similar projects essentially “green field” 21 Estimates have been 2.60 Approximations have been 4 to 7 6 16 prepared using well used based on unreliable tried and documented standards standards 22 This is the first or 2.90 There have been two or 4 to 8 7 20 second attempt at this more attempts to complete project - ie there is no this project - ie it has a history of consistent history of failure failure 118
Ken Bradley’s Understanding PRINCE 2 (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight 23 Few Customer 3.00 Many Customer 4 to 6 5 15 Departments will be Departments will be affected by the final affected by the final outcome outcome 24 The project work will 2.80 Many Customer sites will 3 to 6 6 17 affect few Customer be impacted by the project sites work 25 Sites which the project 2.90 Sites are remote and 3 to 6 6 17 team will visit are easily inaccessible accessible 26 There will be only 2.50 There will be significant 3 to 6 4 10 minor impact on the impact on the Customer’s Customer’s day to day day to day work during the work during the project project cycle 27 Well developed and 1.50 Few Project Management 4 to 7 5 7 understood Project Standards will be available Management Standards to the project team will be available to the project team Maturity 28 There is a well 1.80 Quality Management is ill 4 to 7 5 9 of the developed and defined and/or not visible Organisa understood Quality tion Environment - ie an audited Quality Management System 29 Clear delegation of 2.00 There is strict central 3 to 6 5 10 authority is practised by management control with management little empowerment or delegation 30 Project Staff will wish 2.00 Project Staff are not 3 to 6 5 10 to make use of the expected to utilise any published Project Project Management Management Standards Standards that exist The 31 The Customer 1.90 The Customer 4 to 7 6 11 Customer demonstrates a full demonstrates a poor and the understanding of the understanding of the Contract Requirement and its impact of the Requirement impact 32 There will be little or no 2.20 Extensive modification to 3 to 6 5 11 modification needed to the Customer’s existing the Customer’s existing facilities is expected facilities 33 An agreed contract is in 3.00 No formal contract is yet in 4 to 7 6 18 existence place 34 There have been 1.80 There have been 3 to 7 6 11 previous dealings with difficulties when dealing the Customer and with this Customer on previous contracts have earlier contracts been brought to a satisfactory conclusion 119
Ken Bradley’s Understanding PRINCE 2 (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight Third 35 Suppliers are known, 2.00 The Suppliers are new and 4 to 8 6 12 Party approved and have a little is known about their Supplier satisfactory track capabilities record 36 Only one, well 2.00 Multiple Suppliers (with 3 to 6 6 12 established, approved Sub-Contractor elements) Supplier will be used to are anticipated provide the services 37 Suppliers have an 2.00 Supplier project 3 to 6 6 12 established Structured management arrangements Project Management are ad-hoc with little Method based on visible definition PRINCE or similar 38 A Supplier contract is in 1.50 Informal arrangements 4 to 7 6 9 existence only exist 39 The main Supplier has a 1.50 The main Supplier has no 4 to 7 6 9 fully audited Quality published Quality Management System to Management System ISO9001 40 The future level of 1.80 The future level of Supplier 3 to 6 6 11 Supplier performance is performance is un- expected to be excellent assessable because too little is known TOTALS 214 494 SUMMARY The project is assessed as LOW RISK if 494 (Column (f) Total) is LESS than 428 (Column (e) x 2.00) The project is assessed as VERY HIGH RISK if 494 (Column (f) is MORE than 556 (Column (e) x 2.60) The RISK FACTOR for the project is 2.31 (Column (f) total divided by Column (e) total) The Project is assessed as HIGH RISK at this time. nb: A Risk Factor of less than 2.00 indicates a LOW RISK project. A Risk Factor between 2.00 to 2.20 indicates a MODERATE RISK project. A Risk Factor between 2.20 to 2.60 indicates a HIGH RISK project. A Risk Factor in excess of 2.60 indicates a VERY HIGH RISK project. 120
Ken Bradley’s Understanding PRINCE 2 Chapter 8 UNDERSTANDING THE QUALITY MANAGEMENT COMPONENT 121
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 & BS/EN/ISO9001 PRINCE 2 has been designed to comply with the BS/EN/ISO9001 Quality Management Standard and the method contains a section relating its content to each section of the ISO Standard. BS6079, the Project management Standard, is also reflected within PRINCE 2. ISO9001, BS6079 and PRINCE 2 are all Process-driven; the foundation for quality and effective, modern project management is therefore integral and inherent in PRINCE 2. The Method assumes that a PRINCE 2 managed project will be carried out within a published quality environment with defined standards and procedures. The PRINCE 2 Manual contains a fairly detailed review of all parts of ISO9001 and states the extent to which each of the parts of the full ISO standard is met by PRINCE 2. Quality Management Quality Assurance Set up & Audit of Quality Management System Quality Management System Quality Policy Statement Quality Manual Organisation Structure Processes Procedures Quality Planning Quality Control * Objectives & Requirements * Measurement Against * Overall Approach Quality Criteria * Project Quality Plan * Measuring Against * Stage Quality Activities Requirements Figure 59 : The Quality Structure The prime aim of Quality Management within a project environment is to ensure that the quality expected by the customer is delivered within the project and extends beyond delivery of the outcome. 123
Ken Bradley’s Understanding PRINCE 2 Figure 53 summarises the main components of a quality structure. The PRINCE 2 Method provides specific guidelines for Quality Planning and Quality Control, with the process “Planning For Quality (IP1)” taking place very early in the life of the project and planning for quality within each Product or Deliverable being a major part of “Planning A Stage (SB1)” as the project proceeds. Specific Product quality planning occurs with the creation of a Product Description for each project-level and Management Stage-level Product. The vehicle for this is the Product Description which states the Quality Criteria, type of quality check and the people who need to be involved. Quality Control is effected in the most sensible way for the Product under scrutiny and the organisation. PRINCE 2 includes the technique of Quality Review to provide the means of assessing a Product against its stated Quality Criteria but leaves selection of the most appropriate means to control quality to the Project Manager and Project Board. Of course, this puts much emphasis on getting the Product Description right in the first place, especially the Quality Criteria which will form the basis of acceptance, or not. Customer Quality Expectations These must be reflected in the PRINCE 2 project environment.Ideally they will be stated within the Project Mandate, but will, in any event, be included in the Project Brief (“Starting Up A Project (SU)” Process) and expanded, if necessary, in the Project Initiation Document (“Initiating A Project (IP)” Process). The results of the quality planning activity must be integrated into the timescale and resource plans at each level. Just as quality must be built into the Products, so must quality control be built into the plans. Within PRINCE 2, Planning for Quality within the project takes place predominantly in the “Initiating A Project (IP1)” Process where the Quality Management Systems of both the Customer and the Supplier are used to prepare a foundation of quality for the project. This does not, of course, mean that quality matters are taken into account only during this Process; quality is a component which takes prominence throughout the life of the project and fits closely with the Quality Review Technique discussed later in this publication. Quality Aspects For Suppliers & Sub-Contractors PRINCE 2 assumes a Customer:Supplier relationship where the total project outcome may be undertaken, under contract, by an external supplier; in most projects, there will be the need to buy in components or services from external sources. In these situations, control over quality takes on further importance as the procedures and staff used to carry out the quality control function is outside the direct control of the Project Manager. The approach used within the Method is to provide the “supplier” (internal or external) with a clear statement of what is wanted, the quality standard that must be adhered to and the reporting requirements, in the form of an authorised Work Package. 124
Ken Bradley’s Understanding PRINCE 2 The authorised Work Package may take the form of a formal contract or, where the supplier of the Product or service is internal, a memorandum. The typical content for an Work Package is: ♦ Date ♦ Team or Individual or organisation authorised to carry out the work ♦ Description of the Work Package (Product Description) ♦ Extract from the Management Stage Plan ♦ Statement of joint agreement on effort, costs, start date and end date ♦ Any specific techniques, processes or procedures that are to be employed ♦ Any interfaces that must be addressed before, during and at the conclusion of the work ♦ Any constraints to be observed ♦ Reporting Arrangements - timing, content, responsibilities ♦ Quality Checking arrangements A copy of the relevant Product Description(s) will always accompany the authorised Work Package; this will contain the specific Quality Criteria and checking arrangements that must be observed. Work Packages are authorised by the Project Manager in the “Controlling A Stage (CS1)” Process and passed to the supplier in the “Managing Product Delivery (MP1)” Process for discussion where necessary and agreement before work commences. Completed Work Packages (Products/Deliverables) are delivered back into the commissioning organisation on completion of the work. Completed Work Packages should always be complete and Quality Reviewed in accordance with the agreed Work Package. Where there are difficulties with the quality of supplier’s products, it will be necessary to set up additional quality review/control arrangements within the customer’s organisation. In such cases a smoothly working Configuration Management system is essential in order to track down “offending” suppliers and take remedial action. Quality Management - Summary Action must be taken at project planning time (within the “Initiating A Project (IP1)” Process) to ensure that the project can deliver its Products to the quality standards required by the customer. Quality Criteria must be defined and agreed, and incorporated into a Product Description for each major Product identified; a Project Quality Plan must be defined, published and adopted; Quality Review procedures must be established and staff trained; review activities must be properly resourced. Whatever action is proposed to build quality into the project, the measures must be consistent with any published Quality Management System (QMS) that is already in effect. 125
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 9 UNDERSTANDING THE CONFIGURATION MANAGEMENT COMPONENT 127
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Configuration Management - Introduction A configuration is a logically related set of products which need to be managed as a composite set. The “Configuration” to be managed may, therefore, be summarised as the sum total of all the equipment, instructions, information used, and documentation which together represent the total of the Products or Deliverables from the project. Configuration Management Techniques Configuration Management (CM) provides techniques and procedures to perform the following functions: ♦ Identifying the individual items which are to be managed. These are referred to as Configuration Items (CIs). ♦ Recording, monitoring and reporting on the current status of each Configuration Item as its development progresses through its own specific development life-cycle. ♦ Filing all development documentation produced during the project life of the CIs. ♦ Distributing and recording holders of copies of all project documentation for all CIs. ♦ Managing Project Issues raised during the project. ♦ Managing change to all CIs, from receipt of a Project Issue Report, through assessment of the impact of proposed changes, release of both the documentation and the Product itself. In PRINCE 2, Configuration Management is not optional. All the above functions are necessary for successful projects. Without CM, managers would have little or no control over the products their projects are producing. All the Products of a PRINCE project, including documentation Products, Management and Quality Products should be con- trolled using a suitable Configuration Management Method (CMM). Depending upon the sophistication of the method used, some or all of the following should be observed; it should be possible to use the following list of criteria during the selection process for a CMM method and/or support tool: ♦ Configuration Items must be able to be created, amended and deleted; ♦ Configuration Items must be capable of being uniquely identified; ♦ the owner of each Configuration Item must be able to be uniquely identified; ♦ the owner of a Configuration Item must be able to be changed, without necessarily changing the Configuration Item itself; 129
Ken Bradley’s Understanding PRINCE 2 ♦ baselines must be capable of being established; ♦ configuration audits must be able to be performed; ♦ it should be possible to restore a Product (or related group of Products) to its state as at a previous baseline, either temporarily or permanently; ♦ the placing of a Configuration Item in the system library must be documented; ♦ Impact Analysis must be able to be carried out to help assess the ramifications involved in changing one or more configuration item; ♦ Configuration Items which are of interest to more than one project must be able to be held centrally. In order to aid impact analysis the CMM should also provide a structure defining the relationships between the configuration items, so that no configuration item is changed without triggering a check for possible ramifications in its neighbours. CM Activities The word “configuration” has in the past been associated mainly with equipment and the term “Configuration Management” was originally applied to the control of hardware development and production. Nowadays, however, it is internationally accepted that Configuration Management can be and needs to be applied to all elements of a project. In PRINCE 2, the term Configuration Management refers essentially to the management of project Specialist Products and the associated Documentation. Configuration Management consists of four basic activities which together assist in the management and control of development projects: ♦ Configuration Identification; ♦ Configuration Control; ♦ Status Accounting; ♦ Configuration Audits. Configuration Management is a service function which assists in making both the specialist and managerial activities more effective. Effectiveness of the CM processes increases in proportion to the degree that the discipline is part of the normal day-to-day activities of everyone involved in the project. Configuration Management practices offer support to the specialist activities as well as providing management with the information necessary for controlling Products as they are produced by the project teams. 130
Ken Bradley’s Understanding PRINCE 2 Configuration Management oversees all the Products of a project by controlling access to them and by maintaining records of their status. Operation of Configuration Management will benefit from the appointment of a Configuration Manager or Configuration Librarian as custodian of master copies of all project Products. This role can be combined with the Project Support role where appointed. Where no specific appointment has been made, and where a Project Support role has not been confirmed by the Project Board, the Project Manager is responsible for Configuration Management of the project’s Products. 131
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 10 UNDERSTANDING THE CHANGE CONTROL COMPONENT AND CHANGE CONTROL TECHNIQUE 133
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Change Control - Introduction There are three types of changes which can be raised within a project under a PRINCE 2 controlled project; they are used to document desired change to, or some failure in, the project's products; they are: ♦ Project Issue; ♦ Off-Specification; ♦ Request for Change. This chapter is written on the assumption that exceptions will be controlled by a Configuration Manager. If no such role has been allocated, control of exceptions will be the responsibility of the Project Manager or Project Support, where appointed. Project Issue A project Issue is used by anyone to raise issues relating to the project. The subject of a Project Issue is limited only in so far as it must in some way relate to the project, it may: ♦ address a specialist or technical problem, for example: ♦ Perceived errors in the project's products; ♦ Perceived failures of a current representation of the products to meet User Requirements; ♦ An identified inconsistency between one representation of a Configuration Item and any of its earlier representations; ♦ Ideas for improvements in design, functionality, customer interface, documentation, standards etc; ♦ Identification of improved Business Benefits, proposals to reduce the risks; ♦ Or, alternatively, it may be to address a management issue, perhaps related to budgets, plans, schedules or projected staff or skill shortages. Project Issues are often raised during the testing or operation phases of the project, but can be raised by anyone, at any point during the project. Changes to Products after completion and hand-over of the project outcome (ie after project closure) will not be subject to the project's change control procedures, but will be dealt with in accordance with the organi- sation's normal maintenance and enhancement procedure standards. Errors discovered at a Quality Review are only noted on a Project Issue (Report) if the error relates to an item other than that which is being reviewed, or an error which is unlikely to be corrected via the normal Follow Up procedures. 135
Ken Bradley’s Understanding PRINCE 2 At the end of the project all Project Issues should be closed (ie signed off, indicating that the issue has been resolved, possibly by transfer to one of the other two change categories, Request For Change or Off-Specification). The Issues Log, which is used to record each Project Issue, allocate a unique reference and provide a summary of the status of all Project Issues raised, should be provided to the Senior User/Customer at each End Stage review for prioritisation of outstanding Project Issues. This might involve the Senior User in “canvassing” the other Project Board members to provide the resources necessary to action outstanding Project Issues. Off Specifications An Off-Specification is used to document any situation where any project outcome fails to meet its specification in some respect. The error(s) it describes are less likely to be corrected and, as a consequence, are more likely to remain in the delivered output of the project. For this reason Off-Specifications are normally filed in the approved Configuration Items File. Off-Specifications are normally raised by the Project Manager, Team Manager, or Project Board after analysis of received Project Issue Reports. The method does, however allow the originator to identify an issue as an Off-Specification at the time it is formally raised. If a number of Off-Specifications remain outstanding at the conclusion of the project, it is in order to bring them forward as the basis for a separate enhancement project after the main project has been formally signed off and accepted into the business environment. Request for Change A Request For Change is a means of recording a proposed modification to the delivered output of the project and is raised by the Project Manager, Team Manager or Project Board as a result of either analysis of a Project Issue or the decision to rectify a deficiency currently recorded in an Off-Specification. As with the Off-Specification, the originator of an issue may identify it as a Request for Change - this will be most appropriate in circumstances where an error has been discovered. Requests For Change are not used to record deficiencies in an otherwise working system. Deficiencies are documented on the Project Issue Report and Off-Specification Report forms. All RFCs will be actioned and cleared prior to project closure. Change Control Forms and Documentation No forms are provided within the PRINCE 2 Method for managing changes; however suitable forms are available from within the IBM PRINCE Environment and the SPOCE Project Management Launch Pad. 136
Ken Bradley’s Understanding PRINCE 2 Change Control - Summary More information on the PRINCE 2 change control procedures are contained in the PRINCE 2 Manual. It is advisable, however to check with the Quality Manager, Project Support Office or Project Assurance representative as existing, effective, change-control procedures are often (rightly) maintained after the adoption of the PRINCE 2 standard. At the conclusion of the project all Requests for Change must be cleared. This will normally be through completion of all outstanding work on them but, exceptionally, Requests for Change still not started or incomplete may be transferred to an enhancement project. This device can be used to effect customer and business sign-off of the main project. Some Off-Specifications may be present throughout the whole life of the output of the project. Outstanding Off-Specifications should be considered for an enhancement project, possibly on a year-by-year basis. Originator Raises A * Good Ideas * Errors Project Issue (Request for Change * Departures From Agreed Specification or Off-Specification) * Resource Changes * Specification Changes Sent to Project Support Copy returned Notify Originator to confirm receipt Project Issues Log Logged byProject Support Project Issues Log Up-dated Reviewed by Project Manager * Slippage/Budget Changes, exceeding Tolerance or affecting other projects within the Programme = Decision by Project Board (Exception Report) OR .... *Changes Within Tolerance = Decision by Project Manager and action taken to implement the change. Figure 60: Suggested Change Control Procedure Based On PRINCE 2 Principles A diagram summarising a suitable change control procedure is as follows. Each stage of the process is logged into the Issues Log. On completion of the project all the Project Issues must be resolved - either by rejection or conversion to a Request for Change, or an Off-Specification. However, the originator may identify the particular category of Project Issue at the time it is raised. The summary provides an enhancement of the PRINCE 2 suggested procedure. 137
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 11 UNDERSTANDING THE PRINCE 2 PROCESSES 139
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Introduction To Processes PRINCE 2 focuses on the Processes that are needed to manage a successful outcome for any project. The Processes identified in PRINCE 2 represent the minimum content for a PRINCE-compliant project but this certainly is not intended to encourage slavish following of any or all of them! The key to successful management of a project is to ensure that each of the Processes identified within a PRINCE 2 controlled project are addressed in one form or another; how each Process is actually interpreted as a project management procedure is left to the implementing organisation, or where an organisational-wide implementation has not been made, the Project Board and Project Manager. Of course, the concept of a process-driven approach is not new; Project Managers have always used the processes of starting, managing and closing their projects, and senior managers have always been involved in the processes of direction and decision making whether they realised it or not! PRINCE 2 formalises these implied processes and sets them into the context of a successful management. The Processes There are eight major Processes in all, identified within the PRINCE 2 methodology; the eighth Process of “Planning (PL)” is used by all the other Processes. The eight major Processes are: ♦ Starting Up A Project (SU) ♦ Initiating A Project (IP) ♦ Directing A Project (DP) ♦ Managing Stage Boundaries (SB) ♦ Controlling A Stage (CS) ♦ Managing Product Delivery (MP) ♦ Closing A Project CP) ♦ Planning (PL) The Planning Process is common to all the others, making a major contribution to “Initiating A Project” where the whole project is planned, “Managing Stage Boundaries” where the next Management Stage of the project is planned, and “Managing Product Delivery” where the work of teams and each individual Team Member is planned. In addition to these Processes, “Planning” also makes a contribution to all others 141
Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Process Model The overall structure of the PRINCE 2 Process Model can be summarised as follows: * Project Mandate * Project Start Notification IP * Project End Notification * IP1 - Plan Quality SU * IP2 - Plan Project * SU1 - Appoint Exec & PM * IP3 - Refine Bus Case & Risks * SU2 - Design A Team * IP4 - Set Up Controls * SU3 - Appoint A Team * IP5 - Set Up Files * Authorisation * SU4 - Prepare Brief * IP6 - Assemble PID To Proceed * SU5 - Prepare Approach * SU6 - Prepare Initiation Plan *Draft Project Initiation Document (PID) * Trigger for * Project Brief Next Stage Plan * Info from * Project Approach External * Organisation Sources & * Plan for Initiation Stage Feedback DP * Request for Exception Plan * DP1 - Authorise Initiation * DP2 - Authorise Project * Next Stage SB * DP3 - Authorise Stage or Exception Plan * SB1 - Plan A Stage Plan * DP4 - Give Ad-Hoc Direction * SB2 - Up-date Project Plan * DP5 - Project Close * SB3 - Up-date Business Case * Exception * SB4 - Up-date Risk Log Plan * SB5 - Report Stage End * SB6 - Produce Exception Plan * Direction * Highlight *Requests For Reports Advice * Trigger - Next Stage Plan * Authorisation * Exception * Premature To Proceed Reports Close CS * CS1 - Authorise Work Package * Project Issues * CS2 - Assess Progress * CS3 - Capture Project Issues * CS4 - Examine Project Issues * CS5 - Review Stage Status * CS6 - Report Highlights * Work Package * CS7 - Take Corrective Action + Confirmation of Acceptance * CS8 - Escalate Project Issues * CS9 - Receive Completed Work Package * Customer Acceptance * Checkpoint Reports * End Project Report * Trigger - End Project * Project Evaluation * Lessons Learned MP * Completed Work Package * MP1 - Accept Work Package * Follow-on Items * MP2 - Execute Work Package * Post-Project * MP3 - Deliver Work Package Review Plan CP * CP1 - Decommission A Project * CP2 - ID Follow-on Actions Archive Files * CP3 - Project Evaluation Review * Product Based Planning PL Figure 61: Structure Model of the PRINCE 2 Process Model And Major Product Flows 142
Ken Bradley’s Understanding PRINCE 2 Each of the major Processes has associated Processes which drive the management of the project through the use of Components and Techniques, The Processes do not link with any required way of achieving the required outcome; this enables the use of any techniques which are appropriate to the business and reflects the flexibility which comes as part of the PRINCE 2 package. Major Processes and Processes Each of the eight major Processes has a number of Processes which are used to get the job done. A table relating each Process to its parent, major Process is useful to illustrate where each Process resides within the overall Process Model and a summary of each major Process and its “children” is particularly helpful to anyone intending to take the APM Group PRINCE 2 Examinations. The main objectives of each of the eight major Processes are summarised as follows: ♦ Starting Up A Project – Gathering the basic information needed to start the project. ♦ Initiating A Project – Ensuring that the key decision makers understand what is involved and obtaining agreement and commitment to a formal baseline for the project. ♦ Directing A Project – Decision making on behalf of the project by senior managers (in PRINCE terms – “The Project Board”). ♦ Controlling A Stage – Day-to-day project management and controlling the project by the Project Manager, on behalf of the Project Board. ♦ Managing Product Delivery – Creating, modifying and obtaining the Products or Deliverables. ♦ Managing Stage Boundaries – Taking stock of the current situation and getting ready for the next part (Management Stage) of the project. ♦ Closing A Project – Ensuring the project has properly completed prior to formal closure of the project by senior management. ♦ Planning – Planning steps that are common to all the Processes except “Controlling A Stage” and “Directing A Project”. Plans are, however, used by all the Processes. These Processes link to the Components and Techniques included in the PRINCE 2 Method to provide a comprehensive “best practice” Project Management Method. 143
Ken Bradley’s Understanding PRINCE 2 A summary chart of Processes and Sub-Processes is shown below: Parent Process Sub- Sub-Process Name Process Starting Up A Project SU1 Appointing A Project Board Executive & Project Manager (SU) SU2 Designing A Project Management Team SU3 Appointing A Project Management Team SU4 Preparing A Project Brief SU5 Defining Project Approach SU6 Planning An Initiation Stage Initiating A project IP1 Planning Quality (IP) IP2 Planning A Project IP3 Refining The Business Case and Risks IP4 Setting Up Project Controls IP5 Setting Up Project Files IP6 Assembling A Project Initiation Document Directing A Project DP1 Authorising Initiation (DP) DP2 Authorising A Project DP3 Authorising A Stage Or Exception Plan DP4 Giving Ad-Hoc Direction DP5 Confirming Project Closure Controlling A Stage CS1 Authorising A Work Package (CS) CS2 Assessing Progress CS3 Capturing Project Issues CS4 Examining Project Issues CS5 Reviewing Stage Status CS6 Reporting Highlights CS7 Taking Corrective Action CS8 Escalating Project Issues CS9 Receiving A Completed Work Package Managing Product MP1 Accepting A Work Package Delivery MP2 Executing A Work Package (MP) MP3 Delivering A Work Package Managing Stage SB1 Planning A Stage Boundaries SB2 Updating A Project Plan (SB) SB3 Updating A Project Business Case SB4 Updating The Risk Log SB5 Reporting Stage End SB6 Producing An Exception Plan Closing A Project CP1 Decommissioning A Project (CP) CP2 Identifying Follow-on Actions CP3 Project Evaluation Review 144
Ken Bradley’s Understanding PRINCE 2 Planning PL1 Designing A Plan (PL) PL2 Identifying, Defining And Analysing Products PL3 Identifying Activities And Dependencies PL4 Estimating PL5 Scheduling PL6 Analysing Risks PL7 Completing A Plan Structure of the Individual Process Models Each of the major Processes and Processes is described by reference to a common formula: The Fundamental Principles ♦ The reason(s) for the Process; ♦ The project management aims for the Process; ♦ Why the Process is fundamental to good project management practice and, therefore, a requirement in any PRINCE 2-compliant project. This section is a good first-step to understanding the rationale for the Process and what it is trying to achieve. Context ♦ The relationship with the other Processes and external activities. A Context Diagram is provided for each Process showing the flows of information into and out of the Process. This section is particularly useful to provide a visual statement of the inputs, processes and outputs as a quick guide. Process Description ♦ An explanation of the objectives of the Process and a statement of the steps contained within it. The steps identified are in no particular order and are not intended to be comprehensive. This section contains the “meat” of the Process and provides a fair commentary on what the Process sets out to achieve, together with the means of achieving it. There is little attempt to describe how the Process is expected to work in practice, as the PRINCE 2 Method addresses mainly “What” and “Why” with a much restricted “How” confined mainly to the “Techniques” Section. 145
Ken Bradley’s Understanding PRINCE 2 Responsibilities ♦ Identification of who should be held accountable for the successful conduct of the Process, and responsible for its management. Generic responsibilities (Project Board, Project Manager etc) only are provided and implementing organisations need to look very carefully at assignment of key project activities to specified personnel. Information Needs ♦ The key information needed for the Process to function in such a way to meet its objectives. The information needs identified might take the form of Products/Deliverables, Plans, Reports, Decisions etc. This section is particularly useful in understanding the flows of information into and out of the Process. Read in conjunction with the Context Diagram, a good understanding of the complete Input/Process/Output cycle can be obtained. Key Criteria ♦ Identification of significant issues which will impact upon and affect the successful working of the Process. These criteria are generally straightforward and pose little difficulty in their understanding and implementation. They are important in that they represent the minimum standard for any PRINCE 2-compliant project. In essence, any PRINCE 2-compliant project will address all eight Processes in one form or another and each of the Processes will meet the Key Criteria stated here. Hints and Tips ♦ Guidance on the application of the Process within a PRINCE environment; the method recommends that this section be augmented by reference to specific situations encountered during the use of PRINCE on projects within the implementing organisation. The Hints and Tips contained throughout the PRINCE 2 Manual should not be viewed as an integral part of the Method but rather as helpful guidelines. Much of the PRINCE 2 Manual is given to describing the Processes using the above headings. Understanding the structure of the Processes and their objectives is fundamental to the successful use of the method. PRINCE may be likened to an organic structure which must be allowed to mature and adapt to fit changing circumstances and new knowledge within the host organisation; up-dating the Process Models and descriptions, especially with regard to the Hints and Tips section is recommended to achieve this. 146
Ken Bradley’s Understanding PRINCE 2 Scalability ♦ All PRINCE controlled projects will address all eight major Processes in some form and the key question to be posed is “How extensively should this Process be applied on this project?”. Each of the eight major Processes includes a section on “Scalability” which provides suggested approaches to scaling the major Process to reflect the size and scope of the particular project. A “Scalability” section is not included within each Process definition but the principles established in the major Process may be used to provide a suitable solution. Individual Process Summary Models On the pages that follow are summaries of the inputs and outputs for each of the Processes within the PRINCE 2 Method. The summaries also indicate the action performed on a Product within the Process. The notation is as follows: Product Created = [C] Product Updated = [U] Product Referenced and/or Reviewed = [R] The Major Process Models shown at the beginning of each section are reproduced from the PRINCE 2 Manual, with minor amendments and corrections made. 147
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 12 UNDERSTANDING THE STARTING UP A PROJECT (SU) PROCESS 149
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Starting Up A Project (SU) - Introduction This is the first Process within a PRINCE 2 managed project. A Project Mandate in the form of a memo, formal or informal request will normally trigger this Process, although there is no prescribed format. Designing a Appointing a Appointing a Project Project PB Executive Project Management Management Mandate and PM Team Team SU1 SU2 SU3 Defining Preparing a Planning an Project Project Brief Initiation Stage Approach SU4 SU5 SU6 Draft Initiation Stage Plan Project Project Project Management Team Brief Approach structure and job descriptions Project Brief Planning Assembling Authorising Quality a PID Initiation IP1 IP6 DP1 Figure 62: Starting Up A Project (SU) Process The “Starting Up a Project (SU)” Process provides a solution to the “ragged beginning” concept that bedevils many projects. Just how a project gets under way is a question often posed by managers who find that they are asked to carry out planning and preparatory work by Customers but are warned against committing any resources without authority! Quite a dilemma which PRINCE 2 seeks to bridge by the use of this Process. The Process seeks to set up the project by creating clear objectives, set up a suitable Project Management Team, identify a realistic approach to the work to be done, and planning for the next stage of the work (normally the Initiation Stage). The project formally exists at the conclusion of this Process when the Project Board will be asked to give a “go/no-go” decision on whether there is the rationale, will and business need for the proposed project. This decision will normally take place at a “Project Initiation Meeting (PIM) which marks the formal start to the project. 151
Ken Bradley’s Understanding PRINCE 2 SU1 - Appointment of a Project Board Executive and a Project Manager To get any undertaking under way, there is a need for a decision-maker (the Project Board Executive) and a planner (the Project Manager). As soon as the project is “floated” by the receipt of a Project Mandate, these two appointments must be made by Corporate Management. Between them they will arrange to set up the proposed project in an orderly and structured way by creating suitable decision-support documentation comprising The Project Brief, The Project Management Team, The Project Approach, and the Plan for the Initiation Stage. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU1 – Project Mandate Project Board Executive Designing A Project Appointing (Corporate Appointment [C] Management Team A Project Management) (SU2) Board Executive & Project Manager Project Manager Appointment [C] Designing A Project Management Team (SU2) Figure 63: SU1 Plus Inputs and Outputs The appointment of the Project Board Executive and the Project Manager will allow a number of Products to be started. Although the PRINCE 2 Manual indicates an order of precedence - design and appointment of the Project Management Team as the next step - there is no reason why the Project Manager should not immediately commence work on the Project Approach and the Project Brief. These two documents will have a major influence on the design of the Project Management Team and identification of the most appropriate individuals to make the project management actually work. In practice, the Executive needs to have a close involvement with the production of the Project Approach and the Project Brief, as these are the two prime documents which will provide the decision support information for the Project Board Members when they are asked to approve the Initiation Stage of the project. 152
Ken Bradley’s Understanding PRINCE 2 SU2 & SU3 - The Project Management Team The Project Management Team is the group of people who are responsible for the planning, management , and control of the project. It might not always be possible to appoint the whole team at this early stage but as many of the key appointments as possible should be made. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU2 – Project Mandate Project Management Team Appointing A Project Designing A (Corporate Structure [C] Management Team Project Management) (SU3) Management Team Executive & Project Manager Appointment (SU1) SU3 – Project Job Definitions [C] Assembling A PID (SU6) Appointing A Management Team Project Structure (SU2) Authorising Initiation Management (DP1) Team Project Management Team Assembling A PID (SU6) Structure [C] Authorising Initiation (DP1) Figure 64: SU2 & SU3 Plus Inputs and Outputs Part of the work in this Process will include the definition of Roles and Responsibilities for each member of the Project Management Team. A start point for these is included at Appendix C of the PRINCE 2 Manual. It is important to ensure that each member of the Project Management Team clearly understands the expectations that go with the job, and the Role Descriptions ensure that this is clearly communicated. Role Descriptions will apply to all members of the Project Management Team including the senior managers who are on the Project Board for the project. Responsibility for establishing the Project Management Team rests jointly with the Executive and Project Manager, the Executive taking the lead in identifying and appointing the Project Board Members. When the Project Management Team has been established it will accompany the other outputs of SU to be endorsed by the newly established Project Board during consideration of the Initiation Stage Plan in DP1. The source documentation will be used to assemble the Project Initiation Document in IP6 153
Ken Bradley’s Understanding PRINCE 2 SU4 - The Project Brief and Its Relationship To The Project Mandate The Project Brief will normally contain the formal Terms of Reference (objectives, scope, constraints, interfaces etc) for the Project together with an Outline Business Case, based on the information contained in the Project Mandate PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU4 – Project Mandate Project Brief [C] Defining Project Preparing A (Corporate Approach (SU5 Project Management) Brief Planning An Initiation Stage (SU6) Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks) Assembling A PID (IP6) Authorising Initiation (DP1) Risk Log [C] Planning An Initiation Stage (SU6) Planning A Project IP2 Refining The Business Case & Risks (IP3) Figure 65: SU4 Plus Inputs and Outputs The Project Brief is based on the Project Mandate which provides the “trigger” for the project. The Project Mandate may take any form from an informal request by a senior manager to a formal request to provide a proposal from a customer to a potential supplier. The Project Mandate may therefore be quite thin on information in which case the Project Brief will take a fair amount of effort to complete. On the other hand, where the Project Mandate is a comprehensive document emanating from, say, a feasibility or scoping study, there should be little to add to turn it into a suitable Project Brief. The Project Brief is used primarily in “DP1 - Authorising Initiation”, by the Project Board, to decide whether the proposed project merits the time and effort needed to produce 154
Ken Bradley’s Understanding PRINCE 2 a Project Initiation Document. It needs to address the fundamental reasons and constraints that support the proposal for the project - it is essentially a “first-cut” Project Initiation Document. The Customer’s Acceptance Criteria are contained within the Project Brief and although the Product Outline for the Project Initiation Document , included in the PRINCE 2 Manual , does not specifically mention the Acceptance Criteria within the “Composition” section, it makes sense to incorporate Acceptance Criteria within the PID as these can then be used for comparative purposes at each Management Stage review (End Stage Assessment), at Project Closure (“Decommissioning A Project (CP1)”) where Customer Acceptance is obtained, and in “Confirming Project Closure (DP5)” where the project is formally shut down. 155
Ken Bradley’s Understanding PRINCE 2 SU5 - The Project Approach: A suitable Approach to the project must be considered, discussed with the Project Board Executive Member and agreed before seeking authority to prepare a Project Initiation Document (acceptance of which by the full Project Board will signal the formal start of the project). Examples of the Approach to the project are: ♦ In-house development/construction; ♦ Out-sourcing to one or more Suppliers; ♦ Joint venture development as a partnership; ♦ Prime Contractor sourcing with multiple sub-contractors; PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU5 – Project Brief (SU4) Project Approach [C] Planning An Initiation Defining Stage (SU6) Project Risk Log (SU4) Approach Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks (IP3) Assembling A PID (IP6) Authorising Initiation (DP1) Planning (PL) Figure 66: SU5 Plus Inputs and Outputs After formal endorsement by the Project Board, the Project Approach is included in the Project Brief (and possibly also the Project Initiation Document). It provides a major contribution to planning the project - Initiating A Project (IP2). 156
Ken Bradley’s Understanding PRINCE 2 SU6 - The Initiation Stage Plan A suitable plan for the Initiation Stage must be produced to enable the Project Board to authorise the creation of a suitable Project Initiation Document (PID) to authorise the commencement of the project. Production of the PID might well consume considerable time, effort and cost and is a key document that will be used to Baseline the project. It therefore needs to be properly planned, resourced and authorised at a level appropriate to the investment being proposed. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU6 – Project Brief (SU4) Draft Initiation Stage Plan [C] Authorising Initiation Planning An (DP1) Initiation Risk Log (SU4) Stage Project Approach Risk Log [U] Authorising Initiation (SU5) (DP1) Figure 67: SU6 Plus Inputs and Outputs The Method presumes that the “Starting Up A Project (SU)” Process will be a separate “front-end” to the project and approval of the Initiation Stage Plan will provide authorisation for the first Management Stage of the project. However, for smaller, low risk, projects, the first stage might well embrace the “Starting Up A Project (SU)” and “Initiating A Project (IP)” Processes. Indeed other Processes might also come into play during the first Stage of the project - these include “Controlling A Stage (CS)”, “Managing Product Delivery (MP)”, “Managing Stage Boundaries (SB)”. Because of the involvement in the authorisation processes, the Project Board will also be in play within the “Directing A Project (DP)” Process. The “Planning (PL)” Process, the “Planning A Stage (SB1)” Process, and the Product Based Planning Technique, are all used in Planning An Initiation Stage. The planning aspects are straightforward as there is a need only to plan for a short time-scale and for a very simple series of Products and related Activities. 157
Ken Bradley’s Understanding PRINCE 2 Starting Up A Project - Summary This Process, with the next (“Initiating A Project (IP)”) is critical to the success of any PRINCE 2 project as it sets the scene, expands the often flimsy Project Mandate, and lays down the foundation for the organisational structure for the project. It will often be combined with the IP Process and others, especially where a smaller project is being addressed. If “Starting Up A Project (SU)” serves to put a brake on the understandable enthusiasm to commence development work before the basics of the project have been thought through, then it will have served its purpose. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU1 – Project Mandate Project Board Executive Designing A Project Appointing A (Corporate Appointment [C] Management Team Project Management) (SU2) Board Executive & Project Manager Project Manager Appointment [C] Designing A Project Management Team (SU2) SU2 – Project Mandate Project Management Team Appointing A Project Designing A (Corporate Structure [C] Management Team Project Management) (SU3) Management Team Executive & Project Manager Appointment (SU1) SU3 – Project Job Definitions [C] Assembling A PID (SU6) Appointing A Management Team Project Structure (SU2) Authorising Initiation Management (DP1) Team Project Management Team Assembling A PID (SU6) Structure [C] Authorising Initiation (DP1) 158
Ken Bradley’s Understanding PRINCE 2 SU4 – Project Mandate Project Brief [C] Defining Project Preparing A (Corporate Approach (SU5 Project Brief Management) Planning An Initiation Stage (SU6) Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks) Assembling A PID (IP6) Authorising Initiation (DP1) Risk Log [C] Planning An Initiation Stage (SU6) Planning A Project IP2 Refining The Business Case & Risks (IP3) SU5 – Project Brief (SU4) Project Approach [C] Planning An Initiation Defining Stage (SU6) Project Risk Log (SU4) Approach Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks (IP3) Assembling A PID (IP6) Authorising Initiation (DP1) Planning (PL) SU6 – Project Brief (SU4) Draft Initiation Stage Plan [C] Authorising Initiation Planning An (DP1) Initiation Risk Log (SU4) Stage Project Approach Risk Log [U] Authorising Initiation (SU5) (DP1) Figure 68: Summary of the “Starting Up A Project (SU) Process 159
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 13 UNDERSTANDING THE INITIATING A PROJECT (IP) PROCESS 161
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Initiating A Project (IP) - Introduction The “Initiating A Project (IP)” Process is aimed at ensuring that a firm Baseline exists for the project and that everyone involved understands what the project is seeking to achieve. In smaller projects, this Process might well be combined with the “Starting Up A Project (SU)” process but this should be considered carefully. A controlled break between “Starting Up A Project” and “Initiating A Project” is always required event though both Processes may be combined within the same Management Stage. Corporate QMS Authorising Initiation DP1 Authorised Stage Initiation Plan Refining the Planning Planning a Business Quality Project Case and Risks IP1 IP2 IP3 Setting up Setting up Assembling a Project Project Files PID Controls Project IP4 IP5 IP6 Brief Draft PID Authorising a Project DP2 Figure 69: Initiating A Project (IP) Process The Project Initiation Document The major output for this Process is a Project Initiation Document (PID), which will be used throughout the project to ensure that the work carried out and the Products/Deliverables being produced are supporting the key objectives and meet the customer’s needs. The PID will always need to address the following: ♦ to identify the benefits and risks and to evaluate proposals for managing identified areas of risk, thus confirming that an acceptable Business Case exists for the project; 163
Ken Bradley’s Understanding PRINCE 2 ♦ to provide a foundation for the project from which the Project Initiation Document can be assembled or prepared. ♦ to provide decision support information to enable the Project Board to confirm the initial (and ongoing) viability for the project; ♦ to encourage the Project Board to understand and take ownership of the project; ♦ to provide sufficient information for the Project Board to approve the whole project in principle and to commit resources, formally, for the next Management Stage; ♦ to provide a Baseline for all decision-making for the duration of the project; ♦ to initiate the project in an orderly manner, thus setting “Norms” for the remainder of the project; ♦ to monitor the progress of the project initiation process against the approved plans. An Initiation Stage is recommended to be included in any PRINCE 2 managed project; given that the minimum number of Management Stages within any PRINCE 2 project will be two, this principle ensures that there will always be at least one “planning” Stage and one “action” Stage. The PID is used as a Baseline for the project. It is assembled from Products generated in the “Starting Up A Project (SU)” Process and the “Initiating A Project (IP)” Process and when approved by the Project Board it signifies the official start of the project. The approved PID will be input to every formal review of the Project (ESAs and MSAs) to check progress against the agreed baseline. It is also used at Project Closure (“Decommissioning A Project (CP1)”) to measure the project outcome against the Acceptance Criteria; successful matching will generate a Customer Acceptance of the outcome. 164
Ken Bradley’s Understanding PRINCE 2 IP1 - Planning For Quality Quality plays an important role in any PRINCE 2 project and as such it must be considered before any major planning activity takes place. The Customer’s Quality Expectations will have been identified in the “Starting Up A Project (SU)” at the time the Project Brief was prepared. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP1 – Quality Standards Project Quality Plan [C] Planning A Project (IP2) Planning (Programme and/or Quality Corporate QMS) Setting Up Project Controls (IP4) Project Brief (SU4) Setting Up Project Files Project Approach (IP5) (SU5) Assembling A PID (IP6) Figure 70: IP1 Plus Inputs and Outputs This needs to be built upon and cross-matched with the supplier organisation’s own quality standards, usually resident in the Quality Management System (QMS). A correlation between the International Standards Organisation BS/EN/ISO 9001 standard for quality management and what is offered within the PRINCE 2 Method is provided in Appendix B of the PRINCE 2 Manual. This Appendix should be used to match the supplier organisation’s QMS to the requirements of PRINCE 2 and is especially useful where a QMS is being specified and introduced. Where an organisation-wide QMS is not already in force, management should consider introducing a specific Project QMS - having no quality strategy is not an option! Other aspects that need to be considered are the project staff’s ability to perform effective Quality Reviews and to understand the significance of the Quality Criteria that will be included in the Product Description for each Product/Deliverable. 165
Ken Bradley’s Understanding PRINCE 2 IP2 - Planning A Project Although PRINCE 2 includes a separate Process for “Planning (PL)” and includes planning as a Component and a specific Technique (Product-Based Planning), the activities associated with planning for a specific project situation come into operation within the Process concerned with the specific plan required. For example, planning the project is an activity which must be undertaken right at the start of the project and lies naturally within the “Initiating A Project (IP)” Process. Similarly, planning for each Management Stage is a function of “Managing Stage Boundaries (SB)” as the Project Manager prepares for the transition from the Current Stage to the Next Stage and prepares documentation for the Project Board to reach an informed decision. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP2 – Project Brief (SU4) Project Plan [C] Refining The Business Planning A Case & Risks (IP3) Project Risk Log (SU4) Setting Up Project Project Approach Controls (IP4) (SU5) Setting Up Project Files Project Quality Plan (IP5) (IP1) Assembling A PID (IP6) Planning A Stage (SB1) Risk Log [U] Refining The Business Case & Risks (IP3) Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1) Figure 71: IP2 Plus Inputs and Outputs The Project Manager and the rest of the Project Management Team will use the “Planning (PL)” Process and the Product Based Planning Technique to prepare the required plans within the appropriate Processes. The Process requires a demonstration of an understanding of the project in the long term. The Project Manager is not expected to be able to predict accurately to the full term of the project, but must make an intelligent stab at what the future holds and plan for contingencies. 166
Ken Bradley’s Understanding PRINCE 2 On their part, the Project Board must take a sensible and realistic view of the project, especially where the duration is extended, and view the project plan as a “soft estimate”. The Management Stage Plan (produced in “Managing Stage Boundaries (SB1)”) provides the firm, but limited, commitment of resources within the framework of the Project Plan. This approach ensures that a realistic planning horizon is always in focus (the Stage Plan) within the context of the overall Project Plan. 167
Ken Bradley’s Understanding PRINCE 2 IP3 - Refining The Business Case The Project Brief will have identified an outline Business Case for the project. This preliminary assessment will have been approved in principle by the Project Board when considering the package put forward in support of investing resources into creating a suitable Project Initiation Document to support the authorisation of the project. The outline Business Case needs to be enhanced and refined before a final decision to start the project can be made. The expected Business Benefits will need to be clearly specified and the risks associated with the project identified. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP3 – Project Brief (SU4) Risk Log [U] Setting Up Project Refining Controls (IP4) The Project Approach Business (SU5) Assembling A PID (IP6) Case & Risks Project Plan (IP2) Business Case [C] Assembling A PID (IP6) Risk Log (IP2) Project Plan [U] Assembling A PID (IP6) Figure 72: IP3 Plus Inputs and Outputs Where possible, both elements of Business Benefits and Risk will need to be measured in concert. In the case of the Business Benefits, a Costs:Benefits Analysis/Investment Appraisal should be considered. Risks can be measured in many ways; PRINCE 2 does not recommend any particular approach from the many software-based risk assessment tools that are available but there needs to be a balance between creating an effective Risk Assessment, suitable as the basis for Risk Management, and the time and effort that a comprehensive assessment is bound to consume. A simple Risk Analysis Checklist has been in use in PRINCE projects for many years and an enhanced variant of this has been included at Chapter 7. Use of the Risk Analysis Checklist is straightforward and an advantage is its visibility - it is well worth a try and usually provides acceptably accurate results. The Business Case, when approved by the Project Board will need to be reviewed and up- dated when preparing for each Management Stage Review (see “Managing Stage Boundaries (SB)”). 168
Ken Bradley’s Understanding PRINCE 2 IP4 - Setting Up Project Controls Project controls are the key to the successful management of any project. It is only possible to control a project to the level of detail in which it has been planned so the Project (and later, the Stage) plans are critical to the successful management of the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP4 – Project Quality Plan Project Plan [U] Assembling A PID (IP6) Setting Up (IP1) Project Project Controls [C] Assembling A PID (IP6) Controls Project Plan (IP2) Risk Log [U] Assembling A PID (IP6) Risk Log (IP3) Communication Plan [C] Assembling A PID (IP6) Figure 73: IP4 Plus Inputs and Outputs This Process is concerned with the identification of the most appropriate level of control for the project. For large, high-risk projects it may be expected that all the controls listed below will be appropriate. For smaller, low-risk projects it will be necessary to consider both the types of control that are appropriate and their frequency. In principle, however, all the controls listed below will be appropriate to all projects whatever their size. The management controls that will be identified and used in any PRINCE 2 project fall into two main categories: Project Board Controls ♦ Project Initiation Meeting & Project Initiation; ♦ Management Stages - End Stage Assessment; ♦ Exception Reporting & Management - Mid Stage Assessment; ♦ Tolerance – Time & Costs; ♦ Highlight Reporting (from the Project Manager to Project Board Members). ♦ Business Case Re-evaluation (Business Benefits) 169
Ken Bradley’s Understanding PRINCE 2 ♦ Risk Analysis (+ Up-date of the Risk Log); ♦ Project Closure. Project Manager/Team Controls: ♦ Checkpoints; ♦ Quality Reviews (Informal); ♦ Quality Reviews (Formal); ♦ Day-to-Day Communication/Ad-hoc Meetings. Controls may also be appropriate at the Programme level but this will depend on the number, size and relationship of the projects that fall within the aegis of the PRINCE 2 arrangements within a particular implementing organisation. 170
Ken Bradley’s Understanding PRINCE 2 IP5 - Set Up Project Files All projects will produce documentation which must be stored in an appropriate and secure way. A fair amount of documentation will already have been produced in the “Starting Up A Project (SU)” Process and organisations implementing PRINCE 2 project management systems will wish to consider whether setting up the project filing structure would best be carried out during the SU Process. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP5 – Project Quality Plan Project Filing Structure [C] Assembling A PID (IP6) Setting Up (IP1) Project Issue Log [C] Controlling A Stage (CS) Files Project Plan (IP2) Quality Log [C] Controlling A Stage (CS) Lessons Learned Report [C] Controlling A Stage (CS) Figure 74: IP5 Inputs & Outputs The documentation which will already be in place following “Starting Up A Project (SU)” is: ♦ The Project Management Team Organisation Structure; ♦ Roles and Responsibilities for Project Management Team Members; ♦ The Project Brief; ♦ The Project Approach; ♦ The Risk Log; ♦ The Plan for the Initiation Stage; ♦ The Project Board Sign-off Approving the Initiation Stage Plan; ♦ Records of the Project Board Meeting (if appropriate). 171
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 suggests a filing structure but does not require an electronic format, a physical file or both. Perhaps the best approach is to have both electronic and physical file structures sharing a common structure. This will enable Project Managers to maintain copies of documentation in a format which is permanent, structured and flexible. All files and their associated documentation, whatever their format, will need to be archived at the conclusion of the project to allow for appropriate auditing. Files Project File Stage File(s) Specialist File Quality File Organisation Organisation Configuration Items Product Descriptions Plans Plans Configuration Log Quality Checks Business Case Control Documents CI Locations Project Issues Risk Log Daily Log Off-Specifications Control Documents Correspondence Products Checklist Products Checklist Figure 75: PRINCE 2 Suggested Filing Structure 172
Ken Bradley’s Understanding PRINCE 2 IP6 - Assembling The Project Initiation Document The key document to be output from the “Initiating A Project (IP)” Process is the Project Initiation Document. (PID) This document provides a comprehensive view of the project as it is viewed from the outset of the project. The PRINCE 2 concept of “assembling” a Project Initiation Document is understandable but not necessarily realistic as there are always many additional elements that, at the point the PID is put together, are not available. To help with this, a Project Initiation Document Template should be prepared for use in all projects within the implementing organisation. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP6 – Project Approach Draft Project Initiation Document Authorising A Project Assembling (SU5) (PID) [C] (DP2) A PID Project Brief (SU4) Project Management Team Structure + Job Definitions (SU3) Project Quality Plan (IP1) Project Plan (IP2) Business Case (IP3) Risk Log (IP3) Project Controls (IP4) Communication Plan (IP4) Project Filing Structure (IP5) Figure 76: IP6 Plus Inputs and Outputs 173
Ken Bradley’s Understanding PRINCE 2 Completion of the PID will trigger the need to plan for the next Management Stage of the project. The work for this activity will be carried out in the Process “Managing Stage Boundaries (SB)” within the Sub-Process “Planning A Stage (SB1)”. The PRINCE 2 Method does not recommend that the plan for the next stage be included in the Project Initiation Document, thereby putting the emphasis on this document being concerned with the project itself. Approach to Assembling or Producing The PID Assembly of the PID is a very simple task if all the component parts are available and it can easily be performed by Project Support or the Project Manager. If this is not the case, the use of the PID Template will make the task much simpler and enable the work to be shared. In practice, the best approach has been found to be to hold a “PID Workshop” attended by all members of the Project Management Team (including Project Board members where they can spare the time). Typically one or two days is sufficient, provided some foundation work has been undertaken. Where this approach is taken, the Project Initiation Stage Plan should reflect the time and resources needed. 174
Ken Bradley’s Understanding PRINCE 2 Initiating A Project (IP) - Summary Successful initiation of any project is a key contributor to its eventual outcome. The time, effort and resources invested in this stage will be well worthwhile, especially if some unforeseen problem occurs during the project. The Project Board and Project Management Team will have firm ground on which to base decisions about proposed changes in direction and investment of resources. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP1 – Quality Standards Project Quality Plan [C] Planning A Project (IP2) Planning (Programme and/or Quality Corporate QMS) Setting Up Project Controls (IP4) Project Brief (SU4) Setting Up Project Files Project Approach (IP5) (SU5) Assembling A PID (IP6) IP2 – Project Brief (SU4) Project Plan [C] Refining The Business Planning A Case & Risks (IP3) Project Risk Log (SU4) Setting Up Project Project Approach Controls (IP4) (SU5) Setting Up Project Files Project Quality Plan (IP5) (IP1) Assembling A PID (IP6) Planning A Stage (SB1) Risk Log [U] Refining The Business Case & Risks (IP3) Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1) IP3 – Project Brief (SU4) Risk Log [U] Setting Up Project Refining Controls (IP4) The Project Approach Business (SU5) Assembling A PID (IP6) Case & Risks Project Plan (IP2) Business Case [C] Assembling A PID (IP6) Risk Log (IP2) Project Plan [U] Assembling A PID (IP6) 175
Ken Bradley’s Understanding PRINCE 2 IP4 – Project Quality Plan Project Plan [U] Assembling A PID (IP6) Setting Up (IP1) Project Project Controls [C] Assembling A PID (IP6) Controls Project Plan (IP2) Risk Log [U] Assembling A PID (IP6) Risk Log (IP3) Communication Plan [C] Assembling A PID (IP6) IP5 – Project Quality Plan Project Filing Structure [C] Assembling A PID (IP6) Setting Up (IP1) Project Issue Log [C] Controlling A Stage (CS) Files Project Plan (IP2) Quality Log [C] Controlling A Stage (CS) Lessons Learned Report [C] Controlling A Stage (CS) IP6 – Project Approach Draft Project Initiation Document Authorising A Project Assembling (SU5) (PID) [C] (DP2) A PID Project Brief (SU4) Project Management Team Structure + Job Definitions (SU3) Project Quality Plan (IP1) Project Plan (IP2) Business Case (IP3) Risk Log (IP3) Project Controls (IP4) Communication Plan (IP4) Project Filing Structure (IP5) Figure 77: Summary Of The Initiating A Project (IP) Process Another major, but intangible output from this Process is the understanding that individuals within the Project management Team (including the Project Board Members) will gain about the nature, scope and possible pitfalls that the project may have to face. 176
Ken Bradley’s Understanding PRINCE 2 The inclusion of an Initiation Stage in any PRINCE 2 controlled project is not optional - the method is very clear that an Initiation Stage be included whatever the type, scope or size of the project. The PID itself will be used to provide a baseline for the project throughout its life and beyond, extending to the completion of a Post-Project Review sometime after the project is closed down (typically some 6-9 months after the Product from the project has been handed over to the customer). When the PID has been completed and assembled, it is ready to be reviewed by the Project Board within the “Directing A Project (DP2)“ Process. The vehicle for this is an End Stage Assessment (at the completion of the mandatory Initiation Stage). Acceptance of the PID and approval by the Project Board signals the formal start of the project. 177
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 14 UNDERSTANDING THE DIRECTING A PROJECT (DP) PROCESS 179
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Directing A Project (DP) - Introduction Directing A Project (DP) operates throughout all stages of the project, from the end of Project Start-up through to Project Closure and is the primary concern of the Project Board. They achieve this by managing by exception, monitoring through reports provided primarily by the Project Manager, and controlling through a series of key decision points. Project Start-up Information from external sources Mobilisation of support Notification services Approved PID Exception Report Follow-on Action Recommendations Lessons Learned Report Post Implementation Review Plan Project Closure Notification Authorising Giving Confirming Authorising Authorising a Stage or Ad hoc Project Initiation a Project Exception Direction Closure Plan DP1 DP2 DP3 DP4 DP5 Highlight Report Authorisation Authorisation Exception Reports End Project Report to proceed to proceed Requests for advice Project Closure Request For Recommendation Exception Plan Draft Post Implementation Authorisation Review Plan to proceed PID Follow-on Action Project Brief Exception Plan Recommendations Draft Initiation Stage Plan End Stage Report Lessons Learned Report Job Definitions Draft Next Stage Plan Operational and Project Management Team PID Project Team changes maintenance confirmation structure Updated Project Plan PID Project Approach Updated Business Case Updated Risk Log Managing Starting up Initiating a Controlling Closing a Stage a Project Project a Stage Project Boundaries SU IP CS SB CP Figure 78: Directing A Project (DP) Process The key Processes break into the following areas: ♦ Control of the Initiation of the project ensuring it has the best possible start; ♦ Authorisation of the Project, committing the organisation to its successful outcome; ♦ Authorising Continuation of the project where a significant departure from the approved plans has occurred; ♦ Control of the Stage Boundaries, committing new and additional resources as the project progresses towards its ultimate aim; 181
Ken Bradley’s Understanding PRINCE 2 ♦ Ad-hoc Decision-making and Direction, monitoring progress and providing advice and guidance as necessary; ♦ When the project has achieved its outcome, or is no longer considered to be a viable business proposition, arranging for Project Closure, bringing the whole undertaking to a controlled finish. This Process does not cover the day-to-day activities of managing the project - these rest with the Project Manager. The Process is positioned at the level of management residing above the Project Manager. Information will be presented to the Project Board in a number of ways, from formal report documents such as the Project Initiation Document (PID) through Highlight Reports, usually prepared on a monthly basis, to requests for ad-hoc direction by the Project Manager where a gentle “touch on the tiller” is required and senior management support is recommended. The Process is one of the busiest within the Process Model in terms of potential and actual inputs and outputs and the physical interpretation of how to direct a project may be expected to add further reports and directives. A key requirement within this Process is having senior managers on the Project Board who have the organisational authority to commit the resources that will be needed to see the project through to a successful conclusion. The ability to make decisions on commitment of additional resources in the event of problems and the vision to see the wider picture are also vital ingredients resident within this Process. Management By Exception A guiding principle at this level should always be the ability for senior managers to adopt a “hands-off” approach and to become involved with the project only at those points in time when their input is needed and to adopt a Management by Exception approach. Essentially this approach requires Project Board members to view the project strategically and to become involved only at planned review dates and at unscheduled meeting called only because the project has significantly departed from the approved plan. This is measured by a control known as “Tolerance” - essentially the scope a Project Manager has to depart from an approved Stage Plan without needing to report the departure to the Project Board. A forecast that the current Stage will not be able to complete within Tolerance (standard Tolerance of Time and Cost) will result in an Exception Report being prepared by the Project Manager for consideration by the Project Board members. An Exception Plan will often follow, this being produced by the Project Manager, which will be considered by the Project Board at a specially convened Mid-Stage Assessment. 182
Ken Bradley’s Understanding PRINCE 2 DP1 – Authorising Initiation The work carried out in the “Starting Up A Project (SU)” Process is designed to put together enough information for the Project Board to make a “go/no-go” decision on whether to invest the necessary resources into the creation of a Project Initiation Document (PID). The Project Board will be presented with a set of decision support documentation and asked to approve the project in principle. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP1 – Project Authorisation To Proceed [C] Initiating A Project (IP) Authorising Management Team Initiation Structure (SU3) Stage Plan [U] Job Definitions (SU3) Project Brief (SU) Project Brief [U] Risk Log (SU) Risk Log [R] Project Approach (SU5) Draft Initiation Project Management Team Stage Plan (SU6) Structure [R] Project Approach [U] Project Start-up Notification [C] Corporate or Programme Management Figure 79: DP1 Plus Inputs and Outputs The project formally starts when this approval is gained (not when the Project Initiation Document has been prepared and approved). For low risk, smaller, projects a formal meeting of the Project Board may not be necessary and approval may be given directly by the Executive member (having responsibility for the overall business objectives). 183
Ken Bradley’s Understanding PRINCE 2 DP2 – Authorising A Project Following the creation of the Draft Project Initiation Document (PID) in “Initiating A Project (IP)” the project can be approved formally by the Project Board and the PID “frozen”. The point of doing this is to establish a baseline against which to judge the project as it proceeds towards its conclusion and to measure against the final out-turn although certain parts of the PID are reviewed and modified at the end of each Management Stage; these are the Project Plan, the Business Case and the Risk Log. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP2 – Draft Project Authorisation To Proceed [C] Authorising Work Authorising Initiation Document Package (CS1) A Project (IP6) Approved Project Initiation Corporate or Next Stage Plan Document [U] Programme (SB1) Management Figure 80: DP2 Plus Inputs and Outputs The above diagram shows how both the Draft Project Initiation Document and the plans for the next Management Stage are input to this Process as decision support documentation. Note that the plans for the next Management Stage are not included as part of the PID but are prepared within a separate Process (“Managing Stage Boundaries (SB1)”) and accompany the PID as a separate document (the End Stage Report). Approval of the draft PID and the next Management Stage plans commits the resources and triggers commencement of work, providing authorisation for the Project Manager to begin using the resources in the plans. A copy of the approved PID is lodged in the Project File and Corporate Management is notified of the existence of the project by dispatch of a notification, or copy of the PID whatever is most appropriate. 184
Ken Bradley’s Understanding PRINCE 2 DP3 – Authorising A Stage Or Exception Plan As it proceeds, the project will be reviewed by the Project Board at the conclusion of each Management Stage. Essentially the Project Board will be looking for evidence that the Management Stage has been completed to budget, on time and meeting the requirements of the Product Descriptions. This will be formally undertaken at an End Stage Assessment (ESA) and an approval will be sought for the project to continue and the next Management Stage plans approved and resources committed. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP3 – Next Stage Plan Authorisation To Proceed [C] Controlling A Stage (CS) Authorising (SB5) A Stage or Tolerances [C] Controlling A Stage (CS) Exception Project Plan Management Team Business Case [U] Controlling A Stage (CS) Changes (SB5) Project Plan [U] Controlling A Stage (CS) Product Checklist (SB5) Progress Information [C] Corporate or Programme Business Case Management and other (SB5) interested parties. Risk Log (SB5) End-Stage Report (SB5) Request for Authorisation To Proceed (SB5) Exception Plan (SB6) Project Initiation Document (IP6) Project Tolerances (Corporate or Programme Management) Figure 81: DP3 Plus Inputs and Outputs 185
Ken Bradley’s Understanding PRINCE 2 A number of products and documentation are needed for the Project Board to properly carry out this responsibility and these are all created and/or updated within the “Managing Stage Boundaries (SB)” Process. Logs and on-going reports will be retrieved from the appropriate file and input to the Project Board either before or at the Project Board meeting. Care should be taken not to swamp the Project Board with too much paper or unimportant information. Approval of Exception Plans This Process is used also for approving Exception Plans. An exception occurs when a significant deviation from an approved plan occurs; a “significant deviation” is measured by whether Tolerance is exceeded and may occur as a result of a technical or quality problem within the project or a suggested change to one or more Products. The procedure is for an Exception Report to be raised by the Project Manager, alerting the Project Board members of the perceived problem. The Exception Report provides a statement of the problem, an analysis of its impact, the options available for recovery and a firm recommendation for recovery. The Exception Report is considered by the Project Board and a decision taken on whether the project may continue without any further action, or whether the remainder of the Management Stage needs to be re-planned to reflect the problem or required change. If the Project Board decide that the situation is serious enough to warrant it, an Exception Plan is produced by the Project Manager. The Exception Plan will be considered by the Project Board at a Mid Stage Assessment and after its approval, substitutes the plan it replaces. 186
Ken Bradley’s Understanding PRINCE 2 Problem … Forecast to Exceed Tolerance Premature Termination of Project CS8 1: Exception Report Escalating DP4 Project Issues 2A: Direction Giving Ad-Hoc Advice 2B: Request for 3: Trigger - (Copy of Exception Plan Exception Report) CS1 - DP3 Authorising A Authorising A Stage or Work Package Exception Plan 5: Authorisation SB6 To Proceed Mid-Stage Producing An Assessment Exception Plan 4: Exception Plan Figure 82: Exception Reporting and Planning Figure 76 summarises the procedure for notifying the Project Board of a significant departure from plan (via the Exception Report) and subsequently the creation of the Exception Plan. Also shown on the above diagram is the Project Board’s option to terminate the project prematurely if they do not wish to continue with the undertaking following a major change in the approved plans (although this decision might have been taken earlier, when the exception was first reported and considered in the Process “Giving Ad-Hoc Direction (DP4)”. Where the cancellation option is preferred, the premature closedown of the project will be handled within the “Closing A Project (CP)” Process. 187
Ken Bradley’s Understanding PRINCE 2 DP4 – Giving Ad-Hoc Direction This Process is the most powerful of all the Processes in that it includes provision to terminate the project prematurely if the Project Board are unhappy about the progress being made or if a significant departure from the approved plans occurs. The Process is also concerned with giving advice to the Project Manager and other staff employed on the project as and when it is needed and requested. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP4 – Information from & Exception Plan Request [C] Producing An Exception Giving Ad- to External Sources Plan (SB6) Hoc (Corporate or Direction Programme Premature Close [C] De-Commissioning A Management) Project (CP1) Highlight Reports (CS6) Response to External Sources Corporate & Programme Requests for (Corporate & Programme Management Advice (CS7) Management) Exception Report (CS8) Response to Requests for Advice Project Manager Communication Plan (IP4) Figure 83: DP4 Plus Inputs and Outputs Highlight Reports, prepared by the Project Manager (usually monthly, but at the frequency required by the Project Board) will provide much of the everyday input for the Project Board’s advice, comments and direction. Information coming into the project from external sources will also be filtered by the Project Board and acted upon, usually by providing direction to the Project Manager. 188
Ken Bradley’s Understanding PRINCE 2 DP5 – Confirming Project Closure The responsibilities of this sub-process will usually (but not necessarily) be exercised through the holding of a Project Closure Meeting where the project will be shut down in an orderly and structured way. The information needed for the Project Board to shut down the project will be produced in “Closing A Project (CP)” Process and will include Customer Sign-off and identification of any follow up actions. The approval of a plan for performing a Post-Project Review (usually some 9-12 months after the closedown of the project will also be considered during this final Process. A fuller summary of the inputs and outputs to DP5 is shown in the following diagram: DP5 – Operational & Project Closure Notification [U] Corporate or Confirming Maintenance (Approved) Programme Project Acceptance (CP1) Management Closure Customer Follow0on Action Corporate or Acceptance (CP1) Recommendations [U] (Approved) Programme Management Project Closure Recommendation Post-Project Review Plan [U] Corporate or (CP1) (Approved) Programme Management Post-Project Review Plan (CP2) Lessons Learned Report [U] Corporate or (Approved) Programme Follow-on Action Management Recommendations (CP2) Lessons Learned Report (CP3) End Project Report (CP3) Baselined Project Initiation Document (DP2) Figure 84: DP5 Plus Inputs and Outputs 189
Ken Bradley’s Understanding PRINCE 2 Specifically, the Project Board will wish to satisfy themselves that the project has a clearly defined end and that an orderly hand-over to operational use has been effected. The Project Board will look to the Senior User for confirmation that an acceptable End-Product is in existence and that it can be supported in an operational environment. A close liaison with the Project Board members will need to be maintained throughout the Project Manager’s preparation for this very important Process, ensuring that there are no surprises awaiting the members at the closure meeting. 190
Ken Bradley’s Understanding PRINCE 2 Summary of the DP Process It is within the “Directing A Project (DP)” Process that every authorisation takes place. The Process is extremely important to the successful outcome of the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP1 – Project Authorisation To Proceed [C] Initiating A Project (IP) Authorising Management Team Initiation Structure (SU3) Stage Plan [U] Job Definitions (SU3) Project Brief (SU) Project Brief [U] Risk Log (SU) Risk Log [R] Project Approach (SU5) Draft Initiation Project Management Team Stage Plan (SU6) Structure [R] Project Approach [U] Project Start-up Notification [C] Corporate or Programme Management DP2 – Draft Project Authorisation To Proceed [C] Authorising Work Authorising Initiation Document Package (CS1) A Project (IP6) Approved Project Initiation Corporate or Next Stage Plan Document [U] Programme (SB1) Management 191
Ken Bradley’s Understanding PRINCE 2 DP3 – Next Stage Plan Authorisation To Proceed [C] Controlling A Stage (CS) Authorising (SB5) A Stage or Tolerances [C] Controlling A Stage (CS) Exception Project Plan Management Team Business Case [U] Controlling A Stage (CS) Changes (SB5) Project Plan [U] Controlling A Stage (CS) Product Checklist (SB5) Progress Information [C] Corporate or Programme Business Case Management and other (SB5) interested parties. Risk Log (SB5) End-Stage Report (SB5) Request for Authorisation To Proceed (SB5) Exception Plan (SB6) Project Initiation Document (IP6) Project Tolerances (Corporate or Programme Management) DP4 – Information from & Exception Plan Request [C] Producing An Exception Giving Ad- to External Sources Plan (SB6) Hoc (Corporate or Direction Programme Premature Close [C] De-Commissioning A Management) Project (CP1) Highlight Reports (CS6) Response to External Sources Corporate & Programme Requests for (Corporate & Programme Management Advice (CS7) Management) Exception Report (CS8) Response to Requests for Advice Project Manager Communication Plan (IP4) 192
Ken Bradley’s Understanding PRINCE 2 DP5 – Operational & Project Closure Notification [U] Corporate or Confirming Maintenance (Approved) Programme Project Acceptance (CP1) Management Closure Customer Follow0on Action Corporate or Acceptance (CP1) Recommendations [U] (Approved) Programme Management Project Closure Recommendation Post-Project Review Plan [U] Corporate or (CP1) (Approved) Programme Management Post-Project Review Plan (CP2) Lessons Learned Report [U] Corporate or (Approved) Programme Follow-on Action Management Recommendations (CP2) Lessons Learned Report (CP3) End Project Report (CP3) Baselined Project Initiation Document (DP2) Figure 85: Summary of the Directing A Project (DP) Process 193
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 15 UNDERSTANDING THE CONTROLLING A STAGE PROCESS 195
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Controlling A Stage (CS) - Introduction Following the Project Board’s decision to approve a Stage, the Project Management Team must be fully focused on delivery of the Products, to their stated Quality Criteria, within the approved time-scales and budget, within the stated Tolerances. Managing Closing a Product Project Work Package Delivery CP MP Project End Checkpoint Report Completed Notification Quality Log Work Package Receiving Taking Authorising Assessing Completed Corrective Work Package Progress Work Action Package CS7 CS1 CS2 CS9 Examining Project Issues CS4 Escalating Risk Log Project Issues Business Case CS8 Reviewing Reporting Capturing Stage Status Highlights Project Issues Exception Report CS5 CS6 CS3 Issue Log Authorisation to proceed New Project Stage Plan Stage/Exception Issues Plan Managing Directing a Highlight Copy of Exception Report Stage Project Report Boundaries DP SB Figure 86: Controlling A Stage (CS) Process This Process forms the main part of the Project Manager’s effort on the management of the project, and provides the direction for the day-to-day management of the Stage and the overall project. All through the Stage there will be an on-going cycle of: ♦ authorising Packages of Work that must be completed during the Management Stage and receiving Completed Work Packages (or Products) back into the host organisation; ♦ gathering Progress Information about the work carried out and the resources and effort expended; 197
Ken Bradley’s Understanding PRINCE 2 ♦ watching for Changes to the approved plan; managing any changes raised formally against the project (Project Issues) and making decisions on the introduction of beneficial changes provided these do not result in the Stage Plans exceeding the Tolerance; ♦ reviewing situations for Stage and Project Impact; ♦ reporting to the Project Board and to other members of the Project Management Team; ♦ approving and initiating any Corrective Action. It may be expected that for much of the time events during a Management Stage will follow a regular and predictable pattern. However, personal qualities and project management abilities need to combine to address situations which are not going according to plan and it is then that the Project Manager must use knowledge, political and people skills to bring things back on course. 198
Ken Bradley’s Understanding PRINCE 2 CS1 – Authorising A Work Package Work is released to Team Managers or directly to staff working on the project via the issue of authorised Work Packages. The format for these might be a formal contract, where the Products are being produced by a Supplier external to the host organisation, or much less formal (for example by internal memorandum or discussion) where the provider is employed within the host organisation. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS1 – Stage or Exception Plan Adjustments [C] Assessing Progress Authorising Plan (DP3) (CS2) Work Package Authorisation To Proceed (DP3) Proposed Work Package (CS5) Work Package [C] Accepting A Work Package (MP1) Work Trigger (CS7 Product Descriptions (PL2) Figure 87: CS1 Plus Inputs and Outputs The Project Manager is responsible for the preparation, release and agreement of Work Packages; authority for this responsibility stems from the Project Board’s approval of the relevant Management Stage Plan and for this reason Management Stage Plans (produced in the “Managing Stage Boundaries (SB)” Process) must be sufficiently detailed for the Project Board to understand to what they are committing. Changes necessary as the Management Stage progresses must be reflected in the work being carried out on the relevant Work Packages – this demands a close association between the Project Manager and the Team Manager(s) responsible for producing the Product(s). Where a formal contract is in existence, care must be taken not to upset the contract arrangements by demands for trivial changes. This Process provides the Project Manager with the main vehicle for release of work and is a major control on a day to day basis. 199
Ken Bradley’s Understanding PRINCE 2 CS2 – Assessing Progress The Project Manager must keep track on how well the Management Stage, and the Project, is performing against the plan approved by the Project Board at the last End Stage Assessment. This Process provides the mechanics for capturing “Actuals” and passing the information forward to “Reviewing Stage Status (CS5)” where the Project Manager can take stock of progress so far. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS2 – Checkpoint Reports Up-dated Stage Plan [U] Examining Project Assessing (MP2) Issues (CS4) Progress Quality Log (MP2) Reviewing Stage Status (CS5) Plan Adjustments (CS1) Stage Plan (CS5) Work Package Status (CS9) Figure 88: CS2 Plus Inputs and Outputs The information needed to update the approved Management Stage Plan comes from three major sources: ♦ Checkpoint Reports (created within the “Managing Product Delivery (MP2)” Process); ♦ Timesheets (where these are in use within the host organisation – otherwise an assessment by the Project Manager of effort expended and financial liability incurred); ♦ Project Issues – especially where errors or departures from the agreed requirement have been identified. This Process is best carried out by Project Support, where appointed, with a presentation of the plans, updated to show “actuals”, to the Project Manager for overall assessment on at least a weekly basis. Use of a suitable software planning tool (such as MS Project, Project Manager Workbench, Primavera etc) will simplify this Process especially if standard “actuals” 200
Ken Bradley’s Understanding PRINCE 2 reporting forms generated within the package are fully utilised. The output from CS2 goes towards the Project Manager’s review of how well the Management Stage is progressing when measured against the Management Stage plan approved by the Project Board at the previous End Stage Assessment. 201
Ken Bradley’s Understanding PRINCE 2 CS3 - Capturing Project Issues As the project progresses there will be a need to capture and decide upon changes that occur. All changes within a PRINCE 2 project are treated as types of Project Issue. These include errors found in signed-off Products, departures from the agreed Specification, ideas and suggestions people have for improving the project’s outputs, resource changes that need to be reflected in the project and stage plans. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS3 – Issue Log (Quality Up-dated Issue Log [U] Examining Project Capturing File) Issues (CS4)) Project Issues New Project Issues (Any Project Source) Figure 89: CS3 Plus Inputs and Outputs A Project issue can be raised by anyone associated with the project. Typically organisations will have their own existing change control arrangements and these should be adopted where they are performing satisfactorily. The first job on receipt of a Project Issue is to record it on the Issue Log - this will normally be a function of Project Support or the Configuration Librarian where appointed. The Issue can then be passed to “CS4 - Examining Project Issues”. The types of Project Issue are: ♦ Request For Change - causing a change to the Customer’s Specification or Acceptance Criteria; usually paid for by the Customer. ♦ Off-Specification causing errors or omissions in work already completed or planned; usually paid for by the Supplier. ♦ Other Changes such as modification to the Project Management Team. More information can be found in the Chapter on Understanding The Change Control Component and Technique. 202
Ken Bradley’s Understanding PRINCE 2 CS4 - Examining Project Issues This Process enables each Project Issue to be examined and its impact assessed; this should be carried out as soon as possible after receipt and logging of the Project Issue. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS4 – Business Case Issue Log [U] Reviewing Stage Status Evaluating (SB3) (CS5) Project Issues Stage Plan (CS2) Risk Log [U] Reviewing Stage Status (CS5) Issue Log (CS3) Issue Log [U] Reporting Highlights Risk Log (SB4) (CS6) Project Plan (SB2) Figure 90: CS4 Plus Inputs and Outputs The examination and evaluation of Project Issues may take place via a regular meeting or by circulation of the Issue and comments to those involved. Whatever route is chosen, progress needs to be recorded in the Issues Log. Project Issues should always be examined from a Customer, Supplier and Business perspective; any action needed which would take the Management Stage over the agreed Tolerance must be referred to the Project Board in the form of an Exception Report (see “Escalating Project Issues (CS8))”. Responsibility for examining Project Issues rests with the Project Manager who will use the support services of Team Managers in helping arrive at an appropriate decision. The Senior User member of the Project Board will prioritise and if necessary canvas the Project Board for any additional resources needed to clear outstanding Project Issues. Prioritisation of outstanding Project issues is usually done by referring to the Issues Log at each End Stage Assessment. 203
Ken Bradley’s Understanding PRINCE 2 CS5 - Reviewing Stage Status This Process provides for a regular check of how the Management Stage is performing against its approved plan. The intention is to allow the Project Manager to stand back from the day to day problem solving activities and take stock, prior to reporting the situation to the Project Board. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS5 – Stage Plan (CS2) Notification of Project End [C] De-Commissioning A Reviewing Project (CP1) Stage Issue Log (CS4) Status Work Trigger(s) [C] Authorising Work Risk Log (CS4) Package (CS1) Tolerances (DP3) Stage Status Information [C] Reporting Highlights (CS6) Business Case (DP3) Plan Deviation [C] Taking Corrective Action (CS7) Project Plan (DP3) Stage Plan [U] Escalating Project Issues (CS8) Planning A Stage (SB1) Project Issue [R] Escalating Project issues (CS8) Stage End Notification [C] Planning A Stage (SB1) Figure 91: CS5 Plus Inputs and Outputs The key driver for assessing Management Stage status is the “Assessing Progress (CS2)” Process which captures information from Checkpoint Reports and Timesheets and updates the approved plans with “actuals”. Inputs will also be needed from the Issues Log where modifications to the Management Stage plans may be brewing following the discovery of errors and omissions or ideas for improvement., and the Risk Log which will enable the Project Manager to review emerging risks identified at the outset of the Management Stage. The overall outcome of the Process is to ensure on a regular basis (recommended weekly at the minimum) that the Management Stage remains within Tolerance and that nothing untoward is likely to occur without warning. Information and knowledge gleaned from this Process will feed the creation of the Highlight Report for the Project Board. 204
Ken Bradley’s Understanding PRINCE 2 CS6 - Reporting Highlights Having approved a Management Stage Plan, the Project Board will need to be kept informed of the progress being made towards the successful conclusion of the stage. Reporting Highlights to the Project Board will be a regular, time-related activity, typically every month but specifically at the frequency required by the Project Board. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS6 – Communication Highlight Reports [C] Giving Ad-Hoc Direction Reporting Plan (Project (DP4) Highlights File/PID) Stage Plan (CS5) Checkpoint Reports Communications To Interested Corporate or (CS5) Parties [C] Programme Management Issue Log (CS5) Risk Log (CS5) Tolerances (CS5) Plan Revisions (CS5) Figure 92: CS6 Plus Inputs and Outputs The objective of the Highlight Report is to provide summary information to the Project Board - one sheet of paper (or its equivalent) is all that is needed. The steps taken in performing this Process are: Assemble information from Checkpoint Reports and Project Issues received during the previous period since the last Highlight Report ♦ Identify any new or potential problem arising from “Reviewing Stage Status (CS5)” ♦ Identify any significant revisions to the approved plan from “Taking Corrective Action (CS7)” ♦ Create the Highlight Report (Project Support might well produce the first draft) 205
Ken Bradley’s Understanding PRINCE 2 ♦ Distribute the Highlight Report to Project Board members and any other agreed recipients. The Highlight Report does not normally require a meeting of the Project Board although this is an option for high-profile, high-risk projects where the Project Board are particularly sensitive about the progress that is being made. 206
Ken Bradley’s Understanding PRINCE 2 CS7 - Taking Corrective Action In even the best managed projects, departures from the planned course of action will occur and remedial action must be taken to bring the work back into line. This Process enables the Project Manager to make small adjustments, within the agreed Tolerance, to the work being carried out. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS7 – Stage Plan (CS5) Work Trigger [C] Authorising Work Taking Package (CS1) Corrective Issue Log (CS5) Action Up-dated Stage Plan [U] Reporting Highlights Plan Deviation (CS6) (CS5) Request For Advice [C] Giving Ad-Hoc Direction Risk Log (CS5) (DP4) Figure 93: CS7 Plus Inputs and Outputs The main driver for the Process comes from “CS5 - Reviewing Stage Status” where deviations from the required and planned outcome will start to become apparent. Projects seldom change course dramatically but rather significant slippage is prompted by many smaller incidents and this Process aims to treat each incident as it occurs. Additional Work Packages may be identified in this Process. Advice and guidance may well need to be sought from Project Board members and this will usually be informal. The results of this Process will need to be considered for reporting to the Project Board by inclusion on the next Highlight Report but this should be the exception rather than the rule. The Project Manager is responsible for the operation of this Process helped by the Project Management Team. Project Managers should always be aware of the build-up of apparently minor problems being symptomatic of bigger trouble with the project. 207
Ken Bradley’s Understanding PRINCE 2 CS8 - Escalating Project Issues As soon as it is forecast that a Management Stage (or the Project) is likely to go outside the Tolerance the Project Manager must notify the Project Board by raising an Exception Report. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS8 – Business Case Exception Report [C] (+ Response Giving Ad-Hoc Direction Escalating (CS5) back from Project Board) (DP4) Project Issues Issue Log (CS5) Producing An Exception Plan (SB6) Project Plan (CS5) Project Board Response [R] Producing An Exception Stage Plan (CS5) Plan (SB6) Risk Log (CS5) Stage Plan [R] Producing An Exception Project Initiation Plan (SB6) Document (IP6) Figure 94: CS8 Plus Inputs and Outputs Although many things may contribute to or trigger this Process the most common situation is where a Project Issue has been raised to record an error or deficiency with one or more Products. The steps to be taken in this Process are: ♦ Identify the problem and carry out an Impact Analysis ♦ Identify and Evaluate options for recovery ♦ Select a recommended direction ♦ Document the problem, reasons, impact, options and recommendations in an Exception Report for the Project Board ♦ Await the Project Board’s response The expected outcome will be a request to produce an Exception Plan which will replace the plan that has gone into exception. The Project Board’s views and advice should always be sought before producing an Exception Plan and the effect on the overall Project Plan (including the Business Case and Risks) must always be evaluated. 208
Ken Bradley’s Understanding PRINCE 2 CS9 - Receiving A Completed Work Package This Process records the successful completion of a Work Package (or Product) and delivery of it back into the host organisation. It is closely associated with “Authorising A Work Package (CS1)” discussed earlier. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS9 – Approved Work Work Package Status [C] Assessing Progress Receiving Package (MP3) (CS2) Completed Work Package Figure 95: CS9 Plus Inputs and Outputs The arrangements for delivering the Completed Work Package will have been agreed when the Work Package was accepted by the Supplier, Team Manager or person responsible for its production in the Process “Accepting A Work Package (MP1)”. Completed Work Packages or Products delivered into the host organisation will all have been Quality Reviewed (in Process “Executing A Work Package (MP2)”) in accordance with the requirements agreed when the Work Package was accepted. The results of the Process are used to assess the progress made by recording the task as complete and updating the Management Stage and project records accordingly. 209
Ken Bradley’s Understanding PRINCE 2 Summary of the Controlling A Stage Process Controlling A Stage (CS) is the main project management driver for a PRINCE 2 controlled project. The Process is owned by the Project Manager and is where most of the “day-to-day” project management activities are carried out. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS1 – Stage or Exception Plan Adjustments [C] Assessing Progress Authorising Plan (DP3) (CS2) Work Package Authorisation To Proceed (DP3) Proposed Work Package (CS5) Work Package [C] Accepting A Work Package (MP1) Work Trigger (CS7 Product Descriptions (PL2) CS2 – Checkpoint Reports Up-dated Stage Plan [U] Examining Project Assessing (MP2) Issues (CS4) Progress Quality Log (MP2) Reviewing Stage Status (CS5) Plan Adjustments (CS1) Stage Plan (CS5) Work Package Status (CS9) CS3 – Issue Log (Quality Up-dated Issue Log [U] Examining Project Capturing File) Issues (CS4)) Project Issues New Project Issues (Any Project Source) 210
Ken Bradley’s Understanding PRINCE 2 CS4 – Business Case Issue Log [U] Reviewing Stage Status Evaluating (SB3) (CS5) Project Issues Stage Plan (CS2) Risk Log [U] Reviewing Stage Status (CS5) Issue Log (CS3) Issue Log [U] Reporting Highlights Risk Log (SB4) (CS6) Project Plan (SB2) CS5 – Stage Plan (CS2) Notification of Project End [C] De-Commissioning A Reviewing Project (CP1) Stage Issue Log (CS4) Status Work Trigger(s) [C] Authorising Work Risk Log (CS4) Package (CS1) Tolerances (DP3) Stage Status Information [C] Reporting Highlights (CS6) Business Case (DP3) Plan Deviation [C] Taking Corrective Action (CS7) Project Plan (DP3) Stage Plan [U] Escalating Project Issues (CS8) Planning A Stage (SB1) Project Issue [R] Escalating Project issues (CS8) Stage End Notification [C] Planning A Stage (SB1) CS6 – Communication Highlight Reports [C] Giving Ad-Hoc Direction Reporting Plan (Project (DP4) Highlights File/PID) Stage Plan (CS5) Checkpoint Reports Communications To Interested Corporate or (CS5) Parties [C] Programme Management Issue Log (CS5) Risk Log (CS5) Tolerances (CS5) Plan Revisions (CS5) 211
Ken Bradley’s Understanding PRINCE 2 CS7 – Stage Plan (CS5) Work Trigger [C] Authorising Work Taking Package (CS1) Corrective Issue Log (CS5) Action Up-dated Stage Plan [U] Reporting Highlights Plan Deviation (CS6) (CS5) Request For Advice [C] Giving Ad-Hoc Direction Risk Log (CS5) (DP4) CS8 – Business Case Exception Report [C] (+ Response Giving Ad-Hoc Direction Escalating (CS5) back from Project Board) (DP4) Project Issues Issue Log (CS5) Producing An Exception Plan (SB6) Project Plan (CS5) Project Board Response [R] Producing An Exception Stage Plan (CS5) Plan (SB6) Risk Log (CS5) Stage Plan [R] Producing An Exception Project Initiation Plan (SB6) Document (IP6) CS9 – Approved Work Work Package Status [C] Assessing Progress Receiving Package (MP3) (CS2) Completed Work Package Figure 96: Summary of the Controlling A Stage (CS) Process 212
Ken Bradley’s Understanding PRINCE 2 Chapter 16 UNDERSTANDING THE MANAGING PRODUCT DELIVERY PROCESS 213
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Managing Product Delivery (MP) - Introduction This major Process is aimed primarily at managing the interface between the Customer Project Manager and the Supplier Project Manager ensuring that work is actually progressing in accordance with the customer’s expectations and that all the planned Products are created and delivered within the agreed time-scales and contract price or internally approved budget, and meet their approved Quality Criteria. The Process is also used for managing the delivery of Products where an external Supplier is not involved in the project and where all resources managed by the project are internal; it is also appropriate where there is a mixture of both. Work Package Authorising Accepting a Executing a Delivering a Work Package Stage Plan Work Package Work Package Work Package CS1 MP1 MP2 MP3 Checkpoint Report Work Package Quality Log Closure Stage Plan Product Sign-off Receiving Assessing Completed Progress Work Package CS2 CS9 Figure 97: Managing Product Delivery (MP) Process The Process comprises: ♦ making certain that work on Products allocated to each external Team or Team Member resource is properly Authorised; ♦ ensuring that Packages of Work are identified, discussed, agreed, authorised and accepted by those responsible for the creation of Products; ♦ checking that all Interfaces between the Customer and Supplier organisations are identified, recorded, observed and handled in an appropriate way; 215
Ken Bradley’s Understanding PRINCE 2 ♦ ensuring that all the Work is actually Carried Out, as agreed; ♦ ensuring that the Progress of Work and Forecasts of the time and effort to completion are regularly assessed; ♦ checking that all finished Products conform to their agreed Quality Criteria; ♦ obtaining Approval for completed Products. This will usually be at three levels – Producer and Reviewer level, Project Manager level, and ultimately endorsement by the Project Board at the end of each Project Stage. These levels of approval will be reflected in both the Customer and Specialist Supplier organisations, although it is not necessary that either will be working within a PRINCE environment; it is essential, however, that all involved are working within a suitably controlled project management environment. This Process will operate continuously throughout each Stage; it provides a healthy separation between the Customer Project Manager and the Supplier Project Manager and requires the interface between the Supplier(s) (be they internal or external) and the Customer to be identified, defined and operated. Care must be taken to ensure that the interfaces are neither missed nor lost, and that bureaucracy is kept to the absolute minimum consistent with effective control. Where a Project Manager allocates work directly to individuals responsible for carrying out the work package, this Process will be informal but will always exist. 216
Ken Bradley’s Understanding PRINCE 2 MP1 - Accepting A Work Package The Process provides for the establishment of agreement between the Project Manager and the Team Manager, Team or individual who will be responsible for creating and delivering the completed Work package (or Product) for the host organisation. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP1 – Work Package Risk Log [U] Up-Dating The Risk Log Accepting A (CS1) (SB4) Work Package Work Package (Authorised) [C] Executing A Work Package (MP2) Team Plan [C] Executing A Work Package (MP2) Figure 98: MP1 Plus Inputs and Outputs The interface between the Project Manager and those responsible for creating the Products of the project needs to be properly managed. This Process enables the agreement to be established before any work is commenced. The agreement/interface manifests itself in the form of a Work Package authorisation of which the key elements are: ♦ Agreement of the Objectives for the Work Package ♦ Tolerances for the Work Package ♦ The Reporting Arrangements - Timing and Content ♦ A Plan for the Work Package ♦ A Product Description specifying the Product’s content, its Quality Criteria and the Method of measuring if the Product conforms to its stated Quality Criteria. The Project Manager is responsible for delivering the Products to the Project Board as part of the Management Stage objectives; responsibility for agreement of the Work Package resides with the Project Manager and the Team Manager, where appointed (and the Project Manager where no Team Manager exists). 217
Ken Bradley’s Understanding PRINCE 2 MP2 - Executing A Work Package This Process addresses the creation of the Products of the project.It may be that the creators of the Products are not using PRINCE or any other formal project management method and where this is the case agreement of the Work Package in MP1 is even more significant. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP2 – Work Package Quality Log [U] Assessing Progress Executing A (Authorised) (MP1) (CS2) Work Package Team Plan (MP1) Checkpoint Reports [C] Assessing Progress (CS2) Completed Work Package [C] Delivering A Work Package (MP3) Team Plan [U] Stage File Figure 99: MP2 Plus Inputs and Outputs It is within this Process that “actuals” are captured, at source, to enable the effort and costs in the Management Stage Plan and the Project Plan to be updated within the “Controlling A Stage - Assessing Progress (CS2)” Process. The quality checking arrangements agreed within MP1 will be performed during this Process; the objective is to ensure that quality is integral to the Product(s) being built so that Products delivered back into the host organisation are complete and ready to be placed into the Configuration Management System as finalised Products. Indeed it might well be that the Configuration Librarian may be the first recipient of completed Work Packages or Products to log and file them before reporting the situation to the Project Manager. Checkpoint Reports are generated within MP2 at the frequency and in the format agreed in the Work Package. Checkpoint Reports are used within CS2 to update the Management Stage and Project Plans. Responsibility for all activities within this Process is vested in the Team Manager where appointed, or the Project manager where no such appointment has been made. 218
Ken Bradley’s Understanding PRINCE 2 MP3 - Delivering A Work Package Formalising the return of a completed Work Package is the focus for this Process. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP3 – Completed Work Approved Work Package [C] Receiving Completed Delivering A Package (MP2) Work Package (CS9) Work Package Figure 100: MP3 Plus Inputs and Outputs A simple but significant Process, MP3 provides for final sign-off of the Product(s), dispatch and hand-over of the Product(s) and formal notification to the Project manager of the completion of work by the Team Manager or person responsible. The arrangements for hand-over and notification should have been established in MP1 and will often be embodied into a formal contract document. Responsibility lies with the Team Manager where appointed. 219
Ken Bradley’s Understanding PRINCE 2 Summary of the Managing Product Delivery Process Managing Product Delivery is the “engine room” for the PRINCE 2 project, creating the Products required for Management Stage; it is where the bulk of the project’s time, effort and financial resources will be spent. The Process will always be present in some form although it will be less formal where no outside Supplier or sub-contractor is being used. External suppliers may not be using the PRINCE 2 Method for their project management standard and this Process may not, therefore be physically implemented or understood where this is the case. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP1 – Work Package Risk Log [U] Up-Dating The Risk Log Accepting A (CS1) (SB4) Work Package Work Package (Authorised) [C] Executing A Work Package (MP2) Team Plan [C] Executing A Work Package (MP2) MP2 – Work Package Quality Log [U] Assessing Progress Executing A (Authorised) (MP1) (CS2) Work Package Team Plan (MP1) Checkpoint Reports [C] Assessing Progress (CS2) Completed Work Package [C] Delivering A Work Package (MP3) Team Plan [U] Stage File MP3 – Completed Work Approved Work Package [C] Receiving Completed Delivering A Package (MP2) Work Package (CS9) Work Package Figure 101: Summary of the “Managing Product Delivery (MP)” Process 220
Ken Bradley’s Understanding PRINCE 2 Chapter 17 UNDERSTANDING THE MANAGING STAGE BOUNDARIES PROCESS 221
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Managing Stage Boundaries (SB) - Introduction To achieve a successful outcome to the project, it is necessary to break it into smaller, discrete packages to enable the Project Team to focus on specific Products or Deliverables; this approach provides the concept of Project Stages. By controlling the start and finish of each stage, specific attention can be given to whether the Stage Products/Deliverables have all been completed in accordance with their Quality Criteria, whether the remaining project Products/Deliverables are still required, and whether the Business Case for the project remains viable. Lessons Learned Report End Stage Report Next Stage Plan Authorising a Risk, Issue and Reporting Stage or Quality Logs Request for Authorisation to proceed Stage End Exception Project Plan, Business Case, Plan SB5 Project Brief DP3 Current Stage Plan Business Case Current PM Team Updating a Risk & Issue Log Planning A Updating a Project Stage Plans Project Plan Plans Business Project Plan SB1 SB2 Case SB3 Updated PM team Issue Plans and Risk Project Brief Logs Request For Exception Plan Issue Log + Exception Report Producing An Updating the Exception Risk Log Risk Log Plan Agreed Tolerance SB6 SB4 Current Issue Stage and Risk Project Plan Log Quality Plan Project Approach Closing a Project CP Figure 102: Managing Stage Boundaries (SB) Process The aims of the Process are: ♦ to assure the Project Board that all the Products/Deliverables planned for the current stage have been completed and meet their Quality Criteria; ♦ to provide the information on time-scale, technical achievement, and the budget needed to enable the Project Board to assess whether the overall project Business Case is still viable, and whether the Benefits can be achieved within an acceptable level of risk; 223
Ken Bradley’s Understanding PRINCE 2 ♦ to provide decision-support information on the status of the current stage and the overall project, which will enable the Project Board to reach a decision on final completion of the current stage, authorise the start of the next stage, and to endorse the overall project. ♦ to provide a vehicle for stating the Tolerance which may be allowed for the next Stage. Tolerance is a control providing cost and time “trigger-figures” beyond which the Project Manager may not progress without the approval of the Project Board. ♦ to record any information or Lessons Learned which might impact on later stages of the project, or on the organisation as a whole. The Process is an iterative one as the project proceeds from one stage to the next. Controlling the start and end of stages is a key control process for the Project Board and incorporates all the key aspects of directing a project. Exception Plans The steps of this Process may also be used when creating an Exception Plan, where a significant departure from the approved plan has occurred and Tolerance is forecast to be exceeded. In order to reach a decision on the future of the project, the Project Board will need to consider an impact analysis, options appraisal, and a recommendation for action prepared by the Project Manager; these will all need to be supported by an up-dated Business Case confirming the benefits and re-appraisal of the risks. 224
Ken Bradley’s Understanding PRINCE 2 SB1 - Planning A Stage As the project progresses the Project Board will limit their commitment and risk exposure by releasing the commitment of effort and funding via End Stage Assessments at the completion of each Management Stage. A key input to these major Project Board controls is the plan for the next Management Stage put together in SB1. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB1 – Current Stage Plan Next Stage Plan [C] Up-Dating A Project Planning A (CS5) (Stage File) Plan (SB2) Stage Stage End Notification (CS5) Project Plan [R] Up-Dating A Project Plan (SB2) Project Plan (IP2) (Project File) Project Management Team Reporting Stage End Changes [U] (SB5) Trigger For Next Stage Plan (IP2) PID (IP6) (Project Product Checklist [U] Reporting Stage End File) (SB5) Current Project Management Team (IP6) (Project File & Stage File) Figure 103: SB1 Plus Inputs and Outputs The aim of the Process is to identify all the Products (Specialist, Management and Quality) that will need to be produced during the next Management Stage and estimate the effort and cost to its completion. A number of inputs will be necessary to achieve this end (including the agreed Project Plan) to accurately position the Management Stage, and they are summarised in the above diagram. The Organisation Structure for the Project Management Team will also be reviewed during this Process, to ensure that the most appropriate resources and management team are available for the work to be undertaken. Much of the work involved in creating the Next Stage Plan will be carried out by members of the Project Management Team under the supervision of the Project Manager, who has prime responsibility for the timely production of the plan. Any individuals having responsibility for Project Assurance will need to be consulted during this Process especially in respect of the proposed management controls and quality control structure. 225
Ken Bradley’s Understanding PRINCE 2 SB2 - Updating A Project Plan Information needed for decision support at the end of each Management Stage obviously includes an updated view of the Project Plan to identify what impact work so far on the project has impacted on the final delivery date and cost. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB2 – Up- Current & Next Up-Dated Project Plan [U] Up-Dating A Project Dating A Stage Plans (SB1) Business Case (SB3) Project Plan Exception Plan Reporting Stage End (SB6) (SB5) Project Approach Up-Dating The Risk Log (IP6) (Project File) (SB4) Project Quality Plan Next Stage Plan [R] Reporting Stage End (IP6) (Project File) (SB5) or Exception Plan [R] Figure 104: SB2 Plus Inputs and Outputs The three key inputs to this Process are: ♦ the Management Stage which has just been completed (the Current Stage Plan) ♦ the Next Management Stage Plan created in SB1 ♦ the approved Project Plan Actual schedule, effort and cost information is extracted from the Current Stage Plan and any changes proposed in the Next Stage Plan are used to present an up-to-date view of the likely final out-turn for the project. Other inputs are also available to this Process from a number of sources; the main objective is to present a comprehensive view of what the Project Board is being asked to commit to, long term, at the approaching End Stage Assessment. Any significant changes in the Project Plan brought about by this Process should be included in the End Stage Report produced by the Project Manager for the Project Board. 226
Ken Bradley’s Understanding PRINCE 2 SB3 - Updating A Project Business Case The Business Case is the main driving force behind any PRINCE 2 controlled and this must be kept up to date and reviewed at the completion of each Management Stage as a minimum requirement. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB3 – Up- Up-Dated Project Business Case [U] Reporting Stage End Dating A Plan (SB2) (SB5) Project Business Exception Plan or Case Next Stage Plan (SB2) Risk Log [R] Reporting Stage End Risk Log (SB4) SB5) Issue Log (SB4) Figure 105: SB3 Plus Inputs and Outputs Many events would have occurred during the previous Management Stage which will impact the Business Benefits which were used to justify the project initially and at the last formal Project Board Review. For example, if the overall project plan has been extended or its predicted out-turn cost increased then there will be a detrimental effect on the Business Benefits; the reverse is also true! On the positive side, it can be expected that the risks faced by the project will be reduced as progress is made. This aspect is treated in SB4 - “Updating The Risk Log” but needs to be considered here as the two topics are very closely related. Changes requested (and made) during the Management Stage will also impact on the Business Benefits, especially where required changes for improved functionality have incurred additional effort and costs. 227
Ken Bradley’s Understanding PRINCE 2 SB4 -Updating The Risk Log As the project proceeds towards its planned conclusion, the risks faced for delivering on time, within budget and to the required specification should reduce. This must be recorded and presented to the Project Board when they are being asked to approve the next Management Stage Plan. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB4 – Up- Project Plan (SB2) Risk Log [U] Up-Dating A Project Dating The Business Case (SB3) Risk Log Next Stage Plan (SB2) Accepting A Work Package (MP1) Exception Plan (SB2) Issue Log [U] Up-Dating A Project Business Case (SB3) Issue Log CS4 (Quality File) Figure 106: SB4 Plus Inputs and Outputs Essentially the Risk Management Component comes back into play and the project risk re- assessed. Although PRINCE 2 does not include any requirement to use any specific risk management tool the Risk Analysis Checklist described in Chapter 6 can be used to update the risks. Whatever approach is used, the results must be logged and presented to the Project Board at the End Stage Assessment. The Risk Log should indicate a downward trend if the project is to proceed without any changes. Significant increases in the risk measurement must always be brought to the attention of the Project Board and recommendations made. Ownership of each identified risk should always be considered - the most appropriate member of the Project Management Team being best placed to keep a watchful eye on movements against the baseline. Changes in approach, planning and resource usage will always have a potential impact on the risks facing the project and so changes to the Project Plan or Next Stage Plan should always be reviewed for their impact within this Process. 228
Ken Bradley’s Understanding PRINCE 2 SB5 - Reporting Stage End The results of a Management Stage needs to be reported back to those who have provided the resources which have contributed to its completion PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB5 – Project Plan (SB2) End Stage Report [C] Authorising A Stage or Reporting Exception Plan (DP3) Stage End Current Stage Plan (SB2) Request for Authorisation To Authorising A Stage or Next Stage Plan or Proceed [C] Exception Plan (DP3) Exception Plan (SB2) Next Stage Plan [R] Authorising A Stage or Exception Plan (DP3) Business Case (SB3) Exception Plan [R] Authorising A Stage or Issue & Risk Logs Exception Plan (DP3) (SB3) Quality Log (CS5) Risk Log [R] Authorising A Stage or (Quality File) Exception Plan (DP3) Communication Plan (IP4) (Project Product Status Account [C] De-Commissioning A File) Project (CP1) Communications to interested Corporate or parties [C] Programme Management Figure 107: SB5 Plus Inputs and Outputs This Process is activated as near as possible to the end of the Current Management Stage. The results of the Process are presented as an End Stage Report which summarises the result of the Management Stage; the report provides the following information to the Project Board: ♦ Planned vs out-turn costs ♦ Planned vs out-turn effort 229
Ken Bradley’s Understanding PRINCE 2 ♦ Planned vs out-turn milestone dates ♦ Products delivered (and confirmation they meet the stated Quality Criteria The End Stage Report acts as the vehicle for presentation of the Stage results and the Next Stage Plan to the Project Board. Responsibility for creation of the report rests with the Project Manager, with help and support from the Project Management Team as appropriate. It will be provided up to a week in advance of the End Stage Assessment to allow Project Board members to consider its content; arrangements for handling Management Stage endings to allow for this are discussed in the Chapter on Understanding The Stages Component. 230
Ken Bradley’s Understanding PRINCE 2 SB6 - Producing An Exception Plan As soon as it is forecast that a Management Stage is likely to deviate beyond the Tolerance set by the Project Board at the previous End Stage Assessment, it is deemed to be in Exception and an Exception Report must be prepared for the Project Board. The likelihood is that the Project Board will require an Exception Plan to be prepared and this Process is where such a plan is created. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB6 – Exception Report Exception Plan [C] Up-Dating A Project Producing (CS8) Plan (SB2) An Exception Stage Plan (CS8) Authorising A Stage or Plan Exception Plan (DP3) Exception Plan Request (DP4) Figure 108: SB6 Plus Inputs and Outputs Standard Tolerance is measured in Time (Schedule) and Cost. For each Management Stage Tolerance is recommended by the Project Manager, based on the latest assessment of risk and the nature of the work, and confirmed by the Project Board at the End Stage Assessment. There is a separate component within PRINCE 2 for Tolerance described in the Controls Component. Additional Tolerances might be usefully considered – these include Scope, Quality and Risks. The Exception report, raised by the Project Manager as soon as it is forecast that Tolerance will be exceeded, describes the nature of the exception, its impact on the Management Stage and Project, the options open to recover the situation, and the recommendation by the Project Manager. The Exception Report is considered in “Giving Ad-Hoc Direction (DP4)” by the Project Board members (although no specific meeting or control for this consideration is identified by PRINCE). The Project Board will normally require an Exception Plan to be created to replace the approved plan which has been departed from; they might, of course decide to prematurely terminate the project or to just live with the departure but this could not be described as realistic management. This Process creates the Exception Plan which will be approved by the Project Board in “Authorising A Stage or Exception Plan (DP3)” Process at a specially convened Mid Stage Assessment. 231
Ken Bradley’s Understanding PRINCE 2 Summary of the Managing Stage Boundaries Process The “Managing Stage Boundaries Process (SB)” Process will always be present in a PRINCE 2 controlled project (since every PRINCE project will have a minimum of two Management Stages, and therefore at least one SB Process). PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB1 – Current Stage Plan Next Stage Plan [C] Up-Dating A Project Planning A (CS5) (Stage File) Plan (SB2) Stage Stage End Notification (CS5) Project Plan [R] Up-Dating A Project Plan (SB2) Project Plan (IP2) (Project File) Project Management Team Reporting Stage End Changes [U] (SB5) Trigger For Next Stage Plan (IP2) PID (IP6) (Project Product Checklist [U] Reporting Stage End File) (SB5) Current Project Management Team (IP6) (Project File & Stage File) SB2 – Up- Current & Next Up-Dated Project Plan [U] Up-Dating A Project Dating A Stage Plans (SB1) Business Case (SB3) Project Plan Exception Plan Reporting Stage End (SB6) (SB5) Project Approach Up-Dating The Risk Log (IP6) (Project File) (SB4) Project Quality Plan Next Stage Plan [R] Reporting Stage End (IP6) (Project File) (SB5) or Exception Plan [R] 232
Ken Bradley’s Understanding PRINCE 2 SB3 – Up- Up-Dated Project Business Case [U] Reporting Stage End Dating A Plan (SB2) (SB5) Project Business Exception Plan or Case Next Stage Plan (SB2) Risk Log [R] Reporting Stage End Risk Log (SB4) SB5) Issue Log (SB4) SB4 – Up- Project Plan (SB2) Risk Log [U] Up-Dating A Project Dating The Business Case (SB3) Risk Log Next Stage Plan (SB2) Accepting A Work Package (MP1) Exception Plan (SB2) Issue Log [U] Up-Dating A Project Business Case (SB3) Issue Log CS4 (Quality File) SB5 – Project Plan (SB2) End Stage Report [C] Authorising A Stage or Reporting Exception Plan (DP3) Stage End Current Stage Plan (SB2) Request for Authorisation To Authorising A Stage or Next Stage Plan or Proceed [C] Exception Plan (DP3) Exception Plan (SB2) Next Stage Plan [R] Authorising A Stage or Exception Plan (DP3) Business Case (SB3) Exception Plan [R] Authorising A Stage or Issue & Risk Logs Exception Plan (DP3) (SB3) Quality Log (CS5) Risk Log [R] Authorising A Stage or (Quality File) Exception Plan (DP3) Communication Plan (IP4) (Project Communications to interested Corporate or File) parties [C] Programme Management Product Status Account [C] De-Commissioning A Project (CP1) SB6 – Exception Report Exception Plan [C] Up-Dating A Project Producing (CS8) Plan (SB2) An Exception Stage Plan (CS8) Authorising A Stage or Plan Exception Plan (DP3) Exception Plan Request (DP4) Figure 109: Summary of the “Managing Stage Boundaries (SB)” Process 233
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 18 UNDERSTANDING THE CLOSING A PROJECT PROCESS 235
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Closing A Project (CP) - Introduction At its conclusion, the project must be closed down in an orderly and firm manner. The end of a project may arise when all the planned work has been completed and the Products/Deliverables finished and signed off as meeting their stated Quality Criteria. Alternatively a project might be brought to a premature conclusion because of changes to requirement, removal of resources or unacceptable slippage of time, effort or costs. Giving ad hoc Premature Direction Close Project Files DP4 Project Closure Notification Notification of approaching Operational and De- Project End Maintenance commissioning Reviewing Acceptance Product Status a Project Stage Status CP1 Customer Acceptance Account Confirming CS5 Project Follow-on Action Closure Recommendations Identifying Lessons Learned Post-Project Follow-on Reporting Report Review Plan Actions Stage End CP2 SB5 Issue, Risk and Lessons Learned Quality Logs Report Project Evaluation PID End Project Report Review CP3 DP5 Figure 110: Closing A Project (CP) Process Most of the work involved in this major Process is concerned with preparation of information for the Project Board in order for it to make the decision to close the project, or not. Rather like Project Initiation and Stage Initiation, this Process provides a decision- support structure; it aims to: ♦ ensure that the Objectives for the project have been met; ♦ confirm that the Customer is Satisfied with the outcome; 237
Ken Bradley’s Understanding PRINCE 2 ♦ obtain Formal Acceptance of the project Products/Deliverables; ♦ confirm that all Products/Deliverables have been handed over to the Customer, and that these have been accepted; ♦ ensure that where Ongoing Support, enhancement and maintenance is appropriate (and required), suitable provision has been made; ♦ identify any recommendations for Follow-on Actions and document; ♦ Capture “Lessons Learned” and publish these in a suitable report for the Project Board; ♦ Prepare an “End Project Report” for sign-off by the Project Board; ♦ Notify the Customer/Sponsor/Host Organisation, as appropriate, of the Intention to Close the project, disband the project organisation and release the resources. Obviously, it will be difficult to close down a project in an orderly manner if the expectations and criteria for completion and close-down have not been agreed at the outset and this will normally have been done and the final Acceptance Criteria included within the Project Initiation Document. Project staff and managers should be provided with as much notice as possible in order for them to plan their return to normal operations. Thanks to those who have contributed to the project are also in order! 238
Ken Bradley’s Understanding PRINCE 2 CP1 - Decommissioning A Project The main aim of this Process is to bring the project to an orderly close, ensuring that the Customer is happy with the outcome and demonstrates this by providing a Customer Acceptance sign-off. Assurance that the outcome can be supported and that a proper audit trail exists for the project documentation, should it be needed in the future, must also be forthcoming. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP1 – De- Premature Close Project Closure Notification [C] Confirming Project Commissio (DP4) Closure (DP5) ning A Project Notification of Project End (CS5) Operational & Maintenance Confirming Project Acceptance [C] Closure (DP5) Product Status Account (CS5) Customer Acceptance [C] Confirming Project Closure (DP5) Issue Log (SB5) PID (IP6) (Project Draft communication to interested Confirming Project File) parties [C] Closure (DP5) Communication Project Files [R] Archives Plan (IP6) (Project File) Figure 111: CP1 Plus Inputs and Outputs Key features of CP1 are: ♦ Checking that all Project issues have been dealt with; ♦ Checking that all Products have been completed, documented and handed over; ♦ Confirmation that the Customer’s Specification has been addressed; ♦ Confirmation that the outcome can be supported, operationally; ♦ Archive of all project documentation (mainly for audit purposes); 239
Ken Bradley’s Understanding PRINCE 2 ♦ Notify all concerned that the project is coming to a conclusion and resources will be returned. This Process is primarily the responsibility of the Project Manager in that it marks the conclusion of the work performed over what will often be a considerable period of time. There will be a need for close contact between the Project Manager and Project Board members to ensure there are “no surprises” at the final meeting to close the project formally. 240
Ken Bradley’s Understanding PRINCE 2 CP2 - Identifying Follow-on Actions Essentially picking up any loose ends that remain at the conclusion of the project. In particular any outstanding changes in requirements, raised as Project Issues, which were not actioned for fear of prejudicing a contractual situation or because time and budget did not allow the changes to be introduced. There might also have been some general technical improvements that would benefit the project’s outcome that the Supplier wishes to bring to the Customer’s attention. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP2 - Business Case Post-Project Review Plan [C] Confirming Project Identifying (SB5) Closure (DP5) Follow-On Actions Risk Log (SB5) Follow-On Action Confirming Project Issue Log (SB5) Recommendations [C] Closure (DP5) Figure112: CP2 Plus Inputs and Outputs A major output from this Process is the Post-Project Review Plan which will be used to set up a future project to review whether the Business Benefits identified at the outset (and reviewed and updated at each formal review) of the project, have been achieved. This will usually take place between 6-12 months after the project has been formally closed. The follow-on Actions Recommendations will provide the basis for Project Mandates for any future projects which may arise from the recommendations made. 241
Ken Bradley’s Understanding PRINCE 2 CP3 – Project Evaluation Review The lessons learned during the project must be captured as it progresses and disseminated to those in the host organisation that would benefit from it at the conclusion of the project. There is also a need to compare what was intended to be achieved by the project against what was actually achieved. This review addresses the project and its outcome rather than the outcome itself (which will the subject of a Post-Project Review (see CP2). PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP3 - Lessons Learned Lessons learned Report [U] Confirming Project Project Report (SB5) Closure (DP5) Evaluation Review Risk Log (SB5) Quality Log (SB5) Issue Log (SB5) End-Project Report [C] Confirming Project Closure (DP5) PID (IP6) (Project File) Figure 113: CP3 Plus Inputs and Outputs The Lessons Learned Report (Log) is a prime input to this Process, along with the various Logs needed to provide a comprehensive view of the performance of the project. The outputs are: ♦ An assessment of the project against its targets; ♦ An examination of the records to establish how well the Project Management and Quality Management Standards performed and to what extent they supported the project; ♦ Identify any lessons learned and to recommend changes to the existing standards. The Project Manager has responsibility to produce these analyses and present them to the Project Board 242
Ken Bradley’s Understanding PRINCE 2 Summary of the Closing A Project Process Closing A Project provides the “housework” tasks for properly shutting down a project. Authority for closure can only be given by the Project Board. The Process is essential for an orderly and effective shut-down of the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP1 – De- Premature Close Project Closure Notification [C] Confirming Project Commissio (DP4) Closure (DP5) ning A Project Notification of Project End (CS5) Operational & Maintenance Confirming Project Acceptance [C] Closure (DP5) Product Status Account (CS5) Customer Acceptance [C] Confirming Project Closure (DP5) Issue Log (SB5) PID (IP6) (Project Draft communication to interested Confirming Project File) parties [C] Closure (DP5) Communication Project Files [R] Archives Plan (IP6) (Project File) CP2 - Business Case Post-Project Review Plan [C] Confirming Project Identifying (SB5) Closure (DP5) Follow-On Actions Risk Log (SB5) Follow-On Action Confirming Project Issue Log (SB5) Recommendations [C] Closure (DP5) CP3 - Lessons Learned Lessons learned Report [U] Confirming Project Project Report (SB5) Closure (DP5) Evaluation Review Risk Log (SB5) Quality Log (SB5) Issue Log (SB5) End-Project Report [C] Confirming Project Closure (DP5) PID (IP6) (Project File) Figure 114: Summary of the Closing A Project (CP) Process 243
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Chapter 19 UNDERSTANDING THE PLANNING PROCESS 245
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Planning (PL) - Introduction Planning embraces PRINCE Components, Processes, and Techniques and is an on-going activity throughout the project. Understanding of the tasks involved and the possible pitfalls will emerge from planning the project and stages; control can only be exercised in as much detail as the project plan allows; and the approaches to planning, using manual or software supported techniques is a matter of preference and choice for the implementing organisation. Planning for all but the smallest projects is best tackled using a software support tool as the time saved in the longer term will more than repay the initial outlay, especially where complicated inter-dependencies exist between Products and Activities. Defining Project Product Approach Plan Flow Design Diagrams SU5 (Identifying), Defining and Identifying Designing a Analysing Activities and Plan Products Dependencies Planning PL1 PL2 PL3 Quality Product Descriptions List of IP1 Activity dependencies Activities Draft Product Checklist Planning a Estimating Project PL4 IP2 Estimate d Assessed Activities Schedule Plan Planning an Initiation Stage Completing a Analysing Scheduling SU6 Plan Risks PL7 PL6 PL5 Planning a Stage Resourc SB1 Completed Product e Plan for Risk Log Checklist availabilit approval y Producing an Authorising a Reviewing Giving ad hoc Exception Project or Plan Stage Status Direction Plan SB6 DP2 or DP3 CS5 DP4 Figure 115: Planning (PL) Process The philosophy behind the PRINCE 2 planning concepts are: ♦ Plans are constructed by identifying the final Products/Deliverables and all associated intermediate Products/Deliverables; 247
Ken Bradley’s Understanding PRINCE 2 ♦ Products/Deliverables are defined and specified by producing associated Product Descriptions; ♦ The Activities and associated Resources are identified; all Activities must be thought through to a level consistent with the control requirements identified in the Project Initiation Document; The planning framework incorporated in PRINCE 2 is intended to cater for any type or size of project - after given due consideration to the design of the plan (content, software tool to be used, levels of planning, detail of content required etc.) the steps are: ♦ Step 1: Identify and Define what Products/Deliverables are needed; ♦ Step 2: Determine the sequence in which each Product/deliverable should be produced; ♦ Step 3: Identify the Activities needed for the creation of the Products/Deliverables; ♦ Step 4: Estimate the Resource Requirements and calculate the durations (elapsed times) where appropriate; ♦ Step 5: Schedule the Activities (usually using a software planning tool; ♦ Step 6: Schedule the Resource Requirements (usually at the same time as scheduling the Activities); ♦ Step 7: Review the Plan especially in respect of Risks and determine the need for any contingency planning; ♦ Step 8: Finalise the Plan by assembling all the information and creating a Plan Text; ♦ Step 9: Print the Plan and obtain approval from the appropriate project authority. 248
Ken Bradley’s Understanding PRINCE 2 PL1 - Designing A Plan PRINCE 2 defines the plan as “the backbone” of every project; essentially it is not possible to control in any more detail than that planned, so the best advice is to plan in detail and then select the level of control appropriate to the risk and understanding there is for the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL1 – Project Approach Plan Design [C] Relevant Process Designing A (SU5) (Project File) Plan Project Quality Plan (IP1) (Quality File) Project Brief (SU4) (Project File) Or Project Initiation Document (IP6) (Project File) Company Planning Standards Figure 116: PL1 Plus Inputs and Outputs The Process addresses the fundamental decisions that must be made about planning before any real planning can commence. Decisions must be taken about the approach to planning and the style of presentation. The required number of levels of plan (Project-level and Stage-level plans are required in PRINCE controlled projects) and the amount of information to be included to provide the Project Board with adequate decision-support must be clearly understood. Use of software tools for estimating and planning (and possibly for preparation of analysis tools such as Product Flow Diagrams) must be considered and decisions taken. Decisions on software tools will affect the means of establishing control, especially how “actuals” are to be captured and reflected in the approved plans as the project progresses (see “Controlling A Stage (CS2)” Process). 249
Ken Bradley’s Understanding PRINCE 2 PL2 - Identifying, Defining And Analysing Products The benefits of Product-based planning is that management and the Project Management Team can be assured that all planned activity within the project is geared towards providing known, required Products or Deliverables that will all contribute towards the final outcome. As the activities within a project always consume resources (time, effort and money) then management can be confident that no resource is being wasted on carrying out unnecessary work. This Process requires the Project Manager to identify the required Products for the Project (A Product Breakdown Structure), Define each Product in terms of a Product Description, and then analyse the relationship of Products with each other (and the outside world) by producing a Product Flow Diagram. Each of these three Product Plans is described and illustrated in the Chapter on “Understanding The Product Based Planning Component and Technique”. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL2 – Project Approach Product Breakdown Structure [C] Relevant Process (Identifying) (SU5) (Project File) Defining & Product Descriptions [C] Identifying Activities & Analysing Project Quality Plan Dependencies (PL3) Products (IP1) (Quality File) Relevant Process Product Flow Diagram [C] Identifying Activities & Dependencies (PL3) Relevant Process Draft Product Checklist [C] Completing A Plan (PL7) Figure 117 : PL2 Plus Inputs and Outputs For a Project Plan it will not always be possible (or desirable) to identify and define all the Products for the life of the project. An attempt should be made, however, to present the most comprehensive information available to the Project Board. Often this will be limited to a statement of the name and a brief description of the expected Product. Planning at Management Stage level is quite different - a firm commitment in terms of Products, Activities and Resources required must be made and a fully-featured plan created. If this 250
Ken Bradley’s Understanding PRINCE 2 is not possible, consideration must be given to moving the Management Stage boundary forward to the point where a firm commitment can be made. The Product Checklist is a useful means of identifying Products (at Project-level and Management Stage-level), showing their planned Milestone dates and, subsequently, the achievement dates. 251
Ken Bradley’s Understanding PRINCE 2 PL3 - Identifying Activities And Dependencies The Product Flow Diagram can be put to use to identify the Activities within the plan and to provide an indication of the likely dependencies between them. PROCESS INPUT & PRODUCTS CREATED, OUTPUT TO SOURCE UPDATED, REFERENCED OR USED PL3 – Product Flow List of Activities [C] Scheduling (PL5) Identifying Diagram (PL2) Activities & and Dependencies Product Descriptions Activity Dependencies [C] (PL2) Risk Log (Project File) Figure 118: PL3 Plus Inputs and Outputs Each connection between Products (and external entities) on the Product Flow Diagram represents one or more potential activities to be carried out to create the Product. Armed with this principle, the Project Manager or planner can derive the raw data to plan the activities of the Project, Management Stage or Team Plan. The process of deriving activities from the Product Flow Diagram is also known as “Transformation”. 252
Ken Bradley’s Understanding PRINCE 2 PL4 - Estimating Accuracy and consistency of estimating is perhaps the single most important aspect of project management. PRINCE 2 devotes little space to how to estimate the project activities as it relies on the availability of specific approaches and techniques being available within the organisations involved in the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL4 – All Planning Activity Estimates [C] Scheduling (PL5) Estimating Information Figure 119: PL4 Plus Inputs and Outputs Organisations wishing to formalise their estimating methods and procedures will wish to consider Function Points Analysis Mark 2 which is a license-free estimating method, owned by CCTA and placed in the public domain to support the PRINCE and Structured Systems Analysis and Design (SSADM) Methods. The Method is suitable only for IT projects but the principles can be adapted for other types of project if required. Other methods of estimating are “Delphi” which is essentially asking experienced people (oracles) to provide the answer! This approach can be structured and formalised by obtaining a “first-cut” estimate from each individual and gradually refining the estimates through filters until the most optimistic, most pessimistic, and most likely by consensus is obtained and using the following formula to create the final estimate: 1 x Most Optimistic + 1 x Most Pessimistic + 4 x Most Likely 6 This approach may not be very scientific but has been around and used effectively for many years! 253
Ken Bradley’s Understanding PRINCE 2 PL5 - Scheduling Scheduling requires the creation of a Programme Evaluation and Review Technique (PERT) Network and a Gantt (Timescale) Plan. This will usually be done using a Software planning tool such as MS Project®. There is no requirement in the Method to use a software tool but it will be a great timesaver in all but the smallest of projects. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL5 – List of Activities Schedule [C] Scheduling (PL6) Scheduling (PL3) Relevant Process and Activity Dependencies (PL3) Activity Estimates (PL4) Figure 120: PL5 Plus Inputs and Outputs The techniques used in this Process are fully explained in the Chapter on “Understanding The Product-Based Planning Component and Technique”. At the same time that activities are being inserted into a software support tool, the planner will be prompted to enter resource availability and estimating information. The plan created in this Process addresses both the work to be done, including start and finish dates, and the people needed to work on them; it will also provide information on bought-in resources (such as fixed- price sub-contracted work) and equipment. From the information provided, Resources Reports can be generated for the Project Management Team and the Project Board members. Where a software support tool is not being used, a separate Resource Plan will need to be produced to inform the Project Board of the commitment of resources that is being asked of them. 254
Ken Bradley’s Understanding PRINCE 2 PL6 - Analysing Risks Before a plan can be completed the risks must be re-visited to ensure that any appropriate contingency planning has been catered for. Risks should, of course, also be addressed at the outset of planning and through every step. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL6 – All Planning Risk Log [U] Completing A Plan Analysing Information (PL7) Risks Risk Log (Project File) Assessed Plan (Schedule) [U] Completing A Plan Schedule (PL5) (PL7) Figure 121 : PL6 Plus Inputs and Outputs Each of the resources planned for should be examined and considered for potential risk and action taken to include a contingency in the plan. Risks can arise from many sources including: ♦ Quality issues; ♦ Past ability to meet deadlines; ♦ Commitment from Management and Team members; ♦ Past Sub-Contractor performance; ♦ Sources of labour and skill types; ♦ Foreseen and unforeseen external events; ♦ Other initiatives currently under way; ♦ Deadlines set for the project; ♦ Self-belief. 255
Ken Bradley’s Understanding PRINCE 2 PL7 - Completing A Plan The plans addressed in PL2 - PL5 are largely support documents for presenting information to those responsible for decision-making (mainly the Project Board). To conclude the plans the Project Manager or Team Manager must draw all the elements together and provide a brief summary addressing all the salient points; this is known as the “Plan Text”. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL7 – Assessed Plan Plan Text [C] Relevant Process and Completing (Schedule)(PL6) Approval By Project A Plan Plus Board/Project Manager Draft Product Checklist (PL2) Completed Plan For Approval [U] Product Checklist [U] Project or Stage File Figure 122: PL7 Plus Inputs and Outputs A Plan Text describing the plan in straightforward language is created and the various plans and analysis sheets appended to it. The Product Checklist (initially created in “IP2 – (Identifying), Defining And Analysing Products”) is also completed by the insertion of planned start and completion dates for each of the Products. It is in this Process that consideration should also be given to creating a “Graphical Summary of the Plan” which, although not a part of the stated PRINCE 2 plan package, is an invaluable aid to the Project Board and other members of senior management in understanding what the plan is trying to achieve. 256
Ken Bradley’s Understanding PRINCE 2 Summary of the Planning (PL) Process Planning is uses throughout the PRINCE 2 Method. In many ways it is unhelpful to view planning as a “Process” - it is essentially a “Technique” used on a day to day basis and coming into prominence at the beginning of the project and at the end of each Management Stage. PROCESS INPUT & PRODUCTS CREATED, OUTPUT TO SOURCE UPDATED, REFERENCED OR USED PL1 – Project Approach Plan Design [C] Relevant Process Designing A (SU5) (Project Plan File) Project Quality Plan (IP1) (Quality File) Project Brief (SU4) (Project File) Or Project Initiation Document (IP6) (Project File) Company Planning Standards PL2 – Project Approach Product Breakdown Structure [C] Relevant Process (Identifying) (SU5) (Project Defining & File) Product Descriptions [C] Identifying Activities & Analysing Dependencies (PL3) Products Project Quality Plan (IP1) Relevant Process (Quality File) Product Flow Diagram [C] Identifying Activities & Dependencies (PL3) Relevant Process Draft Product Checklist [C] Completing A Plan (PL7) 257
Ken Bradley’s Understanding PRINCE 2 PL3 – Product Flow List of Activities [C] Scheduling (PL5) Identifying Diagram (PL2) Activities & and Dependencies Product Descriptions Activity Dependencies [C] (PL2) Risk Log (Project File) PL4 – All Planning Activity Estimates [C] Scheduling (PL5) Estimating Information PL5 – List of Activities Schedule [C] Scheduling (PL6) Scheduling (PL3) Relevant Process and Activity Dependencies (PL3) Activity Estimates (PL4) PL6 – All Planning Risk Log [U] Completing A Plan Analysing Information (PL7) Risks Risk Log (Project File) Assessed Plan (Schedule) [U] Completing A Plan (PL7) Schedule (PL5) PL7 – Assessed Plan Plan Text [C] Relevant Process and Completing A (Schedule)(PL6) Approval By Project Plan Plus Board/Project Manager Draft Product Checklist (PL2) Completed Plan For Approval [U] Product Checklist [U] Project or Stage File Figure 123: Summary of the Planning (PL) Process 258
Ken Bradley’s Understanding PRINCE 2 Chapter 20 UNDERSTANDING THE PRINCE 2 FILING TECHNIQUE 259
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Filing Technique - Introduction PRINCE 2 suggests a suitable filing structure based on three different types of file: ♦ The Management File (Broken down into an overall Project File and a series of Stage Files) ♦ The Specialist File ♦ The Quality File Files Project File Stage File(s) Specialist File Quality File Organisation Organisation Configuration Items Product Descriptions Plans Plans Configuration Log Quality Checks Business Case Control Documents CI Locations Project Issues Risk Log Daily Log Off-Specifications Control Documents Correspondence Products Checklist Products Checklist Figure 124: Summary of the PRINCE 2 Suggested Filing Structure There is no requirement in the Method to adopt the suggested filing structure - implementing organisations are free to retain their existing standards or to modify the suggested structure to suit their own requirements. The Management File This comprises the following components: The Project File (One File for the Whole Project): ♦ The Project Organisation Structure Chart and agreed/signed-off Job Descriptions; ♦ Project-level Plans: ♦ Project-level Product Breakdown Structure; 261
Ken Bradley’s Understanding PRINCE 2 ♦ Project-level Product Flow Diagram; ♦ Timescale Plan (Project-level Gantt Plan); ♦ Project-level PERT Network; ♦ Project Resource Report; ♦ The Business Case: ♦ Business Benefits Assessment; ♦ Risk Assessment & Proposals; ♦ Risk Log; ♦ Control Documentation: ♦ the Project Initiation Document; ♦ End Project Report ♦ The Lessons Learned Report; ♦ Products Checklist; ♦ Products Status Account; ♦ Follow-On Items; ♦ Post-Project Review Plan; ♦ Project Closure Sign-off Document 262
Ken Bradley’s Understanding PRINCE 2 Management File - Project File * Project Mandate * Product Checklist (Project Level Products) * Project Brief * Highlight Reports * Project Organisation Structure * Exception Reports (Project) * Project Organisation Roles & Responsibilities * Project End Notification * Project Approach * Project Board Approval For Initiation * Business Case (Initial & Updates) * Project Plan (Initial & Updates) * Baselined Project Initiation Document * Risk Log * Project Filing Structure Summary * Project Board Approval For The Project * Lessons Learned Report * Project Closure Recommendation * Record of End Stage Assessments * Post Implementation Review Plan * Record of Mid Stage Assessments * End Project Report Figure125: Comprehensive View of the Project File The Management Stage Files (one file or section for each Management Stage of the Project): ♦ Management Stage Organisation Structure Chart and agreed/signed-off Job Descriptions; this will relate to the Team Members. ♦ Management Stage and any lower-level Plans: ♦ Stage-level Product Breakdown Structure; ♦ Stage-level Product Descriptions (The Master Product Descriptions will be stored in the Quality File); ♦ Stage-level Product Flow Diagram; ♦ Stage-level Timescale Plan (Gantt Plan); ♦ Stage-level PERT Network; ♦ Stage-level Resources Report; ♦ Exception Plans and associated documentation. ♦ (nb: The Stage Plans should normally be up-dated to reflect “actuals” at least once every week) ♦ Management Stage-level Control Documentation: ♦ Copies of Work Package Authorisations; 263
Ken Bradley’s Understanding PRINCE 2 ♦ Checkpoint Reports, Highlight Reports; ♦ Exception Reports; ♦ End Stage Assessment and Mid Stage Assessment records and formal Project Board sign-offs. ♦ Products Checklist for the Management Stage Products; ♦ Daily Log recording events, problems questions, informal discussions with Project Board members and other senior managers and resultant actions impacting on the Management Stage. ♦ Correspondence - management correspondence and other papers relevant to the Management Stage. 264
Ken Bradley’s Understanding PRINCE 2 Management File - Stage File * Stage Organisation Structure * Work Package Authorisation (Contract) * Stage Organisation Roles & Responsibilities * Checkpoint Reports * Exception Reports (Stage Level) * Current Stage Plan * Product Checklist (Stage Level Products) * Project Board Approval For The Stage * End Stage Report * Daily Log * Correspondence Figure 126: Comprehensive View of the Stage File The Specialist File (One File for the whole Project): ♦ The Configuration Items for the project and the Configuration History (changes, version etc); log-out and in information. Correspondence relating to a specific Configuration Item will be associated with the item it addresses. ♦ Physical Location of each Configuration Item. ♦ A copy of the relevant Product Description for each Specialist Product may be included for completeness. (The Master Product Descriptions will be stored in the Quality File); ♦ Specialist General Correspondence especially where a number of Configuration Items are referred to. Specialist File * Configuration Items * Location of Configuration Items * Log of Configuration Items * Off Specifications For Configuration Items * Correspondence Relating To Specialist Products Figure 127: Comprehensive View of the Specialist File 265
Ken Bradley’s Understanding PRINCE 2 The Quality File (One File for the Whole Project): • The Master Product Descriptions; • Quality Control Documentation • Selection Criteria for Quality Reviewers; • Invitations to Quality Reviews; • Error/Observations Lists; • Follow-up Actions List; • Reviewers’ Sign-offs for each Configuration Item will be stored either here or in the Specialist File, associated with the relevant product. • Project Issues; • Project issues Log. Quality File * Master Product Descriptions * Project Issues * Project Quality Plan - Issue Log * Stage Quality Plan * Quality Review Documentation - Project Issues - Invitations - Requests For Change * Quality Log - Error Lists - Off-Specifications - Follow-up Actions - Sign-offs/Results * Project Quality Plan Figure 128: Comprehensive View of the Quality File Physical Filing Considerations The files themselves may take on a variety of guises from a consolidated four-post binder for a small project to a whole room of filing cupboards for a major initiative. The Method has no views on the physical implementation of filing arrangements. It will often be sensible to establish an electronic filing structure to help standardise the filing arrangements within the implementing organisation. 266
Ken Bradley’s Understanding PRINCE 2 Chapter 21 UNDERSTANDING THE QUALITY REVIEW TECHNIQUE 267
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Quality Review Technique - Introduction In PRINCE projects, quality is controlled through a number of quality management procedures and techniques. Used correctly, in appropriate circumstances and in conjunction with Product Descriptions (see the Product-Based Planning Technique), the Quality Review is one of the most powerful of the techniques used within the Method. Quality within PRINCE 2 is embedded within each of the Components, Processes and Techniques; it is not perceived as something separate that can be applied after a Product or Deliverable has been produced, or even at isolated points during the product cycle. Quality Assurance and Quality Control It is well worth viewing the concepts of Quality Assurance and Quality Control as different, but mutually supportive, Quality Assurance will normally be present in the form of a published and defined Quality Management System, often implemented against the BS/EN/ISO9001 standard. A Quality Management System (QMS) provides the all important backdrop to managing quality throughout the whole organisation and provides an environment of confidence for staff and customers alike. This confidence manifests itself in a considered, professional approach to all tasks undertaken by all personnel - ensuring that the primary objective of the control functions - the Quality Review Technique, for example - is to confirm that all project deliverables meet their stated Quality Criteria (contained within the appropriate Product Description) rather than to identify perceived deficiencies and mistakes. Some organisations may find they are at odds with this approach, having spent many years using quality control techniques to pick up faults and planning re-work of deliverables as an inevitable outcome of the quality checks. But it does not have to be like this - given a sensibly written set of quality procedures, published in the form of a Quality Management System, reflecting the principles of BS/EN/ISO9001 and regularly audited by internal and external auditors, any organisation can enjoy a quality environment, where “getting it right first time” is the watchword for all staff. What is a Quality Review? PRINCE 2 describes a Quality Review as “an involved partnership designed to ensure a Product’s completeness and adherence to standards by a review procedure”. In essence a Quality Review is a review of a Product with the emphasis on checking for errors and omissions, and non-compliance with the stated Quality Criteria. The PRINCE 2 Quality Review has a clear and defined structure which when followed will produce the required results. 269
Ken Bradley’s Understanding PRINCE 2 Quality Reviews - Formal and Informal Quality Reviews can be either formal, for example a scheduled meeting, or informal. The selection of the type of quality control is the responsibility of the Project Manager, endorsed by the Project Board at the Project Initiation or End Stage Assessment meetings. The Project Manager will consider the relative importance of each project deliverable in reaching a final decision on whether to recommend a formal or informal Quality Review but whatever the decision, the objective is the same - to confirm that the product or deliverable under review conforms to its stated and agreed Quality Criteria. An informal Quality Review may take many forms. A simple test or visual inspection to check out the Product may be both sensible and acceptable. A "desk-check" may be carried out. This might be performed by the author's line manager, or could be carried out by an expert Reviewer either within or outside the project, site or organisation. In many cases a physical test of the deliverable will be the obvious way to assure compliance with the Quality Criteria. In all circumstances, the documentation must be produced to record the review and to provide the essential “audit trail”. People Involved Those involved in the Quality Review process are: ♦ The Producer: who is usually the creator/ author of the Product being reviewed. ♦ The Review Chair: who may be the Producer’s line manager, the Project Manager, or any other competent person with authority (or perceived authority). ♦ The Reviewers: who must be competent to assess the Product from their particular specialist viewpoints. ♦ The Scribe: who will take notes of the agreed actions arising from the review. ♦ Project Support: providing administrative support for the Quality Review technique; this will typically include arranging the venue, sending out invitations and providing the scribe role, taking note of the follow-up actions during the meeting. ♦ Project Assurance and Quality Assurance: assuring the effective use of the Quality Management System and the techniques associated with it, and monitoring appropriate use of organisational, industry and ethical standards on behalf of the Project Board and senior managers. 270
Ken Bradley’s Understanding PRINCE 2 The Quality Review Steps Detailed procedures for carrying out a Quality Review will normally be specified by the organisation’s own Quality Management System, but where such a system is not published, the following arrangements will be found to work successfully. Step 1 - Preparation The objective of this step is to examine the Product or Deliverable under review against its Product Description and to create a list of queries, possible errors, and topics that warrant re-examination. ♦ The Chair will check with the Producer that the product will be ready on time and ensure that the team of Reviewers is agreed and that they will all be available. ♦ An invitation to the Quality Review, indicating the Product, time and place for the review is sent with copies of the Product and the Product Description. Any specific Standards used in the production of the Product would normally be available to all project personnel - if not a copy of the relevant Standard used to produce the deliverable should be attached. This should dispatched between one and five days before the review. ♦ Each Reviewer will study the product and supporting documents (including the Quality Criteria included in the Product Description), and will complete a Quality Review Error List. ♦ The QR Error List will, wherever possible, be sent to the Producer before the review. Product Description Finished Product Reviewers of the Product Producer of the Product Error Lists Figure 129: Formal Quality Review Step 1 271
Ken Bradley’s Understanding PRINCE 2 Step 2 - The Review Meeting The objective of the Quality Review is to agree a list of queries, observations and errors in the Product. The Chair and the Producer do not have to reconcile these errors at the meeting - it is sufficient for the QR Chairman and Reviewers to agree that a particular area needs re-examination. Provided that the point and follow-up action is logged, the Reviewers have an opportunity to confirm that action has been taken, after the review meeting. The procedure for the PRINCE Quality Review step is: ♦ The Quality Review Chair opens the meeting and introduces those present if necessary. The meeting Objectives and Timing (a maximum of 2 hours is recommended) is announced. ♦ The Chair asks each Reviewer for comments. The purpose of this is to identify the main areas for discussion that the review must focus upon. It also affords an opportunity for an overall reaction to the total Product and to consider premature closure of the meeting if appropriate. ♦ The Producer then "Walks-through" the Product in detail. This may be sentence-by-sentence or page-by-page and will be determined by the Reviewers' QR Error Lists already sent to the Producer, and by their general comments made earlier. ♦ The QR Chair controls the discussion during the Walk-through ensuring that no arguments or solutions are discussed (other than obvious and immediately accepted solutions!). Follow-up Actions are noted on the QR Follow-Up Action List by either the Scribe or Project Support. No minutes need be taken of the review. Reviewers’ comments are always related to the Quality Criteria contained in the Product Description - these are the measures used by all involved to determine the acceptability, or otherwise, of the Product under review. ♦ At the conclusion of the walk-through, the Chair summarises the Follow-up actions and determines responsibility for sign-off of specific points if required. The initials of the Reviewer who will sign-off any specific point is recorded on the QR Follow-Up Action Sheet. ♦ The Chair, after seeking the Reviewers' and Producers' opinions, will decide on the outcome of the review. A QR Result Notification will be completed and a copy of the Follow-Up Action List attached. These forms will be sent to Project Support (or the Project Manager) and/or Team Manager for the plans to be up-dated. ♦ The Reviewers' Error Lists, copies of the Product (typically containing the Reviewer's annotations) and any other relevant documentation is collected by the Chair and passed to the Producer to assist in the Follow-up. 272
Ken Bradley’s Understanding PRINCE 2 Error Lists Quality Reviewed Product Follow-Up Actions Sign-off Chair-person Quality Review Meeting Figure 130: Formal Quality Review Step 2 Step 3 - Follow-up of Review Meeting The objective of the Follow-up step is to ensure that all items identified on the QR Follow-Up Action List are dealt with and signed off. ♦ The Producer takes the list away from the review and evaluates, discusses, and corrects, if necessary, all the items on the list. ♦ When an error has been fixed, the Producer will obtain sign-off from whoever is nominated on the QR Follow-Up Action List. This person may be the Reviewer who raised the query initially, or may be another Reviewer, the Project Manager, Team Manager, or the Quality Review Chair. ♦ When all errors have been reconciled and sign-off obtained, the Quality Review Chair will raise a QR Review Result Notification confirming that the Product is "Complete" and will attach the signed QR Follow-Up Action List. The documents will be sent to Project Support (or the Project Manager or Team Manager) to up-date plans. 273
Ken Bradley’s Understanding PRINCE 2 Product Description Finished Product Reviewers of the Product Producer of the Product Error Lists Quality Reviewed Product Follow-Up Actions Sign-off Chair-person Quality Review Meeting Figure 131: Formal Quality Review Step 3 Summary of the Quality Review Technique The Quality Review technique is a structured way of running a meeting to ensure that all aspects are properly covered. It needs to be used with common-sense (to avoid the dangers of an over-bureaucratic approach) but with an intent to follow the procedures laid down (to ensure nothing is missed). If an organisation already uses existing effective standards for quality reviewing products, it will not be necessary to change these to reflect the PRINCE 2 Quality Review procedures. PRINCE 2 emphasises the need to ensure that all Products pass through a quality control process (as laid down in the Product Description); this ensures that only "reviewed - correct - products" are regarded as being complete. The PRINCE 2 Manual contains a fairly detailed step-by-step summary of the Quality Review Technique which should be consulted and modified to suit the required procedure within the implementing organisation. 274
Ken Bradley’s Understanding PRINCE 2 Chapter 22 Ken Bradley’s Understanding PRINCE 2 Index 275
Understanding PRINCE 2®
Ken Bradley’s Understanding PRINCE 2 Index Configuration · 26, 31, 40, 43, 52, 53, 65, 74, 125, 129, 130, 131, 135, 136, 202, 218, A 265, 266 Configuration Librarian · 135 Acceptance Criteria · 155, 164, 202, 238 Configuration Management · 40, 43, 52, 74, Accepting A Work Package · 144, 217 129, 130 Accountability · 33, 36, 61, 74 Confirming Project Closure · 144, 155, 189 Activities · 77, 81, 82, 88, 89, 130 Context Diagram · 145, 146 Activity · 38, 77, 91 Control · 17, 25, 26, 34, 39, 42, 43, 44, 45, Actuals · 29, 200, 204, 218, 249, 263 51, 57, 61, 62, 64, 72, 74, 77, 84, 89, 90, Analysing Risks · 145, 255 94, 96, 124, 129, 130, 135, 136, 137, 182, Appointing A Project Management Team · 216, 224, 247, 248, 269, 270 144 Controlling A Stage · 29, 30, 31, 125, 141, Assembling A Project Initiation Document · 144, 157, 197, 210, 212, 218, 249 144 Controls · 44, 50, 52, 94 Assessing Progress · 144, 200, 204, 218 Critical Path · 19, 81 Authorised Work Package · 91, 124, 125 Customer’s Quality Expectations · 165 Authorising A Project · 108, 144, 184 Authorising A Work Package · 144, 199, 209 Authorising Initiation · 144, 154, 183 D decision points · 27, 181 B Decision-support · 224, 237 Decommissioning A Project · 144, 155, 164, Baseline · 44, 96, 164 239 Benefits · 25, 26, 44, 45, 58, 61, 88, 89, 96, Defining Project Approach · 144 163, 224 Deliverables · 25, 26, 27, 36, 38, 39, 40, 47, Benefits Statement · 88 60, 102, 146, 223, 237, 238, 247, 248 boundary · 27, 70, 71 Delivering A Work Package · 144, 219 BS/EN/ISO9000 · 42, 60, 123, 269 Dependencies · 27, 247 BS/EN/ISO9001 · 42, 123 Designing A Plan · 145, 249 BS6079 · 42, 123 Designing A Project Management Team · 144 Business Benefits · 29, 49, 50, 88, 108, 113, Directing A Project · 29, 30, 31, 58, 141, 135, 168, 227, 241, 262 144, 157, 177, 181, 191, 193 Business Case · 26, 45, 88, 89, 96 Business Case · 60, 87, 88, 113, 154, 163, 223, 224, 262 E Earned Value · 86, 87, 90 C End-Stage Assessment · 43, 64 Enhancement · 17, 19 CCTA · 2, 3, 17, 19, 20, 21, 53, 113, 253 ESA · 45, 64, 96, 264 Change Controls · 52 Escalating Project Issues · 203 Checkpoint · 264 Estimating · 38, 65, 249, 253, 254 Closing A Project · 29, 30, 31, 47, 102, 141, Estimating · 38, 145, 253 144, 187, 189, 237, 242 Evaluating A Project · 144, 242 CMM · 52, 129, 130 Exception · 38, 182, 224, 263, 264 Communication · 25, 57, 67, 68, 69 Exception Plan · 44, 45, 98, 144, 182, 185, Completed Work Packages · 125 186, 187, 208, 231 Completing A Plan · 145, 256 Exception Report · 44, 45, 98, 186, 187, 203, Components · 17 208, 231 Components · 28, 30, 31, 32, 54, 143, 247, Executing A Work Package · 144, 218 269 Executive · 30, 34, 59, 61, 71, 74, 89, 144, Concurrent Engineering · 72, 73 152, 153, 156, 183 277
Ken Bradley’s Understanding PRINCE 2 External Assurance · 36, 60, 61 94, 96, 99, 102, 113, 123, 130, 135, 141, 145, 146, 176, 182, 197, 216, 264, 269 Management Products · 64, 65, 78 F Management Stage · 26, 29, 30, 38, 42, 45, 47, 48, 49, 50, 62, 80, 86, 89, 90, 98, 100, Feasibility · 88 102, 104, 108, 109, 110, 124, 125, 141, Feasibility Study · 88 155, 157, 163, 166, 167, 168, 174, 184, Filing · 32, 53, 65, 129, 171, 172, 261, 266 185, 186, 197, 198, 199, 200, 201, 203, Follow-on Actions · 48, 102, 144, 238, 241 204, 205, 208, 209, 217, 218, 220, 225, Formal Quality Review · 51, 65, 271, 273, 226, 227, 228, 229, 230, 231, 250, 251, 274 252, 257, 263, 264 Management Stages · 26, 28, 30, 31, 32, 35, 48, 49, 64, 103, 104, 107, 108, 109, 110, G 164, 169, 232 Managing Product Delivery · 29, 30, 31, 91, Gantt · 40, 41, 42, 43, 77, 82, 83, 84, 90, 91, 107, 125, 141, 157, 200, 215, 220 124, 262, 263 Managing Stage Boundaries · 29, 30, 31, Giving Ad-Hoc Direction · 144, 188 108, 115, 141, 157, 166, 167, 168, 174, Government Departments · 17 184, 186, 199, 223, 232, 233 Graphical Summary · 85, 86, 87, 90, 256 Manuals · 59 Mid Stage Assessment · 45, 98, 169, 186, H 231, 264 Milestone · 87, 251 Highlight Report · 62, 63, 68, 69, 182, 264 Highlight Reports · 30, 48, 73, 102, 188 O Hints and Tips · 33, 146 Objectives · 44, 94, 237 I Off-Specification · 135, 136, 137, 202 Operation · 18, 131 Identifying Activities And Dependencies · Organisation · 26, 32, 33, 34, 35, 36, 37, 39, 145, 252 44, 48, 51, 57, 58, 59, 60, 65, 67, 68, 69, Identifying, Defining And Analysing Products 70, 71, 72, 74, 76, 88, 96, 102, 114, 116, · 145, 250 124, 125, 135, 141, 146, 165, 170, 181, Initiating A Project · 27, 29, 30, 31, 42, 44, 197, 199, 200, 209, 217, 218, 224, 238, 47, 50, 96, 102, 108, 124, 125, 141, 157, 242, 247, 266, 269, 270, 271, 274 158, 163, 164, 166, 173, 175, 176, 184 Organisation · 17, 20, 25, 33, 238, 261, 263 Internal Assurance · 36, 60, 61 Ownership · 58 Issues · 52, 129, 136, 137, 198, 266 Issues Log · 48, 102, 202, 203, 204 P L PERT · 40, 81, 82, 90, 254, 262, 263 PID · 44, 50, 96, 115, 155, 157, 163, 164, Lessons learned · 242 173, 174, 177, 182, 183, 184 Lessons Learned · 47, 102, 224, 238, 242, Plan · 26, 38, 40, 41, 42, 43, 44, 61, 62, 71, 262 72, 76, 77, 83, 85, 87, 89, 90, 94, 182, 198, Lessons Learned Report · 47, 102, 262 224, 238, 247 Levels of plan · 249 Plan Description · 87, 89, 90 Lifecycle · 18 Plan Text · 89, 90, 248, 256 Planning · 19, 20, 27, 30, 31, 35, 38, 39, 40, 41, 42, 43, 44, 50, 53, 62, 65, 72, 74, 76, M 77, 78, 83, 84, 88, 89, 94, 108, 109, 110, 124, 125, 151, 153, 157, 164, 165, 166, Maintenance · 17 200, 228, 247, 248, 249, 250, 255, 257, management · 17, 19, 20, 25, 26, 27, 32, 33, 269 34, 35, 37, 38, 39, 42, 44, 45, 46, 47, 57, Planning · 17, 19, 25, 29, 30, 31, 32, 38, 40, 62, 64, 65, 67, 68, 69, 70, 72, 74, 81, 88, 41, 42, 43, 50, 76, 124, 141, 144, 145, 157, 278
Ken Bradley’s Understanding PRINCE 2 165, 166, 174, 187, 225, 247, 250, 254, 60, 61, 62, 63, 64, 65, 67, 68, 70, 71, 72, 257, 258, 269 73, 74, 82, 83, 84, 85, 86, 87, 89, 90, 94, Planning A Project · 141 96, 98, 99, 100, 102, 103, 107, 108, 110, Planning An Initiation Stage · 144 113, 114, 124, 131, 136, 141, 144, 146, Planning levels · 76 151, 152, 153, 154, 156, 157, 164, 166, Plans · 76, 77, 89, 91 167, 168, 169, 171, 174, 175, 176, 177, Post Project Review · 29, 30, 177, 189, 241, 181, 182, 183, 184, 185, 186, 187, 188, 242 189, 190, 197, 198, 199, 200, 201, 203, Preparing A Project Brief · 144 204, 205, 206, 207, 208, 216, 217, 223, PRINCE · 15, 17, 19, 20, 25, 26, 27, 28, 32, 224, 225, 226, 227, 228, 229, 230, 231, 33, 34, 36, 37, 38, 39, 40, 42, 44, 47, 51, 237, 238, 240, 242, 243, 249, 250, 254, 52, 53, 54, 57, 58, 59, 60, 61, 63, 64, 65, 256, 264, 270 67, 69, 71, 72, 74, 76, 77, 79, 89, 90, 91, Project Brief · 31, 124, 152, 154, 155, 156, 94, 102, 113, 123, 129, 130, 135, 136, 137, 165, 168, 171 141, 145, 146, 216, 247, 261, 269, 272, Project Closure · 47, 102, 181, 182 274 Project Files · 64 PRINCE 2 · 1, 14, 20, 21, 26, 27, 28, 29, 30, Project Initiation · 19, 43, 44, 53, 61, 87, 94, 31, 32, 34, 36, 37, 38, 41, 42, 43, 47, 48, 96, 113, 163, 164, 182, 237, 238, 248, 262, 49, 50, 53, 54, 57, 58, 61, 64, 65, 66, 69, 270 72, 74, 76, 77, 79, 84, 85, 86, 87, 91, 99, Project Issue Report · 129, 135, 136 103, 107, 108, 109, 110, 123, 124, 129, Project issues · 239, 266 137, 139, 141, 142, 143, 145, 146, 151, Project Issues · 32, 48, 102, 129, 135, 136, 152, 153, 155, 158, 164, 165, 166, 168, 137, 144, 200, 202, 203, 208, 241 169, 170, 171, 172, 173, 174, 177, 202, Project Management Team · 29, 30, 58, 74, 210, 220, 227, 228, 231, 232, 248, 249, 78, 151, 152, 153, 166, 171, 174, 175, 198, 253, 256, 257, 259, 261, 269, 274 202, 207, 225, 228, 230, 250, 254 PRINCE Environment · 20, 53 Project Manager · 19, 29, 30, 32, 35, 36, 37, Process Models · 145, 146 39, 43, 45, 47, 48, 49, 50, 52, 53, 61, 62, Process-based · 33 63, 64, 68, 69, 70, 71, 72, 73, 74, 78, 83, Processes · 26, 27, 57, 125, 130, 141, 157 87, 88, 91, 98, 100, 102, 104, 107, 109, Processes · 26, 27, 28, 29, 30, 31, 32, 35, 44, 110, 113, 117, 124, 125, 131, 135, 136, 54, 65, 96, 141, 143, 144, 145, 146, 157, 141, 144, 146, 152, 153, 166, 169, 170, 163, 166, 181, 188, 247, 269 174, 181, 182, 184, 186, 188, 190, 197, Product Breakdown Structure · 40, 78, 80, 198, 199, 200, 201, 203, 204, 207, 208, 90, 261, 263 210, 215, 216, 217, 218, 224, 225, 226, Product Description · 32, 40, 42, 50, 51, 63, 230, 231, 240, 242, 250, 252, 256, 270, 78, 79, 80, 124, 125, 165, 217, 250, 265, 272, 273 269, 271, 272, 274 Project Mandate · 88, 151 Product Flow Diagram · 32, 40, 80, 81, 90, Project plans · 26, 71, 85 250, 252, 262, 263 Project Support · 36, 37, 53, 60, 61, 63, 64, Product Flow Diagrams · 249 65, 69, 71, 72, 74, 131, 135, 137, 270, 272, Products · 20, 26, 34, 35, 38, 40, 43, 49, 50, 273 52, 61, 62, 80, 125, 129, 131, 135, 186, PROMPT · 17, 18, 19, 20 274 Public Domain · 25 Products · 25, 26, 27, 36, 38, 39, 40, 43, 47, 52, 59, 60, 63, 64, 65, 72, 74, 77, 78, 80, 81, 84, 86, 90, 91, 102, 124, 129, 130, 131, Q 135, 146, 197, 215, 216, 223, 237, 238, 247, 248, 262, 264. See Outputs QMS · See Quality Management System Programme · 57, 62, 69, 70, 71, 72, 81 Quality · 17, 19, 26, 36, 38, 40, 42, 50, 51, Programme of work · 48, 103 60, 61, 63, 65, 70, 73, 78, 79, 87, 90, 102, Project Approach · 152, 156, 171 125, 135, 197, 215, 216, 223, 237, 261, Project Assurance · 35, 36, 60, 61, 64, 68, 263, 265, 266, 269, 270, 271, 272, 274 70, 73, 74, 137, 225, 270 Quality assurance · 17, 274 Project Assurance Team · 270 Quality criteria · 35, 43, 50, 51 Project Board · 30, 31, 32, 33, 34, 35, 36, 37, Quality Criteria · 31, 32, 51, 124, 125, 165, 39, 41, 43, 44, 45, 46, 47, 48, 50, 58, 59, 217, 230, 269, 270 279
Ken Bradley’s Understanding PRINCE 2 Quality Management · 19, 26, 42, 50, 73, SPOCE · 113 119, 120, 123, 124, 125, 165, 242, 269, Stage · 18, 26, 27, 36, 38, 39, 40, 42, 43, 44, 270, 271 45, 46, 47, 50, 61, 62, 63, 77, 84, 85, 86, Quality Management System · 42, 73, 125, 89, 90, 96, 99, 102, 125, 137, 164, 223, 269, 270, 271 224, 264 Quality Review Technique · 32, 124, 269, Stage Manager · 83, 136 274 Stages · 18, 26, 27, 33, 64, 72, 89, 181, 224, Quality Reviews · 90, 266, 270 247 Stages · 18, 31, 35, 48, 49, 64, 103, 104, 107, 109, 223, 230 R Starting A Project · 44, 96, 141, 151 Starting Up A Project (SU) · 124 Rapid Application Development · 72, 73 Strategic Planning · 17 Receiving A Completed Work Package · 144, Supplier · 34, 57, 58, 59, 65, 67, 69, 71, 215, 209 216 Refining The Business Case and Risks · 144 System Development · 17 Reporting Highlights · 144, 205 Reporting Stage End · 144, 229 Request for Change · 135, 136, 137 T Request For Change · 136, 202 Resource · 17, 82, 83, 84, 85, 90 Taking Corrective Action · 144, 205, 207 Resource Plan · 40, 42, 84, 85, 90, 254 Team Leader · 36 Resources · 82, 83 Team Manager · 35, 36, 62, 63, 64, 69, 72, Resources Report · 41, 42, 85, 263 74, 78, 83, 136 responsibilities · 26, 33, 36, 58, 62, 63, 64 Team Managers · 35, 61, 62, 64, 72, 74 Review · 136, 271, 272, 273 Team Plan · 91, 252 Reviewing Stage Status · 144, 200, 204, 205, Teams · 36, 37 207 Technical · 18, 31, 35, 47, 48, 49, 61, 64, 84, Risk · 31, 36, 41, 43, 62, 69, 72, 87, 88, 89, 90, 99, 103, 104, 107, 109, 130, 271 110, 113, 114, 115, 117, 163, 168, 169, Techniques · 26, 33, 38, 39, 57, 65, 113, 125, 183, 206, 223, 228, 231, 249, 255 129, 143, 247, 253, 254, 269, 270 Risk Assessment · 65, 87, 88, 113, 115, 262 Techniques · 28, 32, 38, 51, 54, 129, 143, Risk Factor · 115, 117, 120 145, 247 Risks · 26, 27, 44, 45, 83, 87, 89, 90, 96, 113, Terms of Reference · 44, 94, 154 163, 224 Tolerance · 30, 43, 46, 47, 99, 100, 169, 182, Risks · 29, 49, 50, 60, 168, 248, 255 186, 198, 203, 204, 207, 208, 224, 231 Role descriptions · 58 Transformation · 252 Roles · 33, 34, 36, 58, 59, 61 U S UK Government · 17, 20 Scheduling · 145, 254 Updating A Project Business Case · 144, 227 Scoping Diagram · 27 Updating A Project Plan · 144, 226 Senior User · 59, 71, 136 Updating The Risk Log · 144, 227, 228 Setting Up Project Controls · 144, 169 User · 20, 34, 89, 135, 137 Setting Up Project Files · 144 User/Customer Group · 71 Significant deviation · 45, 98, 186 Smaller projects · 59 Software · 20, 65, 72, 76, 77, 83, 84, 90, 247 W Software support tool · 41, 78, 254 Software tools · 249 Walk-through · 51, 272 specialist · 25, 33, 34, 35, 36, 38, 39, 58, 59, Work Package · 263 62, 64, 65, 67, 69, 90, 91, 109, 130, 135, Work Packages · 109, 125, 197, 199, 209, 216, 270 218 Specialist Stages · 64 280

More Related Content

PDF
Treemaps: Visualizing Hierarchical and Categorical Data
Brian Johnson
 
PPT
Prince 2 Pt 7
dmdk12
 
PPT
Prince 2 Pt 5
dmdk12
 
PPT
Prince 2 Pt 6
dmdk12
 
PPTX
Prince2@ Foundation Certification Course
Ramesh Pabba - seeking new projects
 
PPT
Prince 2 Pt 2
dmdk12
 
PPT
Prince 2 Pt 3
dmdk12
 
PPT
Prince 2 Pt 8
dmdk12
 
Treemaps: Visualizing Hierarchical and Categorical Data
Brian Johnson
 
Prince 2 Pt 7
dmdk12
 
Prince 2 Pt 5
dmdk12
 
Prince 2 Pt 6
dmdk12
 
Prince2@ Foundation Certification Course
Ramesh Pabba - seeking new projects
 
Prince 2 Pt 2
dmdk12
 
Prince 2 Pt 3
dmdk12
 
Prince 2 Pt 8
dmdk12
 

Viewers also liked (10)

PPT
Prince 2 Pt 1
dmdk12
 
PPT
Prince 2 Pt 4
dmdk12
 
PDF
PRINCE2 Foundation Training Manual by Frank Turley
Frank Turley
 
PDF
Overview of PRINCE2
iHub
 
PPTX
Framework for Project Layout Meeting
dmdk12
 
PDF
An Introduction to PRINCE2 (book)
Frank Turley
 
PDF
7 Themes of Prince2
Barry Hodge
 
PDF
PRINCE2 Foundation Course Material
stefanhenry
 
PDF
PRINCE2 Process Model
projectingIT
 
PDF
AXELOS - PRINCE2® Foundation
Mirosław Dąbrowski C-level IT manager, CEO, Agile, ICF Coach, Speaker
 
Prince 2 Pt 1
dmdk12
 
Prince 2 Pt 4
dmdk12
 
PRINCE2 Foundation Training Manual by Frank Turley
Frank Turley
 
Overview of PRINCE2
iHub
 
Framework for Project Layout Meeting
dmdk12
 
An Introduction to PRINCE2 (book)
Frank Turley
 
7 Themes of Prince2
Barry Hodge
 
PRINCE2 Foundation Course Material
stefanhenry
 
PRINCE2 Process Model
projectingIT
 
AXELOS - PRINCE2® Foundation
Mirosław Dąbrowski C-level IT manager, CEO, Agile, ICF Coach, Speaker
 
Ad

Similar to Understanding PRINCE 2® (20)

PDF
CHEN4520MinorDesign
Curtis Edwards
 
PPTX
Unit-9 Notes.pptx
MayThuZarWin
 
DOCX
1.  Describe the rational for constructing a new building to be wa.docx
gasciognecaren
 
PDF
Sample lld document v1.0
Tom Mark Giembicki
 
DOCX
CHEN4530URS2Report
Curtis Edwards
 
PDF
Financial capability-review
KROTOASA FOUNDATION
 
PDF
Financial capability-review
KROTOASA FOUNDATION
 
PDF
High Performance Green Building: What is it worth?
scottbrooker
 
DOC
Sd pragathi template abap reports and flow charts of sd
Mohammed Azhad
 
PDF
Agendas For 21st Century Engineers 1st Edition Caroline Brandt David Prescott...
karnygelati
 
DOCX
Task 1 Define Project and Develop Plan 1. Project Scope 2-.docx
josies1
 
PDF
Deller rpl thesis
Linda Meyer
 
PDF
Dr. Karen Deller RPL Thesis
CIMAP
 
PDF
Integrated project-delivery
Ibrahim Al-Hudhaif
 
PDF
Pmp exam-preparation-boot-camp-participant-manual-locked 5 2
Danilo Bruch Martins
 
PDF
Professional android 2 application development (2010) (malestrom)
José Roberto Siqueira
 
PDF
Prediction of housing price
Ashish Kumar Jena
 
PDF
Design Fridays
Kirrily Murphy
 
PDF
CRM
Rajeev Singh
 
PDF
Revising Green Infrastructure Concepts Between Nature And Design Czechowski
wokilsamaey
 
CHEN4520MinorDesign
Curtis Edwards
 
Unit-9 Notes.pptx
MayThuZarWin
 
1.  Describe the rational for constructing a new building to be wa.docx
gasciognecaren
 
Sample lld document v1.0
Tom Mark Giembicki
 
CHEN4530URS2Report
Curtis Edwards
 
Financial capability-review
KROTOASA FOUNDATION
 
Financial capability-review
KROTOASA FOUNDATION
 
High Performance Green Building: What is it worth?
scottbrooker
 
Sd pragathi template abap reports and flow charts of sd
Mohammed Azhad
 
Agendas For 21st Century Engineers 1st Edition Caroline Brandt David Prescott...
karnygelati
 
Task 1 Define Project and Develop Plan 1. Project Scope 2-.docx
josies1
 
Deller rpl thesis
Linda Meyer
 
Dr. Karen Deller RPL Thesis
CIMAP
 
Integrated project-delivery
Ibrahim Al-Hudhaif
 
Pmp exam-preparation-boot-camp-participant-manual-locked 5 2
Danilo Bruch Martins
 
Professional android 2 application development (2010) (malestrom)
José Roberto Siqueira
 
Prediction of housing price
Ashish Kumar Jena
 
Design Fridays
Kirrily Murphy
 
CRM
Rajeev Singh
 
Revising Green Infrastructure Concepts Between Nature And Design Czechowski
wokilsamaey
 
Ad

Recently uploaded (20)

PDF
Robin Fischer: A Visionary Leader Making a Difference in Healthcare, One Day ...
The lifescience magaizne
 
PDF
Charisse Litchman: A Maverick Making Neurological Care More Accessible
The lifescience magaizne
 
PDF
Kishore Vora - Best CFO in India to watch in 2025.pdf
insightssuccess2
 
PPTX
BUSINESS CYCLE_INFLATION AND UNEMPLOYMENT.pptx
TasmiaThalil
 
PDF
ICv2 White Paper - Gen Con Trade Day 2025
DennisViau
 
PDF
Family Law: The Role of Communication in Mediation (www.kiu.ac.ug)
publication11
 
PPTX
operations management : demand supply ch
JayeshJaiswal23
 
PPTX
2 - Self & Personality 587689213yiuedhwejbmansbeakjrk
inshu28231804
 
DOCX
Handbook of Entrepreneurship- Chapter 5: Identifying business opportunity.docx
DrSubinKMohan
 
DOCX
Center Enamel Powering Innovation and Resilience in the Italian Chemical Indu...
cecvessels
 
DOCX
Hand book of Entrepreneurship 4 Chapters.docx
DrSubinKMohan
 
PDF
Daniels 2024 Inclusive, Sustainable Development
CMassociates
 
PDF
income tax laws notes important pakistan
VrindaTayade1
 
PPTX
basic introduction to research chapter 1.pptx
sangeethanagaraj8
 
PDF
Keppel_Proposed Divestment of M1 Limited
KeppelCorporation
 
PPTX
IITM - FINAL Option - 01 - 12.08.25.pptx
MukeshAssociates2
 
PDF
NEW - FEES STRUCTURES (01-july-2024).pdf
priyansubarmanwork
 
PPTX
chapter 2 entrepreneurship full lecture ppt
annejo20
 
PPTX
Slide gioi thieu VietinBank Quy 2 - 2025
hoadm5190
 
PDF
Solaris Resources Presentation - Corporate August 2025.pdf
pchambers2
 
Robin Fischer: A Visionary Leader Making a Difference in Healthcare, One Day ...
The lifescience magaizne
 
Charisse Litchman: A Maverick Making Neurological Care More Accessible
The lifescience magaizne
 
Kishore Vora - Best CFO in India to watch in 2025.pdf
insightssuccess2
 
BUSINESS CYCLE_INFLATION AND UNEMPLOYMENT.pptx
TasmiaThalil
 
ICv2 White Paper - Gen Con Trade Day 2025
DennisViau
 
Family Law: The Role of Communication in Mediation (www.kiu.ac.ug)
publication11
 
operations management : demand supply ch
JayeshJaiswal23
 
2 - Self & Personality 587689213yiuedhwejbmansbeakjrk
inshu28231804
 
Handbook of Entrepreneurship- Chapter 5: Identifying business opportunity.docx
DrSubinKMohan
 
Center Enamel Powering Innovation and Resilience in the Italian Chemical Indu...
cecvessels
 
Hand book of Entrepreneurship 4 Chapters.docx
DrSubinKMohan
 
Daniels 2024 Inclusive, Sustainable Development
CMassociates
 
income tax laws notes important pakistan
VrindaTayade1
 
basic introduction to research chapter 1.pptx
sangeethanagaraj8
 
Keppel_Proposed Divestment of M1 Limited
KeppelCorporation
 
IITM - FINAL Option - 01 - 12.08.25.pptx
MukeshAssociates2
 
NEW - FEES STRUCTURES (01-july-2024).pdf
priyansubarmanwork
 
chapter 2 entrepreneurship full lecture ppt
annejo20
 
Slide gioi thieu VietinBank Quy 2 - 2025
hoadm5190
 
Solaris Resources Presentation - Corporate August 2025.pdf
pchambers2
 

Understanding PRINCE 2®

  • 1. Ken Bradley’s Understanding PRINCE 2® PRINCE is a Registered Trademark of CCTA
  • 2. Ken Bradley’s Understanding PRINCE 2 ISBN 1 902192 00 1 Published by: SPOCE Project Management Limited Homelife House Oxford Road Bournemouth, Dorset BH8 8EZ Telephone & Fax: 01202-780740 Switchboard: 01202-319987 E-Mail: enquiries@spoce.com Information: www.spoce.com PRINCE is a Registered Trademark of CCTA © Ken Bradley 1997 First Published October 1997 Revised and reprinted February 1999 All rights reserved by the copyright holder and the licensee. No part of this publication may be reproduced in any material form (including photocopying and/or storage in any medium by electronic means and whether or not transiently or incidentally to some other use of this publication) without the written permission of the copyright holder identified above, except in accordance with the provisions of the Copyright Designs and Patents Act 1988. Applications for the copyright holder’s written permission to reproduce any part of this publication should be addressed to the publisher at the address above. 2
  • 3. Ken Bradley’s Understanding PRINCE 2 Dedication This book is dedicated to the many clients and friends who over the past two decades have put their trust and key projects into my hands, often for just the first few critical weeks of life and sometimes for support from cradle to grave. Thanks also go to the “SPOCETTES” Carol and Livia who have used their charm and charisma to ensure that this project was delivered on time, to the agreed plan and only marginally over budget! Ken Bradley What Others Say About This Book “An excellent companion to the CCTA PRINCE 2 Reference Manual. The many clear diagrams and supporting text answer the questions What should I do now? – and Why?” Martin Shepherd ICL HR Consultancy “This book provides a comprehensive and practical exposition of the PRINCE 2 Method and truly lives up to its title. Ken Bradley’s practical experience of managing projects, together with his understanding of the needs of Project Managers, whether new to the profession or old hands, gleaned from many years of providing consultancy and training is evident through the techniques and best practice tips that abound in this publication.” Dave Rose, Principal Consultant Project Management Devon IT Services 3
  • 5. Ken Bradley’s Understanding PRINCE 2 LIST OF CONTENTS Foreword ................................................................................................................................... 13 Who This Publication Is Intended For ......................................................................................... 13 Origins Of The PRINCE 2 Method .............................................................................................. 17 The PROMPT Methodology ........................................................................................................ 17 Government PROMPT................................................................................................................ 17 The Standard PROMPT Lifecycle ............................................................................................... 18 PROMPT Organisation - Stage Managers................................................................................... 18 PROMPT Planning..................................................................................................................... 19 The Enhancement Project And PRINCE...................................................................................... 19 PRINCE 2 And Other Developments ........................................................................................... 20 Introduction To PRINCE 2.......................................................................................................... 25 Benefits Of PRINCE 2 ................................................................................................................ 25 The Structure Of A PRINCE 2 Project......................................................................................... 26 The Key Elements Contained In PRINCE 2 ................................................................................. 28 The PRINCE 2 Processes............................................................................................................ 29 The PRINCE 2 Components:....................................................................................................... 30 The PRINCE 2 Techniques.......................................................................................................... 32 The Organisation Component ..................................................................................................... 33 The Project Board ...................................................................................................................... 34 The Project Manager.................................................................................................................. 35 The Team Manager..................................................................................................................... 35 Project Resources And (Specialist) Teams................................................................................... 36 Project Assurance....................................................................................................................... 36 Project Support .......................................................................................................................... 37 The Project Support Office.......................................................................................................... 37 Summary Of The Organisation Component ................................................................................. 37 5
  • 6. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Planning.................................................................................................................... 38 Products Or Deliverables And Related Activities........................................................................ 38 Planning For The Delivery Of Specialist Products ...................................................................... 40 Resource Planning & Reporting.................................................................................................. 41 Quality Planning -BS/EN/ISO9001 ............................................................................................. 42 Tolerance And Planning ............................................................................................................. 43 The Controls Component ............................................................................................................ 44 Management Controls ................................................................................................................ 44 Project Initiation ........................................................................................................................ 44 End Stage Assessment (ESA)....................................................................................................... 45 Mid Stage Assessment (MSA) ...................................................................................................... 45 Tolerance ................................................................................................................................... 46 Project Closure .......................................................................................................................... 47 Highlight Reports ....................................................................................................................... 48 Stages......................................................................................................................................... 48 Business Benefits And Risk Management..................................................................................... 49 Planning For Quality.................................................................................................................. 50 Quality Controls - Quality Review............................................................................................... 50 Change Control.......................................................................................................................... 52 Configuration Management ........................................................................................................ 52 Filing Arrangements................................................................................................................... 53 Software Support For PRINCE 2 ................................................................................................ 53 Following This Introduction........................................................................................................ 54 PRINCE 2 Organisation - Introduction ....................................................................................... 57 Responsibilities In A PRINCE 2 Controlled Project.................................................................... 58 The Project Board ...................................................................................................................... 58 The Executive Role ..................................................................................................................... 59 The Senior User Role.................................................................................................................. 59 6
  • 7. Ken Bradley’s Understanding PRINCE 2 The Senior Supplier Role ............................................................................................................ 59 Responsibilities Of The Project Board Members.......................................................................... 59 The Project Assurance Function ................................................................................................. 60 Delegation Of Day-To-Day Project Assurance ............................................................................ 61 The Project Manager.................................................................................................................. 61 Team Manager(s) ....................................................................................................................... 62 Responsibilities Of The Team Manager....................................................................................... 63 Team Managers And Technical Stages ........................................................................................ 64 Project Support .......................................................................................................................... 64 Customer:Supplier Environment ................................................................................................. 65 Developments On The PRINCE 2 Theme..................................................................................... 66 The Supplier Project Board ........................................................................................................ 67 Customer: Supplier Steering/Co-Ordinating Group..................................................................... 68 Customer: Supplier Project Manager.......................................................................................... 69 Customer:Supplier - Project Support .......................................................................................... 69 Organising The Managing Of Programmes................................................................................. 69 Programme Board, Programme Manager & Programme Support ............................................... 70 User/Customer Group In A Programme Context ......................................................................... 71 Individual Project Boards In A Programme Context.................................................................... 71 Project Support & Programme Assurance................................................................................... 71 Programme And Project Resources............................................................................................. 72 Other Structures Based On PRINCE 2 ........................................................................................ 72 PRINCE 2 Organisation - Summary........................................................................................... 74 Planning - Introduction & Overview ........................................................................................... 76 Project Level Plans..................................................................................................................... 77 Product Breakdown Structure ..................................................................................................... 78 Product Flow Diagram ............................................................................................................... 80 PERT Network............................................................................................................................ 81 7
  • 8. Ken Bradley’s Understanding PRINCE 2 The PERT Logic Network & The Timed Network......................................................................... 81 Earliest Start Gantt Plan ............................................................................................................ 82 Resource Smoothing ................................................................................................................... 82 Project Gantt Plan...................................................................................................................... 84 Project Resource Reporting ........................................................................................................ 84 Graphical Summary.................................................................................................................... 85 Earned Value Analysis................................................................................................................ 86 Risk Analysis .............................................................................................................................. 87 Measuring The Business Benefits ................................................................................................ 88 Project Plan Text........................................................................................................................ 89 Management Stage Plans............................................................................................................ 89 Team Plans ................................................................................................................................ 91 Individual Plans ......................................................................................................................... 91 PRINCE 2 Planning - Summary .................................................................................................. 91 Introduction To Controls ............................................................................................................ 94 Management Controls ................................................................................................................ 94 The Project Initiation Meeting .................................................................................................... 95 Project Initiation & The Project Initiation Document (PID) ........................................................ 96 End Stage Assessment (ESA)....................................................................................................... 96 Attendees At An End Stage Assessment........................................................................................ 97 End Stage Assessment Agenda .................................................................................................... 97 Mid Stage Assessment (MSA) ...................................................................................................... 98 Tolerance ................................................................................................................................... 99 Project Closure ........................................................................................................................ 102 Highlight Reports ..................................................................................................................... 102 Checkpoint Reports .................................................................................................................. 103 Stages....................................................................................................................................... 103 Management & Technical Stages .............................................................................................. 107 8
  • 9. Ken Bradley’s Understanding PRINCE 2 Management Stages.................................................................................................................. 108 Updating The Business Case..................................................................................................... 108 Technical Stages....................................................................................................................... 109 Handling The End Of A Management Stage .............................................................................. 109 Stages - Summary ..................................................................................................................... 110 Risk Management - Introduction ............................................................................................... 113 Risk Ranges & Risk Factors...................................................................................................... 114 Updating The Risk Analysis ...................................................................................................... 115 Modifying The Risk Analysis Checklist ...................................................................................... 116 PRINCE 2 &BS/EN/ISO9001.................................................................................................... 123 Quality Management ................................................................................................................ 123 Customer Quality Expectations................................................................................................. 124 Quality Aspects For Suppliers & Sub-Contractors..................................................................... 124 Quality Management - Summary............................................................................................... 125 Configuration Management - Introduction ................................................................................ 129 Configuration Management Techniques .................................................................................... 129 CM Activities............................................................................................................................ 130 Change Control - Introduction.................................................................................................. 135 Project Issue............................................................................................................................. 135 Off Specifications ..................................................................................................................... 136 Request For Change ................................................................................................................. 136 Change Control Forms And Documentation.............................................................................. 136 Change Control - Summary ...................................................................................................... 137 Introduction To Processes ......................................................................................................... 141 The Processes........................................................................................................................... 141 The PRINCE 2 Process Model .................................................................................................. 142 Major Processes And Processes ................................................................................................ 143 Structure Of The Individual Process Models.............................................................................. 145 9
  • 10. Ken Bradley’s Understanding PRINCE 2 Individual Process Summary Models........................................................................................ 147 Starting Up A Project (SU) - Introduction ................................................................................. 151 SU1 - Appointment Of A Project Board Executive And A Project Manager ................................ 152 SU2 & SU3 - The Project Management Team ............................................................................ 153 SU5 - The Project Approach: .................................................................................................... 156 SU6 - The Initiation Stage Plan................................................................................................. 157 Starting Up A Project - Summary .............................................................................................. 158 Initiating A Project (IP) - Introduction ...................................................................................... 163 The Project Initiation Document ............................................................................................... 163 IP1 - Planning For Quality ....................................................................................................... 165 IP2 - Planning A Project........................................................................................................... 166 IP3 - Refining The Business Case & Risks................................................................................. 168 IP4 - Setting Up Project Controls.............................................................................................. 169 Project Board Controls ............................................................................................................. 169 Project Manager/Team Controls: .............................................................................................. 170 IP5 - Set Up Project Files ......................................................................................................... 171 IP6 - Assembling The Project Initiation Document .................................................................... 173 Approach To Assembling Or Producing The PID....................................................................... 174 Initiating A Project (IP) - Summary........................................................................................... 175 Directing A Project (DP) - Introduction .................................................................................... 181 Management By Exception........................................................................................................ 182 DP1 – Authorising Initiation..................................................................................................... 183 DP2 – Authorising A Project..................................................................................................... 184 DP3 – Authorising A Stage Or Exception Plan.......................................................................... 185 Approval Of Exception Plans .................................................................................................... 186 DP4 – Giving Ad-Hoc Direction ............................................................................................... 188 DP5 – Confirming Project Closure............................................................................................ 189 Summary Of The DP Process .................................................................................................... 191 10
  • 11. Ken Bradley’s Understanding PRINCE 2 Controlling A Stage (CS) - Introduction .................................................................................... 197 CS1 – Authorising A Work Package .......................................................................................... 199 CS2 – Assessing Progress ......................................................................................................... 200 CS3 - Capturing Project Issues ................................................................................................. 202 CS4 - Examining Project Issues ................................................................................................ 203 CS5 - Reviewing Stage Status.................................................................................................... 204 CS6 - Reporting Highlights....................................................................................................... 205 CS7 - Taking Corrective Action ................................................................................................ 207 CS8 - Escalating Project Issues................................................................................................. 208 CS9 - Receiving A Completed Work Package ............................................................................ 209 Summary Of The Controlling A Stage Process........................................................................... 210 Managing Product Delivery (MP) - Introduction ....................................................................... 215 MP1 - Accepting A Work Package............................................................................................. 217 MP2 - Executing A Work Package............................................................................................. 218 MP3 - Delivering A Work Package............................................................................................ 219 Managing Stage Boundaries (SB) - Introduction ....................................................................... 223 Exception Plans........................................................................................................................ 224 SB1 - Planning A Stage............................................................................................................. 225 SB2 - Updating A Project Plan ................................................................................................. 226 SB3 - Updating A Project Business Case................................................................................... 227 SB4 -Updating The Risk Log..................................................................................................... 228 SB5 - Reporting Stage End........................................................................................................ 229 SB6 - Producing An Exception Plan.......................................................................................... 231 Summary Of The Managing Stage Boundaries Process.............................................................. 232 Closing A Project (CP) - Introduction ....................................................................................... 237 CP1 - Decommissioning A Project ............................................................................................ 239 CP2 - Identifying Follow-On Actions ........................................................................................ 241 CP3 – Project Evaluation Review............................................................................................. 242 11
  • 12. Ken Bradley’s Understanding PRINCE 2 Summary Of The Closing A Project Process.............................................................................. 243 Planning (PL) - Introduction.................................................................................................... 247 PL1 - Designing A Plan ............................................................................................................ 249 PL2 - Identifying, Defining And Analysing Products.................................................................. 250 PL3 - Identifying Activities And Dependencies .......................................................................... 252 PL4 - Estimating....................................................................................................................... 253 PL5 - Scheduling ...................................................................................................................... 254 PL6 - Analysing Risks............................................................................................................... 255 PL7 - Completing A Plan.......................................................................................................... 256 Summary Of The Planning (PL) Process ................................................................................... 257 PRINCE 2 Filing Technique - Introduction ............................................................................... 261 The Management File ............................................................................................................... 261 Physical Filing Considerations ................................................................................................. 266 Quality Review Technique - Introduction .................................................................................. 269 Quality Assurance And Quality Control .................................................................................... 269 What Is A Quality Review?........................................................................................................ 269 Quality Reviews - Formal And Informal .................................................................................... 270 People Involved ........................................................................................................................ 270 The Quality Review Steps......................................................................................................... 271 Step 1 - Preparation ................................................................................................................. 271 Step 2 - The Review Meeting .................................................................................................... 272 Step 3 - Follow-Up Of Review Meeting ..................................................................................... 273 Summary Of The Quality Review Technique.............................................................................. 274 Index ........................................................................................................................................ 277 12
  • 13. Ken Bradley’s Understanding PRINCE 2 FOREWORD This publication is based on the PRINCE 2 Project Management Methodology. It has been produced to help anybody involved in a PRINCE 2 controlled project to understand the approaches used in the Method. This re-print incorporates the additional material included in the new manual – “Managing Successful Projects with PRINCE 2” published in October 1998. The book aims to fill the gaps present in the PRINCE 2 Method – in order to do this certain assumptions have been made and these are based upon my own experience and understanding of the practical use of PRINCE. I hope you will not only find this publication of practical use in managing your projects but will also enjoy reading and learning from it. If you have any questions or observations about the content of this publication, please contact me at SPOCE Project Management Limited direct at (UK +44) 01202-780740 (Telephone & fax) or E-Mail KGB@spoce.com Ken Bradley February 1999 Who This Publication Is Intended For PRINCE 2 is the UK Government standard for managing large projects and has been widely adopted as the standard for project management for all types of projects within the private and public sectors. PRINCE 2 was officially launched on 1 October 1996. The book is aimed at Project Managers, project management staff, and anyone needing to organise, plan and control an undertaking using a structured project management approach. Although primarily a summary and interpretation of the PRINCE 2 project management method, this publication provides an excellent start point for anyone wishing to understand the principles and use of structured project management in any activity. It is also an invaluable aid for anyone wishing to take the CCTA/APMG PRINCE 2 examinations. 13
  • 15. Ken Bradley’s Understanding PRINCE 2 Chapter 1 UNDERSTANDING THE BACKGROUND TO THE PRINCE METHODOLOGY 15
  • 17. Ken Bradley’s Understanding PRINCE 2 Origins of the PRINCE 2 Method The PRINCE Methodology is a development of the PROMPT Methodology (Project Resource Organisation Management Planning Technique) originally formulated in the mid 1970s. A private sector company, Simpact Systems Limited, evolved the PROMPT Methodology to provide a suitable framework within which to manage the strategy, feasibility study, development and support of Information Technology systems through a structured project management approach. The PROMPT Methodology The PROMPT Methodology comprised five major components: ♦ PROMPT I - Strategic Planning ♦ PROMPT II - System Development ♦ PROMPT III - Operations, Maintenance and Enhancement ♦ QSTAR Quality Assurance ♦ PROMPT Software Support Tools (The PROMPT Aids). Government PROMPT In the early 1980s, the UK Government published a requirement for a project management method to improve the management and control of government IT projects. Many different methods were proposed and evaluated, and the contract to license the use of the Method was awarded to Simpact Systems Limited. CCTA (Central Computer and Telecommunications Agency) acting for the UK Government commissioned some changes in the basic methodology. Chief amongst these was the incorporation of the quality assurance aspects into the PROMPT II Methodology to provide a product that was to become referred to as “Government PROMPT”. Although CCTA licensed all the PROMPT Methodology, PROMPT II was the only element fully implemented. The belief was that Government Departments were already well supported in the production of strategic plans, and that maintenance and enhancement aspects would be easily handled providing development systems were properly supported by development and quality assurance documentation. PROMPT II was therefore considered to be the key ingredient for success. Government PROMPT, incorporating PROMPT II principles only was introduced into the major UK Government Departments in Spring 1983. 17
  • 18. Ken Bradley’s Understanding PRINCE 2 The Standard PROMPT Lifecycle Government PROMPT had a number of deficiencies from the start; for instance, a pre- defined lifecycle provided the backbone for a PROMPT II project, but this caused some problems with its view that IT projects broke down into standard stages of work addressing Initiation, Specification, Design, Development, Installation, and Operation. Many projects did not conform to this formula and inconsistencies were encountered. Initiation Specification Design Development Installation Operation The PROMPT II “Planning” Stages The PROMPT II “Action” Stages Figure 1: The PROMPT Standard Six Stage Lifecycle PROMPT Organisation - Stage Managers The PROMPT II Method made no mention of Project Managers, instead relying on a series of Stage Managers, each responsible for a pre-defined stage within the standard six stage lifecycle. The philosophy was that this left the way open to appoint the most appropriate individual to manage each Stage of the project. The Specification Stage managed by a User/Customer, the Design Stage by a Designer/Analyst, the Development Stage by a Technical Programmer and the Installation and Operation Stages by User/Customers. The Initiation Stage was typically managed by someone with sufficient technical expertise to understand and plan the whole of the project. 18
  • 19. Ken Bradley’s Understanding PRINCE 2 Senior Management - Strategic Direction The Project Board Senior User Senior Technical Executive Assurance Stage 2 Manager Stage 4 Manager Stage 6 Manager Specification Development Operation Stage 1 Manager Stage 3 Manager Stage 5 Manager Initiation Design Installation Work Direction Administrative Support Project Assurance Team Project Resources & Development Teams * Business Assurance Co-ordinator * Technical Assurance Co-ordinator * User Assurance Co-ordinator Figure 2: The PROMPT Organisation Structure PROMPT Planning The Government PROMPT Methodology also made no mention or use of Critical Path Analysis, which was used extensively in major projects. In practice these omissions did not cause real problems as training courses and consultancy support filled the gaps. However the methodology was perceived as being not quite complete, or indeed, relevant to many projects. The Enhancement Project and PRINCE During 1987, CCTA determined to update the Methodology by reflecting the actual usage of PROMPT II and by introducing modern project management ideas. These elements were Product-based planning, formal Project Initiation procedures, a Project Manager role, sharper focus on Quality Management, and Open Life-cycle planning. Leading consultancy companies in project and quality management were contracted to work with the PROMPT User Group and CCTA to incorporate the changes. 19
  • 20. Ken Bradley’s Understanding PRINCE 2 CCTA were keen to place the enhanced method into the public domain, as an open method, in order to enable suppliers of major IT systems (and their component parts) to adhere to consistent standards when fulfilling UK Government contracts. The overall objective was to provide a high-level of consistency throughout government projects and to improve project management generally. Meanwhile, LBMS (Learmonth & Burchett Management Systems) a major management consultancy company, who had developed SSADM (Structured Systems Analysis and Design Methodology) under a CCTA contract, had acquired the PROMPT products and name from Simpact Systems (which had ceased its commercial operations) and was licensing the methodology successfully to the public and private sectors. LBMS obviously could not agree to an enhanced version of PROMPT II being placed in the public domain in direct competition with their own proprietary method, and negotiations provided that the enhanced method be re-named PRINCE (Projects in Controlled Environments) to meet this point. PRINCE was introduced in April 1989 with full documentation and formal entry into the public domain in January 1990. The PRINCE Methodology is now the UK Government Standard for managing major projects. It has been widely adopted by private sector companies both for use in government projects, and in many cases for their own internal use. CCTA, with its collaborative partners (The Association for Project Management Group, IBM UK Limited, and The Stationery Office) continues to pursue the acceptance of PRINCE as “best practice” project management within the UK, Europe and worldwide. PRINCE 2 and Other Developments PRINCE 2 has now been developed, funded by CCTA and following extensive consultation with users and organisations over a two year period. PRINCE 2 is “Process- driven” (ie “what” and “why” but little in the way of “how”) addresses a wider base of projects (IT and non-IT), Programmes of Work, Smaller Projects, Customer:Supplier: issues and introduces changes to the PRINCE version 1 Organisation component. PRINCE 2 was formally launched by CCTA in London on 1 October 1996. CCTA are working in collaborative partnership with a number of organisations (IBM (UK), The Stationery Office and the Association for Project Management Group) to promote PRINCE. One of the partners, IBM (UK) Limited, has developed a software support product based on their existing Process Integrator application, which provides a full PRINCE 2 Environment, enabling the launch of specific software for planning, word- processing and other office applications. The package is particularly useful for managing the myriad of project documentation that has to be created, updated, tracked and managed during the life of a project. With PRINCE 2, CCTA has launched an accreditation and certification scheme providing a vehicle for assuring users of PRINCE 2 that training and consultancy providers are registered as competent and that training courses reflect a common syllabus with examinations and certification at its conclusion. 20
  • 21. Ken Bradley’s Understanding PRINCE 2 CCTA continue to support and develop the PRINCE 2 Method and a contribution is levied from all those taking the APM Group Professional Examinations and registering as trained PRINCE 2 Practitioners. Future plans include companion volumes covering the “softer” aspects of project management (leadership, delegation, appraisal etc) and Programme Management, Risk Management, including examinations on these topics. Further information can be obtained from CCTA Information Services on telephone: (UK +44) (0)1603 704787 21
  • 23. Ken Bradley’s Understanding PRINCE 2 Chapter 2 UNDERSTANDING THE BASICS 23
  • 25. Ken Bradley’s Understanding PRINCE 2 Introduction to PRINCE 2 PRINCE (PRojects IN Controlled Environments) is a structured method for effective management of any size or type of project. It is the standard method for use in UK Government Departments and is widely used in the private sector, NHS and Local Government. A growing number of overseas Governments and multi-national companies have adopted the method, or integrated it within their existing project management approaches. The Method is being promoted actively by the APM Group (APMG) as a “Best Practice” project management approach. Benefits of PRINCE 2 There are a number of benefits to be gained from introducing and using a structured approach to project management; among the benefits of using PRINCE 2 are that it: ♦ identifies management, technical (specialist) and quality Products or Deliverables and helps ensure that they are produced on time and to budget; ♦ focuses attention on the quality of Products or Deliverables; ♦ separates the management and technical/specialist aspects of Organisation, Planning and Control; ♦ facilitates control at all levels; ♦ makes the project’s progress more visible to management; ♦ provides a communication medium for all staff working on the project; ♦ ensures that work progresses in the correct sequence; ♦ involves senior management in the project at the right time and in the right place; ♦ allows the project to be stopped and, if required, re-started completely under management control, at any time in the project’s life; ♦ is in the Public Domain and requires no license fee; ♦ has a well established User Group dedicated to the support, promotion and strengthening of the method. 25
  • 26. Ken Bradley’s Understanding PRINCE 2 The Structure Of A PRINCE 2 Project Within a PRINCE 2 project environment, each project which is undertaken must: ♦ address all the processes concerned with establishing an effective project management environment; ♦ have a stated business case indicating the benefits and risks of the venture; ♦ demonstrate a properly defined and unique set of Products or Deliverables; ♦ have a corresponding set of activities to construct the Products or Deliverables; ♦ identify appropriate resources to undertake the activities; ♦ have a finite life-span; suitable arrangements for control; ♦ identify an organisation structure with defined responsibilities; ♦ include a set of Processes with associated techniques which will help plan and control the project and bring it to a successful conclusion. A PRINCE 2 project is divided into a number of Management Stages, each forming a distinct unit for management purposes. Like the project, a Stage is driven by a series of Processes, has a defined set of products and activities, a finite life-span, control elements, and an organisational structure. The delivery of these products, to the agreed quality standards, marks the completion of the Management Stage. PRINCE 2 defines: ♦ the organisation of the project and its stages; ♦ the processes which drive the undertaking; ♦ the structure and content of the project plans; ♦ basic project management techniques; ♦ a set of controls which ensure that the project is proceeding to plan. These, together with the products of the project and the activities which produce them, the project business case, all encompassed within a Quality Management framework, make up the PRINCE 2 environment. All products of a PRINCE 2 project are filed within a defined structure - the "Configuration". Management, Specialist and Quality Products are identified and filed separately. The PRINCE 2 framework provides the flexibility to set stage boundaries which are appropriate to the needs of the project. Management Stage boundaries are chosen according to: 26
  • 27. Ken Bradley’s Understanding PRINCE 2 ♦ the sequence of production of Products/Deliverables; ♦ the grouping of Products into self-contained sets or associated Processes; ♦ natural decision points for review and commitment of resources; ♦ the risks and business sensitivity of the project; ♦ the completion of one or more discrete Processes. The project stages correspond to the steps in the natural project life-cycle towards the eventual outcome. Thus the stage boundaries are normally defined to correspond to the completion of the major Products to be built and key decisions concerning commitment of resources that need to be made. Whatever the nature of the project, it is advisable to define one or more planning and/or definition processes in the early part of the project's life. PRINCE 2 provides two Processes to cater for this - “Starting Up A Project (SU)” (where the early foundations for decision support are laid) and “Initiating A Project (IP)” (where senior management are invited to commit to the undertaking and a baseline is produced. The project is triggered by a “Project Mandate” which might take any form from an informal request by a sponsor to a formal recommendation from a report. PRINCE 2 recognises that few projects will be undertaken entirely in isolation. The outputs from one project may be used as input by another project. There may be other dependencies between projects, such as the use of shared resources. PRINCE 2, therefore, provides a mechanism for defining the boundary of a project and its relationship to other projects. A high-level context diagram is a useful mechanism for defining these relationships. Key User Groups Current System Business Processes Cleaned Data The Project Under Development Bullet List of the Main Functions to be produced, developed or bought-in Information Parts Requisitions MIS Project Central Logistics Project Figure 3: Scoping Diagram showing Inputs and Outputs for the Project The Scoping Diagram illustrated above is particularly useful when planning and managing a Programme of Work where individual projects inter-relate with each other and it is necessary to ensure that expected outputs from individual projects are anticipated and planned for. When all individual project Context Diagrams are assembled to complete the 27
  • 28. Ken Bradley’s Understanding PRINCE 2 programme “jigsaw” it will be apparent which outputs and inputs do not match, and appropriate action can be taken by the Programme Director/Manager. The Key Elements Contained In PRINCE 2 To understand the content of the PRINCE 2 Project Management Method, the following model showing the key elements should be studied: ORGANISATION STANDARDS & APPROACHES; BUSINESS STANDARDS & ETHICS QUALITY MANAGEMENT SYSTEM (QMS) (ISO9001) TECHNIQUES COMPONENTS PROCESSES * Product-Based Planning * Organisation * Starting Up A Project (SU) - Product Breakdown - Structure & Role Descriptions - Product Description * Initiating A Project (IP) - Product Flow Diagram * Planning - Products, Activities, Resources * Directing A Project (DP) * Quality Reviews * Controls * Controlling A Stage (CS) - Preparation, Review, - Management, Team, Quality Follow-up * Managing Product Delivery (MP) * Stages - Management & Technical Stages * Managing Stage Boundaries (SB) * Change Control - Capture, Logging, * Management of Risk * Closing A Project (CP) Assessment, Decision - Risk Assessment & Management * Planning (PL) * Quality in a Project Environment * Project Filing Structure - Quality Requirements & Response - Management File THE BUSINESS CASE - Specialist File * Configuration Management * Business Benefits - Quality File - Tracking Products & Documentation + Existing Organisation * Change Control RISK MANAGEMENT Techniques already used - Capture & Assessment * Risk Analysis & Actions within the host organisation * Risk Management PRINCE 2 SOFTWARE SUPPORT ENVIRONMENT EXPERIENCE, BEST PRACTICE, COMMONSENSE Figure 4: Summary Model of the PRINCE 2 Method The PRINCE 2 methodology applies three key elements to each project and to the Management Stages within a project. These are summarised in the above Model and described, briefly, in the following tables. The three elements are the Processes which drive the project management, Components and Techniques, which are used by each of the Processes to effect the management of the project. 28
  • 29. Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Processes DESCRIPTION REF EXPLANATION Starting Up A Project SU Establishes the Objectives and Approach to the Project; Set up the Project Management Team; Plans for the Initiation Process. This is a pre- project Process, which looks to answer the question “do we have a worthwhile and viable project?” before asking for commitment of resources to set up a project environment. Initiating A Project IP Plans the whole Project in terms of its Products, Activities, Resource Usage and Quality; Sets the baseline for the Business Benefits & Risks. Directing A Project DP Provides Authorisation for work to be carried out and Resources to be committed. Authorisation for Project Initiation and Project Closure and, in some cases, its premature termination. The Process is “owned” by the Project Board – the ultimate authority for the Project - accountable for its overall success. Controlling A Stage CS The basic day-to-day project management Process - authorising work to create or change Products (or Deliverables), collecting and reflecting “actuals”, assessing progress and reporting to senior management. Capturing proposed changes and errors and escalating these, where appropriate to management. Managing Product Delivery MP The main “workshop” for the project where the majority of resources are consumed. This Process is where the Products of the Project are created. Progress reports (Checkpoint Reports) are provided to the Project Manager. Quality Review and Delivery of Products occurs here. Managing Stage Boundaries SB Reporting on the achievements of the Current Management Stage and the impact on the overall Project Plan and Business Case. Planning the Next Stage (Products, Activities, Resource Usage). Putting together Exception Plans when the Management Stage has suffered a significant departure from its approved plan. Closing A Project CP Preparation for closing the Project in an orderly way. Customer sign-off, preparation of an End- Project Report and identification of Lessons Learned and Follow-on Recommendations. Planning for a Post-Project Review. Planning PL Used by all the other Processes - a common-to- all Process featuring the design of the plan and its creation. 29
  • 30. Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Components: DESCRIPTION USED EXPLANATION BY Organisation SU Organisation Structure + Role Descriptions. SB Predominantly used in the “Starting Up A Project” Process where the Executive and Project Manager are appointed in the first Process, and the Project Management Team is designed and appointed. The Project Management Team is reviewed at the end of each Management Stage within “Managing Stage Boundaries”. Planning SU All Processes use the Planning Component. The IP Initiation of the project is planned during CS “Starting Up A Project”; the project itself is MP planned in “Initiating A Project”; Stage plans SB are prepared in “Managing Stage Boundaries”; CP and Product planning is carried out in PL “Controlling A Stage” and “Managing Product DP Delivery”. Follow-on actions, including preparation of a Post-Project Review Plan are put together in “Closing A Project”. “Directing A Project” uses the approved plans throughout to confirm the required progress. Controls SU All the Processes use the Controls Component. IP The “control” Processes which make particular CS use of this Component are “Initiating A Project” MP (which sets up the overall project control SB structure); “Controlling A Stage” (which uses CP Checkpoint Reports to capture progress, and PL records actual usage of resources. Highlight DP Reports are used to inform the Project Board of progress); “Managing Product Delivery” generates Checkpoint Reports for control purposes. Stage approval is handled by “Managing Stage Boundaries” where Management Stages are approved via End Stage Assessments. This Process also uses Exception Reporting and Planning to control significant departures from plan. “Directing A Project” is the Process within which overall authorisations are made; this Process uses the key controls of End Stage Assessment, Tolerance, Project Initiation and Project Closure. 30
  • 31. Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Components (Continued) Stages IP Management Stages provide the key control for SB the Project Board and are mainly used by CS “Directing A Project” when authorising DP commitment for expenditure. Technical Stages often overlap and run in parallel; Management Stages may not. The key control Processes use Management Stages in planning and control of the project. Management of Risk SU Risk Analysis is carried out initially in “Starting IP Up A Project” when the Project Brief is created. SB This is refined in “Initiating A Project” where DP the Business Case for the project is established. The Risk Analysis is updated during “Managing Stage Boundaries” to provide the basis for decision support for the Project Board when they review the project at the End Stage Assessment in “Directing A Project”. No specific risk analysis tools or techniques are recommended. Management of risk has close ties with the Business Benefits which are measured and presented as the Business case for the project. Both the Business Case and the Risk Analysis are up-dated, minimally, at the end of each Management Stage. Quality In A Project SU The Customer’s Quality Expectations are first Environment IP identified in “Starting Up A Project” and quality CS aspects are planned in “Initiating A Project”. MP When the project is approved, “Controlling A PL Stage” and “Managing Product Delivery” enable specific Quality Criteria to be set for each Product or Deliverable via Product Descriptions described in the “Planning” Process. Configuration IP Configuration Management addresses the proper Management CS safeguarding and management of Products or MP Deliverables and their associated documentation. CP “Initiating A Project” sets up the Project Files and “Controlling A Stage” and “Managing Product Delivery” executes the Configuration Management arrangements. Project Files are archived in “Closing A Project” mainly for audit purposes. Change Control CS Managing proposals for change is an important aspect of project management and the Process “Controlling A Stage” is where such proposals are captured. 31
  • 32. Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Techniques DESCRIPTION EXPLANATION Product-Based Planning A “Product Breakdown Structure” which identifies the Products or Deliverables to be produced during the project. A “Product Description” for each Product identified in the Product Breakdown Structure, which defines and specifies each Product; a key feature of the Product Description is the Quality Criteria used to ensure that the Product is indeed a “Quality Product” that conforms to its requirements. A “Product Flow Diagram” which shows the relationship that each Product has with others and external entities; the Product Flow Diagram must “balance” with the Product Breakdown Structure. Quality Review Technique Used for measuring a Product or Deliverable against its published Quality Criteria. PRINCE 2 recognises Informal Quality Reviews (typically “Desk Checks”, Tests or Visual inspections) and Formal Quality Reviews (which are more structured “Walkthroughs” of a Product or Deliverable). Formal Quality Reviews comprise three distinct Phases - Preparation, The Review Meeting and Follow-Up. Change Control Every project must be able to accommodate changes required by the customer or anyone else who has an interest in the project’s outcome. All suggested changes, identified errors and departures from the agreed Specification must be captured as “Project Issues, logged, analysed for technical, customer and business impact, and a decision made on whether to accept or reject the Issue. Project Filing A suitable filing structure is suggested; this comprises a “Management File” made up of one Project File and a series of Stage Files - one for each of the Management Stages of the project. A Specialist File housing the documentation relating to the technical aspects of the project and a Quality File housing the Quality Review documentation and the Project Issues complete the structure. More on the PRINCE 2 Processes The eight major Processes state the minimum content that can be expected to be found in a PRINCE 2 compliant project. Exactly how the Processes are addressed within any project is the responsibility of the organisation’s senior management, represented by the Project Board, and the Project Manager, but the method requires that each of the eight Processes is reflected within the project one way or another. All the Processes link to Components and Techniques some of which are described within 32
  • 33. Ken Bradley’s Understanding PRINCE 2 the method. It is anticipated that most organisations will already be using some specific Techniques and might wish to incorporate additional Components reflecting their business environment and culture. PRINCE encourages this where they provide value to the management decision making process. Each Process is defined in the following terms: ♦ The Fundamental Principles that underpin the Process; ♦ The Context within which the Process operates; ♦ An Overview of the Process; ♦ Responsibilities identifying accountability for the Process; ♦ The Information Needs required for the Process to function effectively; ♦ The Key Criteria which will influence the success or failure of the Process; ♦ Hints and Tips for carrying out the Process in the best way. ♦ Major Processes have an additional “Scalability” heading to help with scaling down each Process for smaller, lower risk projects, where this is required by senior managers. The Process-based approach is a powerful feature in PRINCE 2 and is the area which most differentiates it from version 1 of the method. The flexibility of the method is, however, underlined by allowing implementing organisations to choose their own destiny in terms of identifying how to meet the requirements of any given Process. In most organisations already operating successful project management systems there will be little need to make changes to the way they are operating, provided effective project management procedures are already in place. The Organisation Component The organisation and effective use of people assigned to manage a project needs to be considered from the view point both of the specialist skills they bring to the project and their individual personalities. Responsibilities need to be defined within a team structure to ensure that management is both efficient and responsive, and that individuals understand exactly what is expected of them. Within PRINCE 2, responsibilities are defined in terms of roles, rather than individual’s jobs. Assignment of roles to individuals is a decision for each Project Board to take in the light of organisational circumstances, and the same individual may be assigned to more than one role, or to different roles at different stages of the project. Three roles/interests must always be represented on any PRINCE 2 project – Business, User, and Supplier. 33
  • 34. Ken Bradley’s Understanding PRINCE 2 Corporate or Programme Management The Project Board Senior User Senior Supplier Executive Project Assurance Project Manager Project Support Team Manager Team Manager Team Manager Project Resources & Teams Figure 5: The PRINCE 2 Organisation Structure The Project Board Every PRINCE 2 project will have a Project Board appointed. The Project Board is the ultimate authority for the project and is normally appointed by Corporate or Programme Management to take overall responsibility and control of a PRINCE 2 project. The Project Board consists of three senior management roles, each representing major project interests. ♦ Executive: appointed by Corporate/Programme Management to provide overall project guidance and assessment throughout. The Executive represents the interests of the Customer and the Business and has overall responsibility for the project. ♦ Senior User: representing users (and, where appropriate, Customers) of the outcome or the major products from the project. ♦ Senior Supplier: representing areas which have responsibility for providing the specialist “know-how” and/or committing Supplier resources for the solution. The Senior Supplier might be drawn from an external, commercial, organisation or from internal sources responsible for delivering the specialist “End Product” to the customer (or a mixture of both). 34
  • 35. Ken Bradley’s Understanding PRINCE 2 There is a requirement within the Method to have a Project Board function and this cannot be eliminated or delegated (although the terminology may be changed to suit the organisation’s culture, for example “The Project Authority”). The Project Board’s accountability for Project Assurance cannot be delegated although the day-to-day work of Project Assurance can if Project Board members do not have the time or expertise to carry out the tasks involved. The Project Manager A Project Manager will always be appointed to assume day-to-day responsibility for planning and management of the project throughout all its Management Stages. The Project Manager takes direction from the Project Board and is responsible for managing, on behalf of the Project Board, the Processes, planning and delivery of Products for the project, on-time, within budget, meeting the specialist/technical and quality criteria agreed with the Project Board. As with the Project Board, the role of Project Manager is a required role within the Methodology and cannot be shared, delegated or eliminated. The Team Manager In a large or complex project, one or more Team Managers may be assigned the responsibility for ensuring that the products of one or more particular Technical, or Specialist, Stages of work are planned, controlled and produced on schedule, to the defined and agreed quality standards, and within budget. Project Manager Project Support Team Manager Team Manager Team Manager Project Resources & Teams Figure 6: Project Manager and Team Manager Relationships The Team Manager role is optional and will only be present in large projects or where the Project Manager lacks the specialist skills to plan and control specific parts of the project. 35
  • 36. Ken Bradley’s Understanding PRINCE 2 Project Resources and (Specialist) Teams The Project and/or Team Manager have responsibility for Teams of specialist staff, tasked to carry out the activities and produce the Products of the stage. The team organisation, responsibility definitions and the allocation of these responsibilities to individuals will depend upon the size and nature of the project and the skill mix available. PRINCE 2 recognises the need to establish Team Manager roles where appropriate; Project Assurance PRINCE 2 separates the Project Assurance function from the Project Support function. The Project Board have responsibility and accountability for Project Assurance. Depending on the size, scope, risk and profile of the project, and their own knowledge, skills and time available, they may choose to delegate responsibility for overseeing day to day Project Assurance to others within the organisation. However, accountability for Project Assurance rests with the Project Board and they are not able to delegate this. Project Assurance may not be delegated to the Project Manager or to Team Managers. The Project Board Senior User Senior Supplier Executive User Assurance Specialist Assurance Business Assurance Project Assurance Figure 7: Project Board and Project Assurance Functions Although not specifically separated out in the PRINCE 2 Method, Project Assurance can be found in two distinct forms: ♦ External Assurance to confirm that the project is following overall and corporate standards (eg the published Quality Management System, or particular accounting conventions) and the organisation can be expected to have an audit function already in place to check these aspects. ♦ Internal Assurance to verify that the project is delivering Products or Deliverables that meet the agreed Quality Criteria and that internal project standards are being followed. Internal Assurance is ultimately the responsibility of the Project Board. 36
  • 37. Ken Bradley’s Understanding PRINCE 2 Project Support Within PRINCE 2, Project Support, on a formal basis, will only exist where there is a perceived need for it. A Project Manager may well find that the Project Board see no scope for any administrative support, and that any day-to-day assistance might need to be on an “ad-hoc” basis. Project Manager Project Support Figure 8: Project Manager and Project Support Relationships Where a project does warrant the appointment of a Project Support function, the individual(s) selected will report directly to the Project Manager. Incidental support for the Team Managers, where appointed, and Team resources will normally form part of Project Support’s responsibilities. The Project Support Office A Project Support Office might well evolve in a Programme or multi-project environment, to support a number of individual projects. The methodology supports the possibility of a transition from several Project Support individuals to a central Project Support Office where the number of projects under development warrants it. The resultant Project Support Office will be able to provide a centre of expertise for all project management aspects within the organisation/site, effectively delivering an internal consultancy service where required by Project Board members, Project Managers and project team members. Summary of The Organisation Component In the final analysis, it is the people who are responsible for the management of the project and the creation of its deliverables who have its success in their hands. Clear definition of responsibilities and a tenacious commitment to achieving agreed goals will always be the predominant factor in success. The PRINCE 2 Method must always be tuned to suit the implementing organisation’s existing standards, business approaches, culture and people; the latter two are arguably the most important. 37
  • 38. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Planning Estimating, planning and re-planning are constant and key activities when managing any project. PRINCE 2 provides a structure for preparing and maintaining plans at appropriate levels throughout the life of a project. Plans are prepared for the Project as a whole, for each stage within the project and, optionally, for the teams’ work within each Management Stage. There is also an Exception Reporting and Planning process to handle divergences from the original plan. The PRINCE 2 method include a Technique for Product-Based planning incorporating Activity planning, Resource reporting and Quality planning. Products or Deliverables and Related Activities PRINCE 2 provides a set of planning techniques which give structure to the project. The key to PRINCE 2 planning is the identification and definition of the Products required. From this comes an analysis of the work (ie the activities) required to generate these products, and the sequencing of the work. PRINCE makes a distinction between Management Products and Activities, Specialist Products and Activities, and Quality Products and Activities. This is partly because these are usually the concern of different groups of people, but also to ensure that management activities are not overlooked in planning and estimating. The Plan Text provides a high-level, overall view of Plan the plan, summarising its key features Text Product Identifying the Products/Deliverables that will be Breakdown produced by the Project. The Products will be categorised Structure under the headings of “Specialist”, “Management”, and “Quality” Products. Describing the Products/Deliverables that will be Product produced by the Project. There is a prescribed format Descriptions for Product Descriptions Describing the relationships that exist between Product each Product/Deliverable, and external entities. Flow Diagram PERT or Showing the relationships that extist between the Activities that will be undertaken Activity to create the Products identified in the Product Breakdown Structure. Network Gantt Derived from the PERT Network, this shows when Activities are or planned to start and end. Major Review points (End Stage Timescale Assessments) are also shown on this plan. Plan Figure 9: PRINCE 2 Plans Structure 38
  • 39. Ken Bradley’s Understanding PRINCE 2 Management activities are concerned with planning, monitoring and reporting the work of the project, in both normal and exceptional situations. They produce Management Products in the form of plans, reports and other control documents. Management activities include the planning and control of all specialist activities on the project. Although influenced by the specialist content, a similar pattern of management tasks can be expected to be present in any PRINCE 2 project. Conversely, the Specialist activities undertaken by a project are determined entirely by the scope and objectives of the project. The Specialist activities describe the work needed to produce the Specialist Products required from the project. The Specialist Products required by the user/customer are identified and defined at the start of the project by the Project Manager and accepted by the Project Board. Additional Specialist Products may be defined by the strategy appropriate to a particular Management Stage of the project; specialist activities may also be prescribed by an organisation’s own particular technical strategy. PRINCE 2 therefore acknowledges the need for flexibility in the selection and definition of Specialist activities and the corresponding Products. Completed Feasibility Study Management Products Specialist Products Quality Products MP01 - Project Initiation Document MP02 - Stage Plans FS 01 - Business review MP03 - Lessons Learned Log FS02 - Problem Definition QP01 - Product Descriptions MP04 - Risk Log FS03 - Options Identified & Agreed QP02 - Quality Review Documentation MP05 - Business Case FS04 - Options Appraised QP03 - Project Issues Log MP06 - Product Checklist FS05 - Selected Option Agreed QP04 - Quality Log MP07 - Highlight Reports FS06 - Final Report QP05 - Configuration Management MP08 - Project Start Notification MP09 - Project End Notification MP10 - Project Filing Structure The Technical Management Standard for the Project The Project Management The Quality Management Standard for the Standard for the Project Project Figure 10: Management, Quality and Specialist Products (For A Typical Feasibility Study) Quality activities may be performed by anyone who is able to make a contribution to the Product under review. Individuals within the project and host organisation as well as people external to the organisation are all appropriate. Quality activities must be planned for early in the life of the project. The PRINCE 2 Product planning techniques require every project to be described and 39
  • 40. Ken Bradley’s Understanding PRINCE 2 defined in terms of its Products or Deliverables. This is a very effective way to ensure full understanding of what is required and to ensure that, as far as possible, all resource consuming activities are related to one or more required Products. Planning for the Delivery of Specialist Products PRINCE 2 Plans are concerned with the Products to be delivered and with the activities necessary to ensure that these Products emerge on time and to the required quality standards. The project Products are identified as a first step in Product-Based Planning; definition of each product (via the PRINCE Product Description) allows its make-up and quality requirements to be documented and properly understood. A Product Breakdown Structure illustrates the hierarchical make-up of the complete set of project products and a Product Flow Diagram provides a view of the relationship each product has with others, within and outside of the project. FS01 Solution Providers Strategy Plan Business Review FS02 Problem Definition FS03 Options Identified & Agreed FS04 Options Appraised FS06 FS05 Final Report Selected Option Agreed Figure 11: Product Flow Diagram (For A Feasibility Study) The Project Timescale or Gantt Plan charts the major activities of the project. It is usually derived from the PERT (Programme Evaluation and Review Technique) or Activity Network which shows the relationships that exist between project activities. It is used in conjunction with a Project Resources Report to monitor progress on the project as a whole. It also addresses planning requirements related to Quality Control and Configuration Management. A Stage-level Gantt (or time-scale) Plan shows the products, activities and quality controls for each stage of the project. The Stage-level Gantt Plan is produced and approved at the end of the previous stage (the plan for the first stage is prepared with the project plan). 40
  • 41. Ken Bradley’s Understanding PRINCE 2 Additional, lower-level Gantt Plans can be expected to exist in most projects, to give a detailed breakdown of particular major activities These are termed “Team Plans”. Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Figure 12: Gantt Plan (Time-scale Plan) Lower level Plans (or Individual Work-to Lists), if required, are derived from the Stage and Team Plans to allocate detailed activities (and Products/Deliverables) to particular members of a Specialist Stage Team. Although this level of plan is not formally included in PRINCE 2 they may be utilised if the size and/or complexity of the project requires their production. Resource Planning & Reporting Resource requirements are concerned with managing the funding and effort resources of the project. Specific resource plans are not produced for PRINCE 2 controlled projects, as the method assumes that a software planning tool will be used. Where this is the case, relevant reports on planned and actual resource usage can be drawn from the Project Plan in the form of a “Resources Report” as and when required. Where a software support tool for planning is not in use (for example in the case of a low cost, short duration, low risk project) the format for a resources plan or report shown in figure 13 may be of use. Even where a software planning tool is in use, the presentation of the information might well benefit by adopting the format shown in figure 13 as it reflects the type and level of information required by the Project Board in reaching a suitable business decision. It is the decision-support information about the requested commitment of resources that is of most use to Project Board members in reaching their decision to start or continue with the project and careful thought must be given as to the most appropriate presentation of the data. 41
  • 42. Ken Bradley’s Understanding PRINCE 2 Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual EFFORT (Staff Weeks) Skill Types Customers Engineers IT Analysts Others COSTS (£K) Skill Types Customers Engineers IT Analysts Others Equipment Fixed Price Elements Total Stage Costs Total Project Costs Figure 13: Typical Project Resources Report (or Plan) The standard Resources Report drawn from any software-driven Project Plan will identify the type, amount and cost of the resources required by the project related to each Management Stage of the work. It will also identify equipment, building, and fixed-price costs associated with the project. The intention is to provide a complete resource and financial picture of the undertaking. A more detailed Resources Report, at Management Stage Level identifies the resources required by the particular stage. It defines the budget required by the stage and is used to report actual expenditure and resource usage against plan More detailed Resource Plans at the Team Level will be produced when required, to plan and control a particular major activity, and the associated team work-plans and Products. Quality Planning - BS/EN/ISO9001 Action must be taken at project planning time (within the “Initiating A Project (IP1)” Process) to ensure that the project can deliver its Products to the required quality standards (the Customers Quality Expectations) required by the customer. Quality Criteria must be defined and agreed, and incorporated into a Product Description for each major Product identified; a Project Quality Plan must be defined, published and adopted; Quality Review procedures must be established and staff trained; review activities must be properly resourced. Whatever action is proposed to build quality into the project, the measures must be consistent with any published Quality Management System (QMS) that is already in effect. PRINCE 2 has been designed to comply with the BS/EN/ISO9001 Quality Management Standard and the method contains a section relating its content to each section of the ISO Standard. BS6079, the Project management Standard, is also reflected within PRINCE 2. ISO9001, BS6079 and PRINCE 2 are all Process-driven; the foundation for quality and 42
  • 43. Ken Bradley’s Understanding PRINCE 2 effective, modern project management is therefore integral and inherent in PRINCE 2. The results of the quality planning activity must be integrated into the timescale and resource plans at each level. Just as quality must be built into the Products, so must quality control be built into the plans. Project Plan (Mandatory Plan) Stage Plan Stage Plan Stage Plan Team Team Team Team Team Team Plan Plan Plan Plan Plan Plan Project Resources Report (Effort, Costs, Equipment, Direct Costs) Figure 14: PRINCE 2 Planning Levels - Project, Stage & Team ♦ The Project Level plan (required) sets the overall quality approach for the entire project. It defines the standards to be followed and the quality criteria for the major products. It also identifies external constraints that may apply to the project, such as a specific Configuration Management Method. ♦ The Stage Level plan (required) identifies the quality criteria, methods and review guidelines for each Product produced during the stage. ♦ A Team plan (optional) might be required for specific individual activities such as carrying out interviews within a particular user/customer area. The Project Manager is responsible for deciding whether any plans below stage-level are required; this decision will be endorsed by the Project Board at the Project Initiation or End-Stage Assessment meeting. Tolerance and Planning The Project Board Executive sets tolerances for Stage Plans. These define the limits of time-scale and cost (or sometimes effort) within which the Project Manager can operate without further reference to the Project Board. Tolerance is variable and will be assigned to each Management Stage to reflect the respective business risk, but a general rule of 43
  • 44. Ken Bradley’s Understanding PRINCE 2 thumb is that Time Tolerance of plus/minus 1 week and Cost Tolerance of plus/minus 10% is about right. An Exception Report and, subsequently, if required by the Project Board, an Exception Plan, is produced in situations where costs or time-scales are forecast to be exceeded beyond the tolerances set by the Project Board. The Exception Report describes the cause of the deviation from plan and its consequences and recommends corrective action to the Project Board. Once considered and approved by the Project Board at a Mid-Stage Assessment (MSA), the Exception Plan replaces the re- mainder of the current Stage Plan. The Controls Component Regular and formal monitoring of actual progress against the approved plan is essential to ensure the timeliness, cost control and quality of the system or undertaking being developed. PRINCE 2 provides a support structure of Management and Product-oriented controls to monitor progress, supported by a reporting procedure which enables re- planning or other appropriate corrective action to be taken. Management Controls PRINCE 2 provides a structure of management controls to be applied throughout the project. These controls cover all aspects of project activity and, at the highest level, allow the Project Board to assess project achievement and status prior to committing further expenditure. Controls are applied through measuring the progress towards production of a set of pre-defined outputs (Products or Deliverables). The overall structure of Management Controls is defined during the project Initiation Stage (“Initiating A Project (IP4)” Process) to ensure that the project is set up with clear Terms of Reference, incorporating agreed and measurable Objectives and an adequate management control structure. Project Initiation To document a firm foundation and to provide a positive start to the project, ensuring that the terms of reference, objectives, plans and controls, business risks, benefits and financial return, organisation structure and job definitions are clearly defined, published, understood and agreed. This Management Product is very important to the project and is the result of two Processes - the pre-project “Starting Up A Project (SU)” and “Initiating A Project (IP)”. The key output is the Project Initiation Document (PID) which, when approved by the Project Board, is a “frozen” document used to baseline the project. 44
  • 45. Ken Bradley’s Understanding PRINCE 2 End Stage Assessment (ESA) This is a required management control and occurs at the end of each stage. It typically consists of a formal presentation to the Project Board of the current project status, and reviews the overall business case (benefits and risks). The approval of the proposed plans for the next stage is also obtained. Project Board approval, with agreement by all the members, must be obtained before the project can proceed to the next stage. “Managing Stage Boundaries” Process •Up-date the Plans for Stage 1; •Up-date the Project Plans; •Up-date the Business Case (Benefits & Risks); •Prepare the Plans for Stage 2 Stage 1 - Planning & Definition Stage 2 - Design & Contract End Stage Assessment (ESA) “Directing A Project” Process •Review the Outcome of Stage 1; •Review the Project Plans; •Review the Business Case (Benefits & Risks); •Preview the Plans for Stage 2. •Endorse the Project & Approve continuation of the project up to the next End Stage Assessment. Figure 15: Handling End Stage Assessments Mid Stage Assessment (MSA) This Project Board control is held only to review a significant deviation from an approved Management Stage Plan and to approve an Exception Plan produced, at the request of the Project Board, following an Exception Report. An Exception Report is produced by the Project Manager to alert the Project Board as soon as it is apparent that a significant departure from the approved plan is forecast. The Exception Report records what has happened to cause the “significant departure” from the approved plan, the impact on the Management Stage, overall Project and its Business Case. The plan will also recommend appropriate action to take the project to the end of the Stage and, where possible, recover the situation. 45
  • 46. Ken Bradley’s Understanding PRINCE 2 “Controlling A Stage” Process •Deviation from approved Stage Plans Forecast; •Exception Report Created - Reasons; Impact; Options; •Direction from Project Board .... Create an Exception Recommendation; Plan; “Managing Stage Boundaries” Process •Produce an Exception Plan Stage 1 - Planning & Definition Stage 2 - Design & Contract Mid Stage Assessment (MSA) “Directing A Project” Process •Consider theException Plan an unscheduled Mid Stage at •Review the Problems with Stage Assessment. 1; •Review the Impact on the Project Plans; •Review the im[pact on the Business Case (Benefits & Risks); •Preview the revised Plans for the remainder of the Stage. •Endorse the Project & Approve continuation the Stage up to the next End Stage of Assessment. Figure 16: Handling Mid Stage Assessments Tolerance The measure of a “significant departure” is that the Tolerance stated by the Project Board at the beginning of the management stage has been, or is likely to be, exceeded. Tolerance may be thought of as the scope that the Project Manager has been granted by the Project Board to move away from the approved Management Stage Plan without needing to report the variance. Tolerance is not time and money to be spent but should be thought of as “trigger” figures which help keep the Management Stage (and the Project Manager) within “tolerable” bounds. Responsibility for Tolerance stems from the Project Board, with the Executive having responsibility for setting Management Stage Tolerance with the Project Manager. The Executive is also responsible for ensuring that an overall Tolerance is set for the project by Corporate or Programme Management and that it is suitably recorded in the Project Brief during “Starting Up A Project (SU)”. Tolerance should always be set in terms of both time and cost, as over-concentration on just one aspect will imbalance the overall project resulting in an unexpected and unpredicted time or budget slippage. 46
  • 47. Ken Bradley’s Understanding PRINCE 2 Plus 10% Tolerance £110K £100K Planned Delivery & Total Cost o Cost £90 Minus 10% Tolerance £80K £70K £60K £50K Plus 1 Week Tolerance £40K £30K Minus 1 Week £20K Tolerance £10K Time 2 4 6 8 10 12 14 16 18 Weeks STAGE PLAN Figure 17: Tolerance - plus/minus 1 week; plus/minus 10% Standard Tolerance in PRINCE 2 is measured in terms of Time (Schedule) and Cost. There are other types of Tolerance which may be applied; these include Tolerance on Quality, Technical Conformance, Scope, and Risk. The level of Tolerance is decided by the Project Board and set by the Executive following recommendations by the Project Manager. Tolerance is most usually applied to a Management Stage but is also be applied at Project level (set by Corporate or Programme Management) and Product level (set by the Project Manager in specific Work Packages). Project Closure A final review of the project's work is held, usually (but not necessarily) in the form of a Project Board meeting. This is similar to a stage assessment but relates to the entire project rather than a single stage. The objective is to ensure that all the project Products/Deliverables have been satisfactorily delivered to their stated quality standard and that the project documentation is complete. A review of the project management standards and approaches used by the project will be carried out within the “Closing A Project (CP)” Process and a Lessons Learned Report produced for consideration by the Project Board. The Lessons Learned Report records what has been learned from using the PRINCE 2 project management and quality management standards for the project and is created during the “Initiating A Project” 47
  • 48. Ken Bradley’s Understanding PRINCE 2 process and “populated” as the project progresses (at the end of each Management Stage); it will eventually be sent to the organisation’s manager responsible for quality. Recommendations will also be made for Follow-on Actions to record and trigger further work which is recommended following the closure of the project. Follow-on Actions will usually be derived from any outstanding Project Issues, shown on the Issues Log. A Post-Project Review Plan, to enable the organisation to check the actual realisation of benefits after the project’s output has been operating for a while (perhaps 9-12 months following hand-over), will be prepared and authorised by the Project Board. Highlight Reports The Project Board is kept informed of the progress of the Management Stage (and the project) against the approved plans via regular, time-related Highlight Reports. These are prepared by the Project Manager and are usually provided monthly, although their frequency will always be agreed with the Project Board. Highlight Reports are usually sent through the post or by e-mail; the objective is to remove the need for unnecessary time-related Project Board meetings which consume the Project Board members’ valuable time, while still keeping them abreast of significant developments. The format for Highlight Reports will typically include: ♦ a statement of the progress made during the last (usually monthly) period; ♦ a statement of problems during the last period, and how they were handled; ♦ confirmation of the Activities and Products to be worked on during the next period; ♦ a statement of the financial and schedule situation for the overall project and the current Management Stage. Some organisations specify that Highlight Reports should be kept to one side of A4 (or its equivalent). Where the project is part of a Programme of work, separate Project and Programme Highlight Reports will normally be produced. Stages Stages are partitions of the project with decision points at their conclusion, and sometimes during their life. PRINCE 2 differentiates between “Management Stages” (which equate to the commitment of resources by the Project Board and a decision to continue with the project and authority to spend) and “Technical Stages” which comprise sets of technical activities leading to a stated and required Product. 48
  • 49. Ken Bradley’s Understanding PRINCE 2 Technical Stages Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Review of Management Stage at Project Closure End Stage Assessment (ESA) Figure 18: Management & Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned and managed by Team Managers who report to, and take direction from, the Project Manager. Management Stages will always run in series. In figure 18, some of the Technical Stages have been planned to run in parallel. Of course, in a smaller project these might well be described as “Technical Activities”; in medium to larger projects, the Activities will often combine to provide the Technical Stages under the immediate control of a Team Manager. In only the most exceptional circumstances will authority be given for work to commence on the next Management Stage before all the Products of the current Management Stage is completed. Business Benefits and Risk Management PRINCE 2 places emphasis on the Business Benefits for the project; they are described by the Method as “…the driving force behind the project …”. The purpose of the PRINCE 2 Business Case is the identification and measurement of the Business Benefits and the continued review of them as the project progresses through its Management Stages. Closely associated with the Business Benefits are the Risks that the project faces; essentially the risks divide into two main areas: ♦ Business Risks relating to threats associated with the project not delivering products capable of achieving the claimed and published Business Benefits (eg legislative changes, market changes, environmental issues). 49
  • 50. Ken Bradley’s Understanding PRINCE 2 ♦ Project Risks which are concerned with the ability to deliver the project’s outcome within the required time and cost requirements (eg failure of third party suppliers, skills shortages, technical problems). The Method does not specify any particular way of measuring Business Benefits or assessing Risks but whatever the chosen approach, PRINCE 2 requires the Business Case and Risks to be updated on a regular basis - minimally at the end of each Management Stage. This provides the Project Board with sufficient, up to date, information on which to base their decision to continue with the project. Planning For Quality PRINCE 2 presumes that the project will be managed under the umbrella of a published Quality Management System (QMS) conformant to ISO9001. If such a QMS is not present the Method compensates by specifying that quality must be planned from the outset. Planning Quality takes place in the “Initiating A Project (IP)” Process and the resultant Project Quality Plan is incorporated into the Project Initiation Document (PID) and used throughout the project. The Process provides the following: ♦ it establishes a Quality regime for the project; ♦ it defines the overall project quality criteria and assurance arrangements to be employed by the project; ♦ it establishes the approach to control of change during the project. Responsibility for planning quality lies with the Project Manager, working in close association with those responsible for quality (ie the Quality Manager). Quality Controls - Quality Review Quality controls are applied to specific products rather than to the overall output of a stage or project. The aim is to identify and correct errors as early as possible in the development process. They will usually take the form of a formal or informal quality review, whichever is specified in the Product Description. 50
  • 51. Ken Bradley’s Understanding PRINCE 2 Activity (shown on the Gantt or Timescale Plan) consuming Resources (Time/Effort/Funding) Product Description The Product •Composition •Quality Criteria Quality Review •Type of Check Checking the Product against •People Required the Quality Criteria published in the Product Description Figure 19: The Product Description & Quality Review Relationship Quality control may take many forms from a visual inspection, through a test programme, to a formal meeting. These are all Techniques and PRINCE 2 describes some, but not all that might be available - the selection of appropriate Techniques is left to the implementing organisation. However, one of the most powerful Techniques is the Quality review which has been successfully used in a wide variety of projects for a number of years. The Formal Quality Review has three distinct steps: ♦ Preparation - where the Product or Deliverable is measured against the Quality Criteria contained in the Product Description, and Error Lists are created by selected Reviewers who are able to make a suitable contribution. ♦ Review - where the Product or Deliverable is “walked-through” by its Producer and an agreed list of Follow-up Actions is agreed. The Reviewers who prepared the original Error Lists attend this Review. ♦ Follow-up - where the identified faults, errors, omissions and inconsistencies in the Product or Deliverable are fixed, agreed and signed-off. At each Quality Review, appropriate Supplier and user/customer staff are designated to examine a Product to ensure that it is complete and correct; these “appropriate resources” are identified in the Stage-level Plan and the corresponding Product Description. The Product is reviewed against defined quality criteria contained within the Product Description, which assures its technical integrity and its compliance with user or customer requirements; It is thereafter an “Approved Product “subject to formal change control procedures. If any subsequent changes are made to Approved Products, there should always be a reference back to the original Product Description to determine whether a corresponding change needs to be made. This procedure applies to informal quality reviews (for example a test, visual inspection, or desk-check) and to formal quality reviews where 2-3 reviewers meet with the author of the product under the chair of a suitably senior person to “walk-through” the product. 51
  • 52. Ken Bradley’s Understanding PRINCE 2 Change Control Unplanned situations relating to changes to one or more Products need to be captured as “Issues” relating to the project. Originator Raises A * Good Ideas * Errors Project Issue (Request for Change * Departures From Agreed Specification or Off-Specification) * Resource Changes * Specification Changes Sent to Project Support Copy returned Notify Originator to confirm receipt Project Issues Log Logged byProject Support Project Issues Log Up-dated Reviewed by Project Manager * Slippage/Budget Changes, exceeding Tolerance or affecting other projects within the Programme = Decision by Project Board (Exception Report) OR .... *Changes Within Tolerance = Decision by Project Manager and action taken to implement the change. Figure 20: Suggested Procedure For Controlling Changes Examples of this are good ideas that project team members identify, resource changes, errors discovered in a finished product, and departures from the agreed specification. Because the situation is unplanned, it needs to be recorded and action agreed, in order to contain the impact and prevent wider divergence from plans. Issues are best handled within the framework of a formal Configuration Management scheme. An Issue will be raised to cover any situation which needs to be addressed within the project and to a large extent is a “catch-all” for many unforeseen incidents; for example, where no agreement can be reached on the outcome of a Quality Review, am Issue will be raised to alert the Project Manager. Configuration Management A Configuration Management Method (CMM) controls the development of products by providing a formal mechanism for labeling products, their development status, and the relationship between them. PRINCE 2 does not define or recommend a specific CMM but emphasises the need for a suitable system and clearly states that the presence of suitable arrangements for Configuration Management is not optional. 52
  • 53. Ken Bradley’s Understanding PRINCE 2 Configuration Management can be particularly useful in tracking back problems with delivered, signed-off Products which fail to perform as expected in operation; identification of the developer or supplier is vital to ensure that problems are tracked back to source and appropriate action taken. Filing Arrangements PRINCE 2 contains a recommended filing structure which implementing organisations may find useful as a start point. Where existing filing arrangements are in force, or where organisations wish to arrange things differently, this may be done without conflicting with the Method. Files Project File Stage File(s) Specialist File Quality File Organisation Organisation Configuration Items Product Descriptions Plans Plans Configuration Log Quality Checks Business Case Control Documents CI Locations Project Issues Risk Log Daily Log Off-Specifications Project Issues Log Control Documents Correspondence Quality Log Product Checklist Product Checklist Lessons Learned Report Figure 21: The PRINCE 2 Suggested Filing Structure Software Support for PRINCE 2 In partnership with CCTA, the owners of the PRINCE Methodology, IBM (UK) have developed a support tool called “The PRINCE 2 Environment”. This tool provides a complete electronic support function which enables the Project Manager (or Project Support) to keep track of the many project documents that are created during the life of the project and to launch any application that is needed to manage the project. Typical applications will be project planning tools, word-processing and spreadsheets; both applications and associated files can be launched, modified and saved. The PRINCE 2 Environment also contains the full PRINCE documentation and “skeletons” for the creation of the Project Initiation Document. Users can add extra options and incorporate their existing documentation to supplement the basic material supplied with the PRINCE 2 Environment. An alternative – The Launch Pad – is available from SPOCE Project Management Limited, providing similar functionality to the PRINCE 2 Environment. An evaluation copy can be downloaded from web site www.spoce.com 53
  • 54. Ken Bradley’s Understanding PRINCE 2 Following This Introduction The introduction to PRINCE 2 in this Chapter should be sufficient for the “incidental user” or senior manager to understand the basics of the Method. The rest of this book provides further information on PRINCE 2 and explores each topic in more detail. Although the Method is “Process-Driven” and the eight Processes use the Components and Techniques, the recommended starting point to understand what is going on within a PRINCE 2 project is the Components. The remaining Chapters deal with the PRINCE 2 Components, explaining their composition and progresses through Processes to Techniques, adding value to the basic descriptions in the PRINCE 2 Manual. 54
  • 55. Ken Bradley’s Understanding PRINCE 2 Chapter 3 UNDERSTANDING THE ORGANISATION COMPONENT 55
  • 57. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Organisation - Introduction Project organisation and staffing is the key to the successful management of any project. If the project staff have the right leadership, the appropriate technical competence, have the will to make the venture successful, and understand exactly what is expected of them, then the project will have an excellent chance of success. Corporate or Programme Management The Project Board Senior User Senior Supplier Executive Project Assurance Project Manager Project Support Team Manager Team Manager Team Manager Project Resources & Teams Figure 22: The Suggested PRINCE 2 Organisation Structure At the top of the organisation structure there will normally be a strategy body (PRINCE 2 identifies this as Corporate or Programme Management) responsible for interpreting the overall objectives of the organisation into working arrangements, systems or other outcomes. In private-sector organisations this body might well be the Board of Directors. The PRINCE 2 organisation model assumes a Customer:Supplier environment within which the project management components, processes and techniques will operate. The structure assumes there will be a customer who will state and define the requirement, pay for the project and use the outcome, and a supplier who will provide the necessary experience, skills and know-how to create the End Product for the customer. This model is used for all PRINCE 2 controlled projects - the supplier might be an external private sector company or an internal division of the purchasing organisation - the approaches used are similar. The main emphasis within the PRINCE 2 organisation component is concentration on direction, management, control and communication. The method provides a flexible framework which is capable of being mapped onto any organisation with the minimum of disruption, and which provides the template to achieve the key outputs. 57
  • 58. Ken Bradley’s Understanding PRINCE 2 Within any PRINCE project organisation, at least three interests must be represented: ♦ Business Interests - ensuring that the eventual output of the project meets (and continues to meet) a stated business need while at the same time representing good value for the time, money and other resources expended. ♦ User Interests - specifying the desired outcome and ensuring that the project actually delivers what is required. Essentially representing the interests of those who will use the outcome to deliver the business benefits. ♦ Supplier(s) Interests - providing the necessary knowledge, skills, equipment and resources to produce the outcome in accordance with the specification and acceptance criteria. There will often be internal and external specialist suppliers working co- operatively on the project. Responsibilities in a PRINCE 2 Controlled Project The PRINCE 2 Method provides guidelines for the responsibilities that can be expected to be placed on individuals working within the PRINCE environment. These are presented in the form of Role Descriptions which should be used as input to discussions to secure the final definition of the roles and responsibilities for all members of the Project Board and the Project Management Team. Tuning the role descriptions is best carried out in three passes: ♦ Step 1 - Tune the role descriptions to suit the specific project (they should already have been tuned to reflect the organisation’s culture, standards and requirements); ♦ Step 2 - Modify the resultant role descriptions to suit the individual filling the role - ask why that particular individual has been chosen for the role - what specifically does he/she bring to the project; ♦ Step 3 - Discuss each tuned role description with the individuals concerned and secure their agreement and commitment to their organisational role. Following this simple three-step process will help secure the commitment of the Project Board members and Project Management Team. Taking the role definitions directly from the PRINCE 2 manual is not recommended. The Project Board The Project Board is the overall authority for the project, having specific ownership for the process “Directing A Project” and responsibility for delivering the required outcome or End Product. It is the ultimate project authority and is responsible for the initiation, direction, review and eventual closure of the project. To meet this function, Project Board members must have the authority required to commit resources and to initiate new work. These are the prime selection criteria for Project Board members. The Project Board comprises, as a minimum, representatives from the following three functional areas: 58
  • 59. Ken Bradley’s Understanding PRINCE 2 The Executive Role: Overall Responsibility: to be ultimately responsible for the project, supported by the Senior User and Senior Supplier. The Executive has to ensure that the project is delivering value for the time, effort, costs and resources being invested, confirming a cost-conscious approach to the project, balancing the demands of the Business, User and Specialist Provider Organisations. The Executive will normally chair the Project Board meetings, owns the Business Case, represents the Customer’s interests and has final responsibility for the project. The Senior User Role: Overall Responsibility: Responsible for the specification of User needs, user liaison with the project team, the integrity of the desired outcome of the project and for monitoring that the solution will meet those needs within the constraints imposed upon the project. The role represents the interests of all those affected by the outcome and the Products arising from the project. The Senior User role commits User resources and monitors Products against the stated and agreed requirement. This role will often involve more than one person to represent all the user interests. The User and Customer roles will sometimes be represented by the same individual or group of people. The Senior Supplier Role: Overall Responsibility: Representing the interests of those designing, developing, facilitating, procuring and implementing the project Products. The Senior Supplier role must have the authority to commit or acquire the (specialist) supplier resources required. In some projects, more than one person may be required to represent the interests, and commit the resources, of the supplier. Responsibilities of the Project Board Members The PRINCE 2 Manual (Appendix C) provides lists of responsibilities for each of the above roles. These are split between the Specific Responsibilities and the Assurance Responsibilities for each of the identified roles. The role definitions must be adapted to suit the organisation, project and individual tasked with the responsibility. The three functional roles comprising the Project Board should not be interpreted as a requirement for three individuals. In smaller projects, for example, two functional roles may be combined in one person (although in normal circumstances it is not advisable for the Project Board to be reduced to less than two individuals). In other circumstances several individuals may take on a single functional role (eg where a number of user areas are being served by the eventual outcome of the project). 59
  • 60. Ken Bradley’s Understanding PRINCE 2 The Project Assurance Function PRINCE 2 separates the Project Assurance function from the Project Support function. Accountability for assuring the project always resides with the Project Board and cannot be delegated; the day to day tasks involving the assurance function may, however, be delegated to appropriate individuals. There are two types of Project Assurance that can be expected to be found within a project - External and Internal. External Assurance & Audit Function Standards - Quality - Financial - Technical Project Board Assurance Function Project Assurance Function - Business - User - Supplier - Business Project Management Function - User Project Manager Project Support - Supplier Team Managers Project Team Members - Product Creators Figure 23: The Levels of Assurance ♦ External Assurance concerns itself with the assurance that the project is performing in accordance with overall standards and approaches either published or recognised in some way by the organisation. Examples might be that the project is conforming to the BS/EN/ISO9001 Quality Management Standard or following Accounting Conventions laid down by a professional body or within legislation. Invariably some form of audit will already be present within the organisation to verify that these standards are being followed. ♦ Internal Assurance is ultimately the responsibility of the Project Board. Examples of Internal Assurance are verifying that the Products/Deliverables output by the project conform to their agreed Quality Criteria; that they perform in accordance with the User’s statement of requirement; that schedule and cost budgets are being met; and that the Business Case (Business Benefits) and Risks remains viable. 60
  • 61. Ken Bradley’s Understanding PRINCE 2 Delegation of Day-to-Day Project Assurance Although accountability for Project Assurance rests with the Project Board it might well be impractical for the individual members to carry out the tasks involved personally (because of lack of time or lack of expertise). Each Project Board member may, therefore, enlist help from other sources to actually perform the day-to-day Project Assurance function on their behalf. It is important to note, however, that this responsibility is only delegated - the Project Board retain full accountability. Delegation of the assurance function may be to any number of individuals, although the numbers must obviously, be sensible. The selection of appropriate people for the assurance roles is also important - the assurance function must be independent of the Project Manager and it is not appropriate for any of the assurance function to be delegated to the Project Manager or Team Manager(s). In practice, an existing Quality Manager or Project Support Office might be used to carry out either or both Internal Assurance and External Assurance - responsibility for getting it right rests with the Project Board (and ultimately with the Executive Member). The Project Manager All projects need a focal point to plan, control and oversee the day to day work and to co-ordinate the total effort. The Project Manager fulfills this role. PRINCE 2 requires that all projects under the control of the Methodology have a Project Manager. The prime responsibility of the Project Manager is: ♦ to ensure that the project as a whole produces the required products, to the required standard of quality, and within the specified constraints of time and cost. The Project manager is also responsible for the project producing a result which is capable of achieving the benefits defined in the Project Initiation Document. The Project Board Senior User Senior Supplier Executive User Assurance Specialist Assurance Business Assurance Project Assurance Assurance Project Manager Figure 24: The Project Manager’s Relationship with the Project Board In any PRINCE 2 project, there might also be one or more Team Managers to assist the Project Manager to plan, manage and control a specific Technical Stage. It is the 61
  • 62. Ken Bradley’s Understanding PRINCE 2 responsibility of the Project Manager to direct and co-ordinate the efforts of all Team Managers. Team Managers will usually be appointed to plan and control particular specialist areas, where the Project Manager lacks the detailed knowledge and/or experience and/or resources directly under his/her control to carry through the specific tasks required. A selection of the main tasks for the Project Manager is as follows: ♦ Overall planning for the total project; ♦ Motivation and Inspiration; ♦ Drive the project towards a successful outcome; ♦ Liaison with other related/associated projects; ♦ Liaison with Programme Management for related projects; ♦ Define responsibilities for each Specialist Team Manager; ♦ Report to and take direction from, the Project Board; ♦ Present regular Highlight Reports for the Management Stage (and the impact on the overall project) to the Project Board. The Project Manager role is essential for large, complex, high-profile, high-risk, undertakings and may be supported by one or more specialist Team Managers. Team Manager(s) The Team Manager is an optional role and may be expected to exist on large, high risk projects. Where appointed the Team Manager is responsible for the day-to-day management of the specialist work package activities and products under his/her control. Typically, but not necessarily, a Team Manager will have line responsibility for a specific specialist team appointed to be responsible for a discrete part of the project; for example the supplier of key technical equipment, or a building contractor might be appointed as a Team Manager for part of the customer’s project. In such circumstances it is quite normal that the Team Manager is also the supplier’s Project Manager. The Team Manager works to the defined and agreed plans for the stage products and activities and reports to the Project Manager. Team Managers may also be appointed where the project is large and the Project Manager requires some experienced support at the management level. Also where there are pressing geographical reasons, a Team Manager might well be nominated to implement a particular part of the solution within a geographic region. 62
  • 63. Ken Bradley’s Understanding PRINCE 2 The options described above are not exhaustive and Project Managers and their respective Project Boards should use imagination and creativity to determine where and when to make the best use of this PRINCE 2 role. Project Manager Team Manager Team Manager Team Manager Project Resources & Teams Figure 25: The Team Manager’s Relationship with the Project Manager Responsibilities of the Team Manager The prime responsibility of the Team Manager is: ♦ to ensure production of those Products defined by the Project Manager to an appropriate quality (ie conforming to the Product’s Quality Criteria agreed within the Product Description), in a time-scale and at a cost acceptable to the Project Manager and the Project Board. The Team Manager reports to and takes direction from the Project Manager. The Team Manager will work with the Project Manager to define responsibilities for the team members and provide plans, guidance, motivation and inspiration. All suggested changes relating to the Products which are the responsibility of the Team Manager, raised informally or as Project Issues will be routed through the Team Manager for recommendation or decision on further action. The Team Manager will work closely with his/her teams, providing advice and guidance and taking decisions. The Team Manager will attend (and usually run) Checkpoints and raise Checkpoint Reports for the Project Manager at the frequency agreed in the Work Package, and may help the Project Manager to provide the regular Highlight Reports to the Project Board. Project Support may be used by the Team Manager where this is acceptable to the Project Manager. At the discretion of the Project Manager, Project Support will provide administrative assistance freeing the Team Manager from the day to day administration, and enabling provision appropriate support and guidance to the team members. In some cases, Project Support may act as a “Scribe” at Quality Reviews to help with the 63
  • 64. Ken Bradley’s Understanding PRINCE 2 administration and recording of this important control. Team Managers and Technical Stages PRINCE 2 draws a distinction between Technical Stages and Management Stages. A Team Manager will take responsibility for one or more discrete Technical Stages of the project. Technical Stages relate to the delivery of specific portions of the final solution (or End Product) for the project and there may well be a number of Technical stages, each under the control of a different specialist Team Manager, running within one or more Management Stages. The Management Stages provide the basis for a series of major milestones during the life of the project and represent the points in time when the Project Board will, at an End- Stage Assessment (ESA) decide whether the project should go forward, be “frozen” for a period of time, existing work be “re-visited”, or the whole project aborted. Management Stages allow the Project Board to control the commitment of resources to the project and provide authority to spend; they are also described by the Method as “partitions of the project with decision points”. Project Support The Project Support function on a formal basis within a PRINCE 2 project will only exist where there is a need for it. Its existence is driven by the needs of an individual project (and Project Manager). In general, the kind of support provided will be administrative help to the Project Manager and the Team Managers where these are appointed. Where organisations already have a Project Support Office in place, there need be no change, although there will need to be a clear distinction drawn between the services provided to the Project Manager by the Project Support Office staff and any Project Assurance function they might be performing on behalf of the Project Board. The Project Support prime function is: ♦ to provide administrative support and assistance to the Project Manager and the Specialist Team Managers. Project Support may also provide support to the Team Members in terms of advice and the interpretation of the project management, quality and technical standards. Project Support responsibilities comprise (among others as specified and agreed with the Project Manager) the following: ♦ Administer Change Control; ♦ Set up and maintain the Project Files; ♦ Establish Document Control Procedures for the Management Products; 64
  • 65. Ken Bradley’s Understanding PRINCE 2 ♦ Compile, copy and distribute all Management Products; ♦ Collect Actual Performance Data and Forecast Data, and update the Plans; ♦ Administer the Quality Control Processes; ♦ Administer Project Board Meetings; ♦ Assist with the compiling of reports; ♦ Configuration Management activities. ♦ Performing the “Scribe” role at Formal Quality Review Meetings. The selection of appropriate Project Support personnel (either for the direct support of the project or through the creation of a Project Support Office) is important to the overall success of the project. Typical knowledge and skills necessary for this key position might include, among other areas: ♦ A broad understanding of estimating techniques (especially those used by the Organisation); ♦ specialist knowledge and competence with the organisation’s chosen software support tool, and other project management software support tools such as those for Risk Assessment and Management; ♦ any other specialist knowledge that might be needed to support and reflect the organisation’s existing standards, approaches and professional ethics and approaches; ♦ administrative approaches relating to the organisation’s own filing and related configuration approaches; ♦ planning and scheduling principles knowledge and expertise; ♦ good communication and interpersonal skills; ♦ a pro-active approach! Customer:Supplier Environment A suitable organisation structure for Customer:Supplier projects is included in the PRINCE 2 manual and shown in figures 26 and 27. PRINCE 2 assumes that the project will be a joint venture between a Customer and a Supplier, who might be an internal or external supplier of the specialist portion of the project. 65
  • 66. Ken Bradley’s Understanding PRINCE 2 Customer Project Supplier Project Board Board I Customer Account Manager I Senior User I Supplier Skill Management I Executive I Senior Supplier Project Board •Executive •Senior User •Senior Supplier Figure 26: The PRINCE 2 Customer:Supplier Organisation Structure Figure 26 is as far as the PRINCE 2 Manual takes the Customer:Supplier Environment – a full view of the typical Customer:Supplier Organisation Environment to be found in a PRINCE 2 managed project is illustrated in figure 27 below. Customer Organisation Supplier Organisation Customer Project Board Supplier Project Board The Project Board (Joint Representation from Customer & Supplier Project Boards) Customer Supplier Project Manager Project Manager Customer Supplier Team Manager Team Manager Customer Supplier Resources Resources Figure 27: Comprehensive View of the Customer:Supplier Organisation Environment Developments On The PRINCE 2 Theme A similar structure has been used successfully by customer and supplier organisations for a number of years; it is similar to that proposed by PRINCE 2 as a suitable start-point, but 66
  • 67. Ken Bradley’s Understanding PRINCE 2 has a few modifications which provide an alternative but compliant option. This model (figure 28) provides a practical approach to handling the day-to-day communication linkages between the respective Project Managers and their respective teams, and the higher level exchanges between each Project Board and has been used as an organisational basis for private sector companies Local Government; Central Government and NHS Trusts. A key element is to ensure that the customer and supplier organisations have an opportunity to take the necessary commercial and business decisions within the privacy of their own management organisations, but with the facility to meet to iron out difficulties and problems on a “without prejudice” basis. The Supplier Project Board Supplier senior management will always need to represent the interests of their customers if the eventual business outcome is to be satisfactory to all parties involved. Reflecting the “partnership” approach, it is tempting to include a User/Customer representative on the Supplier Project Board. This approach is, however, flawed as the PRINCE Methodology places overall and ultimate responsibility and authority for the project in the hands of the Project Board with consensus agreement. A “real” User/Customer representative at this level within the project will always be placed in an invidious position, especially in times of trouble when hard decisions have to be made about the possibility of re-defining the project deliverables or re-negotiating the contract price or terms and conditions, where the Customer‘s only realistic stance can be “no comment” - indecisive and certainly not recommended at Project Board level! A similar situation occurs where a Supplier is asked to provide a representative for a Customer’s Project Board. Although commitment of the Supplier’s resources will be able to be achieved, in times of difficulty where a specialist solution appears not to be working in the way the Customer had expected, the supplier representative always experiences a conflict over whose interests should be protected. The solution, endorsed by practical experience, is for the Supplier to provide representation from internal resources such as a Customer Account Manager to speak for the customer and to ensure that, at the highest level within the project, due account is taken of the customer’s position. For the customer, where there is an unwillingness to have a Senior Supplier from the organisation they have contracted with on the Project Board, specialist technical expertise for the project may be bought-in from outside if there is no specialist expertise already resident or available from within. Such an appointment carries with it the disadvantage that the individual(s) concerned are unable to commit the necessary technical resources, but this is relatively easily remedied through the contract arrangements. Establishment of a Steering/Co-ordinating Group (possibly evolving into a Joint Project Board) will help smooth the path for communication between all the senior managers responsible for the project. 67
  • 68. Ken Bradley’s Understanding PRINCE 2 Customer: Supplier Steering/Co-ordinating Group Each individual Project Board will be primarily responsible for the management of the project within its own organisation, but there is also the need to meet on a regular basis to discuss issues and to enable communication at a senior level. The Steering/Co-ordinating Group (or Joint Project Board) pulls together all interested parties at Project Board, Project Manager and, if appropriate, Project Assurance levels so that key decisions can be made. Customer Organisation Supplier Organisation Project Board Senior Management (Project Board Equivalent) Steering/Co-ordinating Group (Joint Representation from Customer & Supplier Project Boards) Customer Supplier Project Manager Project Manager Customer Supplier Team Manager Team Manager Customer Supplier Resources Resources Figure 28: The Customer & Supplier Management Structures It is important to focus on the purpose of each meeting of the Steering/Co-ordinating Group The objective is to provide a joint forum for decision making, the exchange of “positive” views and the clarification of any issues. Progress and project status will be the subject of separate arrangements (typically monthly Highlight Reports). Within a contractual environment, it will always be advisable to set up each meeting with the proviso that any discussions, views and agreements reached within the Liaison/Steering Group forum will always be “without prejudice to the agreed terms and conditions of the contract”. Failure to do this might well result in an unwillingness to enter into constructive debate and to provide mutually constructive suggestions to avoid or repair problems. 68
  • 69. Ken Bradley’s Understanding PRINCE 2 Customer: Supplier Project Manager The supplier will always appoint someone to take responsibility for day-to-day management of the project - the Supplier Project Manager. The communication lines between the Customer Project Manager and the Supplier Project Manager are the strongest ties between the two parties. This is reinforced where the Customer Project Manager regards the Supplier Project Manager as a (specialist) Team Manager within the customer project. The Project Manager will normally come from the Customer organisation and will take on responsibility for managing the total project. This is because the Supplier’s role in the overall scheme of things is usually restricted to supply and installation of equipment. There are many other vital component parts which must derive from the Customer project - examples are the Specification, Business Design, Testing, Training etc. Customer:Supplier - Project Support Project Support may or may not exist on either side, but for major projects some form of support will be established for the Project Manager. The communication links between the support functions will be the regular reports (typically Highlight Reports) and resolution of day-to-day queries between the customer and supplier project teams. It is not envisaged that there will be any formal communication between customer and supplier team members as this will always be routed through the Project Managers or Project Support. Organising The Managing Of Programmes Most projects will have inter-relationships with other undertakings within and outside the host organisation. In larger, longer term and high risk projects, there will be a conscious effort to break the overall initiative into a series of smaller, more manageable projects, each under the overall direction of a Programme Board. The organisational aspects of programmes of work are straightforward and reflect the basic principles of the PRINCE Methodology. The actual arrangements and structure will vary with each programme and will need to reflect the local approaches, culture and, if appropriate, contracts. The PRINCE 2 manual provides a suggested structure which should always be considered as a suitable start point. The following model (Figure 29) has formed the basis for a number of successful programmes and provides a near alternative for consideration: 69
  • 70. Ken Bradley’s Understanding PRINCE 2 Steering Corporate Management Group Programme Board Representation from User/Customer, Supplier Function & Business Function Customer Programme Support Group Programme Manager + Project Support Project Board - 1 Project Board - 2 Project Board - 3 Project Manager Project Manager Project Manager Programme/Project Resources (some common; someowned by one project) Figure 29: Alternative Programme Management Organisation Model Programme Board, Programme Manager & Programme Support The Programme Board will appoint a Programme Manager to oversee the delivery of the overall initiative. The Programme Manager may be a member of the Programme Board, although this is not necessary or recommended. Support to the Programme Manager is provided by Programme Support who are also responsible for the overall programme integrity and the correct use of the organisation’s project management and quality management standards. They will also, therefore, take on the day to day role of Programme and individual Project Assurance on behalf of the Programme Board members and individual Project Board members. Accountability for Programme and Project Assurance remains, of course, with the individual roles on the respective bodies. Quality Assurance is normally a separate function and vested in the Quality Manager; the appointment of a joint Programme/Quality Assurance function role is the responsibility of the Programme Board. To avoid large numbers of individuals on Programme Boards, it is often convenient to establish a Steering Group which is strictly speaking outside the project boundary. Such a group may meet as frequently or infrequently as deemed to be appropriate and the membership need not be limited. 70
  • 71. Ken Bradley’s Understanding PRINCE 2 The Steering Group will be kept fully informed of the progress of the programme and will be invited to contribute to the overall direction of the initiative. The group will not, however, be responsible for decision making within the programme - this vests absolutely in the Programme Board, devolved as appropriate to the Programme Manager, Individual Project Boards and Individual Project Managers. User/Customer Group In A Programme Context Programmes of work often imply the need to address a large customer base and this is catered for by having a separate Customer Group. This group will provide the Senior User/Customer on the Programme Board and the Senior User for each of the individual Project Boards. Each individual Project Board Senior User is responsible for appointing any necessary user/customer liaison resource, possibly coupled with assurance responsibilities, within the project management team. Individual Project Boards In A Programme Context The individual Project Boards operate exactly as they would within a standard PRINCE 2 project. The members are overall responsible for delivery of the project(s) they own. They will meet at appropriate event-related times to review the project and to approve its continuation and commit the resources. Each individual Project Board will comprise a Senior User/Customer representative, a Supplier representative, and an Executive/Business representative. As mentioned above, the User/Customer Group will provide the Senior User. The Programme Manager is best positioned to chair each Project Board and represent the business interests of the overall programme and the host organisation. The individual Project Board Supplier representative will be assigned/appointed by the Senior Supplier on the Programme Board. Project Support & Programme Assurance Each individual Project Manager may be assisted by a Project Support function if this is deemed to be necessary given the size, scope and complexity of the project and the experience of the Project Manager. Project Support will keep the project plans up to date and on a regular basis, usually monthly, will provide a summary of status and progress to Programme Support who will use this information to up-date the overall programme plan for the Programme Manager. A Programme Highlight Report will be prepared and sent from the Programme Manager to each member of the Programme Board. Assurance for the whole programme of work and for individual projects will primarily be the responsibility of Programme Support whose 71
  • 72. Ken Bradley’s Understanding PRINCE 2 authority devolves from the Programme Manager. Typically (but not necessarily) the Programme Board will meet on a time related basis, possibly every 6-8 weeks, depending entirely on the sensitivity, risk or profile the programme has within the organisation. Programme And Project Resources These are often shared over all projects and identification, use and monitoring of the resource pool is an important aspect of managing a programme of work. It is all too easy for each individual project to plan to use the same resources to the full extent of their availability, thus ensuring over-utilisation and consequent slippage of the whole programme. This can be avoided by the use of a suitable software planning tool which allows sub-project or roll-up planning. Other Structures Based On PRINCE 2 The PRINCE 2 organisation structure principles may be used to form the basis of a variety of different projects. For example, many organisations are involved in Concurrent Engineering or Rapid Application Development projects; a suitable PRINCE 2 compliant structure has been produced and is included on the next page (Figure 30). The model as presented is straightforward and conforms, generally, to the requirements of PRINCE 2, with an owner with ultimate authority (The Project Board) reporting to Corporate Management to ensure that the development project resides within the overall strategy for the organisation, reflecting corporate objectives. The Project Team is totally enclosed within the project structure, with separate Team Managers responsible for the discrete stages of the work. The project is under the direction of a Project Manager, exercising management control on a day to day basis through the Team Managers and through Project Support, as the Project Manager may be expected to be fully involved with the development, testing and installation of the emerging end-product. Products will be passed forward within the organisation to the succeeding Team Manager, and in some circumstances passed back for re-work. 72
  • 73. Ken Bradley’s Understanding PRINCE 2 Corporate Management Project Board & Project Assurance Project Manager Specification, Analysis Project Support & Design Team & Administration Team Manager Development Team - User/Customer - Analyst Team Manager - Design Implementation & User Resources - Programmer Testing Team - Analyst - Design Team Manager Resources - User/Customer - Analyst Resources Project Resources Figure 30: Rapid Application/Concurrent Engineering Organisation Model Project Support will provide an important co-ordination function within this type of project. Typical tasks will include: ♦ setting up regular (possibly 4-6 meetings between Team Managers and the Project Manager every day); ♦ up-dating the Project Plan to show actual progress and expenditure profiles; ♦ initial preparation of Highlight Reports for the Project Board; ♦ liaison with any Project Assurance appointees to ensure that organisational standards are being observed; ♦ incidental support to the Team Managers; ♦ provision of a communications centre for the whole project. Quality Assurance imposes a discipline from the Corporate level through a published Quality Management System and Project Assurance remains the responsibility of the Project Board, although this may be delegated (but not to anyone within the Concurrent Engineering/Rapid Application Development team). 73
  • 74. Ken Bradley’s Understanding PRINCE 2 It should be stressed that the organisation structure shown does not form part of the PRINCE 2 Method but is included to illustrate how the principles within the method may be easily adapted to reflect organisational needs. PRINCE 2 Organisation - Summary The key points within the PRINCE 2 Organisation Component are: ♦ Corporate or Programme Management appoints the Project Board, who have overall and ultimate responsibility for the successful delivery of the project. Initially the Executive member is appointed (Process SU1) along with the Project Manager. ♦ The Project Board endorse the Project Management Team designed and initially appointed by the Project Manager and Executive within the SU Process. ♦ The Project Manager is responsible for day to day planning and control, helped where appropriate by one or more of Team Managers. Project Support might be provided where the Project Board believe this would help. ♦ The Project Board members may choose to delegate some or all of their Project Assurance responsibilities, but accountability will always reside within the Project Board, and ultimately with the Executive. ♦ Project Support provide administrative support (and sometimes technical help) to the Project Manager and, where appropriate, to the Team Manager(s). ♦ Project Assurance will always be a separate entity to Project Support. ♦ A Project Support Office might well address both support and assurance functions, but these would need to be assigned to separate individuals within the Project Support Office. ♦ Products and documents must be properly stored and safeguarded, and a suitable Configuration Management System must be in force to make these arrangements; Project Support will usually be responsible for the operation of the Configuration Management System - the Project Manager is responsible for its integrity, which will be audited by Project Assurance on behalf of the Project Board. 74
  • 75. Ken Bradley’s Understanding PRINCE 2 Chapter 4 UNDERSTANDING THE PLANNING COMPONENT AND PRODUCT-BASED PLANNING TECHNIQUE 75
  • 76. Ken Bradley’s Understanding PRINCE 2 Planning - Introduction & Overview The PRINCE 2 Method does not prescribe any particular type of plans which must be used on a project. The principles of “Product Based Planning” are incorporated in the method within the “Techniques” section and the overall assumption is that some form of software support planning tool will be used. The exact form and layout of the plans is left for the implementing organisation to decide, probably influenced strongly by whatever software planning tool is currently in use. There will typically be up to 3 planning levels within a PRINCE 2 project, although there is no limitation on the number of levels which might be utilised. Typical levels of plan are: ♦ Level 1: Project Plans ♦ Level 2: Stage Plans ♦ Level 3: Team Plans ♦ plus Exception Plans where there has been a significant departure from the approved plans and some re-planning must be done to recover the situation. Individual Plans assigning particular Products and their associated work packages to members of the project team might also be utilised if this is appropriate. Project Plan (Mandatory Plan) Stage Plan Stage Plan Stage Plan Team Team Team Team Team Team Plan Plan Plan Plan Plan Plan Project Resources Report (Effort, Costs, Equipment, Direct Costs) Figure 31: Levels of Plan In PRINCE 2 Plans at Levels 1 and 2 are necessary for effective planning of a major project – both the Project Plan and the Stage Plan are mandated in the Method. 76
  • 77. Ken Bradley’s Understanding PRINCE 2 Project Plans may provide sufficient detail for the early stage plans to be incorporated within them. Plans at the lower Levels are optional but will usually be necessary to produce in order to gain full understanding of the undertaking and to exercise effective control at team level. The plan structures at all levels (including the Exception Plans, which are intended to replace the plan which it has been necessary to up-date) are similar in content and structure; at team level for the individual, if these are used, the only plan needed will be a simple Gantt Chart or Activity List covering either one or two elapsed weeks. This type of plan is often available as a standard output from the planning support software. The Plan Text provides a high-level, overall view of Plan the plan, summarising its key features Text Product Identifying the Products/Deliverables that will be Breakdown produced by the Project. The Products will be categorised Structure under the headings of “Specialist”, “Management”, and “Quality” Products. Describing the Products/Deliverables that will be Product produced by the Project. There is a prescribed format Descriptions for Product Descriptions Describing the relationships that exist between Product each Product/Deliverable, and external entities. Flow Diagram PERT or Showing the relationships that extist between the Activities that will be undertaken Activity to create the Products identified in the Product Breakdown Structure. Network Gantt Derived from the PERT Network, this shows when Activities are or planned to start and end. Major Review points (End Stage Timescale Assessments) are also shown on this plan. Plan Figure 32: The PRINCE 2 Plan Package Project Level Plans Construction of PRINCE plans should normally be on a top-down basis; this will provide a logical and controlled descent into detail and will help to identify any grouping of Products and associated activities that might usefully be treated as a separate sub-project. In some cases, however, it will be appropriate to work at the stage level in order to provide a realistic picture of the total development. The more detailed activities will then need to be grouped to provide an overall view at the project level. 77
  • 78. Ken Bradley’s Understanding PRINCE 2 Product Breakdown Structure The start-point will be to give consideration to the design of the plan (how many levels, the general approach to planning, the most suitable software support tool to use, involvement of external support services etc). As the initial step, a list of Products to be produced during the project must be created. These Products will be at the Project level and must be identified by the Project Manager and the appropriate Team Manager where appointed. The resultant list should then be critically reviewed with the Project Management Team in the light of what is known about the proposed project, to produce an agreed list of high-level Products to be produced. This is known as a Product Breakdown Structure and contains a list of the Specialist Products, Management Products, and Quality Products associated with the project. Management Information System Management Products Specialist Products Quality Products MP01 - Project Initiation Document SP01 - User Specification QP01 - Product Descriptions MP02 - Stage Plans SP02 - Logical Design QP02 - Quality Review Documentation MP03 - Lessons Learned Log SP03 - Physical Design QP03 - Project Issues Log MP04 - Risk Log SP04 - Contract QP04 - Quality Log MP05 - Business Case SP05 - Hardware QP05 - Configuration Management MP06 - Product Checklist SP06 - Software MP07 - Highlight Reports SP07 - Communications MP08 - Project Start Notification SP08 - Integrated System MP09 - Project End Notification SP09 - Technically Tested System MP10 - Project Filing Structure SP10 - User Accepted System SP11 - Trained Staff SP12 - Test Products The Project Management The Quality Management Standard for the The Technical Management Standard for the Project Standard for the Project Project Figure 33: Specialist, Management & Quality Products Each Product must be supported by a Product Description which addresses the following: ♦ Product Title & Identification; ♦ Purpose; ♦ Composition; ♦ Derivation; 78
  • 79. Ken Bradley’s Understanding PRINCE 2 ♦ Format & Presentation; ♦ Allocated To; ♦ Quality Criteria; ♦ Type of Quality Check Required; ♦ People or Skills Required for Reviewing/Testing the Product. The above headings may be added to but must not be omitted in order to secure PRINCE 2 compliance. Product Descriptions form a significant part of the Quality Plan for the project and are fundamental to its successful outcome. For these reasons Product Descriptions must not, in any circumstances be omitted from any PRINCE controlled project. SP01 - User Specification User Requirements Enhancements Functional Data Short/Medium Long Requirements Requirements Term Term Strategies Education Testing Cut-Over Fall-Back Strategy Strategy Strategy Strategy Technical User Testing Testing Module System Testing Testing Figure 34: Example Product Breakdown Structure For The “User Specification” Product Every PRINCE 2 project will have at least one Product identified (the End Product) and defined in terms of a published and baselined Product Description. Baselining of a Product Description will take place when the plan it relates to is baselined (agreement by the Programme Director/Executive (for Programme Plans), the Project Board (for Project Plans) and the Project Manager (for Team Plans)). A Product Description, once approved and base-lined, may only be changed via the Change Control procedure. 79
  • 80. Ken Bradley’s Understanding PRINCE 2 Product Flow Diagram A Product Flow Diagram may then be drawn showing how the various products identified are derived, one from another and from external Products and Entities. This helps to confirm that all the Products that need to be produced have, in fact, been identified; all Products in the Product Flow Diagram must balance with those in the Product Breakdown Structure, and each must be supported by a Product Description. Feasibility Study SP01 - User Specification Users/Existing System Potential Suppliers SP02 - Logical Design SP03 - Physical Design SP04 - Contract SP12 - Test Products SP05 - Hardware SP07 Communications SP06 - Software SP08 - Integrated System SP09 - Technically Tested SP11 - Trained Staff System SP10 - User Accepted System Figure 35: Product Flow Diagram The Product Flow Diagram helps set a basic approach and chronology for the completion of the Products. Stage beginnings and endings, and candidates for sub-project groupings can also be determined from this diagram, although the final timings of Management Stage endings will not be able to be made until later when the Gantt Plan (or Timescale Plan) has been produced. Construction of the Product Flow Diagram helps the project planners to appreciate the overall approach and strategy that underpin the project. Any "missing" Products will be more easily identified (these must of course be incorporated into the Product Breakdown Structure and defined within Product Descriptions). Less than obvious linkages between Products will be more clearly apparent at the time the Product Flow Diagram is drawn, and the successive iterations will help to hone the overall approach to a more realistic shape. Another useful function of the Product Flow Diagram is the help it gives in identifying Activities for inclusion in the activity plans. 80
  • 81. Ken Bradley’s Understanding PRINCE 2 * Interview Users * Produce Specification Users/Existing System SP01 - User Specification Review FS Produce Business (Logical) Design Feasibility Study SP02 - Logical Design * Extract Test Data * Clean Data Produce Business (Logical) Design * Produce Test Schedule SP03 - Physical Design SP12 - Test Products * Prepare & Issue Tenders * Produce Tender Evaluation Criteria * Unit Testing * Assess Offers & Select Supplier * Suite Testing * Issue Contract * Produce & Agree Program Designs * Write Programs (& Fixes) SP04 - Contract SP06 - Software Figure 36: Product Flow Diagram With Activities Identified The Activities identified on the Product Flow Diagram are sometimes referred to as “Transformations” reflecting that they provide the means of transforming one or more Products into another. PERT Network The PERT Network is a basic tool in project management; its full designation is “Programme Evaluation & Review Technique” and the information to produce it may be derived from the Product Flow Diagram. Alternative names for the PERT Network are “Critical Path Network”, “Critical Path Method”, and “MIST - Minimum Irreducible Sequencing Technique”. The Product Flow Diagram defines the data flow and relationships between Products to be produced, and the PERT Network defines the activities needed to create each Product. The PERT Logic Network & The Timed Network The Logic Network shows the activities needed to produce each Product and establishes the dependency relationship between activities. The Timed Network provides additional information on the elapsed time to be taken for each activity and allows the total project cycle time to be predicted. The Timed Network will also provide information on start and finish times, critical paths, sub-critical paths and float. 81
  • 82. Ken Bradley’s Understanding PRINCE 2 3 7 10 10 4 14 50 Review The 60 Prepare Board Strategy Plan Position Paper 5 2 12 12 2 16 0 3 3 3 2 5 11 5 16 16 2 18 10 Appoint The 20 Appoint The 30 Design & Appoint 40 Produce The PB Executive Project Manager The Project Team Project Brief 0 0 3 9 6 11 11 0 16 16 0 18 Earliest Start Time (EST) Duration Earliest FinishTime 3 8 11 (EFT) 70 Plan The 0 3 3 Project Approach 10 Appoint The 3 0 11 PB Executive 0 0 3 Latest Start Time Total Float Latest Finish Time (LST) (LFT) Figure 37: PERT Network - Timed And Logic Diagram Earliest Start Gantt Plan Using the information on earliest start and finish times from the Timed Network, an Earliest Start Gantt Plan can be produced. This chart will provide the basis for Project Board approval. But first some tuning/resource smoothing has to be carried out. Earliest Start Time Earliest Finish Time Latest Finish Time Activity Total Float Figure 38: Creating The Earliest Start Gantt Plan Resource Smoothing The Timed Network will have assumed unlimited resources were available and concentrated solely on the underlying logic of the relationship between activities. This 82
  • 83. Ken Bradley’s Understanding PRINCE 2 does not, of course mean that any number of people are available to the project, but that those that are assigned to the project are assumed to be able to work at any time (even to the extent of carrying out simultaneous multiple activities. Un-smoothed Gantt Plan (Earliest Start) Produce Plan Id Sources Prepare Docs Prepare I/Vs Appointments Interviews Resource Smoothed Gantt Plan (With Stage Reviews) Produce Plan Id Sources Prepare Docs Prepare I/Vs Appointments Interviews Management Management Management Stage 1 Stage 2 Stage 3 Figure 39: Creating The Resource Smoothed Gantt Plan The Earliest Start Gantt Plan will clearly show overlapping activities where resource usage will be over-stretched. To inject reality into the plan it will be necessary to smooth the resources. Although not dealt with in the methodology, resource smoothing is an essential feature of project planning. Resource smoothing is best carried out using a software support package (such as Microsoft Project (MS Project), Project Manager’s Workbench (PMW), or Primavera), initially, and then tuning "by hand". Full manual resource smoothing is a time consuming and tedious task involving many iterations and modification of both the Time- scale/Bar Chart and the underlying Timed Network. After smoothing, the resource usage may still be excessive, or the end date for the project may have slipped back too far to be acceptable to the sponsor. In these cases it will be necessary to reconsider the logic of the Timed Network and to plan for overlaps of activity that would enable more effective use of resources and bring forward the delivery forecast. Such action will invariably increase the risks to the project and will need to be properly assessed and documented for a decision by the Project Manager or Team Manager and subsequent endorsement by the Project Board. 83
  • 84. Ken Bradley’s Understanding PRINCE 2 Project Gantt Plan The Gantt Plan is the result of the resource-smoothed earliest-start bar chart. and provides a view of the Products related to the envisaged time-scales for the total project, readily showing where "clusters" of Products will be ready and thus point to natural Stage beginnings and endings. The Project level Gantt Plan has the End Stage Assessment control symbols added in, at appropriate key decision and resource commitment points and is then ready for approval by the Project Board. Initiate Specify Design Build Test Train Hand-over Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Closure End Stage Assessment (ESA) Figure 40: Gantt Plan With End Stage Assessments Added Project Resource Reporting A Project Resource Report provides a summary of the Effort and Cost of that effort on a Stage-by-Stage basis. A separate Resource Plan is not specifically required by PRINCE 2, as the Method presumes that a software planning tool will be in use and any resource information required will be able to be drawn from the Project Plan and presented in whatever format is required. Information on the planned use of resources (and the subsequent record of actual usage) is an essential element of decision support for management and should not be omitted without good reason. In projects where a software support tool is not being utilised, it may be produced by taking a copy of the Project Gantt Plan and creating a "Transfer Sheet" for each resource type. The transfer sheet provides a statement of the resource usage against each activity for the whole project; the planned effort usage for each stage is totalled and transferred to the Project Resource Plan. 84
  • 85. Ken Bradley’s Understanding PRINCE 2 Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual EFFORT (Staff Weeks) Skill Types Customers Engineers IT Analysts Others COSTS (£K) Skill Types Customers Engineers IT Analysts Others Equipment Fixed Price Elements Total Stage Costs Total Project Costs Figure 41: Resources Report (or Plan) The resource effort on the Project Resource Plan is then converted to resource cost by reference to capitation or charge-out rates. Direct costs (for purchase of equipment etc) is also added, as is the cost of any purchases for the development. The aim is to capture the total, true costs of the project. When all the costs have been identified on the Project Resource Plan, they are cumulated in order to provide input to a Graphical Summary of the overall project. Graphical Summary This plan is not a stated or required part of the PRINCE 2 Method, but is useful to know about as it enables the project plans to be summarised on a single sheet in a graphical format. It summarises the planned expenditure using the vertical axis to illustrate costs and the horizontal axis for time. At the project level it is acceptable to show a cumulative summary of each stage's planned costs , although the Project Board may require a more detailed analysis. If this is required, the Project Resource Plan should be re-drawn to show information at a similar level as it is important that all plans should be consistent with each other. 85
  • 86. Ken Bradley’s Understanding PRINCE 2 Cost Stage £110K £18K .... Stage £92K £58K .... Stage £34K Stage £14K .... £20K £20K .... Management Management Management Management Stage 1 Stage 2 Stage 3 Stage 4 Time Product Ready Specification Business Design Agreed Design Contract Completed System Tested System Trained Staff Pilot Handover Initial Support Complete Customer Acceptance Project Close-Out Quality Reviewed Work Finished Work Started Work Package Agreed Figure 42: Graphical Summary Of The Plans A useful feature on the Graphical Summary is the inclusion of delivery slots for major Products. This information provides essential technical progress data and enables the Project Board to assess the actual achievement against actual spend when reviewing the plans at the end of each stage. The headings used in the Graphical Summary to show the status of each Product may be used in conjunction with the Product Checklist. This document has planned and actual dates inserted to show progress of Products. It is most useful at Management Stage level but is also produced at Project level. Earned Value Analysis An extension to the Graphical Summary is the Earned Value Analysis chart. This technique takes performance measurement a step further, enabling a clear measurement of the project work accomplished and more disciplined forecasts of the likely task and Product completion dates and associated costs. The concept of Earned-Value Analysis is not incorporated into the PRINCE 2 Method, but is being used increasingly and may be expected to be included in a subsequent revision. Earned Value replaces the traditional practice which only compares Actual Cost with Actual Progress and is based on assigning a value to the achievement of project work. Ideally achievement is measured in terms of Milestones and Major (ie Product-level) Products delivered. 86
  • 87. Ken Bradley’s Understanding PRINCE 2 Cost £200K Time Now Predicted Revised Cost Projection of Planned Predicted Cost Actual Costs Cost Over-Run £110K Actual Cost Original Planned Cost Predicted Schedule Value Earned Over-Run Time Initial Support Complete Product Ready Specification Business Design Agreed Design Contract Completed System Tested System Trained Staff Pilot Handover Customer Acceptance Project Close-Out Quality Reviewed Work Finished Work Started Work Package Agreed Figure 43: Earned Value Analysis The value is usually monetary but can be expressed in any appropriate unit such as staff hours or days. The value to be earned when a specific Milestone or Major Product is achieved is based on the planned cost of achieving the Milestone. For example, if the plan showed that £100,000 was required to achieve a specified Milestone/Project Product, £100,000 worth of Earned Value would be credited to the Project Manager (as “owner” of the Product”) when achievement of the Product was demonstrated (ie that the Product had successfully met all its Quality Criteria). Again, it is worth emphasising that the plans described above, the Graphical Summary and the Earned Value Analysis plan are not requirements of PRINCE 2, but are useful vehicles for illustrating project situations to the Project Board and other senior managers. Risk Analysis Risk analysis must be carried out in a structured manner. A Risk Analysis should always be completed at Project Initiation and up-dated, minimally, when preparing for each End Stage Assessment/Project Board meeting. PRINCE 2 requires that a Risk Log be kept to record the (hopefully reducing) risks faced as the project progresses. The risk analysis provides a complementary part of the Business Case for the Project and will be summarised in the Project Plan Description. 87
  • 88. Ken Bradley’s Understanding PRINCE 2 The risk analysis will address other issues, of course, (eg staff turnover; project management expertise, third party suppliers etc) but if time is to be saved by the compression of time-scales by overlapping naturally dependent activities, this presents a very real risk to the success of the undertaking and may well involve some nugatory expenditure. For these reasons the implications of resource smoothing at this point in planning must be seriously considered. Measuring The Business Benefits When all the resource usage and cost information has been assembled, the Project Business Case can be created (“Initiating A Project”) or reviewed (“Managing Stage Boundaries”). Year 0 1 2 3 4 5 Costs: (10 0 ) (20) (20) (20) (40) (30) Benefits: 0 40 80 10 0 10 0 10 0 CashFlow: (10 0 ) 20 60 80 60 70 Cumulat ed: (10 0 ) (80) (20) 60 120 190 Discount Factor (@6 %) 1.00 .94 .8 8 .83 .78 .74 Discount ed Cash Flow (10 0 ) 19 53 66 47 52 Cumulat ed DCF (10 0 ) (81) (28) 38 85 137 Figure 44: Simplified Business Benefits - Costs:Benefits Analysis & Investment Appraisal A high-level Business Case would normally have been produced during the Feasibility or Preliminary Study, based upon information contained in the organisation's Strategic Plan. This initial business case would have been subsequently refined and, following approval by Corporate or Programme Management, passed with the Project Mandate to the Project Manager for formal Start-up and, following approval at the Project Initiation Meeting, the Initiation of the project. The main elements of the Business Case are the reasons for the project, and a Benefits and Costs Statement. An optional Costs:Benefits Analysis and Investment Appraisal may also be created to measure the Business Benefits of the project’s outcome. If thought to be necessary a Sensitivity Analysis may also be produced. A Risk Analysis and proposals arising from it, recorded in the Risk Log, is also closely linked to the PRINCE Business Case. Essentially all costs are fed into the model and all tangible benefits added in. The result will be a Cash-flow for the project. This is then discounted by the appropriate rate (currently 6% in Government, but often higher within the private sector) and the Dis- counted Cash Flow identified. The areas of main interest are: 88
  • 89. Ken Bradley’s Understanding PRINCE 2 ♦ the point at which the project starts showing a positive return ♦ the overall return on the investment in the project (the Net Present Value). Where a full Cost:Benefits Analysis and Investment Appraisal is not required by the Project Board, a narrative statement of the Benefits should be produced. This lists all the anticipated benefits but does not attach any specific financial value to them. Project Plan Text The plans described are used for the overall control of the project and provide a summary of the planned work and expenditure. To initiate the project (and to approve each successive Management Stage) the Project Board will require a document which ties the complete plan package together and describes the approach and general philosophy. This document is the Plan Text (also known as the Plan Description, Plan Narrative or Executive Summary) and will be mainly a narrative summary with the plans described above attached as appendices. The Plan Text typically contains the following information: ♦ the plan pre-requisites (what must be in place in order for the plan to work - eg staff recruited, users assigned, equipment installed and building work completed); ♦ the plan assumptions (the bases upon which the plans has been constructed - eg staff rates, discount factors used etc); ♦ the plan risks (the specific areas of risk that have been identified and must be closely monitored - eg overlapping activities, staffing concerns etc); ♦ the overall time-scale for the project and how it has been achieved; ♦ the impact of resource usage on this project on other projects, undertakings etc. ♦ the return on the investment and the overall business case related to project viability. Management Stage Plans The Management Stage Plan package has a similar structure and its production follows a similar path to the Project Plan package. The Stage Plans are produced in the “Managing Stage Boundaries (SB)” Process. Short horizon, limited commitment, planning is a fundamental feature of PRINCE. The aim is to provide an overall view of the likely project profile (via the Project Plan package) with a succession of short term limited commitments for the sponsor (via the Management 89
  • 90. Ken Bradley’s Understanding PRINCE 2 Stage Plan documentation). The structure of the PRINCE 2 Stage Plan package is as follows: ♦ Stage Product Breakdown Structure - listing all the Stage Products to be produced. Product Descriptions must also be available (or produced) for all Stage Products. ♦ Stage Product Flow Diagram - listing the Products to be produced during the stage and the derivation paths. ♦ Stage Timed PERT Network - showing the Earliest Start/Finish Times, Float and overall project timings. ♦ Stage Gantt Plan - This plan relates specialist activities against time-scales (typically on a week-by-week basis) and summarises the level of control (frequency of Checkpoints, Quality Reviews and another meetings required by the Project Board). ♦ Stage Resources Report- summarises the resource effort and costs for the stage. Where there is no software support package in use, a Stage Resource Plan should be provided to identify the effort and costs to be approved by the Project Board. It is produced by taking the Stage Gantt Plan and creating a Transfer Sheet for each resource. The Stage Resource Plan is usually constructed on a week-by-week timescale and, in any case, must match the Stage Gantt Plan. ♦ Optional Stage Graphical Summary - provides a graphical view of the time:cost: achievement for the stage. This might be supplemented or replaced by and Earned Value Analysis Plan. ♦ Stage Plan Text - ties together and summarises the above plans and will essentially cover the stage plan pre-requisites, assumptions and risks. This narrative might be incorporated into the Project Plan Description. Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Start-Up Project Brief Project Approach PID Interview Users Produce Spec Outline Design Final Design Agree Design Figure 45: Stage Plan Derived From The Project Plan 90
  • 91. Ken Bradley’s Understanding PRINCE 2 Team Plans Team Plans will usually (but not necessarily) be required for all but the smallest of projects. They drop the Stage Plans down to an increased level of detail in much the same way that the Stage Plans reflect an increased level of detail of the Project Plans. Team plans are optional within the PRINCE 2 Method and where they are produced they will normally be prepared by the Team Manager within the “Managing Product Delivery (MP)” Process, based on the authorised Work Package in consultation with the Team Members and agreed with the Project Manager. The Team Plan Package, where produced, will be related to a specialist team working on a specific Product or set of Products or they might be aimed at an individual working within the project. Team Plans will often reflect the work to be carried out in a Technical Stage within a Management Stage of the project. Individual Plans Individual Plans (sometimes referred to as Work-to Lists) are not required within PRINCE 2 but may, at the Project Manager/Team Manager’s discretion, be drawn up for individuals working on specified Products. The Individual Plans, where used, will be derived directly from the Detailed Gantt Plan and will form the basis for discussion of progress at the regular (usually weekly, but at the regularity agreed within the authorised Work Package) Checkpoints. The Individual Plan may comprise a detailed Bar Chart/Gantt Chart, Activity List, or might only identify start and finish dates and Activity Status for specific Products. PRINCE 2 Planning - Summary There is a need within any project to produce plans in sufficient detail to derive understanding of the way that objectives are to be achieved. In the final analysis, control can only be exercised at the level that is enabled by the plans. If a project is planned only at a high level then detailed control cannot be effected. The recommended approach is to plan in detail to get a full understanding of what is involved and then to select an appropriate level of control based on what is known about the project. 91
  • 93. Ken Bradley’s Understanding PRINCE 2 Chapter 5 UNDERSTANDING THE CONTROLS COMPONENT 93
  • 94. Ken Bradley’s Understanding PRINCE 2 Introduction To Controls The main mission of any project management method is to enable management at all levels to exercise control over what has been planned and approved. The approved plans reflect what is required to be achieved and the structure of controls enables managers to reach informed decisions about committing resources and giving approval to proceed. Regular and formal monitoring of actual progress against the approved plan is essential to ensure the timeliness, cost control and quality of the system or undertaking being developed. PRINCE 2 provides the essential support structure of Management and Product-oriented controls to monitor progress, supported by a reporting procedure which enables re-planning or other appropriate corrective action to be taken. PRINCE 2 controls fall into three main categories – Management Controls, Quality Controls and Configuration Controls; the latter two are covered in separate Chapters in this book. Management Controls Most PRINCE 2 management controls are “event-based”; this facilitates management- by-exception and helps reduce the overall cost of project control by limiting managers’ effort to occasions when decisions are really needed. PRINCE 2 provides a structure of management controls to be applied throughout the project. These controls cover all aspects of project activity and, at the highest level, allow the Project Board to assess project achievement and status prior to committing further expenditure. Controls are applied through measuring the progress towards production of a set of pre-defined outputs (Products or Deliverables). The overall structure of Management Controls is defined at Project Initiation (IP4) to ensure that the project is set up with clear Terms of Reference, incorporating agreed and measurable Objectives and an adequate management structure. Controls are applied at Project Board, Project Manager and Team Manager levels. Configuration control and Quality control is exercised by the Project Manager and Team Managers. The main Project Board controls are: ♦ The Project Initiation Meeting (establishing whether there is a worthwhile and viable project); ♦ Project Initiation & the Project Initiation Document (PID) (fixing a baseline for the project); ♦ End Stage Assessment (ensuring the project is still viable and authorising progress to the next Management Stage through the approval of the next Management Stage Plan); 94
  • 95. Ken Bradley’s Understanding PRINCE 2 ♦ Tolerance (providing time and cost margins within which the Project Manager has discretion to deviate from the approved plan without seeking authority from the Project Board); ♦ Mid-Stage Assessment (where significant deviations from the approved plans are considered and an Exception Plan approved); ♦ Project Closure (authorising close-down of the project after ensuring that all the project’s Products have been delivered to the required quality standards and that customer acceptance has been obtained); ♦ Highlight Reports (regular, normally time-based, reports from the Project Manager to Project Board members to keep them informed of the progress and status of the current Management Stage); The Project initiation Meeting The pre-project Process “Starting Up A Project (SU)” seeks to answer the question “Do we have a worthwhile and viable project?”. Creation of the Project Brief, Risk Log, Project Approach, Initiation Stage Plans, Organisation Structure and Role definitions contribute to answering this question and formal acceptance that there is a worthwhile project on offer is confirmed by the Project Board at the Project Initiation Meeting (PIM). There is no real need to hold a formal meeting for all projects but the formality that a meeting provides will be appropriate for major investments. The PIM is a control function of “Authorising Initiation (DP1)” which sits in the “Directing A Project (DP)” Process. The “official start” of the project occurs following this approval which enables the Project manager and team to begin to create the elements of the Project Initiation Document (PID) during the required Initiation Stage of the project. • Project Brief • Risk Log Initiation Stage 2 • Project Approach • Organisation Stage • Initiation Stage Plan Project Initiation End Stage End Stage Assessment Meeting Assessment Do we Have A Worthwhile& The Project Initiation viable Project? Document Provides The End Stage Report the Project Baseline confirms the result of the last Stage and reports on the overall project viability. It also contains the plans for the next Stage. Pre-Project ........ The Project Lifecycle ......................... Figure 46: Pre-Project and the Project Initiation Meeting 95
  • 96. Ken Bradley’s Understanding PRINCE 2 Project Initiation & the Project initiation Document (PID) Project Initiation ensures a firm foundation and provides a positive start to the project, ensuring that the terms of reference, objectives, plans and controls, business risks, benefits and financial return, quality plans, organisation structure and job definitions are clearly defined, published, understood and agreed. Every organisation using PRINCE 2 as the basis for its project management standards should create, agree and publish a suitable specification for its content and quality criteria – this will normally take the form of a Product Description and a suitable start-point is the outline contained in Appendix A17 of the PRINCE 2 Method manual. This Management Product is very important to the project and is the result of two Processes - “Starting Up A Project (SU)” and “Initiating A Project (IP)”. The key output is the Project Initiation Document (PID) which, when approved, is a reference document used to Baseline the project. The PID is used throughout the project as a reference back to the original intentions and management objectives. During the “Closing A Project” Processes, the PID is used to reference the original Acceptance Criteria and secure Customer Acceptance (CP1), and to provide the statement of the original project objectives, scope and constraints for creation of the End Project Report. End Stage Assessment (ESA) This is a mandatory management control and occurs at the end of each stage. It typically consists of a formal presentation to the Project Board of the current project status, and reviews the overall Business Case and risks. The vehicle used for this is the End Stage Report. “Managing Stage Boundaries” Process •Up-date the Plans for Stage 1; •Up-date the Project Plans; •Up-date the Business Case (Benefits & Risks); •Prepare the Plans for Stage 2 Stage 1 - Planning & Definition Stage 2 - Design & Contract End Stage Assessment (ESA) “Directing A Project” Process •Review the Outcome of Stage 1; •Review the Project Plans; •Review the Business Case (Benefits & Risks); •Preview the Plans for Stage 2. •Endorse the Project & Approve continuation of the project up to the next End Stage Assessment. Figure 47: Handling End Stage Assessments The approval of the proposed plans for the next stage is also obtained. Project Board 96
  • 97. Ken Bradley’s Understanding PRINCE 2 approval, with agreement by all the members, must be obtained before the project can proceed to the next stage. Attendees at an End Stage Assessment The attendees at an End Stage Assessment will be as follows: The Project Board members (attendance should not be delegated to someone else except in exceptional circumstances; where a Project Board member finds it necessary to send a representative rather than attend personally, the representative must be empowered to take decisions on behalf of the Project Board member. Frequent delegation of attendance should provoke the Executive to consider replacement of the non-attending Project Board member). The Project Manager (the Project Manager is not a member of the decision-making Project Board but must attend to report to the Project Board and to take direction). Project Assurance (to confirm that project management standards are being observed and that “all is well” with the project. This function is essentially one of “reassurance”). Project Support (to take care of the administrative arrangements and record the End Stage Assessment). In addition to the above, the Project Board and Project Manager may invite any other person or representative of any organisation who may be able to assist in the Project Board’s decision making process. These might include Team Managers, Team Members, Policy Advisors, Suppliers and Sub-Contractors. ESA Agenda Although PRINCE 2 does not specify a specific agenda for running ESAs, the following suggested agenda will help in preparing for this important Project Board control: Item 1: Introductions (if external people are present for the first time). Item 2a: Project Manager’s Report on the Current Management Stage. Item 2b: Project Assurance report on the Current Stage. Item 2c: Discussion, Questions and Acceptance of Project Manager’s Report. Item 3a: Project Manager’s Report on the Overall Project: - Project-Level Products – Added/Removed. - Timescale – Current/Forecast to Completion/Variation + Reasons. - Costs/Effort – Current/Forecast to Completion/Variation + Reasons. Item 3b: Project Assurance report on the Overall Project and Projections. Item 3c: Discussion, Questions and Acceptance of Project Manager’s Report. 97
  • 98. Ken Bradley’s Understanding PRINCE 2 Item 4a: Project Manager’s Report on the Business Case & Risks: - Business Case – Original/Current/Forecast/Variations + Reasons. - Risks – Original/Current/Forecast/Variation + Reasons. - Risk Log –Entries Removed; New Entries. Item 4b: Project Assurance report on the Business Case & Risks. Item 4c: Discussion, Questions and Acceptance of Project Manager’s Report. Item 5a: Project Manager’s Proposals for the Next Management Stage. Item 5b: Project Assurance comments on the Proposals for the Next Stage. Item 5c: Discussion, Questions and Acceptance of Project Manager’s Proposals. Item 6: Discussion, Questions on Overall Situation. Agreement on Future Actions. Item 7: Any Other Project Related Business (eg External Information Which Impacts on the Project’s Future). Item 8: Project Board Formal Sign-off of the Current Stage and Commitment to the Current View of the Project Plan, Business Case and Risks. Acceptance of the Next Management Stage Plans. + Thanks and Close. Remember, the information to prepare the Project Board for the End Stage Assessment will be contained in the End Stage Report, prepared in the “Reporting Stage End (SB5)” Process which is part of “Managing Stage Boundaries (SB)” Major Process. Mid Stage Assessment (MSA) This Project Board control is held only to review a significant deviation from an approved Management Stage Plan and to approve an Exception Plan produced, at the request of the Project Board, following an Exception Report. An Exception Report is produced by the Project Manager to alert the Project Board as soon as it is apparent that a significant departure from the approved plan is forecast. The Exception Report records what has happened to cause the “significant departure” from the approved plan, the impact on the Management Stage, overall Project and its Business Case. The plan will also recommend appropriate action to take the project to the end of the Stage and, where possible, recover the situation. 98
  • 99. Ken Bradley’s Understanding PRINCE 2 “Controlling A Stage” •Deviation from approved Stage Plans Forecast; Process •Exception ReportCreated - Reasons; Impact; Options; Recommendation; •Direction from Project Board .... Create an Exception Plan; “Managing Stage Boundaries” •Produce an Process Exception Plan Stage 1 - Planning & Definition Stage 2 - Design & Contract Mid Stage Assessment (MSA) “Directing A Project” •Consider the Exception Plan at an unscheduled Mid Stage Assessment. Process •Review the Problems with Stage 1; •Review the Impact on the Project Plans; •Review the im[pact on the Business Case (Benefits & Risks); •Preview the revised Plans for the remainder of the Stage. •Endorse the Project & Approve continuation of the Stage up to the next End Stage Assessment. Figure 48: Handling Mid Stage Assessments The Exception Report may be triggered by a number of different events, sometimes without much advance warning, but in most cases a deteriorating situation will be known by the Project Manager and observed by Project Assurance. Where Project Assurance become aware of a Management Stage in decline an immediate report must be made to the appropriate Project Board member (or the Executive). The Project Manager should provide advance warning to the Project Board members via the Highlight Report – it is most important to “come clean” and not attempt to disguise or hide the situation in the hope that something will happen to improve matters – it invariably won’t happen! Where appropriate the Project Manager should advise the Project Board members informally (by telephone, e-mail, internal memorandum etc) rather than wait for the next formal report. Tolerance The measure of a “significant departure” is that the Tolerance stated by the Project Board at the beginning of the management stage has been, or is likely to be, exceeded. Standard Tolerance in PRINCE 2 is measured in terms of Time (Schedule) and Cost. There are other types of Tolerance which may be applied; these include Tolerance on Quality, Technical Conformance, Scope and Risk. Tolerance need not necessarily be equal – for example, it may be appropriate to set differential Tolerance of +0 and –4 weeks, coupled with cost Tolerance of +£10K and -£30K depending on where priorities lie. 99
  • 100. Ken Bradley’s Understanding PRINCE 2 Plus 10% Tolerance £110K £100K Planned Delivery & Total Cost o Cost £90 Minus 10% Tolerance £80K £70K £60K £50K Plus 1 Week Tolerance £40K £30K Minus 1 Week £20K Tolerance £10K Time 2 4 6 8 10 12 14 16 18 Weeks STAGE PLAN Figure 49: Tolerance - plus/minus 1 week; plus/minus 10% The level of Tolerance is decided by the Project Board following recommendations by the Project Manager. Tolerance is exercised mainly for a Management Stage but is also appropriate at Project and Team Levels. Project Tolerance is set by Corporate/Programme Management. The Executive member of the Project Board is responsible for ensuring that Project Tolerance has been established and recorded in the Project Brief. If at any time Project Tolerance is forecast to be exceeded it is the responsibility of the Executive to report to Corporate/Programme Management and to obtain new direction (possibly re-baselining the project and establishing new Project Tolerance levels). (Management) Stage Tolerance is agreed by the Project Board and set by the Executive. Stage Tolerance is always set within the context of the Project Tolerance – the Project Board do not have any discretion to exceed Project Tolerance without authority from Corporate/Programme Management. Where Tolerance is forecast to be exceeded the Project Manager will convey this to the Project Board via an Exception Report which will typically be followed up by an Exception Plan; alternatively, the Project Board may decide to prematurely close the project. Product Tolerance will usually be recorded in the Work package agreed between the Project Manager and the Team Manager responsible for the Products addressed by the Work Package. Product Tolerance will be agreed in “Accepting A Work Package (MP1)” and used as part of the basis for Checkpoint Reporting in “Executing A Work Package (MP2)”. Obviously, Product Tolerance must not, individually or collectively, exceed the approved Stage Tolerance. 100
  • 101. Ken Bradley’s Understanding PRINCE 2 Premature Termination of Project CS8 1: Exception Report Escalating Project Issues DP4 Giving Ad-Hoc Advice 2: Exception Plan Request) CS1 - Authorising A DP3 Work Package Authorising A Stage or Exception Plan 4: Authorisation SB6 To Proceed Producing An Mid-Stage Exception Plan Assessment 3: Exception Plan Figure 50: Summary of the PRINCE 2 Exception Procedure Tolerance is a major control for the Project Board, which allows its members to focus on exceptions rather than be swamped with information about work which is proceeding to plan. Similar benefits also accrue for Corporate/Programme Management who are able to leave responsibility for the project to the Project Board, sure in the knowledge that any major departures will be brought to their attention. Similarly for the Project Manager who, by setting Product Tolerance with Team Managers/Suppliers, can direct attention to those areas of the project which do need additional support. Project Assurance has a vital role to play here in assuring the Project Board (and the Project Manager for Individual Products) that all is “set fair”. Approving An Exception Plan As mentioned above, the Mid Stage Assessment (MSA) in PRINCE 2 is held only to approve an Exception Plan, following the raising of an Exception Report. Obviously, MSAs will not be planned in advance and will only be held exceptionally. If the duration of a proposed Management Stage is deemed to be too long to be acceptable to the Project Board, then the Stage should be broken into more than one Management Stage with an End Stage Assessment at each new break. The Mid-Stage Assessment control is not appropriate for breaking up long duration Stages. Neither is the MSA intended to be the vehicle for “incidental progress meetings” held by the Project Board; the PRINCE 2 Method makes no provision for such meetings. The End Stage Assessment and the Mid-Stage Assessment are decision-based meetings and major Project Board controls to ensure that all work being undertaken has the support and overt approval of the key managers. 101
  • 102. Ken Bradley’s Understanding PRINCE 2 Project Closure This provides a final review of the project's work is held, usually (but not necessarily) in the form of a Project Board meeting. This is similar in structure to an End Stage Assessment but relates to the entire project rather than a single stage. The objective is to ensure that all the project Products/Deliverables have been satisfactorily delivered to their stated quality standard and that the project documentation is complete. A review of the contribution made by the project management standards and approaches used by the project will be carried out within the “Closing A Project (CP)” Process and a Lessons Learned Report produced for consideration by the Project Board. The Lessons Learned Report records what has been learned from using the PRINCE 2 project management and quality management standards for the project and is first created during the “Initiating A Project – Setting Up Project Files (IP5)” process and “populated” as the project progresses; it will eventually be sent, via Corporate/Programme Management to the organisation’s manager responsible for quality. Recommendations will also be made by the Project Manager for Follow-on Actions to record and trigger any further work recommended following the closure of the project. Recommended Follow-on Actions will usually be derived from any outstanding Project Issues, recorded on the Issues Log and from recommendations impacting on operational and maintenance of the delivered outcome. Highlight Reports The Project Board is kept informed of the progress of the Management Stage (and the project) against the approved plans via regular, time-related Highlight Reports. These are prepared by the Project Manager using information derived from Checkpoint Reports and following a review of the status of the Management Stage. They are usually provided monthly, although their frequency will always be decided by the Project Board. Highlight Reports are usually sent through the post or by e-mail; the objective is to remove the need for unnecessary time-related Project Board meetings which consume the Project Board members’ valuable time, while still keeping them abreast of significant developments. The format for Highlight Reports will typically include: ♦ a statement of the progress made during the last (usually monthly) period; ♦ a statement of problems during the last period, and how they were handled; ♦ confirmation of the Activities and Products to be worked on during the next period; ♦ a statement of the financial and schedule situation for the overall project and the current Management Stage. Some organisations specify that Highlight Reports should be kept to one side of A4 (or its equivalent) and this makes very good sense. 102
  • 103. Ken Bradley’s Understanding PRINCE 2 Where the project is part of a Programme of work, separate Project and Programme Highlight Reports will normally be produced and special attention must be paid to reporting on interfaces with associated projects. It is always good practice to agree a common format for Highlight Reporting where a Programme Director (or Project Board responsible for a number of projects) has responsibility for assessing Programme progress. A graphical representation is a useful medium for achieving a common reporting structure, especially in a Programme environment where the Programme Director may prefer to have a regular, time-based meeting where individual project Managers present their Highlight Report Summaries in short time units. A suitable format which can be adapted for this purpose is the Graphical Summary/Earned Value Analysis plan described in the “Understanding Planning” Chapter in this book. Checkpoint Reports Progress on the work of a Team against the agreed Work Package is the subject of the Checkpoint Report. Typically a Checkpoint Report will be created following a Checkpoint (meeting) in the “Managing Product Delivery Process – Executing A Work Package (MP2)”. Its format and frequency will be agreed in “Accepting A Work Package (MP1)” and it will generally mirror the information contained in the Highlight Report to ease the task of reporting. The Checkpoint Report is used to up-date the Management Stage Plans with “actuals” to date and will ultimately be used as an input to the Highlight Report to inform the Project Board of progress made. Stages Stages are partitions of the project with decision points at their conclusion, and sometimes during their life. PRINCE 2 differentiates between “Management Stages” (which equate to the commitment of resources by the Project Board and a decision to continue with the project and authority to spend) and “Technical Stages” which comprise sets of technical activities leading to a stated Product. 103
  • 104. Ken Bradley’s Understanding PRINCE 2 Technical Stages Initiate Specify Design Build Test Train Handover Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Review of Management Stage at Project Closure End Stage Assessment (ESA) Figure 51: Management & Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned and managed by Team Managers who report to, and take direction from, the Project Manager. Management Stages will always run in series. In the above diagram, the Technical Stages have been planned to run in parallel. Of course, in a smaller project these might well be described as “Activities”; in medium to larger projects, the Activities will often combine to provide the Technical Stages. In only the most exceptional circumstances will authority be given for work to commence on the next Management Stage before all the Products of the current Management Stage is completed. 104
  • 105. Ken Bradley’s Understanding PRINCE 2 Chapter 6 UNDERSTANDING THE STAGES COMPONENT 105
  • 107. Ken Bradley’s Understanding PRINCE 2 Introduction Stages are partitions of the project with decision points at their conclusion and, sometimes, during their life. Management & Technical Stages PRINCE 2 differentiates between “Management Stages” (which equate to the commitment of resources by the Project Board and a decision to continue with the project and authority to spend) and “Technical Stages” which comprise sets of technical activities leading to a stated Product. Technical Stages Initiate Specify Design Build Test Train Hand-over Management Management Management Stage 1 Stage 2 Stage 3 Project Initiation Project Closure Project Board Review of Management Stage - End Stage Assessment (ESA) Figure 52: Management and Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned and managed by Team Managers (within the “Managing Product Delivery (MP1)” Process) who report to, and take direction from, the Project Manager. Management Stages, on the other hand, will always run in series; they will overlap only in exceptional circumstances and always only with the prior agreement of the Project Board. In the above diagram, the Technical Stages have been planned to run in parallel. Of course, in a smaller project these might well be described as “Activities”; in medium to larger projects, the Activities will often combine to provide the Technical Stages. In only the most exceptional circumstances will authority be given for work to commence on the 107
  • 108. Ken Bradley’s Understanding PRINCE 2 next Management Stage before all the Products of the current Management Stage is completed. Management Stages Each PRINCE 2 controlled project will contain at least two Management Stages - one (the Initiation Stage) for planning the project and the other containing the “action” portion, or implementation of the project. Management Stages enable the Project Board to control the release of funding for the project and provide the major control for the project. This is known as “Limited Commitment”. Approval of each Management Stage commits the effort, cost and time resources contained within the Next Stage Plan (prepared in the “Managing Stage Boundaries (SB)” Process). Project Board approval to each Management Stage is given in the context of endorsing continuation of the overall project. The important thing here is that Project Board members understand that the estimates of effort, cost and time within the Project Plan are “soft” estimates only and certainly not cast in stone. The originally approved Project Plan will be embodied in the approved Project Initiation Document which will have been “frozen” at the time it was formally approved (in “Authorising A Project (DP2)” Sub-Process) at the conclusion of the “Initiating A Project (IP)” Process. Each Management Stage will culminate in an End Stage Assessment (ESA), at which point the following options will be open to the Project Board: ♦ Continue into the Next Stage; ♦ Re-visit part (or all) the Current Stage; ♦ “Freeze” the project for a finite or an indeterminate period; ♦ Abort the project. The Project Board should not treat lightly any proposal to commence the next Management Stage before all the Products of the Current Stage are complete. Exceptionally the Project Board may agree to this but the practice is dangerous and may well result in nugatory expenditure. Updating The Business Case At the conclusion of each Management Stage, the Business Case must be reviewed and updated. Specifically this will mean up-dating the statement of Business Benefits to confirm that the project remains on track to achieve them. Where the Business Benefits are supported by a Cost:Benefit Analysis, this must be re-assessed and the results reported to the Project Board. 108
  • 109. Ken Bradley’s Understanding PRINCE 2 The Risk Assessment must also be reviewed and the Risk Log updated, minimally at the completion of each Management Stage. Technical Stages Technical Stages are quite different from Management Stages in that they will invariably be planned to run in parallel, within one or more Management Stages. This saves time within the Management Stage and enables the best use to be made of the available resources. Initiate Specify Design Build Test Train Hand-over Management Management Management Stage 1 Stage 2 Stage 3 Start-Up Project Brief Project Approach PID Interview Users Produce Spec Outline Design Final Design Agree Design Management Stage 1 Figure 53: Creating The Stage Plan From The Project Plan In most major projects, Technical Stages will be present, planned and controlled by Team Managers working directly for the Project Manager. Typically Technical Stages will address specific specialist areas of the project such as Work Packages placed with Suppliers under the cover of formal contracts. There will, however, also be room for Technical Stages for discrete parts of the project being undertaken by internal resources, such as the creation of the Specification for the project’s outcome, as illustrated in the diagram. This work will best be planned and managed by a customer or user. Handling The End Of A Management Stage Handling Management Stage endings is a straightforward task once the basic principles of PRINCE 2 planning and control are properly understood. The main feature to bear in 109
  • 110. Ken Bradley’s Understanding PRINCE 2 mind is that as Management Stages must not run in parallel, some degree of planning for the next Management Stage must be included within the current Management Stage. PRINCE 2 planning allows any combination of activities to be planned and executed provided authority for the work is obtained from the Project Board. It is, therefore, quite acceptable to be working on Products which will be delivered in the next Management Stage provided approval and authority has been given. This enables Management Stages to “butt” against each other and avoids the need to stop work on the project while Project Board members assess the content of the End Stage Report, updated Project Plans, updated Business Case, and the Next Stage Plans. Work, Effort & Cost “at risk” “Natural” Stage End Time needed for the Project Board to review the papers & prepare for End Stage Assessment Stage 1 Stage 2 Figure 54: Handling Management Stage Endings The approach does mean that a risk is being taken that, should the project be terminated at the End Stage Assessment, some nugatory costs would have been incurred - but this risk is well worth taking. If, as is likely, the Project Board is unwilling to accept up to two weeks’ delay to the project at every Management Stage end, this approach is the only real alternative. Failure to plan for Management Stage endings will inevitably put pressure on the Project Manager to undertake some preliminary work on the next Management Stage without formal authority to do so, and this must be avoided. Stages - Summary Management Stages are key control components within a PRINCE 2 project. Adequate review procedures must be established to ensure that commitment of effort and funding resources is fully under the control of the Project Board. 110
  • 111. Ken Bradley’s Understanding PRINCE 2 Chapter 7 UNDERSTANDING THE RISK MANAGEMENT COMPONENT 111
  • 113. Ken Bradley’s Understanding PRINCE 2 Introduction PRINCE 2 places stress on the need for a strong and visible Business Case with the Business Benefits and Risk Management being key features within this concept. No specific techniques are suggested by the Method, although there are some pointers to commonly available packages which will help, especially in the identification and management of risk. The risks perceived for any individual project will be summarised by the Project Manager at the time of Project Initiation, and will be reviewed and up-dated at each Project Review. For many small, low risk projects it will be acceptable to provide only a narrative statement of the perceived risks. However for higher profile, higher value, contentious projects a more formal risk assessment may be required by the Project Board. Version 1 of the PRINCE Methodology referred to a Risk Analysis Checklist, originally put together by CCTA at the request of the User Group. This Checklist has been modified, added to, and adjusted by SPOCE Project Management over a number of years and client implementations, and is reproduced on the following pages. An Excel Spreadsheet containing the Risk Analysis Checklist is available, upon request, from SPOCE Project Management Limited (Telephone UK (+44) (0)1202-780740). It provides a simple and structured way to identify the main risk areas for the project. It should not be regarded as a definitive statement of the precise risks faced by the project but rather as an indicator of the areas that are more likely than not to cause problems! The Risk Analysis Checklist expresses the project manager’s feelings about the likely risks faced A completed example of the Risk Analysis Checklist is included at the end of this Chapter. The final score derived from the Risk Analysis will provide guidance for the proposals put forward by the project manager. Any score in excess of 15 should be extracted and proposals made to the Project Board for reducing or managing the risk. A suggested format for risk management proposals recorded in a Risk Log is as follows: Description of the Risk Risk Score Comment on the Risk Proposals The Project Manager has 21 The Project Manager has many Proposal 1: only limited experience of on-going responsibilities which The Project Manager to managing a major project are expected to take up much attend a Project Mgt. of this type. time and effort (about 4 days training course. each week). He also has no The Project Manager is previous experience of planning Cost: £2,000 also responsible for 3 or managing a project of this other mainstream projects size and scope. Proposal 2: being developed concurrently Buy in an experienced Project Management consultant to advise the Project Manager and provide support during the first two weeks of the project. Cost: £4,000 Figure 55: Risk Log 113
  • 114. Ken Bradley’s Understanding PRINCE 2 Risk Ranges & Risk Factors The risk factors of 2.00 and 2.60 within the Checklist relate to the assessed risk for the project recorded in column (b) which is always rated on a scale of 0.10 to 4.00. The norm for this scale is 2.00; any higher assessment would point to a higher than norm risk and any lower assessment points to a lower than norm risk. 2.00 “Norm Risk” Higher Risk Recommended “Norm” Range 0.10 1.00 3.00 4.00 Lower Risk 2.00 “Norm Risk” Figure 56: The Risk Management Analysis Ranges Applying a risk factor of 2.00 to the assessed weighting in column (e) provides a comparative figure to that obtained when multiplying the weighting by the assessed risk (column (e) x column (b), placed in column (f)). Therefore, if the result of applying the risk factor of 2.00 to the weighting column (e), is less than that calculated for column (f) then the particular component (or the whole assessment) indicates a higher than norm risk for the project as a whole. Conversely, if the application of the 2.00 factor to the assessed weighting (column (e) results in a higher score than that calculated for the total score in column (f), then the component (or overall assessment) indicates a lower than norm risk. The selection of a factor of 2.60 as the threshold for a “very high risk” project is somewhat arbitrary, based on experience and actual situations. The factor may be reduced or increased as experience with project risk within an organisation is gained. The risk Analysis Checklist includes a simple calculation for identifying the risk factor for the project. Regular assessment should indicate a downward movement in the calculated risk factor as the project progresses towards its conclusion. Any consistent upward movement should be investigated and reported to the Project Board Executive. 114
  • 115. Ken Bradley’s Understanding PRINCE 2 (b) (e) (f) (e) x 2.00 (e) x 2.60 2 x 4 = 8 8 10.4 (higher than 8 = LOW RISK) 2 x 5 = 10 10 13.0 (higher than 10 = LOW RISK) 2 x 6 = 12 12 15.6 (higher than 12 = LOW RISK) 2 x 7 = 14 14 18.2 (higher than 14 = LOW RISK) 3 x 4 = 12 8 10.4 (lower than 12 = HIGH RISK) 3 x 5 = 15 10 13.0 (lower than 15 = HIGH RISK) 3 x 6 = 18 12 15.6 (lower than 18 = HIGH RISK) 3 x 7 = 21 14 18.2 (lower than 21 - HIGH RISK) TOTALS: 44 110 88 114 Figure 57: Summary of the Impact of the Risk Scores & Weightings In the example, if the assessed total score (column (f)) of 110 is less than 88 (having had the 2.00 “norm” Risk Factor applied), the overall assessment of risk is LOW. If the assessed total score (column (f)) of 110 is greater than 114 (having had the threshold 2.60 Risk Factor applied), the overall assessment of risk is VERY HIGH. Updating the Risk Analysis Where a formal risk assessment is carried out, the project will be re-appraised, minimally, at each review of the project (in “Managing Stage Boundaries (SB)” Process) and a log of the overall score maintained. The Risk Analysis should also be up-dated and logged at regular intervals (possibly weekly) for the first 4 to 6 weeks of the project following approval of the PID, especially where the initial risk factor is in excess of 2.20. 115
  • 116. Ken Bradley’s Understanding PRINCE 2 Risk Factor Score Very High Risk 2.60 = 114 2.50 = 110 2.40 = 105 High Risk At Project 2.30 = 101 Initiation 2.20 = 97 At End of 2.10 = 92.4 Stage 1 Moderate Risk 2.00 = 88 At End of Stage 2 Low Risk Continuous Risk Assessment by the Project Manager Figure 58: Reducing Level Of Risk As The Project Progresses Modifying The Risk Analysis Checklist The best results will be achieved where the Risk Analysis Checklist is modified to reflect the business, culture and types of project which predominate within the implementing organisation. It will be noted that the Risk Analysis Checklist is particularly relevant to the initiation of projects and contains comparatively little assessment of the on-going control and management of the project. It may well be that amendments to the standard checklist would benefit from focusing on the control aspects. 116
  • 117. Ken Bradley’s Understanding PRINCE 2 STANDARD RISK ANALYSIS CHECKLIST The Risk Factors which affect the probability that the project will be completed on time and within the agreed time and budget, and will deliver a quality-compliant End Product arise from six sources - Project Management, The Project Staff, The Nature of the Project, The Maturity of the Development/Supplier Organisation (Internal and External Suppliers), The Customer and the Contract, and Third Party Suppliers. The project risks associated with each of these Elements are itemised and estimated below in the form of statements typifying Low and High Risk on either side of a scale of 0.10 to 4.00. The “norm” range used is 1.00 to 3.00 and values outside this norm have only been used exceptionally and an explanation is provided. The assessed risk score under column (b) has been multiplied by the weighting factor inserted under column (e) to provide a total risk score (rounded) for each question posed. Individual risks scoring in excess of 15 have been extracted to a Risk Log recording the identified risks & proposed actions. A Risk Factor for the project has been calculated and this will provide a Baseline for measurement of movements in the project risk. A Risk Factor of 2.00 is the neutral measurement, greater than 2.0 indicates an increasing project risk; lower indicates a reducing project risk. (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight Project 1 Full time, experienced 3.00 Part time, inexperienced 5 to 7 7 21 Managem Project Manager Project Manager ent 2 Customer Management 3.00 Inexperienced Customer 4 to 6 5 15 experienced and likely Management - little to be active participation expected Project 3 Customer staff likely to 2.30 Little Customer staff 3 to 6 3 7 Staff be supportive and fully involvement expected and involved in the project little contribution 4 High standard of 1.50 Wide span of supervision 4 to 6 4 6 supervision & narrow and control expected to be span of control in the poor project team 5 Good quality project 1.50 Inexperienced project team 6 to 8 6 9 team, experienced with lacking the key skills the right skills 6 Staff assigned full time 3.00 Staff have many other 3 to 6 5 15 to the project responsibilities 7 Low turnover of project 2.00 High turnover of project 4 to 7 7 14 staff staff 8 Staff experienced at 1.8 No experience of Quality 4 to 6 6 11 Quality Reviews Reviews among staff 9 An organisational 2.20 Staff take little interest in 4 to 6 6 13 commitment to quality achieving a Quality exists Culture 117
  • 118. Ken Bradley’s Understanding PRINCE 2 (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight Nature of 10 Typical project with a 2.20 A project lifecycle that has 4 to 6 5 11 the straightforward a number of inter technical Project lifecycle relationships 11 The project has no, or 2.30 Pioneering new 6 to 8 5 12 few novel features approaches are being tried out in the project 12 Equipment being 2.10 Equipment is untried and 4 to 6 5 10 installed by the project its use in uncertain is well known, tried and tested 13 Current main 3.00 Significant impact on 3 to 5 5 15 operations will be only current main operations by minimally affected by the project the project 14 The Requirements are, 2.00 Requirements are 3 to 6 5 10 or will be, well (expected to be) poorly established and well understood, documented documented by the and presented by the Customer Customer 15 Little or no 2.60 Extensive modification 3 to 6 5 13 modification needed to needed to existing existing technical technical standards will be standards needed 16 Little project work is 2.80 Other project work is 3 to 6 5 14 being undertaken being carried out in currently parallel with this project 17 There is little 2.80 There is a dependence on 3 to 7 6 17 dependence on development facilities development facilities which are outside the not under the control of control of the project team the project team 18 Project duration is less 2.60 Project duration is longer 2 to 5 4 10 than 6 months or there than 6 months or there is a is only a small number high number of workdays of workdays required 19 There is little or no 3.00 There is a mandatory 4 to 7 6 18 constraint on the completion date stated by completion date the Customer 20 Plans and estimates are 3.00 Plans and estimates are 4 to 7 6 18 (will be) based on (will be) based on reliable data from unreliable data - similar projects essentially “green field” 21 Estimates have been 2.60 Approximations have been 4 to 7 6 16 prepared using well used based on unreliable tried and documented standards standards 22 This is the first or 2.90 There have been two or 4 to 8 7 20 second attempt at this more attempts to complete project - ie there is no this project - ie it has a history of consistent history of failure failure 118
  • 119. Ken Bradley’s Understanding PRINCE 2 (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight 23 Few Customer 3.00 Many Customer 4 to 6 5 15 Departments will be Departments will be affected by the final affected by the final outcome outcome 24 The project work will 2.80 Many Customer sites will 3 to 6 6 17 affect few Customer be impacted by the project sites work 25 Sites which the project 2.90 Sites are remote and 3 to 6 6 17 team will visit are easily inaccessible accessible 26 There will be only 2.50 There will be significant 3 to 6 4 10 minor impact on the impact on the Customer’s Customer’s day to day day to day work during the work during the project project cycle 27 Well developed and 1.50 Few Project Management 4 to 7 5 7 understood Project Standards will be available Management Standards to the project team will be available to the project team Maturity 28 There is a well 1.80 Quality Management is ill 4 to 7 5 9 of the developed and defined and/or not visible Organisa understood Quality tion Environment - ie an audited Quality Management System 29 Clear delegation of 2.00 There is strict central 3 to 6 5 10 authority is practised by management control with management little empowerment or delegation 30 Project Staff will wish 2.00 Project Staff are not 3 to 6 5 10 to make use of the expected to utilise any published Project Project Management Management Standards Standards that exist The 31 The Customer 1.90 The Customer 4 to 7 6 11 Customer demonstrates a full demonstrates a poor and the understanding of the understanding of the Contract Requirement and its impact of the Requirement impact 32 There will be little or no 2.20 Extensive modification to 3 to 6 5 11 modification needed to the Customer’s existing the Customer’s existing facilities is expected facilities 33 An agreed contract is in 3.00 No formal contract is yet in 4 to 7 6 18 existence place 34 There have been 1.80 There have been 3 to 7 6 11 previous dealings with difficulties when dealing the Customer and with this Customer on previous contracts have earlier contracts been brought to a satisfactory conclusion 119
  • 120. Ken Bradley’s Understanding PRINCE 2 (a) (b) (c) (d) (e) (f) Element Ref Low Risk Score High Risk Suggested Weight Total Weight Third 35 Suppliers are known, 2.00 The Suppliers are new and 4 to 8 6 12 Party approved and have a little is known about their Supplier satisfactory track capabilities record 36 Only one, well 2.00 Multiple Suppliers (with 3 to 6 6 12 established, approved Sub-Contractor elements) Supplier will be used to are anticipated provide the services 37 Suppliers have an 2.00 Supplier project 3 to 6 6 12 established Structured management arrangements Project Management are ad-hoc with little Method based on visible definition PRINCE or similar 38 A Supplier contract is in 1.50 Informal arrangements 4 to 7 6 9 existence only exist 39 The main Supplier has a 1.50 The main Supplier has no 4 to 7 6 9 fully audited Quality published Quality Management System to Management System ISO9001 40 The future level of 1.80 The future level of Supplier 3 to 6 6 11 Supplier performance is performance is un- expected to be excellent assessable because too little is known TOTALS 214 494 SUMMARY The project is assessed as LOW RISK if 494 (Column (f) Total) is LESS than 428 (Column (e) x 2.00) The project is assessed as VERY HIGH RISK if 494 (Column (f) is MORE than 556 (Column (e) x 2.60) The RISK FACTOR for the project is 2.31 (Column (f) total divided by Column (e) total) The Project is assessed as HIGH RISK at this time. nb: A Risk Factor of less than 2.00 indicates a LOW RISK project. A Risk Factor between 2.00 to 2.20 indicates a MODERATE RISK project. A Risk Factor between 2.20 to 2.60 indicates a HIGH RISK project. A Risk Factor in excess of 2.60 indicates a VERY HIGH RISK project. 120
  • 121. Ken Bradley’s Understanding PRINCE 2 Chapter 8 UNDERSTANDING THE QUALITY MANAGEMENT COMPONENT 121
  • 123. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 & BS/EN/ISO9001 PRINCE 2 has been designed to comply with the BS/EN/ISO9001 Quality Management Standard and the method contains a section relating its content to each section of the ISO Standard. BS6079, the Project management Standard, is also reflected within PRINCE 2. ISO9001, BS6079 and PRINCE 2 are all Process-driven; the foundation for quality and effective, modern project management is therefore integral and inherent in PRINCE 2. The Method assumes that a PRINCE 2 managed project will be carried out within a published quality environment with defined standards and procedures. The PRINCE 2 Manual contains a fairly detailed review of all parts of ISO9001 and states the extent to which each of the parts of the full ISO standard is met by PRINCE 2. Quality Management Quality Assurance Set up & Audit of Quality Management System Quality Management System Quality Policy Statement Quality Manual Organisation Structure Processes Procedures Quality Planning Quality Control * Objectives & Requirements * Measurement Against * Overall Approach Quality Criteria * Project Quality Plan * Measuring Against * Stage Quality Activities Requirements Figure 59 : The Quality Structure The prime aim of Quality Management within a project environment is to ensure that the quality expected by the customer is delivered within the project and extends beyond delivery of the outcome. 123
  • 124. Ken Bradley’s Understanding PRINCE 2 Figure 53 summarises the main components of a quality structure. The PRINCE 2 Method provides specific guidelines for Quality Planning and Quality Control, with the process “Planning For Quality (IP1)” taking place very early in the life of the project and planning for quality within each Product or Deliverable being a major part of “Planning A Stage (SB1)” as the project proceeds. Specific Product quality planning occurs with the creation of a Product Description for each project-level and Management Stage-level Product. The vehicle for this is the Product Description which states the Quality Criteria, type of quality check and the people who need to be involved. Quality Control is effected in the most sensible way for the Product under scrutiny and the organisation. PRINCE 2 includes the technique of Quality Review to provide the means of assessing a Product against its stated Quality Criteria but leaves selection of the most appropriate means to control quality to the Project Manager and Project Board. Of course, this puts much emphasis on getting the Product Description right in the first place, especially the Quality Criteria which will form the basis of acceptance, or not. Customer Quality Expectations These must be reflected in the PRINCE 2 project environment.Ideally they will be stated within the Project Mandate, but will, in any event, be included in the Project Brief (“Starting Up A Project (SU)” Process) and expanded, if necessary, in the Project Initiation Document (“Initiating A Project (IP)” Process). The results of the quality planning activity must be integrated into the timescale and resource plans at each level. Just as quality must be built into the Products, so must quality control be built into the plans. Within PRINCE 2, Planning for Quality within the project takes place predominantly in the “Initiating A Project (IP1)” Process where the Quality Management Systems of both the Customer and the Supplier are used to prepare a foundation of quality for the project. This does not, of course, mean that quality matters are taken into account only during this Process; quality is a component which takes prominence throughout the life of the project and fits closely with the Quality Review Technique discussed later in this publication. Quality Aspects For Suppliers & Sub-Contractors PRINCE 2 assumes a Customer:Supplier relationship where the total project outcome may be undertaken, under contract, by an external supplier; in most projects, there will be the need to buy in components or services from external sources. In these situations, control over quality takes on further importance as the procedures and staff used to carry out the quality control function is outside the direct control of the Project Manager. The approach used within the Method is to provide the “supplier” (internal or external) with a clear statement of what is wanted, the quality standard that must be adhered to and the reporting requirements, in the form of an authorised Work Package. 124
  • 125. Ken Bradley’s Understanding PRINCE 2 The authorised Work Package may take the form of a formal contract or, where the supplier of the Product or service is internal, a memorandum. The typical content for an Work Package is: ♦ Date ♦ Team or Individual or organisation authorised to carry out the work ♦ Description of the Work Package (Product Description) ♦ Extract from the Management Stage Plan ♦ Statement of joint agreement on effort, costs, start date and end date ♦ Any specific techniques, processes or procedures that are to be employed ♦ Any interfaces that must be addressed before, during and at the conclusion of the work ♦ Any constraints to be observed ♦ Reporting Arrangements - timing, content, responsibilities ♦ Quality Checking arrangements A copy of the relevant Product Description(s) will always accompany the authorised Work Package; this will contain the specific Quality Criteria and checking arrangements that must be observed. Work Packages are authorised by the Project Manager in the “Controlling A Stage (CS1)” Process and passed to the supplier in the “Managing Product Delivery (MP1)” Process for discussion where necessary and agreement before work commences. Completed Work Packages (Products/Deliverables) are delivered back into the commissioning organisation on completion of the work. Completed Work Packages should always be complete and Quality Reviewed in accordance with the agreed Work Package. Where there are difficulties with the quality of supplier’s products, it will be necessary to set up additional quality review/control arrangements within the customer’s organisation. In such cases a smoothly working Configuration Management system is essential in order to track down “offending” suppliers and take remedial action. Quality Management - Summary Action must be taken at project planning time (within the “Initiating A Project (IP1)” Process) to ensure that the project can deliver its Products to the quality standards required by the customer. Quality Criteria must be defined and agreed, and incorporated into a Product Description for each major Product identified; a Project Quality Plan must be defined, published and adopted; Quality Review procedures must be established and staff trained; review activities must be properly resourced. Whatever action is proposed to build quality into the project, the measures must be consistent with any published Quality Management System (QMS) that is already in effect. 125
  • 127. Ken Bradley’s Understanding PRINCE 2 Chapter 9 UNDERSTANDING THE CONFIGURATION MANAGEMENT COMPONENT 127
  • 129. Ken Bradley’s Understanding PRINCE 2 Configuration Management - Introduction A configuration is a logically related set of products which need to be managed as a composite set. The “Configuration” to be managed may, therefore, be summarised as the sum total of all the equipment, instructions, information used, and documentation which together represent the total of the Products or Deliverables from the project. Configuration Management Techniques Configuration Management (CM) provides techniques and procedures to perform the following functions: ♦ Identifying the individual items which are to be managed. These are referred to as Configuration Items (CIs). ♦ Recording, monitoring and reporting on the current status of each Configuration Item as its development progresses through its own specific development life-cycle. ♦ Filing all development documentation produced during the project life of the CIs. ♦ Distributing and recording holders of copies of all project documentation for all CIs. ♦ Managing Project Issues raised during the project. ♦ Managing change to all CIs, from receipt of a Project Issue Report, through assessment of the impact of proposed changes, release of both the documentation and the Product itself. In PRINCE 2, Configuration Management is not optional. All the above functions are necessary for successful projects. Without CM, managers would have little or no control over the products their projects are producing. All the Products of a PRINCE project, including documentation Products, Management and Quality Products should be con- trolled using a suitable Configuration Management Method (CMM). Depending upon the sophistication of the method used, some or all of the following should be observed; it should be possible to use the following list of criteria during the selection process for a CMM method and/or support tool: ♦ Configuration Items must be able to be created, amended and deleted; ♦ Configuration Items must be capable of being uniquely identified; ♦ the owner of each Configuration Item must be able to be uniquely identified; ♦ the owner of a Configuration Item must be able to be changed, without necessarily changing the Configuration Item itself; 129
  • 130. Ken Bradley’s Understanding PRINCE 2 ♦ baselines must be capable of being established; ♦ configuration audits must be able to be performed; ♦ it should be possible to restore a Product (or related group of Products) to its state as at a previous baseline, either temporarily or permanently; ♦ the placing of a Configuration Item in the system library must be documented; ♦ Impact Analysis must be able to be carried out to help assess the ramifications involved in changing one or more configuration item; ♦ Configuration Items which are of interest to more than one project must be able to be held centrally. In order to aid impact analysis the CMM should also provide a structure defining the relationships between the configuration items, so that no configuration item is changed without triggering a check for possible ramifications in its neighbours. CM Activities The word “configuration” has in the past been associated mainly with equipment and the term “Configuration Management” was originally applied to the control of hardware development and production. Nowadays, however, it is internationally accepted that Configuration Management can be and needs to be applied to all elements of a project. In PRINCE 2, the term Configuration Management refers essentially to the management of project Specialist Products and the associated Documentation. Configuration Management consists of four basic activities which together assist in the management and control of development projects: ♦ Configuration Identification; ♦ Configuration Control; ♦ Status Accounting; ♦ Configuration Audits. Configuration Management is a service function which assists in making both the specialist and managerial activities more effective. Effectiveness of the CM processes increases in proportion to the degree that the discipline is part of the normal day-to-day activities of everyone involved in the project. Configuration Management practices offer support to the specialist activities as well as providing management with the information necessary for controlling Products as they are produced by the project teams. 130
  • 131. Ken Bradley’s Understanding PRINCE 2 Configuration Management oversees all the Products of a project by controlling access to them and by maintaining records of their status. Operation of Configuration Management will benefit from the appointment of a Configuration Manager or Configuration Librarian as custodian of master copies of all project Products. This role can be combined with the Project Support role where appointed. Where no specific appointment has been made, and where a Project Support role has not been confirmed by the Project Board, the Project Manager is responsible for Configuration Management of the project’s Products. 131
  • 133. Ken Bradley’s Understanding PRINCE 2 Chapter 10 UNDERSTANDING THE CHANGE CONTROL COMPONENT AND CHANGE CONTROL TECHNIQUE 133
  • 135. Ken Bradley’s Understanding PRINCE 2 Change Control - Introduction There are three types of changes which can be raised within a project under a PRINCE 2 controlled project; they are used to document desired change to, or some failure in, the project's products; they are: ♦ Project Issue; ♦ Off-Specification; ♦ Request for Change. This chapter is written on the assumption that exceptions will be controlled by a Configuration Manager. If no such role has been allocated, control of exceptions will be the responsibility of the Project Manager or Project Support, where appointed. Project Issue A project Issue is used by anyone to raise issues relating to the project. The subject of a Project Issue is limited only in so far as it must in some way relate to the project, it may: ♦ address a specialist or technical problem, for example: ♦ Perceived errors in the project's products; ♦ Perceived failures of a current representation of the products to meet User Requirements; ♦ An identified inconsistency between one representation of a Configuration Item and any of its earlier representations; ♦ Ideas for improvements in design, functionality, customer interface, documentation, standards etc; ♦ Identification of improved Business Benefits, proposals to reduce the risks; ♦ Or, alternatively, it may be to address a management issue, perhaps related to budgets, plans, schedules or projected staff or skill shortages. Project Issues are often raised during the testing or operation phases of the project, but can be raised by anyone, at any point during the project. Changes to Products after completion and hand-over of the project outcome (ie after project closure) will not be subject to the project's change control procedures, but will be dealt with in accordance with the organi- sation's normal maintenance and enhancement procedure standards. Errors discovered at a Quality Review are only noted on a Project Issue (Report) if the error relates to an item other than that which is being reviewed, or an error which is unlikely to be corrected via the normal Follow Up procedures. 135
  • 136. Ken Bradley’s Understanding PRINCE 2 At the end of the project all Project Issues should be closed (ie signed off, indicating that the issue has been resolved, possibly by transfer to one of the other two change categories, Request For Change or Off-Specification). The Issues Log, which is used to record each Project Issue, allocate a unique reference and provide a summary of the status of all Project Issues raised, should be provided to the Senior User/Customer at each End Stage review for prioritisation of outstanding Project Issues. This might involve the Senior User in “canvassing” the other Project Board members to provide the resources necessary to action outstanding Project Issues. Off Specifications An Off-Specification is used to document any situation where any project outcome fails to meet its specification in some respect. The error(s) it describes are less likely to be corrected and, as a consequence, are more likely to remain in the delivered output of the project. For this reason Off-Specifications are normally filed in the approved Configuration Items File. Off-Specifications are normally raised by the Project Manager, Team Manager, or Project Board after analysis of received Project Issue Reports. The method does, however allow the originator to identify an issue as an Off-Specification at the time it is formally raised. If a number of Off-Specifications remain outstanding at the conclusion of the project, it is in order to bring them forward as the basis for a separate enhancement project after the main project has been formally signed off and accepted into the business environment. Request for Change A Request For Change is a means of recording a proposed modification to the delivered output of the project and is raised by the Project Manager, Team Manager or Project Board as a result of either analysis of a Project Issue or the decision to rectify a deficiency currently recorded in an Off-Specification. As with the Off-Specification, the originator of an issue may identify it as a Request for Change - this will be most appropriate in circumstances where an error has been discovered. Requests For Change are not used to record deficiencies in an otherwise working system. Deficiencies are documented on the Project Issue Report and Off-Specification Report forms. All RFCs will be actioned and cleared prior to project closure. Change Control Forms and Documentation No forms are provided within the PRINCE 2 Method for managing changes; however suitable forms are available from within the IBM PRINCE Environment and the SPOCE Project Management Launch Pad. 136
  • 137. Ken Bradley’s Understanding PRINCE 2 Change Control - Summary More information on the PRINCE 2 change control procedures are contained in the PRINCE 2 Manual. It is advisable, however to check with the Quality Manager, Project Support Office or Project Assurance representative as existing, effective, change-control procedures are often (rightly) maintained after the adoption of the PRINCE 2 standard. At the conclusion of the project all Requests for Change must be cleared. This will normally be through completion of all outstanding work on them but, exceptionally, Requests for Change still not started or incomplete may be transferred to an enhancement project. This device can be used to effect customer and business sign-off of the main project. Some Off-Specifications may be present throughout the whole life of the output of the project. Outstanding Off-Specifications should be considered for an enhancement project, possibly on a year-by-year basis. Originator Raises A * Good Ideas * Errors Project Issue (Request for Change * Departures From Agreed Specification or Off-Specification) * Resource Changes * Specification Changes Sent to Project Support Copy returned Notify Originator to confirm receipt Project Issues Log Logged byProject Support Project Issues Log Up-dated Reviewed by Project Manager * Slippage/Budget Changes, exceeding Tolerance or affecting other projects within the Programme = Decision by Project Board (Exception Report) OR .... *Changes Within Tolerance = Decision by Project Manager and action taken to implement the change. Figure 60: Suggested Change Control Procedure Based On PRINCE 2 Principles A diagram summarising a suitable change control procedure is as follows. Each stage of the process is logged into the Issues Log. On completion of the project all the Project Issues must be resolved - either by rejection or conversion to a Request for Change, or an Off-Specification. However, the originator may identify the particular category of Project Issue at the time it is raised. The summary provides an enhancement of the PRINCE 2 suggested procedure. 137
  • 139. Ken Bradley’s Understanding PRINCE 2 Chapter 11 UNDERSTANDING THE PRINCE 2 PROCESSES 139
  • 141. Ken Bradley’s Understanding PRINCE 2 Introduction To Processes PRINCE 2 focuses on the Processes that are needed to manage a successful outcome for any project. The Processes identified in PRINCE 2 represent the minimum content for a PRINCE-compliant project but this certainly is not intended to encourage slavish following of any or all of them! The key to successful management of a project is to ensure that each of the Processes identified within a PRINCE 2 controlled project are addressed in one form or another; how each Process is actually interpreted as a project management procedure is left to the implementing organisation, or where an organisational-wide implementation has not been made, the Project Board and Project Manager. Of course, the concept of a process-driven approach is not new; Project Managers have always used the processes of starting, managing and closing their projects, and senior managers have always been involved in the processes of direction and decision making whether they realised it or not! PRINCE 2 formalises these implied processes and sets them into the context of a successful management. The Processes There are eight major Processes in all, identified within the PRINCE 2 methodology; the eighth Process of “Planning (PL)” is used by all the other Processes. The eight major Processes are: ♦ Starting Up A Project (SU) ♦ Initiating A Project (IP) ♦ Directing A Project (DP) ♦ Managing Stage Boundaries (SB) ♦ Controlling A Stage (CS) ♦ Managing Product Delivery (MP) ♦ Closing A Project CP) ♦ Planning (PL) The Planning Process is common to all the others, making a major contribution to “Initiating A Project” where the whole project is planned, “Managing Stage Boundaries” where the next Management Stage of the project is planned, and “Managing Product Delivery” where the work of teams and each individual Team Member is planned. In addition to these Processes, “Planning” also makes a contribution to all others 141
  • 142. Ken Bradley’s Understanding PRINCE 2 The PRINCE 2 Process Model The overall structure of the PRINCE 2 Process Model can be summarised as follows: * Project Mandate * Project Start Notification IP * Project End Notification * IP1 - Plan Quality SU * IP2 - Plan Project * SU1 - Appoint Exec & PM * IP3 - Refine Bus Case & Risks * SU2 - Design A Team * IP4 - Set Up Controls * SU3 - Appoint A Team * IP5 - Set Up Files * Authorisation * SU4 - Prepare Brief * IP6 - Assemble PID To Proceed * SU5 - Prepare Approach * SU6 - Prepare Initiation Plan *Draft Project Initiation Document (PID) * Trigger for * Project Brief Next Stage Plan * Info from * Project Approach External * Organisation Sources & * Plan for Initiation Stage Feedback DP * Request for Exception Plan * DP1 - Authorise Initiation * DP2 - Authorise Project * Next Stage SB * DP3 - Authorise Stage or Exception Plan * SB1 - Plan A Stage Plan * DP4 - Give Ad-Hoc Direction * SB2 - Up-date Project Plan * DP5 - Project Close * SB3 - Up-date Business Case * Exception * SB4 - Up-date Risk Log Plan * SB5 - Report Stage End * SB6 - Produce Exception Plan * Direction * Highlight *Requests For Reports Advice * Trigger - Next Stage Plan * Authorisation * Exception * Premature To Proceed Reports Close CS * CS1 - Authorise Work Package * Project Issues * CS2 - Assess Progress * CS3 - Capture Project Issues * CS4 - Examine Project Issues * CS5 - Review Stage Status * CS6 - Report Highlights * Work Package * CS7 - Take Corrective Action + Confirmation of Acceptance * CS8 - Escalate Project Issues * CS9 - Receive Completed Work Package * Customer Acceptance * Checkpoint Reports * End Project Report * Trigger - End Project * Project Evaluation * Lessons Learned MP * Completed Work Package * MP1 - Accept Work Package * Follow-on Items * MP2 - Execute Work Package * Post-Project * MP3 - Deliver Work Package Review Plan CP * CP1 - Decommission A Project * CP2 - ID Follow-on Actions Archive Files * CP3 - Project Evaluation Review * Product Based Planning PL Figure 61: Structure Model of the PRINCE 2 Process Model And Major Product Flows 142
  • 143. Ken Bradley’s Understanding PRINCE 2 Each of the major Processes has associated Processes which drive the management of the project through the use of Components and Techniques, The Processes do not link with any required way of achieving the required outcome; this enables the use of any techniques which are appropriate to the business and reflects the flexibility which comes as part of the PRINCE 2 package. Major Processes and Processes Each of the eight major Processes has a number of Processes which are used to get the job done. A table relating each Process to its parent, major Process is useful to illustrate where each Process resides within the overall Process Model and a summary of each major Process and its “children” is particularly helpful to anyone intending to take the APM Group PRINCE 2 Examinations. The main objectives of each of the eight major Processes are summarised as follows: ♦ Starting Up A Project – Gathering the basic information needed to start the project. ♦ Initiating A Project – Ensuring that the key decision makers understand what is involved and obtaining agreement and commitment to a formal baseline for the project. ♦ Directing A Project – Decision making on behalf of the project by senior managers (in PRINCE terms – “The Project Board”). ♦ Controlling A Stage – Day-to-day project management and controlling the project by the Project Manager, on behalf of the Project Board. ♦ Managing Product Delivery – Creating, modifying and obtaining the Products or Deliverables. ♦ Managing Stage Boundaries – Taking stock of the current situation and getting ready for the next part (Management Stage) of the project. ♦ Closing A Project – Ensuring the project has properly completed prior to formal closure of the project by senior management. ♦ Planning – Planning steps that are common to all the Processes except “Controlling A Stage” and “Directing A Project”. Plans are, however, used by all the Processes. These Processes link to the Components and Techniques included in the PRINCE 2 Method to provide a comprehensive “best practice” Project Management Method. 143
  • 144. Ken Bradley’s Understanding PRINCE 2 A summary chart of Processes and Sub-Processes is shown below: Parent Process Sub- Sub-Process Name Process Starting Up A Project SU1 Appointing A Project Board Executive & Project Manager (SU) SU2 Designing A Project Management Team SU3 Appointing A Project Management Team SU4 Preparing A Project Brief SU5 Defining Project Approach SU6 Planning An Initiation Stage Initiating A project IP1 Planning Quality (IP) IP2 Planning A Project IP3 Refining The Business Case and Risks IP4 Setting Up Project Controls IP5 Setting Up Project Files IP6 Assembling A Project Initiation Document Directing A Project DP1 Authorising Initiation (DP) DP2 Authorising A Project DP3 Authorising A Stage Or Exception Plan DP4 Giving Ad-Hoc Direction DP5 Confirming Project Closure Controlling A Stage CS1 Authorising A Work Package (CS) CS2 Assessing Progress CS3 Capturing Project Issues CS4 Examining Project Issues CS5 Reviewing Stage Status CS6 Reporting Highlights CS7 Taking Corrective Action CS8 Escalating Project Issues CS9 Receiving A Completed Work Package Managing Product MP1 Accepting A Work Package Delivery MP2 Executing A Work Package (MP) MP3 Delivering A Work Package Managing Stage SB1 Planning A Stage Boundaries SB2 Updating A Project Plan (SB) SB3 Updating A Project Business Case SB4 Updating The Risk Log SB5 Reporting Stage End SB6 Producing An Exception Plan Closing A Project CP1 Decommissioning A Project (CP) CP2 Identifying Follow-on Actions CP3 Project Evaluation Review 144
  • 145. Ken Bradley’s Understanding PRINCE 2 Planning PL1 Designing A Plan (PL) PL2 Identifying, Defining And Analysing Products PL3 Identifying Activities And Dependencies PL4 Estimating PL5 Scheduling PL6 Analysing Risks PL7 Completing A Plan Structure of the Individual Process Models Each of the major Processes and Processes is described by reference to a common formula: The Fundamental Principles ♦ The reason(s) for the Process; ♦ The project management aims for the Process; ♦ Why the Process is fundamental to good project management practice and, therefore, a requirement in any PRINCE 2-compliant project. This section is a good first-step to understanding the rationale for the Process and what it is trying to achieve. Context ♦ The relationship with the other Processes and external activities. A Context Diagram is provided for each Process showing the flows of information into and out of the Process. This section is particularly useful to provide a visual statement of the inputs, processes and outputs as a quick guide. Process Description ♦ An explanation of the objectives of the Process and a statement of the steps contained within it. The steps identified are in no particular order and are not intended to be comprehensive. This section contains the “meat” of the Process and provides a fair commentary on what the Process sets out to achieve, together with the means of achieving it. There is little attempt to describe how the Process is expected to work in practice, as the PRINCE 2 Method addresses mainly “What” and “Why” with a much restricted “How” confined mainly to the “Techniques” Section. 145
  • 146. Ken Bradley’s Understanding PRINCE 2 Responsibilities ♦ Identification of who should be held accountable for the successful conduct of the Process, and responsible for its management. Generic responsibilities (Project Board, Project Manager etc) only are provided and implementing organisations need to look very carefully at assignment of key project activities to specified personnel. Information Needs ♦ The key information needed for the Process to function in such a way to meet its objectives. The information needs identified might take the form of Products/Deliverables, Plans, Reports, Decisions etc. This section is particularly useful in understanding the flows of information into and out of the Process. Read in conjunction with the Context Diagram, a good understanding of the complete Input/Process/Output cycle can be obtained. Key Criteria ♦ Identification of significant issues which will impact upon and affect the successful working of the Process. These criteria are generally straightforward and pose little difficulty in their understanding and implementation. They are important in that they represent the minimum standard for any PRINCE 2-compliant project. In essence, any PRINCE 2-compliant project will address all eight Processes in one form or another and each of the Processes will meet the Key Criteria stated here. Hints and Tips ♦ Guidance on the application of the Process within a PRINCE environment; the method recommends that this section be augmented by reference to specific situations encountered during the use of PRINCE on projects within the implementing organisation. The Hints and Tips contained throughout the PRINCE 2 Manual should not be viewed as an integral part of the Method but rather as helpful guidelines. Much of the PRINCE 2 Manual is given to describing the Processes using the above headings. Understanding the structure of the Processes and their objectives is fundamental to the successful use of the method. PRINCE may be likened to an organic structure which must be allowed to mature and adapt to fit changing circumstances and new knowledge within the host organisation; up-dating the Process Models and descriptions, especially with regard to the Hints and Tips section is recommended to achieve this. 146
  • 147. Ken Bradley’s Understanding PRINCE 2 Scalability ♦ All PRINCE controlled projects will address all eight major Processes in some form and the key question to be posed is “How extensively should this Process be applied on this project?”. Each of the eight major Processes includes a section on “Scalability” which provides suggested approaches to scaling the major Process to reflect the size and scope of the particular project. A “Scalability” section is not included within each Process definition but the principles established in the major Process may be used to provide a suitable solution. Individual Process Summary Models On the pages that follow are summaries of the inputs and outputs for each of the Processes within the PRINCE 2 Method. The summaries also indicate the action performed on a Product within the Process. The notation is as follows: Product Created = [C] Product Updated = [U] Product Referenced and/or Reviewed = [R] The Major Process Models shown at the beginning of each section are reproduced from the PRINCE 2 Manual, with minor amendments and corrections made. 147
  • 149. Ken Bradley’s Understanding PRINCE 2 Chapter 12 UNDERSTANDING THE STARTING UP A PROJECT (SU) PROCESS 149
  • 151. Ken Bradley’s Understanding PRINCE 2 Starting Up A Project (SU) - Introduction This is the first Process within a PRINCE 2 managed project. A Project Mandate in the form of a memo, formal or informal request will normally trigger this Process, although there is no prescribed format. Designing a Appointing a Appointing a Project Project PB Executive Project Management Management Mandate and PM Team Team SU1 SU2 SU3 Defining Preparing a Planning an Project Project Brief Initiation Stage Approach SU4 SU5 SU6 Draft Initiation Stage Plan Project Project Project Management Team Brief Approach structure and job descriptions Project Brief Planning Assembling Authorising Quality a PID Initiation IP1 IP6 DP1 Figure 62: Starting Up A Project (SU) Process The “Starting Up a Project (SU)” Process provides a solution to the “ragged beginning” concept that bedevils many projects. Just how a project gets under way is a question often posed by managers who find that they are asked to carry out planning and preparatory work by Customers but are warned against committing any resources without authority! Quite a dilemma which PRINCE 2 seeks to bridge by the use of this Process. The Process seeks to set up the project by creating clear objectives, set up a suitable Project Management Team, identify a realistic approach to the work to be done, and planning for the next stage of the work (normally the Initiation Stage). The project formally exists at the conclusion of this Process when the Project Board will be asked to give a “go/no-go” decision on whether there is the rationale, will and business need for the proposed project. This decision will normally take place at a “Project Initiation Meeting (PIM) which marks the formal start to the project. 151
  • 152. Ken Bradley’s Understanding PRINCE 2 SU1 - Appointment of a Project Board Executive and a Project Manager To get any undertaking under way, there is a need for a decision-maker (the Project Board Executive) and a planner (the Project Manager). As soon as the project is “floated” by the receipt of a Project Mandate, these two appointments must be made by Corporate Management. Between them they will arrange to set up the proposed project in an orderly and structured way by creating suitable decision-support documentation comprising The Project Brief, The Project Management Team, The Project Approach, and the Plan for the Initiation Stage. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU1 – Project Mandate Project Board Executive Designing A Project Appointing (Corporate Appointment [C] Management Team A Project Management) (SU2) Board Executive & Project Manager Project Manager Appointment [C] Designing A Project Management Team (SU2) Figure 63: SU1 Plus Inputs and Outputs The appointment of the Project Board Executive and the Project Manager will allow a number of Products to be started. Although the PRINCE 2 Manual indicates an order of precedence - design and appointment of the Project Management Team as the next step - there is no reason why the Project Manager should not immediately commence work on the Project Approach and the Project Brief. These two documents will have a major influence on the design of the Project Management Team and identification of the most appropriate individuals to make the project management actually work. In practice, the Executive needs to have a close involvement with the production of the Project Approach and the Project Brief, as these are the two prime documents which will provide the decision support information for the Project Board Members when they are asked to approve the Initiation Stage of the project. 152
  • 153. Ken Bradley’s Understanding PRINCE 2 SU2 & SU3 - The Project Management Team The Project Management Team is the group of people who are responsible for the planning, management , and control of the project. It might not always be possible to appoint the whole team at this early stage but as many of the key appointments as possible should be made. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU2 – Project Mandate Project Management Team Appointing A Project Designing A (Corporate Structure [C] Management Team Project Management) (SU3) Management Team Executive & Project Manager Appointment (SU1) SU3 – Project Job Definitions [C] Assembling A PID (SU6) Appointing A Management Team Project Structure (SU2) Authorising Initiation Management (DP1) Team Project Management Team Assembling A PID (SU6) Structure [C] Authorising Initiation (DP1) Figure 64: SU2 & SU3 Plus Inputs and Outputs Part of the work in this Process will include the definition of Roles and Responsibilities for each member of the Project Management Team. A start point for these is included at Appendix C of the PRINCE 2 Manual. It is important to ensure that each member of the Project Management Team clearly understands the expectations that go with the job, and the Role Descriptions ensure that this is clearly communicated. Role Descriptions will apply to all members of the Project Management Team including the senior managers who are on the Project Board for the project. Responsibility for establishing the Project Management Team rests jointly with the Executive and Project Manager, the Executive taking the lead in identifying and appointing the Project Board Members. When the Project Management Team has been established it will accompany the other outputs of SU to be endorsed by the newly established Project Board during consideration of the Initiation Stage Plan in DP1. The source documentation will be used to assemble the Project Initiation Document in IP6 153
  • 154. Ken Bradley’s Understanding PRINCE 2 SU4 - The Project Brief and Its Relationship To The Project Mandate The Project Brief will normally contain the formal Terms of Reference (objectives, scope, constraints, interfaces etc) for the Project together with an Outline Business Case, based on the information contained in the Project Mandate PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU4 – Project Mandate Project Brief [C] Defining Project Preparing A (Corporate Approach (SU5 Project Management) Brief Planning An Initiation Stage (SU6) Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks) Assembling A PID (IP6) Authorising Initiation (DP1) Risk Log [C] Planning An Initiation Stage (SU6) Planning A Project IP2 Refining The Business Case & Risks (IP3) Figure 65: SU4 Plus Inputs and Outputs The Project Brief is based on the Project Mandate which provides the “trigger” for the project. The Project Mandate may take any form from an informal request by a senior manager to a formal request to provide a proposal from a customer to a potential supplier. The Project Mandate may therefore be quite thin on information in which case the Project Brief will take a fair amount of effort to complete. On the other hand, where the Project Mandate is a comprehensive document emanating from, say, a feasibility or scoping study, there should be little to add to turn it into a suitable Project Brief. The Project Brief is used primarily in “DP1 - Authorising Initiation”, by the Project Board, to decide whether the proposed project merits the time and effort needed to produce 154
  • 155. Ken Bradley’s Understanding PRINCE 2 a Project Initiation Document. It needs to address the fundamental reasons and constraints that support the proposal for the project - it is essentially a “first-cut” Project Initiation Document. The Customer’s Acceptance Criteria are contained within the Project Brief and although the Product Outline for the Project Initiation Document , included in the PRINCE 2 Manual , does not specifically mention the Acceptance Criteria within the “Composition” section, it makes sense to incorporate Acceptance Criteria within the PID as these can then be used for comparative purposes at each Management Stage review (End Stage Assessment), at Project Closure (“Decommissioning A Project (CP1)”) where Customer Acceptance is obtained, and in “Confirming Project Closure (DP5)” where the project is formally shut down. 155
  • 156. Ken Bradley’s Understanding PRINCE 2 SU5 - The Project Approach: A suitable Approach to the project must be considered, discussed with the Project Board Executive Member and agreed before seeking authority to prepare a Project Initiation Document (acceptance of which by the full Project Board will signal the formal start of the project). Examples of the Approach to the project are: ♦ In-house development/construction; ♦ Out-sourcing to one or more Suppliers; ♦ Joint venture development as a partnership; ♦ Prime Contractor sourcing with multiple sub-contractors; PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU5 – Project Brief (SU4) Project Approach [C] Planning An Initiation Defining Stage (SU6) Project Risk Log (SU4) Approach Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks (IP3) Assembling A PID (IP6) Authorising Initiation (DP1) Planning (PL) Figure 66: SU5 Plus Inputs and Outputs After formal endorsement by the Project Board, the Project Approach is included in the Project Brief (and possibly also the Project Initiation Document). It provides a major contribution to planning the project - Initiating A Project (IP2). 156
  • 157. Ken Bradley’s Understanding PRINCE 2 SU6 - The Initiation Stage Plan A suitable plan for the Initiation Stage must be produced to enable the Project Board to authorise the creation of a suitable Project Initiation Document (PID) to authorise the commencement of the project. Production of the PID might well consume considerable time, effort and cost and is a key document that will be used to Baseline the project. It therefore needs to be properly planned, resourced and authorised at a level appropriate to the investment being proposed. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU6 – Project Brief (SU4) Draft Initiation Stage Plan [C] Authorising Initiation Planning An (DP1) Initiation Risk Log (SU4) Stage Project Approach Risk Log [U] Authorising Initiation (SU5) (DP1) Figure 67: SU6 Plus Inputs and Outputs The Method presumes that the “Starting Up A Project (SU)” Process will be a separate “front-end” to the project and approval of the Initiation Stage Plan will provide authorisation for the first Management Stage of the project. However, for smaller, low risk, projects, the first stage might well embrace the “Starting Up A Project (SU)” and “Initiating A Project (IP)” Processes. Indeed other Processes might also come into play during the first Stage of the project - these include “Controlling A Stage (CS)”, “Managing Product Delivery (MP)”, “Managing Stage Boundaries (SB)”. Because of the involvement in the authorisation processes, the Project Board will also be in play within the “Directing A Project (DP)” Process. The “Planning (PL)” Process, the “Planning A Stage (SB1)” Process, and the Product Based Planning Technique, are all used in Planning An Initiation Stage. The planning aspects are straightforward as there is a need only to plan for a short time-scale and for a very simple series of Products and related Activities. 157
  • 158. Ken Bradley’s Understanding PRINCE 2 Starting Up A Project - Summary This Process, with the next (“Initiating A Project (IP)”) is critical to the success of any PRINCE 2 project as it sets the scene, expands the often flimsy Project Mandate, and lays down the foundation for the organisational structure for the project. It will often be combined with the IP Process and others, especially where a smaller project is being addressed. If “Starting Up A Project (SU)” serves to put a brake on the understandable enthusiasm to commence development work before the basics of the project have been thought through, then it will have served its purpose. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SU1 – Project Mandate Project Board Executive Designing A Project Appointing A (Corporate Appointment [C] Management Team Project Management) (SU2) Board Executive & Project Manager Project Manager Appointment [C] Designing A Project Management Team (SU2) SU2 – Project Mandate Project Management Team Appointing A Project Designing A (Corporate Structure [C] Management Team Project Management) (SU3) Management Team Executive & Project Manager Appointment (SU1) SU3 – Project Job Definitions [C] Assembling A PID (SU6) Appointing A Management Team Project Structure (SU2) Authorising Initiation Management (DP1) Team Project Management Team Assembling A PID (SU6) Structure [C] Authorising Initiation (DP1) 158
  • 159. Ken Bradley’s Understanding PRINCE 2 SU4 – Project Mandate Project Brief [C] Defining Project Preparing A (Corporate Approach (SU5 Project Brief Management) Planning An Initiation Stage (SU6) Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks) Assembling A PID (IP6) Authorising Initiation (DP1) Risk Log [C] Planning An Initiation Stage (SU6) Planning A Project IP2 Refining The Business Case & Risks (IP3) SU5 – Project Brief (SU4) Project Approach [C] Planning An Initiation Defining Stage (SU6) Project Risk Log (SU4) Approach Planning Quality (IP1) Planning A Project (IP2) Refining The Business Case & Risks (IP3) Assembling A PID (IP6) Authorising Initiation (DP1) Planning (PL) SU6 – Project Brief (SU4) Draft Initiation Stage Plan [C] Authorising Initiation Planning An (DP1) Initiation Risk Log (SU4) Stage Project Approach Risk Log [U] Authorising Initiation (SU5) (DP1) Figure 68: Summary of the “Starting Up A Project (SU) Process 159
  • 161. Ken Bradley’s Understanding PRINCE 2 Chapter 13 UNDERSTANDING THE INITIATING A PROJECT (IP) PROCESS 161
  • 163. Ken Bradley’s Understanding PRINCE 2 Initiating A Project (IP) - Introduction The “Initiating A Project (IP)” Process is aimed at ensuring that a firm Baseline exists for the project and that everyone involved understands what the project is seeking to achieve. In smaller projects, this Process might well be combined with the “Starting Up A Project (SU)” process but this should be considered carefully. A controlled break between “Starting Up A Project” and “Initiating A Project” is always required event though both Processes may be combined within the same Management Stage. Corporate QMS Authorising Initiation DP1 Authorised Stage Initiation Plan Refining the Planning Planning a Business Quality Project Case and Risks IP1 IP2 IP3 Setting up Setting up Assembling a Project Project Files PID Controls Project IP4 IP5 IP6 Brief Draft PID Authorising a Project DP2 Figure 69: Initiating A Project (IP) Process The Project Initiation Document The major output for this Process is a Project Initiation Document (PID), which will be used throughout the project to ensure that the work carried out and the Products/Deliverables being produced are supporting the key objectives and meet the customer’s needs. The PID will always need to address the following: ♦ to identify the benefits and risks and to evaluate proposals for managing identified areas of risk, thus confirming that an acceptable Business Case exists for the project; 163
  • 164. Ken Bradley’s Understanding PRINCE 2 ♦ to provide a foundation for the project from which the Project Initiation Document can be assembled or prepared. ♦ to provide decision support information to enable the Project Board to confirm the initial (and ongoing) viability for the project; ♦ to encourage the Project Board to understand and take ownership of the project; ♦ to provide sufficient information for the Project Board to approve the whole project in principle and to commit resources, formally, for the next Management Stage; ♦ to provide a Baseline for all decision-making for the duration of the project; ♦ to initiate the project in an orderly manner, thus setting “Norms” for the remainder of the project; ♦ to monitor the progress of the project initiation process against the approved plans. An Initiation Stage is recommended to be included in any PRINCE 2 managed project; given that the minimum number of Management Stages within any PRINCE 2 project will be two, this principle ensures that there will always be at least one “planning” Stage and one “action” Stage. The PID is used as a Baseline for the project. It is assembled from Products generated in the “Starting Up A Project (SU)” Process and the “Initiating A Project (IP)” Process and when approved by the Project Board it signifies the official start of the project. The approved PID will be input to every formal review of the Project (ESAs and MSAs) to check progress against the agreed baseline. It is also used at Project Closure (“Decommissioning A Project (CP1)”) to measure the project outcome against the Acceptance Criteria; successful matching will generate a Customer Acceptance of the outcome. 164
  • 165. Ken Bradley’s Understanding PRINCE 2 IP1 - Planning For Quality Quality plays an important role in any PRINCE 2 project and as such it must be considered before any major planning activity takes place. The Customer’s Quality Expectations will have been identified in the “Starting Up A Project (SU)” at the time the Project Brief was prepared. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP1 – Quality Standards Project Quality Plan [C] Planning A Project (IP2) Planning (Programme and/or Quality Corporate QMS) Setting Up Project Controls (IP4) Project Brief (SU4) Setting Up Project Files Project Approach (IP5) (SU5) Assembling A PID (IP6) Figure 70: IP1 Plus Inputs and Outputs This needs to be built upon and cross-matched with the supplier organisation’s own quality standards, usually resident in the Quality Management System (QMS). A correlation between the International Standards Organisation BS/EN/ISO 9001 standard for quality management and what is offered within the PRINCE 2 Method is provided in Appendix B of the PRINCE 2 Manual. This Appendix should be used to match the supplier organisation’s QMS to the requirements of PRINCE 2 and is especially useful where a QMS is being specified and introduced. Where an organisation-wide QMS is not already in force, management should consider introducing a specific Project QMS - having no quality strategy is not an option! Other aspects that need to be considered are the project staff’s ability to perform effective Quality Reviews and to understand the significance of the Quality Criteria that will be included in the Product Description for each Product/Deliverable. 165
  • 166. Ken Bradley’s Understanding PRINCE 2 IP2 - Planning A Project Although PRINCE 2 includes a separate Process for “Planning (PL)” and includes planning as a Component and a specific Technique (Product-Based Planning), the activities associated with planning for a specific project situation come into operation within the Process concerned with the specific plan required. For example, planning the project is an activity which must be undertaken right at the start of the project and lies naturally within the “Initiating A Project (IP)” Process. Similarly, planning for each Management Stage is a function of “Managing Stage Boundaries (SB)” as the Project Manager prepares for the transition from the Current Stage to the Next Stage and prepares documentation for the Project Board to reach an informed decision. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP2 – Project Brief (SU4) Project Plan [C] Refining The Business Planning A Case & Risks (IP3) Project Risk Log (SU4) Setting Up Project Project Approach Controls (IP4) (SU5) Setting Up Project Files Project Quality Plan (IP5) (IP1) Assembling A PID (IP6) Planning A Stage (SB1) Risk Log [U] Refining The Business Case & Risks (IP3) Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1) Figure 71: IP2 Plus Inputs and Outputs The Project Manager and the rest of the Project Management Team will use the “Planning (PL)” Process and the Product Based Planning Technique to prepare the required plans within the appropriate Processes. The Process requires a demonstration of an understanding of the project in the long term. The Project Manager is not expected to be able to predict accurately to the full term of the project, but must make an intelligent stab at what the future holds and plan for contingencies. 166
  • 167. Ken Bradley’s Understanding PRINCE 2 On their part, the Project Board must take a sensible and realistic view of the project, especially where the duration is extended, and view the project plan as a “soft estimate”. The Management Stage Plan (produced in “Managing Stage Boundaries (SB1)”) provides the firm, but limited, commitment of resources within the framework of the Project Plan. This approach ensures that a realistic planning horizon is always in focus (the Stage Plan) within the context of the overall Project Plan. 167
  • 168. Ken Bradley’s Understanding PRINCE 2 IP3 - Refining The Business Case The Project Brief will have identified an outline Business Case for the project. This preliminary assessment will have been approved in principle by the Project Board when considering the package put forward in support of investing resources into creating a suitable Project Initiation Document to support the authorisation of the project. The outline Business Case needs to be enhanced and refined before a final decision to start the project can be made. The expected Business Benefits will need to be clearly specified and the risks associated with the project identified. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP3 – Project Brief (SU4) Risk Log [U] Setting Up Project Refining Controls (IP4) The Project Approach Business (SU5) Assembling A PID (IP6) Case & Risks Project Plan (IP2) Business Case [C] Assembling A PID (IP6) Risk Log (IP2) Project Plan [U] Assembling A PID (IP6) Figure 72: IP3 Plus Inputs and Outputs Where possible, both elements of Business Benefits and Risk will need to be measured in concert. In the case of the Business Benefits, a Costs:Benefits Analysis/Investment Appraisal should be considered. Risks can be measured in many ways; PRINCE 2 does not recommend any particular approach from the many software-based risk assessment tools that are available but there needs to be a balance between creating an effective Risk Assessment, suitable as the basis for Risk Management, and the time and effort that a comprehensive assessment is bound to consume. A simple Risk Analysis Checklist has been in use in PRINCE projects for many years and an enhanced variant of this has been included at Chapter 7. Use of the Risk Analysis Checklist is straightforward and an advantage is its visibility - it is well worth a try and usually provides acceptably accurate results. The Business Case, when approved by the Project Board will need to be reviewed and up- dated when preparing for each Management Stage Review (see “Managing Stage Boundaries (SB)”). 168
  • 169. Ken Bradley’s Understanding PRINCE 2 IP4 - Setting Up Project Controls Project controls are the key to the successful management of any project. It is only possible to control a project to the level of detail in which it has been planned so the Project (and later, the Stage) plans are critical to the successful management of the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP4 – Project Quality Plan Project Plan [U] Assembling A PID (IP6) Setting Up (IP1) Project Project Controls [C] Assembling A PID (IP6) Controls Project Plan (IP2) Risk Log [U] Assembling A PID (IP6) Risk Log (IP3) Communication Plan [C] Assembling A PID (IP6) Figure 73: IP4 Plus Inputs and Outputs This Process is concerned with the identification of the most appropriate level of control for the project. For large, high-risk projects it may be expected that all the controls listed below will be appropriate. For smaller, low-risk projects it will be necessary to consider both the types of control that are appropriate and their frequency. In principle, however, all the controls listed below will be appropriate to all projects whatever their size. The management controls that will be identified and used in any PRINCE 2 project fall into two main categories: Project Board Controls ♦ Project Initiation Meeting & Project Initiation; ♦ Management Stages - End Stage Assessment; ♦ Exception Reporting & Management - Mid Stage Assessment; ♦ Tolerance – Time & Costs; ♦ Highlight Reporting (from the Project Manager to Project Board Members). ♦ Business Case Re-evaluation (Business Benefits) 169
  • 170. Ken Bradley’s Understanding PRINCE 2 ♦ Risk Analysis (+ Up-date of the Risk Log); ♦ Project Closure. Project Manager/Team Controls: ♦ Checkpoints; ♦ Quality Reviews (Informal); ♦ Quality Reviews (Formal); ♦ Day-to-Day Communication/Ad-hoc Meetings. Controls may also be appropriate at the Programme level but this will depend on the number, size and relationship of the projects that fall within the aegis of the PRINCE 2 arrangements within a particular implementing organisation. 170
  • 171. Ken Bradley’s Understanding PRINCE 2 IP5 - Set Up Project Files All projects will produce documentation which must be stored in an appropriate and secure way. A fair amount of documentation will already have been produced in the “Starting Up A Project (SU)” Process and organisations implementing PRINCE 2 project management systems will wish to consider whether setting up the project filing structure would best be carried out during the SU Process. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP5 – Project Quality Plan Project Filing Structure [C] Assembling A PID (IP6) Setting Up (IP1) Project Issue Log [C] Controlling A Stage (CS) Files Project Plan (IP2) Quality Log [C] Controlling A Stage (CS) Lessons Learned Report [C] Controlling A Stage (CS) Figure 74: IP5 Inputs & Outputs The documentation which will already be in place following “Starting Up A Project (SU)” is: ♦ The Project Management Team Organisation Structure; ♦ Roles and Responsibilities for Project Management Team Members; ♦ The Project Brief; ♦ The Project Approach; ♦ The Risk Log; ♦ The Plan for the Initiation Stage; ♦ The Project Board Sign-off Approving the Initiation Stage Plan; ♦ Records of the Project Board Meeting (if appropriate). 171
  • 172. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 suggests a filing structure but does not require an electronic format, a physical file or both. Perhaps the best approach is to have both electronic and physical file structures sharing a common structure. This will enable Project Managers to maintain copies of documentation in a format which is permanent, structured and flexible. All files and their associated documentation, whatever their format, will need to be archived at the conclusion of the project to allow for appropriate auditing. Files Project File Stage File(s) Specialist File Quality File Organisation Organisation Configuration Items Product Descriptions Plans Plans Configuration Log Quality Checks Business Case Control Documents CI Locations Project Issues Risk Log Daily Log Off-Specifications Control Documents Correspondence Products Checklist Products Checklist Figure 75: PRINCE 2 Suggested Filing Structure 172
  • 173. Ken Bradley’s Understanding PRINCE 2 IP6 - Assembling The Project Initiation Document The key document to be output from the “Initiating A Project (IP)” Process is the Project Initiation Document. (PID) This document provides a comprehensive view of the project as it is viewed from the outset of the project. The PRINCE 2 concept of “assembling” a Project Initiation Document is understandable but not necessarily realistic as there are always many additional elements that, at the point the PID is put together, are not available. To help with this, a Project Initiation Document Template should be prepared for use in all projects within the implementing organisation. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP6 – Project Approach Draft Project Initiation Document Authorising A Project Assembling (SU5) (PID) [C] (DP2) A PID Project Brief (SU4) Project Management Team Structure + Job Definitions (SU3) Project Quality Plan (IP1) Project Plan (IP2) Business Case (IP3) Risk Log (IP3) Project Controls (IP4) Communication Plan (IP4) Project Filing Structure (IP5) Figure 76: IP6 Plus Inputs and Outputs 173
  • 174. Ken Bradley’s Understanding PRINCE 2 Completion of the PID will trigger the need to plan for the next Management Stage of the project. The work for this activity will be carried out in the Process “Managing Stage Boundaries (SB)” within the Sub-Process “Planning A Stage (SB1)”. The PRINCE 2 Method does not recommend that the plan for the next stage be included in the Project Initiation Document, thereby putting the emphasis on this document being concerned with the project itself. Approach to Assembling or Producing The PID Assembly of the PID is a very simple task if all the component parts are available and it can easily be performed by Project Support or the Project Manager. If this is not the case, the use of the PID Template will make the task much simpler and enable the work to be shared. In practice, the best approach has been found to be to hold a “PID Workshop” attended by all members of the Project Management Team (including Project Board members where they can spare the time). Typically one or two days is sufficient, provided some foundation work has been undertaken. Where this approach is taken, the Project Initiation Stage Plan should reflect the time and resources needed. 174
  • 175. Ken Bradley’s Understanding PRINCE 2 Initiating A Project (IP) - Summary Successful initiation of any project is a key contributor to its eventual outcome. The time, effort and resources invested in this stage will be well worthwhile, especially if some unforeseen problem occurs during the project. The Project Board and Project Management Team will have firm ground on which to base decisions about proposed changes in direction and investment of resources. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED IP1 – Quality Standards Project Quality Plan [C] Planning A Project (IP2) Planning (Programme and/or Quality Corporate QMS) Setting Up Project Controls (IP4) Project Brief (SU4) Setting Up Project Files Project Approach (IP5) (SU5) Assembling A PID (IP6) IP2 – Project Brief (SU4) Project Plan [C] Refining The Business Planning A Case & Risks (IP3) Project Risk Log (SU4) Setting Up Project Project Approach Controls (IP4) (SU5) Setting Up Project Files Project Quality Plan (IP5) (IP1) Assembling A PID (IP6) Planning A Stage (SB1) Risk Log [U] Refining The Business Case & Risks (IP3) Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1) IP3 – Project Brief (SU4) Risk Log [U] Setting Up Project Refining Controls (IP4) The Project Approach Business (SU5) Assembling A PID (IP6) Case & Risks Project Plan (IP2) Business Case [C] Assembling A PID (IP6) Risk Log (IP2) Project Plan [U] Assembling A PID (IP6) 175
  • 176. Ken Bradley’s Understanding PRINCE 2 IP4 – Project Quality Plan Project Plan [U] Assembling A PID (IP6) Setting Up (IP1) Project Project Controls [C] Assembling A PID (IP6) Controls Project Plan (IP2) Risk Log [U] Assembling A PID (IP6) Risk Log (IP3) Communication Plan [C] Assembling A PID (IP6) IP5 – Project Quality Plan Project Filing Structure [C] Assembling A PID (IP6) Setting Up (IP1) Project Issue Log [C] Controlling A Stage (CS) Files Project Plan (IP2) Quality Log [C] Controlling A Stage (CS) Lessons Learned Report [C] Controlling A Stage (CS) IP6 – Project Approach Draft Project Initiation Document Authorising A Project Assembling (SU5) (PID) [C] (DP2) A PID Project Brief (SU4) Project Management Team Structure + Job Definitions (SU3) Project Quality Plan (IP1) Project Plan (IP2) Business Case (IP3) Risk Log (IP3) Project Controls (IP4) Communication Plan (IP4) Project Filing Structure (IP5) Figure 77: Summary Of The Initiating A Project (IP) Process Another major, but intangible output from this Process is the understanding that individuals within the Project management Team (including the Project Board Members) will gain about the nature, scope and possible pitfalls that the project may have to face. 176
  • 177. Ken Bradley’s Understanding PRINCE 2 The inclusion of an Initiation Stage in any PRINCE 2 controlled project is not optional - the method is very clear that an Initiation Stage be included whatever the type, scope or size of the project. The PID itself will be used to provide a baseline for the project throughout its life and beyond, extending to the completion of a Post-Project Review sometime after the project is closed down (typically some 6-9 months after the Product from the project has been handed over to the customer). When the PID has been completed and assembled, it is ready to be reviewed by the Project Board within the “Directing A Project (DP2)“ Process. The vehicle for this is an End Stage Assessment (at the completion of the mandatory Initiation Stage). Acceptance of the PID and approval by the Project Board signals the formal start of the project. 177
  • 179. Ken Bradley’s Understanding PRINCE 2 Chapter 14 UNDERSTANDING THE DIRECTING A PROJECT (DP) PROCESS 179
  • 181. Ken Bradley’s Understanding PRINCE 2 Directing A Project (DP) - Introduction Directing A Project (DP) operates throughout all stages of the project, from the end of Project Start-up through to Project Closure and is the primary concern of the Project Board. They achieve this by managing by exception, monitoring through reports provided primarily by the Project Manager, and controlling through a series of key decision points. Project Start-up Information from external sources Mobilisation of support Notification services Approved PID Exception Report Follow-on Action Recommendations Lessons Learned Report Post Implementation Review Plan Project Closure Notification Authorising Giving Confirming Authorising Authorising a Stage or Ad hoc Project Initiation a Project Exception Direction Closure Plan DP1 DP2 DP3 DP4 DP5 Highlight Report Authorisation Authorisation Exception Reports End Project Report to proceed to proceed Requests for advice Project Closure Request For Recommendation Exception Plan Draft Post Implementation Authorisation Review Plan to proceed PID Follow-on Action Project Brief Exception Plan Recommendations Draft Initiation Stage Plan End Stage Report Lessons Learned Report Job Definitions Draft Next Stage Plan Operational and Project Management Team PID Project Team changes maintenance confirmation structure Updated Project Plan PID Project Approach Updated Business Case Updated Risk Log Managing Starting up Initiating a Controlling Closing a Stage a Project Project a Stage Project Boundaries SU IP CS SB CP Figure 78: Directing A Project (DP) Process The key Processes break into the following areas: ♦ Control of the Initiation of the project ensuring it has the best possible start; ♦ Authorisation of the Project, committing the organisation to its successful outcome; ♦ Authorising Continuation of the project where a significant departure from the approved plans has occurred; ♦ Control of the Stage Boundaries, committing new and additional resources as the project progresses towards its ultimate aim; 181
  • 182. Ken Bradley’s Understanding PRINCE 2 ♦ Ad-hoc Decision-making and Direction, monitoring progress and providing advice and guidance as necessary; ♦ When the project has achieved its outcome, or is no longer considered to be a viable business proposition, arranging for Project Closure, bringing the whole undertaking to a controlled finish. This Process does not cover the day-to-day activities of managing the project - these rest with the Project Manager. The Process is positioned at the level of management residing above the Project Manager. Information will be presented to the Project Board in a number of ways, from formal report documents such as the Project Initiation Document (PID) through Highlight Reports, usually prepared on a monthly basis, to requests for ad-hoc direction by the Project Manager where a gentle “touch on the tiller” is required and senior management support is recommended. The Process is one of the busiest within the Process Model in terms of potential and actual inputs and outputs and the physical interpretation of how to direct a project may be expected to add further reports and directives. A key requirement within this Process is having senior managers on the Project Board who have the organisational authority to commit the resources that will be needed to see the project through to a successful conclusion. The ability to make decisions on commitment of additional resources in the event of problems and the vision to see the wider picture are also vital ingredients resident within this Process. Management By Exception A guiding principle at this level should always be the ability for senior managers to adopt a “hands-off” approach and to become involved with the project only at those points in time when their input is needed and to adopt a Management by Exception approach. Essentially this approach requires Project Board members to view the project strategically and to become involved only at planned review dates and at unscheduled meeting called only because the project has significantly departed from the approved plan. This is measured by a control known as “Tolerance” - essentially the scope a Project Manager has to depart from an approved Stage Plan without needing to report the departure to the Project Board. A forecast that the current Stage will not be able to complete within Tolerance (standard Tolerance of Time and Cost) will result in an Exception Report being prepared by the Project Manager for consideration by the Project Board members. An Exception Plan will often follow, this being produced by the Project Manager, which will be considered by the Project Board at a specially convened Mid-Stage Assessment. 182
  • 183. Ken Bradley’s Understanding PRINCE 2 DP1 – Authorising Initiation The work carried out in the “Starting Up A Project (SU)” Process is designed to put together enough information for the Project Board to make a “go/no-go” decision on whether to invest the necessary resources into the creation of a Project Initiation Document (PID). The Project Board will be presented with a set of decision support documentation and asked to approve the project in principle. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP1 – Project Authorisation To Proceed [C] Initiating A Project (IP) Authorising Management Team Initiation Structure (SU3) Stage Plan [U] Job Definitions (SU3) Project Brief (SU) Project Brief [U] Risk Log (SU) Risk Log [R] Project Approach (SU5) Draft Initiation Project Management Team Stage Plan (SU6) Structure [R] Project Approach [U] Project Start-up Notification [C] Corporate or Programme Management Figure 79: DP1 Plus Inputs and Outputs The project formally starts when this approval is gained (not when the Project Initiation Document has been prepared and approved). For low risk, smaller, projects a formal meeting of the Project Board may not be necessary and approval may be given directly by the Executive member (having responsibility for the overall business objectives). 183
  • 184. Ken Bradley’s Understanding PRINCE 2 DP2 – Authorising A Project Following the creation of the Draft Project Initiation Document (PID) in “Initiating A Project (IP)” the project can be approved formally by the Project Board and the PID “frozen”. The point of doing this is to establish a baseline against which to judge the project as it proceeds towards its conclusion and to measure against the final out-turn although certain parts of the PID are reviewed and modified at the end of each Management Stage; these are the Project Plan, the Business Case and the Risk Log. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP2 – Draft Project Authorisation To Proceed [C] Authorising Work Authorising Initiation Document Package (CS1) A Project (IP6) Approved Project Initiation Corporate or Next Stage Plan Document [U] Programme (SB1) Management Figure 80: DP2 Plus Inputs and Outputs The above diagram shows how both the Draft Project Initiation Document and the plans for the next Management Stage are input to this Process as decision support documentation. Note that the plans for the next Management Stage are not included as part of the PID but are prepared within a separate Process (“Managing Stage Boundaries (SB1)”) and accompany the PID as a separate document (the End Stage Report). Approval of the draft PID and the next Management Stage plans commits the resources and triggers commencement of work, providing authorisation for the Project Manager to begin using the resources in the plans. A copy of the approved PID is lodged in the Project File and Corporate Management is notified of the existence of the project by dispatch of a notification, or copy of the PID whatever is most appropriate. 184
  • 185. Ken Bradley’s Understanding PRINCE 2 DP3 – Authorising A Stage Or Exception Plan As it proceeds, the project will be reviewed by the Project Board at the conclusion of each Management Stage. Essentially the Project Board will be looking for evidence that the Management Stage has been completed to budget, on time and meeting the requirements of the Product Descriptions. This will be formally undertaken at an End Stage Assessment (ESA) and an approval will be sought for the project to continue and the next Management Stage plans approved and resources committed. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP3 – Next Stage Plan Authorisation To Proceed [C] Controlling A Stage (CS) Authorising (SB5) A Stage or Tolerances [C] Controlling A Stage (CS) Exception Project Plan Management Team Business Case [U] Controlling A Stage (CS) Changes (SB5) Project Plan [U] Controlling A Stage (CS) Product Checklist (SB5) Progress Information [C] Corporate or Programme Business Case Management and other (SB5) interested parties. Risk Log (SB5) End-Stage Report (SB5) Request for Authorisation To Proceed (SB5) Exception Plan (SB6) Project Initiation Document (IP6) Project Tolerances (Corporate or Programme Management) Figure 81: DP3 Plus Inputs and Outputs 185
  • 186. Ken Bradley’s Understanding PRINCE 2 A number of products and documentation are needed for the Project Board to properly carry out this responsibility and these are all created and/or updated within the “Managing Stage Boundaries (SB)” Process. Logs and on-going reports will be retrieved from the appropriate file and input to the Project Board either before or at the Project Board meeting. Care should be taken not to swamp the Project Board with too much paper or unimportant information. Approval of Exception Plans This Process is used also for approving Exception Plans. An exception occurs when a significant deviation from an approved plan occurs; a “significant deviation” is measured by whether Tolerance is exceeded and may occur as a result of a technical or quality problem within the project or a suggested change to one or more Products. The procedure is for an Exception Report to be raised by the Project Manager, alerting the Project Board members of the perceived problem. The Exception Report provides a statement of the problem, an analysis of its impact, the options available for recovery and a firm recommendation for recovery. The Exception Report is considered by the Project Board and a decision taken on whether the project may continue without any further action, or whether the remainder of the Management Stage needs to be re-planned to reflect the problem or required change. If the Project Board decide that the situation is serious enough to warrant it, an Exception Plan is produced by the Project Manager. The Exception Plan will be considered by the Project Board at a Mid Stage Assessment and after its approval, substitutes the plan it replaces. 186
  • 187. Ken Bradley’s Understanding PRINCE 2 Problem … Forecast to Exceed Tolerance Premature Termination of Project CS8 1: Exception Report Escalating DP4 Project Issues 2A: Direction Giving Ad-Hoc Advice 2B: Request for 3: Trigger - (Copy of Exception Plan Exception Report) CS1 - DP3 Authorising A Authorising A Stage or Work Package Exception Plan 5: Authorisation SB6 To Proceed Mid-Stage Producing An Assessment Exception Plan 4: Exception Plan Figure 82: Exception Reporting and Planning Figure 76 summarises the procedure for notifying the Project Board of a significant departure from plan (via the Exception Report) and subsequently the creation of the Exception Plan. Also shown on the above diagram is the Project Board’s option to terminate the project prematurely if they do not wish to continue with the undertaking following a major change in the approved plans (although this decision might have been taken earlier, when the exception was first reported and considered in the Process “Giving Ad-Hoc Direction (DP4)”. Where the cancellation option is preferred, the premature closedown of the project will be handled within the “Closing A Project (CP)” Process. 187
  • 188. Ken Bradley’s Understanding PRINCE 2 DP4 – Giving Ad-Hoc Direction This Process is the most powerful of all the Processes in that it includes provision to terminate the project prematurely if the Project Board are unhappy about the progress being made or if a significant departure from the approved plans occurs. The Process is also concerned with giving advice to the Project Manager and other staff employed on the project as and when it is needed and requested. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP4 – Information from & Exception Plan Request [C] Producing An Exception Giving Ad- to External Sources Plan (SB6) Hoc (Corporate or Direction Programme Premature Close [C] De-Commissioning A Management) Project (CP1) Highlight Reports (CS6) Response to External Sources Corporate & Programme Requests for (Corporate & Programme Management Advice (CS7) Management) Exception Report (CS8) Response to Requests for Advice Project Manager Communication Plan (IP4) Figure 83: DP4 Plus Inputs and Outputs Highlight Reports, prepared by the Project Manager (usually monthly, but at the frequency required by the Project Board) will provide much of the everyday input for the Project Board’s advice, comments and direction. Information coming into the project from external sources will also be filtered by the Project Board and acted upon, usually by providing direction to the Project Manager. 188
  • 189. Ken Bradley’s Understanding PRINCE 2 DP5 – Confirming Project Closure The responsibilities of this sub-process will usually (but not necessarily) be exercised through the holding of a Project Closure Meeting where the project will be shut down in an orderly and structured way. The information needed for the Project Board to shut down the project will be produced in “Closing A Project (CP)” Process and will include Customer Sign-off and identification of any follow up actions. The approval of a plan for performing a Post-Project Review (usually some 9-12 months after the closedown of the project will also be considered during this final Process. A fuller summary of the inputs and outputs to DP5 is shown in the following diagram: DP5 – Operational & Project Closure Notification [U] Corporate or Confirming Maintenance (Approved) Programme Project Acceptance (CP1) Management Closure Customer Follow0on Action Corporate or Acceptance (CP1) Recommendations [U] (Approved) Programme Management Project Closure Recommendation Post-Project Review Plan [U] Corporate or (CP1) (Approved) Programme Management Post-Project Review Plan (CP2) Lessons Learned Report [U] Corporate or (Approved) Programme Follow-on Action Management Recommendations (CP2) Lessons Learned Report (CP3) End Project Report (CP3) Baselined Project Initiation Document (DP2) Figure 84: DP5 Plus Inputs and Outputs 189
  • 190. Ken Bradley’s Understanding PRINCE 2 Specifically, the Project Board will wish to satisfy themselves that the project has a clearly defined end and that an orderly hand-over to operational use has been effected. The Project Board will look to the Senior User for confirmation that an acceptable End-Product is in existence and that it can be supported in an operational environment. A close liaison with the Project Board members will need to be maintained throughout the Project Manager’s preparation for this very important Process, ensuring that there are no surprises awaiting the members at the closure meeting. 190
  • 191. Ken Bradley’s Understanding PRINCE 2 Summary of the DP Process It is within the “Directing A Project (DP)” Process that every authorisation takes place. The Process is extremely important to the successful outcome of the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED DP1 – Project Authorisation To Proceed [C] Initiating A Project (IP) Authorising Management Team Initiation Structure (SU3) Stage Plan [U] Job Definitions (SU3) Project Brief (SU) Project Brief [U] Risk Log (SU) Risk Log [R] Project Approach (SU5) Draft Initiation Project Management Team Stage Plan (SU6) Structure [R] Project Approach [U] Project Start-up Notification [C] Corporate or Programme Management DP2 – Draft Project Authorisation To Proceed [C] Authorising Work Authorising Initiation Document Package (CS1) A Project (IP6) Approved Project Initiation Corporate or Next Stage Plan Document [U] Programme (SB1) Management 191
  • 192. Ken Bradley’s Understanding PRINCE 2 DP3 – Next Stage Plan Authorisation To Proceed [C] Controlling A Stage (CS) Authorising (SB5) A Stage or Tolerances [C] Controlling A Stage (CS) Exception Project Plan Management Team Business Case [U] Controlling A Stage (CS) Changes (SB5) Project Plan [U] Controlling A Stage (CS) Product Checklist (SB5) Progress Information [C] Corporate or Programme Business Case Management and other (SB5) interested parties. Risk Log (SB5) End-Stage Report (SB5) Request for Authorisation To Proceed (SB5) Exception Plan (SB6) Project Initiation Document (IP6) Project Tolerances (Corporate or Programme Management) DP4 – Information from & Exception Plan Request [C] Producing An Exception Giving Ad- to External Sources Plan (SB6) Hoc (Corporate or Direction Programme Premature Close [C] De-Commissioning A Management) Project (CP1) Highlight Reports (CS6) Response to External Sources Corporate & Programme Requests for (Corporate & Programme Management Advice (CS7) Management) Exception Report (CS8) Response to Requests for Advice Project Manager Communication Plan (IP4) 192
  • 193. Ken Bradley’s Understanding PRINCE 2 DP5 – Operational & Project Closure Notification [U] Corporate or Confirming Maintenance (Approved) Programme Project Acceptance (CP1) Management Closure Customer Follow0on Action Corporate or Acceptance (CP1) Recommendations [U] (Approved) Programme Management Project Closure Recommendation Post-Project Review Plan [U] Corporate or (CP1) (Approved) Programme Management Post-Project Review Plan (CP2) Lessons Learned Report [U] Corporate or (Approved) Programme Follow-on Action Management Recommendations (CP2) Lessons Learned Report (CP3) End Project Report (CP3) Baselined Project Initiation Document (DP2) Figure 85: Summary of the Directing A Project (DP) Process 193
  • 195. Ken Bradley’s Understanding PRINCE 2 Chapter 15 UNDERSTANDING THE CONTROLLING A STAGE PROCESS 195
  • 197. Ken Bradley’s Understanding PRINCE 2 Controlling A Stage (CS) - Introduction Following the Project Board’s decision to approve a Stage, the Project Management Team must be fully focused on delivery of the Products, to their stated Quality Criteria, within the approved time-scales and budget, within the stated Tolerances. Managing Closing a Product Project Work Package Delivery CP MP Project End Checkpoint Report Completed Notification Quality Log Work Package Receiving Taking Authorising Assessing Completed Corrective Work Package Progress Work Action Package CS7 CS1 CS2 CS9 Examining Project Issues CS4 Escalating Risk Log Project Issues Business Case CS8 Reviewing Reporting Capturing Stage Status Highlights Project Issues Exception Report CS5 CS6 CS3 Issue Log Authorisation to proceed New Project Stage Plan Stage/Exception Issues Plan Managing Directing a Highlight Copy of Exception Report Stage Project Report Boundaries DP SB Figure 86: Controlling A Stage (CS) Process This Process forms the main part of the Project Manager’s effort on the management of the project, and provides the direction for the day-to-day management of the Stage and the overall project. All through the Stage there will be an on-going cycle of: ♦ authorising Packages of Work that must be completed during the Management Stage and receiving Completed Work Packages (or Products) back into the host organisation; ♦ gathering Progress Information about the work carried out and the resources and effort expended; 197
  • 198. Ken Bradley’s Understanding PRINCE 2 ♦ watching for Changes to the approved plan; managing any changes raised formally against the project (Project Issues) and making decisions on the introduction of beneficial changes provided these do not result in the Stage Plans exceeding the Tolerance; ♦ reviewing situations for Stage and Project Impact; ♦ reporting to the Project Board and to other members of the Project Management Team; ♦ approving and initiating any Corrective Action. It may be expected that for much of the time events during a Management Stage will follow a regular and predictable pattern. However, personal qualities and project management abilities need to combine to address situations which are not going according to plan and it is then that the Project Manager must use knowledge, political and people skills to bring things back on course. 198
  • 199. Ken Bradley’s Understanding PRINCE 2 CS1 – Authorising A Work Package Work is released to Team Managers or directly to staff working on the project via the issue of authorised Work Packages. The format for these might be a formal contract, where the Products are being produced by a Supplier external to the host organisation, or much less formal (for example by internal memorandum or discussion) where the provider is employed within the host organisation. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS1 – Stage or Exception Plan Adjustments [C] Assessing Progress Authorising Plan (DP3) (CS2) Work Package Authorisation To Proceed (DP3) Proposed Work Package (CS5) Work Package [C] Accepting A Work Package (MP1) Work Trigger (CS7 Product Descriptions (PL2) Figure 87: CS1 Plus Inputs and Outputs The Project Manager is responsible for the preparation, release and agreement of Work Packages; authority for this responsibility stems from the Project Board’s approval of the relevant Management Stage Plan and for this reason Management Stage Plans (produced in the “Managing Stage Boundaries (SB)” Process) must be sufficiently detailed for the Project Board to understand to what they are committing. Changes necessary as the Management Stage progresses must be reflected in the work being carried out on the relevant Work Packages – this demands a close association between the Project Manager and the Team Manager(s) responsible for producing the Product(s). Where a formal contract is in existence, care must be taken not to upset the contract arrangements by demands for trivial changes. This Process provides the Project Manager with the main vehicle for release of work and is a major control on a day to day basis. 199
  • 200. Ken Bradley’s Understanding PRINCE 2 CS2 – Assessing Progress The Project Manager must keep track on how well the Management Stage, and the Project, is performing against the plan approved by the Project Board at the last End Stage Assessment. This Process provides the mechanics for capturing “Actuals” and passing the information forward to “Reviewing Stage Status (CS5)” where the Project Manager can take stock of progress so far. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS2 – Checkpoint Reports Up-dated Stage Plan [U] Examining Project Assessing (MP2) Issues (CS4) Progress Quality Log (MP2) Reviewing Stage Status (CS5) Plan Adjustments (CS1) Stage Plan (CS5) Work Package Status (CS9) Figure 88: CS2 Plus Inputs and Outputs The information needed to update the approved Management Stage Plan comes from three major sources: ♦ Checkpoint Reports (created within the “Managing Product Delivery (MP2)” Process); ♦ Timesheets (where these are in use within the host organisation – otherwise an assessment by the Project Manager of effort expended and financial liability incurred); ♦ Project Issues – especially where errors or departures from the agreed requirement have been identified. This Process is best carried out by Project Support, where appointed, with a presentation of the plans, updated to show “actuals”, to the Project Manager for overall assessment on at least a weekly basis. Use of a suitable software planning tool (such as MS Project, Project Manager Workbench, Primavera etc) will simplify this Process especially if standard “actuals” 200
  • 201. Ken Bradley’s Understanding PRINCE 2 reporting forms generated within the package are fully utilised. The output from CS2 goes towards the Project Manager’s review of how well the Management Stage is progressing when measured against the Management Stage plan approved by the Project Board at the previous End Stage Assessment. 201
  • 202. Ken Bradley’s Understanding PRINCE 2 CS3 - Capturing Project Issues As the project progresses there will be a need to capture and decide upon changes that occur. All changes within a PRINCE 2 project are treated as types of Project Issue. These include errors found in signed-off Products, departures from the agreed Specification, ideas and suggestions people have for improving the project’s outputs, resource changes that need to be reflected in the project and stage plans. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS3 – Issue Log (Quality Up-dated Issue Log [U] Examining Project Capturing File) Issues (CS4)) Project Issues New Project Issues (Any Project Source) Figure 89: CS3 Plus Inputs and Outputs A Project issue can be raised by anyone associated with the project. Typically organisations will have their own existing change control arrangements and these should be adopted where they are performing satisfactorily. The first job on receipt of a Project Issue is to record it on the Issue Log - this will normally be a function of Project Support or the Configuration Librarian where appointed. The Issue can then be passed to “CS4 - Examining Project Issues”. The types of Project Issue are: ♦ Request For Change - causing a change to the Customer’s Specification or Acceptance Criteria; usually paid for by the Customer. ♦ Off-Specification causing errors or omissions in work already completed or planned; usually paid for by the Supplier. ♦ Other Changes such as modification to the Project Management Team. More information can be found in the Chapter on Understanding The Change Control Component and Technique. 202
  • 203. Ken Bradley’s Understanding PRINCE 2 CS4 - Examining Project Issues This Process enables each Project Issue to be examined and its impact assessed; this should be carried out as soon as possible after receipt and logging of the Project Issue. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS4 – Business Case Issue Log [U] Reviewing Stage Status Evaluating (SB3) (CS5) Project Issues Stage Plan (CS2) Risk Log [U] Reviewing Stage Status (CS5) Issue Log (CS3) Issue Log [U] Reporting Highlights Risk Log (SB4) (CS6) Project Plan (SB2) Figure 90: CS4 Plus Inputs and Outputs The examination and evaluation of Project Issues may take place via a regular meeting or by circulation of the Issue and comments to those involved. Whatever route is chosen, progress needs to be recorded in the Issues Log. Project Issues should always be examined from a Customer, Supplier and Business perspective; any action needed which would take the Management Stage over the agreed Tolerance must be referred to the Project Board in the form of an Exception Report (see “Escalating Project Issues (CS8))”. Responsibility for examining Project Issues rests with the Project Manager who will use the support services of Team Managers in helping arrive at an appropriate decision. The Senior User member of the Project Board will prioritise and if necessary canvas the Project Board for any additional resources needed to clear outstanding Project Issues. Prioritisation of outstanding Project issues is usually done by referring to the Issues Log at each End Stage Assessment. 203
  • 204. Ken Bradley’s Understanding PRINCE 2 CS5 - Reviewing Stage Status This Process provides for a regular check of how the Management Stage is performing against its approved plan. The intention is to allow the Project Manager to stand back from the day to day problem solving activities and take stock, prior to reporting the situation to the Project Board. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS5 – Stage Plan (CS2) Notification of Project End [C] De-Commissioning A Reviewing Project (CP1) Stage Issue Log (CS4) Status Work Trigger(s) [C] Authorising Work Risk Log (CS4) Package (CS1) Tolerances (DP3) Stage Status Information [C] Reporting Highlights (CS6) Business Case (DP3) Plan Deviation [C] Taking Corrective Action (CS7) Project Plan (DP3) Stage Plan [U] Escalating Project Issues (CS8) Planning A Stage (SB1) Project Issue [R] Escalating Project issues (CS8) Stage End Notification [C] Planning A Stage (SB1) Figure 91: CS5 Plus Inputs and Outputs The key driver for assessing Management Stage status is the “Assessing Progress (CS2)” Process which captures information from Checkpoint Reports and Timesheets and updates the approved plans with “actuals”. Inputs will also be needed from the Issues Log where modifications to the Management Stage plans may be brewing following the discovery of errors and omissions or ideas for improvement., and the Risk Log which will enable the Project Manager to review emerging risks identified at the outset of the Management Stage. The overall outcome of the Process is to ensure on a regular basis (recommended weekly at the minimum) that the Management Stage remains within Tolerance and that nothing untoward is likely to occur without warning. Information and knowledge gleaned from this Process will feed the creation of the Highlight Report for the Project Board. 204
  • 205. Ken Bradley’s Understanding PRINCE 2 CS6 - Reporting Highlights Having approved a Management Stage Plan, the Project Board will need to be kept informed of the progress being made towards the successful conclusion of the stage. Reporting Highlights to the Project Board will be a regular, time-related activity, typically every month but specifically at the frequency required by the Project Board. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS6 – Communication Highlight Reports [C] Giving Ad-Hoc Direction Reporting Plan (Project (DP4) Highlights File/PID) Stage Plan (CS5) Checkpoint Reports Communications To Interested Corporate or (CS5) Parties [C] Programme Management Issue Log (CS5) Risk Log (CS5) Tolerances (CS5) Plan Revisions (CS5) Figure 92: CS6 Plus Inputs and Outputs The objective of the Highlight Report is to provide summary information to the Project Board - one sheet of paper (or its equivalent) is all that is needed. The steps taken in performing this Process are: Assemble information from Checkpoint Reports and Project Issues received during the previous period since the last Highlight Report ♦ Identify any new or potential problem arising from “Reviewing Stage Status (CS5)” ♦ Identify any significant revisions to the approved plan from “Taking Corrective Action (CS7)” ♦ Create the Highlight Report (Project Support might well produce the first draft) 205
  • 206. Ken Bradley’s Understanding PRINCE 2 ♦ Distribute the Highlight Report to Project Board members and any other agreed recipients. The Highlight Report does not normally require a meeting of the Project Board although this is an option for high-profile, high-risk projects where the Project Board are particularly sensitive about the progress that is being made. 206
  • 207. Ken Bradley’s Understanding PRINCE 2 CS7 - Taking Corrective Action In even the best managed projects, departures from the planned course of action will occur and remedial action must be taken to bring the work back into line. This Process enables the Project Manager to make small adjustments, within the agreed Tolerance, to the work being carried out. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS7 – Stage Plan (CS5) Work Trigger [C] Authorising Work Taking Package (CS1) Corrective Issue Log (CS5) Action Up-dated Stage Plan [U] Reporting Highlights Plan Deviation (CS6) (CS5) Request For Advice [C] Giving Ad-Hoc Direction Risk Log (CS5) (DP4) Figure 93: CS7 Plus Inputs and Outputs The main driver for the Process comes from “CS5 - Reviewing Stage Status” where deviations from the required and planned outcome will start to become apparent. Projects seldom change course dramatically but rather significant slippage is prompted by many smaller incidents and this Process aims to treat each incident as it occurs. Additional Work Packages may be identified in this Process. Advice and guidance may well need to be sought from Project Board members and this will usually be informal. The results of this Process will need to be considered for reporting to the Project Board by inclusion on the next Highlight Report but this should be the exception rather than the rule. The Project Manager is responsible for the operation of this Process helped by the Project Management Team. Project Managers should always be aware of the build-up of apparently minor problems being symptomatic of bigger trouble with the project. 207
  • 208. Ken Bradley’s Understanding PRINCE 2 CS8 - Escalating Project Issues As soon as it is forecast that a Management Stage (or the Project) is likely to go outside the Tolerance the Project Manager must notify the Project Board by raising an Exception Report. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS8 – Business Case Exception Report [C] (+ Response Giving Ad-Hoc Direction Escalating (CS5) back from Project Board) (DP4) Project Issues Issue Log (CS5) Producing An Exception Plan (SB6) Project Plan (CS5) Project Board Response [R] Producing An Exception Stage Plan (CS5) Plan (SB6) Risk Log (CS5) Stage Plan [R] Producing An Exception Project Initiation Plan (SB6) Document (IP6) Figure 94: CS8 Plus Inputs and Outputs Although many things may contribute to or trigger this Process the most common situation is where a Project Issue has been raised to record an error or deficiency with one or more Products. The steps to be taken in this Process are: ♦ Identify the problem and carry out an Impact Analysis ♦ Identify and Evaluate options for recovery ♦ Select a recommended direction ♦ Document the problem, reasons, impact, options and recommendations in an Exception Report for the Project Board ♦ Await the Project Board’s response The expected outcome will be a request to produce an Exception Plan which will replace the plan that has gone into exception. The Project Board’s views and advice should always be sought before producing an Exception Plan and the effect on the overall Project Plan (including the Business Case and Risks) must always be evaluated. 208
  • 209. Ken Bradley’s Understanding PRINCE 2 CS9 - Receiving A Completed Work Package This Process records the successful completion of a Work Package (or Product) and delivery of it back into the host organisation. It is closely associated with “Authorising A Work Package (CS1)” discussed earlier. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS9 – Approved Work Work Package Status [C] Assessing Progress Receiving Package (MP3) (CS2) Completed Work Package Figure 95: CS9 Plus Inputs and Outputs The arrangements for delivering the Completed Work Package will have been agreed when the Work Package was accepted by the Supplier, Team Manager or person responsible for its production in the Process “Accepting A Work Package (MP1)”. Completed Work Packages or Products delivered into the host organisation will all have been Quality Reviewed (in Process “Executing A Work Package (MP2)”) in accordance with the requirements agreed when the Work Package was accepted. The results of the Process are used to assess the progress made by recording the task as complete and updating the Management Stage and project records accordingly. 209
  • 210. Ken Bradley’s Understanding PRINCE 2 Summary of the Controlling A Stage Process Controlling A Stage (CS) is the main project management driver for a PRINCE 2 controlled project. The Process is owned by the Project Manager and is where most of the “day-to-day” project management activities are carried out. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CS1 – Stage or Exception Plan Adjustments [C] Assessing Progress Authorising Plan (DP3) (CS2) Work Package Authorisation To Proceed (DP3) Proposed Work Package (CS5) Work Package [C] Accepting A Work Package (MP1) Work Trigger (CS7 Product Descriptions (PL2) CS2 – Checkpoint Reports Up-dated Stage Plan [U] Examining Project Assessing (MP2) Issues (CS4) Progress Quality Log (MP2) Reviewing Stage Status (CS5) Plan Adjustments (CS1) Stage Plan (CS5) Work Package Status (CS9) CS3 – Issue Log (Quality Up-dated Issue Log [U] Examining Project Capturing File) Issues (CS4)) Project Issues New Project Issues (Any Project Source) 210
  • 211. Ken Bradley’s Understanding PRINCE 2 CS4 – Business Case Issue Log [U] Reviewing Stage Status Evaluating (SB3) (CS5) Project Issues Stage Plan (CS2) Risk Log [U] Reviewing Stage Status (CS5) Issue Log (CS3) Issue Log [U] Reporting Highlights Risk Log (SB4) (CS6) Project Plan (SB2) CS5 – Stage Plan (CS2) Notification of Project End [C] De-Commissioning A Reviewing Project (CP1) Stage Issue Log (CS4) Status Work Trigger(s) [C] Authorising Work Risk Log (CS4) Package (CS1) Tolerances (DP3) Stage Status Information [C] Reporting Highlights (CS6) Business Case (DP3) Plan Deviation [C] Taking Corrective Action (CS7) Project Plan (DP3) Stage Plan [U] Escalating Project Issues (CS8) Planning A Stage (SB1) Project Issue [R] Escalating Project issues (CS8) Stage End Notification [C] Planning A Stage (SB1) CS6 – Communication Highlight Reports [C] Giving Ad-Hoc Direction Reporting Plan (Project (DP4) Highlights File/PID) Stage Plan (CS5) Checkpoint Reports Communications To Interested Corporate or (CS5) Parties [C] Programme Management Issue Log (CS5) Risk Log (CS5) Tolerances (CS5) Plan Revisions (CS5) 211
  • 212. Ken Bradley’s Understanding PRINCE 2 CS7 – Stage Plan (CS5) Work Trigger [C] Authorising Work Taking Package (CS1) Corrective Issue Log (CS5) Action Up-dated Stage Plan [U] Reporting Highlights Plan Deviation (CS6) (CS5) Request For Advice [C] Giving Ad-Hoc Direction Risk Log (CS5) (DP4) CS8 – Business Case Exception Report [C] (+ Response Giving Ad-Hoc Direction Escalating (CS5) back from Project Board) (DP4) Project Issues Issue Log (CS5) Producing An Exception Plan (SB6) Project Plan (CS5) Project Board Response [R] Producing An Exception Stage Plan (CS5) Plan (SB6) Risk Log (CS5) Stage Plan [R] Producing An Exception Project Initiation Plan (SB6) Document (IP6) CS9 – Approved Work Work Package Status [C] Assessing Progress Receiving Package (MP3) (CS2) Completed Work Package Figure 96: Summary of the Controlling A Stage (CS) Process 212
  • 213. Ken Bradley’s Understanding PRINCE 2 Chapter 16 UNDERSTANDING THE MANAGING PRODUCT DELIVERY PROCESS 213
  • 215. Ken Bradley’s Understanding PRINCE 2 Managing Product Delivery (MP) - Introduction This major Process is aimed primarily at managing the interface between the Customer Project Manager and the Supplier Project Manager ensuring that work is actually progressing in accordance with the customer’s expectations and that all the planned Products are created and delivered within the agreed time-scales and contract price or internally approved budget, and meet their approved Quality Criteria. The Process is also used for managing the delivery of Products where an external Supplier is not involved in the project and where all resources managed by the project are internal; it is also appropriate where there is a mixture of both. Work Package Authorising Accepting a Executing a Delivering a Work Package Stage Plan Work Package Work Package Work Package CS1 MP1 MP2 MP3 Checkpoint Report Work Package Quality Log Closure Stage Plan Product Sign-off Receiving Assessing Completed Progress Work Package CS2 CS9 Figure 97: Managing Product Delivery (MP) Process The Process comprises: ♦ making certain that work on Products allocated to each external Team or Team Member resource is properly Authorised; ♦ ensuring that Packages of Work are identified, discussed, agreed, authorised and accepted by those responsible for the creation of Products; ♦ checking that all Interfaces between the Customer and Supplier organisations are identified, recorded, observed and handled in an appropriate way; 215
  • 216. Ken Bradley’s Understanding PRINCE 2 ♦ ensuring that all the Work is actually Carried Out, as agreed; ♦ ensuring that the Progress of Work and Forecasts of the time and effort to completion are regularly assessed; ♦ checking that all finished Products conform to their agreed Quality Criteria; ♦ obtaining Approval for completed Products. This will usually be at three levels – Producer and Reviewer level, Project Manager level, and ultimately endorsement by the Project Board at the end of each Project Stage. These levels of approval will be reflected in both the Customer and Specialist Supplier organisations, although it is not necessary that either will be working within a PRINCE environment; it is essential, however, that all involved are working within a suitably controlled project management environment. This Process will operate continuously throughout each Stage; it provides a healthy separation between the Customer Project Manager and the Supplier Project Manager and requires the interface between the Supplier(s) (be they internal or external) and the Customer to be identified, defined and operated. Care must be taken to ensure that the interfaces are neither missed nor lost, and that bureaucracy is kept to the absolute minimum consistent with effective control. Where a Project Manager allocates work directly to individuals responsible for carrying out the work package, this Process will be informal but will always exist. 216
  • 217. Ken Bradley’s Understanding PRINCE 2 MP1 - Accepting A Work Package The Process provides for the establishment of agreement between the Project Manager and the Team Manager, Team or individual who will be responsible for creating and delivering the completed Work package (or Product) for the host organisation. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP1 – Work Package Risk Log [U] Up-Dating The Risk Log Accepting A (CS1) (SB4) Work Package Work Package (Authorised) [C] Executing A Work Package (MP2) Team Plan [C] Executing A Work Package (MP2) Figure 98: MP1 Plus Inputs and Outputs The interface between the Project Manager and those responsible for creating the Products of the project needs to be properly managed. This Process enables the agreement to be established before any work is commenced. The agreement/interface manifests itself in the form of a Work Package authorisation of which the key elements are: ♦ Agreement of the Objectives for the Work Package ♦ Tolerances for the Work Package ♦ The Reporting Arrangements - Timing and Content ♦ A Plan for the Work Package ♦ A Product Description specifying the Product’s content, its Quality Criteria and the Method of measuring if the Product conforms to its stated Quality Criteria. The Project Manager is responsible for delivering the Products to the Project Board as part of the Management Stage objectives; responsibility for agreement of the Work Package resides with the Project Manager and the Team Manager, where appointed (and the Project Manager where no Team Manager exists). 217
  • 218. Ken Bradley’s Understanding PRINCE 2 MP2 - Executing A Work Package This Process addresses the creation of the Products of the project.It may be that the creators of the Products are not using PRINCE or any other formal project management method and where this is the case agreement of the Work Package in MP1 is even more significant. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP2 – Work Package Quality Log [U] Assessing Progress Executing A (Authorised) (MP1) (CS2) Work Package Team Plan (MP1) Checkpoint Reports [C] Assessing Progress (CS2) Completed Work Package [C] Delivering A Work Package (MP3) Team Plan [U] Stage File Figure 99: MP2 Plus Inputs and Outputs It is within this Process that “actuals” are captured, at source, to enable the effort and costs in the Management Stage Plan and the Project Plan to be updated within the “Controlling A Stage - Assessing Progress (CS2)” Process. The quality checking arrangements agreed within MP1 will be performed during this Process; the objective is to ensure that quality is integral to the Product(s) being built so that Products delivered back into the host organisation are complete and ready to be placed into the Configuration Management System as finalised Products. Indeed it might well be that the Configuration Librarian may be the first recipient of completed Work Packages or Products to log and file them before reporting the situation to the Project Manager. Checkpoint Reports are generated within MP2 at the frequency and in the format agreed in the Work Package. Checkpoint Reports are used within CS2 to update the Management Stage and Project Plans. Responsibility for all activities within this Process is vested in the Team Manager where appointed, or the Project manager where no such appointment has been made. 218
  • 219. Ken Bradley’s Understanding PRINCE 2 MP3 - Delivering A Work Package Formalising the return of a completed Work Package is the focus for this Process. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP3 – Completed Work Approved Work Package [C] Receiving Completed Delivering A Package (MP2) Work Package (CS9) Work Package Figure 100: MP3 Plus Inputs and Outputs A simple but significant Process, MP3 provides for final sign-off of the Product(s), dispatch and hand-over of the Product(s) and formal notification to the Project manager of the completion of work by the Team Manager or person responsible. The arrangements for hand-over and notification should have been established in MP1 and will often be embodied into a formal contract document. Responsibility lies with the Team Manager where appointed. 219
  • 220. Ken Bradley’s Understanding PRINCE 2 Summary of the Managing Product Delivery Process Managing Product Delivery is the “engine room” for the PRINCE 2 project, creating the Products required for Management Stage; it is where the bulk of the project’s time, effort and financial resources will be spent. The Process will always be present in some form although it will be less formal where no outside Supplier or sub-contractor is being used. External suppliers may not be using the PRINCE 2 Method for their project management standard and this Process may not, therefore be physically implemented or understood where this is the case. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED MP1 – Work Package Risk Log [U] Up-Dating The Risk Log Accepting A (CS1) (SB4) Work Package Work Package (Authorised) [C] Executing A Work Package (MP2) Team Plan [C] Executing A Work Package (MP2) MP2 – Work Package Quality Log [U] Assessing Progress Executing A (Authorised) (MP1) (CS2) Work Package Team Plan (MP1) Checkpoint Reports [C] Assessing Progress (CS2) Completed Work Package [C] Delivering A Work Package (MP3) Team Plan [U] Stage File MP3 – Completed Work Approved Work Package [C] Receiving Completed Delivering A Package (MP2) Work Package (CS9) Work Package Figure 101: Summary of the “Managing Product Delivery (MP)” Process 220
  • 221. Ken Bradley’s Understanding PRINCE 2 Chapter 17 UNDERSTANDING THE MANAGING STAGE BOUNDARIES PROCESS 221
  • 223. Ken Bradley’s Understanding PRINCE 2 Managing Stage Boundaries (SB) - Introduction To achieve a successful outcome to the project, it is necessary to break it into smaller, discrete packages to enable the Project Team to focus on specific Products or Deliverables; this approach provides the concept of Project Stages. By controlling the start and finish of each stage, specific attention can be given to whether the Stage Products/Deliverables have all been completed in accordance with their Quality Criteria, whether the remaining project Products/Deliverables are still required, and whether the Business Case for the project remains viable. Lessons Learned Report End Stage Report Next Stage Plan Authorising a Risk, Issue and Reporting Stage or Quality Logs Request for Authorisation to proceed Stage End Exception Project Plan, Business Case, Plan SB5 Project Brief DP3 Current Stage Plan Business Case Current PM Team Updating a Risk & Issue Log Planning A Updating a Project Stage Plans Project Plan Plans Business Project Plan SB1 SB2 Case SB3 Updated PM team Issue Plans and Risk Project Brief Logs Request For Exception Plan Issue Log + Exception Report Producing An Updating the Exception Risk Log Risk Log Plan Agreed Tolerance SB6 SB4 Current Issue Stage and Risk Project Plan Log Quality Plan Project Approach Closing a Project CP Figure 102: Managing Stage Boundaries (SB) Process The aims of the Process are: ♦ to assure the Project Board that all the Products/Deliverables planned for the current stage have been completed and meet their Quality Criteria; ♦ to provide the information on time-scale, technical achievement, and the budget needed to enable the Project Board to assess whether the overall project Business Case is still viable, and whether the Benefits can be achieved within an acceptable level of risk; 223
  • 224. Ken Bradley’s Understanding PRINCE 2 ♦ to provide decision-support information on the status of the current stage and the overall project, which will enable the Project Board to reach a decision on final completion of the current stage, authorise the start of the next stage, and to endorse the overall project. ♦ to provide a vehicle for stating the Tolerance which may be allowed for the next Stage. Tolerance is a control providing cost and time “trigger-figures” beyond which the Project Manager may not progress without the approval of the Project Board. ♦ to record any information or Lessons Learned which might impact on later stages of the project, or on the organisation as a whole. The Process is an iterative one as the project proceeds from one stage to the next. Controlling the start and end of stages is a key control process for the Project Board and incorporates all the key aspects of directing a project. Exception Plans The steps of this Process may also be used when creating an Exception Plan, where a significant departure from the approved plan has occurred and Tolerance is forecast to be exceeded. In order to reach a decision on the future of the project, the Project Board will need to consider an impact analysis, options appraisal, and a recommendation for action prepared by the Project Manager; these will all need to be supported by an up-dated Business Case confirming the benefits and re-appraisal of the risks. 224
  • 225. Ken Bradley’s Understanding PRINCE 2 SB1 - Planning A Stage As the project progresses the Project Board will limit their commitment and risk exposure by releasing the commitment of effort and funding via End Stage Assessments at the completion of each Management Stage. A key input to these major Project Board controls is the plan for the next Management Stage put together in SB1. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB1 – Current Stage Plan Next Stage Plan [C] Up-Dating A Project Planning A (CS5) (Stage File) Plan (SB2) Stage Stage End Notification (CS5) Project Plan [R] Up-Dating A Project Plan (SB2) Project Plan (IP2) (Project File) Project Management Team Reporting Stage End Changes [U] (SB5) Trigger For Next Stage Plan (IP2) PID (IP6) (Project Product Checklist [U] Reporting Stage End File) (SB5) Current Project Management Team (IP6) (Project File & Stage File) Figure 103: SB1 Plus Inputs and Outputs The aim of the Process is to identify all the Products (Specialist, Management and Quality) that will need to be produced during the next Management Stage and estimate the effort and cost to its completion. A number of inputs will be necessary to achieve this end (including the agreed Project Plan) to accurately position the Management Stage, and they are summarised in the above diagram. The Organisation Structure for the Project Management Team will also be reviewed during this Process, to ensure that the most appropriate resources and management team are available for the work to be undertaken. Much of the work involved in creating the Next Stage Plan will be carried out by members of the Project Management Team under the supervision of the Project Manager, who has prime responsibility for the timely production of the plan. Any individuals having responsibility for Project Assurance will need to be consulted during this Process especially in respect of the proposed management controls and quality control structure. 225
  • 226. Ken Bradley’s Understanding PRINCE 2 SB2 - Updating A Project Plan Information needed for decision support at the end of each Management Stage obviously includes an updated view of the Project Plan to identify what impact work so far on the project has impacted on the final delivery date and cost. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB2 – Up- Current & Next Up-Dated Project Plan [U] Up-Dating A Project Dating A Stage Plans (SB1) Business Case (SB3) Project Plan Exception Plan Reporting Stage End (SB6) (SB5) Project Approach Up-Dating The Risk Log (IP6) (Project File) (SB4) Project Quality Plan Next Stage Plan [R] Reporting Stage End (IP6) (Project File) (SB5) or Exception Plan [R] Figure 104: SB2 Plus Inputs and Outputs The three key inputs to this Process are: ♦ the Management Stage which has just been completed (the Current Stage Plan) ♦ the Next Management Stage Plan created in SB1 ♦ the approved Project Plan Actual schedule, effort and cost information is extracted from the Current Stage Plan and any changes proposed in the Next Stage Plan are used to present an up-to-date view of the likely final out-turn for the project. Other inputs are also available to this Process from a number of sources; the main objective is to present a comprehensive view of what the Project Board is being asked to commit to, long term, at the approaching End Stage Assessment. Any significant changes in the Project Plan brought about by this Process should be included in the End Stage Report produced by the Project Manager for the Project Board. 226
  • 227. Ken Bradley’s Understanding PRINCE 2 SB3 - Updating A Project Business Case The Business Case is the main driving force behind any PRINCE 2 controlled and this must be kept up to date and reviewed at the completion of each Management Stage as a minimum requirement. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB3 – Up- Up-Dated Project Business Case [U] Reporting Stage End Dating A Plan (SB2) (SB5) Project Business Exception Plan or Case Next Stage Plan (SB2) Risk Log [R] Reporting Stage End Risk Log (SB4) SB5) Issue Log (SB4) Figure 105: SB3 Plus Inputs and Outputs Many events would have occurred during the previous Management Stage which will impact the Business Benefits which were used to justify the project initially and at the last formal Project Board Review. For example, if the overall project plan has been extended or its predicted out-turn cost increased then there will be a detrimental effect on the Business Benefits; the reverse is also true! On the positive side, it can be expected that the risks faced by the project will be reduced as progress is made. This aspect is treated in SB4 - “Updating The Risk Log” but needs to be considered here as the two topics are very closely related. Changes requested (and made) during the Management Stage will also impact on the Business Benefits, especially where required changes for improved functionality have incurred additional effort and costs. 227
  • 228. Ken Bradley’s Understanding PRINCE 2 SB4 -Updating The Risk Log As the project proceeds towards its planned conclusion, the risks faced for delivering on time, within budget and to the required specification should reduce. This must be recorded and presented to the Project Board when they are being asked to approve the next Management Stage Plan. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB4 – Up- Project Plan (SB2) Risk Log [U] Up-Dating A Project Dating The Business Case (SB3) Risk Log Next Stage Plan (SB2) Accepting A Work Package (MP1) Exception Plan (SB2) Issue Log [U] Up-Dating A Project Business Case (SB3) Issue Log CS4 (Quality File) Figure 106: SB4 Plus Inputs and Outputs Essentially the Risk Management Component comes back into play and the project risk re- assessed. Although PRINCE 2 does not include any requirement to use any specific risk management tool the Risk Analysis Checklist described in Chapter 6 can be used to update the risks. Whatever approach is used, the results must be logged and presented to the Project Board at the End Stage Assessment. The Risk Log should indicate a downward trend if the project is to proceed without any changes. Significant increases in the risk measurement must always be brought to the attention of the Project Board and recommendations made. Ownership of each identified risk should always be considered - the most appropriate member of the Project Management Team being best placed to keep a watchful eye on movements against the baseline. Changes in approach, planning and resource usage will always have a potential impact on the risks facing the project and so changes to the Project Plan or Next Stage Plan should always be reviewed for their impact within this Process. 228
  • 229. Ken Bradley’s Understanding PRINCE 2 SB5 - Reporting Stage End The results of a Management Stage needs to be reported back to those who have provided the resources which have contributed to its completion PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB5 – Project Plan (SB2) End Stage Report [C] Authorising A Stage or Reporting Exception Plan (DP3) Stage End Current Stage Plan (SB2) Request for Authorisation To Authorising A Stage or Next Stage Plan or Proceed [C] Exception Plan (DP3) Exception Plan (SB2) Next Stage Plan [R] Authorising A Stage or Exception Plan (DP3) Business Case (SB3) Exception Plan [R] Authorising A Stage or Issue & Risk Logs Exception Plan (DP3) (SB3) Quality Log (CS5) Risk Log [R] Authorising A Stage or (Quality File) Exception Plan (DP3) Communication Plan (IP4) (Project Product Status Account [C] De-Commissioning A File) Project (CP1) Communications to interested Corporate or parties [C] Programme Management Figure 107: SB5 Plus Inputs and Outputs This Process is activated as near as possible to the end of the Current Management Stage. The results of the Process are presented as an End Stage Report which summarises the result of the Management Stage; the report provides the following information to the Project Board: ♦ Planned vs out-turn costs ♦ Planned vs out-turn effort 229
  • 230. Ken Bradley’s Understanding PRINCE 2 ♦ Planned vs out-turn milestone dates ♦ Products delivered (and confirmation they meet the stated Quality Criteria The End Stage Report acts as the vehicle for presentation of the Stage results and the Next Stage Plan to the Project Board. Responsibility for creation of the report rests with the Project Manager, with help and support from the Project Management Team as appropriate. It will be provided up to a week in advance of the End Stage Assessment to allow Project Board members to consider its content; arrangements for handling Management Stage endings to allow for this are discussed in the Chapter on Understanding The Stages Component. 230
  • 231. Ken Bradley’s Understanding PRINCE 2 SB6 - Producing An Exception Plan As soon as it is forecast that a Management Stage is likely to deviate beyond the Tolerance set by the Project Board at the previous End Stage Assessment, it is deemed to be in Exception and an Exception Report must be prepared for the Project Board. The likelihood is that the Project Board will require an Exception Plan to be prepared and this Process is where such a plan is created. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB6 – Exception Report Exception Plan [C] Up-Dating A Project Producing (CS8) Plan (SB2) An Exception Stage Plan (CS8) Authorising A Stage or Plan Exception Plan (DP3) Exception Plan Request (DP4) Figure 108: SB6 Plus Inputs and Outputs Standard Tolerance is measured in Time (Schedule) and Cost. For each Management Stage Tolerance is recommended by the Project Manager, based on the latest assessment of risk and the nature of the work, and confirmed by the Project Board at the End Stage Assessment. There is a separate component within PRINCE 2 for Tolerance described in the Controls Component. Additional Tolerances might be usefully considered – these include Scope, Quality and Risks. The Exception report, raised by the Project Manager as soon as it is forecast that Tolerance will be exceeded, describes the nature of the exception, its impact on the Management Stage and Project, the options open to recover the situation, and the recommendation by the Project Manager. The Exception Report is considered in “Giving Ad-Hoc Direction (DP4)” by the Project Board members (although no specific meeting or control for this consideration is identified by PRINCE). The Project Board will normally require an Exception Plan to be created to replace the approved plan which has been departed from; they might, of course decide to prematurely terminate the project or to just live with the departure but this could not be described as realistic management. This Process creates the Exception Plan which will be approved by the Project Board in “Authorising A Stage or Exception Plan (DP3)” Process at a specially convened Mid Stage Assessment. 231
  • 232. Ken Bradley’s Understanding PRINCE 2 Summary of the Managing Stage Boundaries Process The “Managing Stage Boundaries Process (SB)” Process will always be present in a PRINCE 2 controlled project (since every PRINCE project will have a minimum of two Management Stages, and therefore at least one SB Process). PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED SB1 – Current Stage Plan Next Stage Plan [C] Up-Dating A Project Planning A (CS5) (Stage File) Plan (SB2) Stage Stage End Notification (CS5) Project Plan [R] Up-Dating A Project Plan (SB2) Project Plan (IP2) (Project File) Project Management Team Reporting Stage End Changes [U] (SB5) Trigger For Next Stage Plan (IP2) PID (IP6) (Project Product Checklist [U] Reporting Stage End File) (SB5) Current Project Management Team (IP6) (Project File & Stage File) SB2 – Up- Current & Next Up-Dated Project Plan [U] Up-Dating A Project Dating A Stage Plans (SB1) Business Case (SB3) Project Plan Exception Plan Reporting Stage End (SB6) (SB5) Project Approach Up-Dating The Risk Log (IP6) (Project File) (SB4) Project Quality Plan Next Stage Plan [R] Reporting Stage End (IP6) (Project File) (SB5) or Exception Plan [R] 232
  • 233. Ken Bradley’s Understanding PRINCE 2 SB3 – Up- Up-Dated Project Business Case [U] Reporting Stage End Dating A Plan (SB2) (SB5) Project Business Exception Plan or Case Next Stage Plan (SB2) Risk Log [R] Reporting Stage End Risk Log (SB4) SB5) Issue Log (SB4) SB4 – Up- Project Plan (SB2) Risk Log [U] Up-Dating A Project Dating The Business Case (SB3) Risk Log Next Stage Plan (SB2) Accepting A Work Package (MP1) Exception Plan (SB2) Issue Log [U] Up-Dating A Project Business Case (SB3) Issue Log CS4 (Quality File) SB5 – Project Plan (SB2) End Stage Report [C] Authorising A Stage or Reporting Exception Plan (DP3) Stage End Current Stage Plan (SB2) Request for Authorisation To Authorising A Stage or Next Stage Plan or Proceed [C] Exception Plan (DP3) Exception Plan (SB2) Next Stage Plan [R] Authorising A Stage or Exception Plan (DP3) Business Case (SB3) Exception Plan [R] Authorising A Stage or Issue & Risk Logs Exception Plan (DP3) (SB3) Quality Log (CS5) Risk Log [R] Authorising A Stage or (Quality File) Exception Plan (DP3) Communication Plan (IP4) (Project Communications to interested Corporate or File) parties [C] Programme Management Product Status Account [C] De-Commissioning A Project (CP1) SB6 – Exception Report Exception Plan [C] Up-Dating A Project Producing (CS8) Plan (SB2) An Exception Stage Plan (CS8) Authorising A Stage or Plan Exception Plan (DP3) Exception Plan Request (DP4) Figure 109: Summary of the “Managing Stage Boundaries (SB)” Process 233
  • 235. Ken Bradley’s Understanding PRINCE 2 Chapter 18 UNDERSTANDING THE CLOSING A PROJECT PROCESS 235
  • 237. Ken Bradley’s Understanding PRINCE 2 Closing A Project (CP) - Introduction At its conclusion, the project must be closed down in an orderly and firm manner. The end of a project may arise when all the planned work has been completed and the Products/Deliverables finished and signed off as meeting their stated Quality Criteria. Alternatively a project might be brought to a premature conclusion because of changes to requirement, removal of resources or unacceptable slippage of time, effort or costs. Giving ad hoc Premature Direction Close Project Files DP4 Project Closure Notification Notification of approaching Operational and De- Project End Maintenance commissioning Reviewing Acceptance Product Status a Project Stage Status CP1 Customer Acceptance Account Confirming CS5 Project Follow-on Action Closure Recommendations Identifying Lessons Learned Post-Project Follow-on Reporting Report Review Plan Actions Stage End CP2 SB5 Issue, Risk and Lessons Learned Quality Logs Report Project Evaluation PID End Project Report Review CP3 DP5 Figure 110: Closing A Project (CP) Process Most of the work involved in this major Process is concerned with preparation of information for the Project Board in order for it to make the decision to close the project, or not. Rather like Project Initiation and Stage Initiation, this Process provides a decision- support structure; it aims to: ♦ ensure that the Objectives for the project have been met; ♦ confirm that the Customer is Satisfied with the outcome; 237
  • 238. Ken Bradley’s Understanding PRINCE 2 ♦ obtain Formal Acceptance of the project Products/Deliverables; ♦ confirm that all Products/Deliverables have been handed over to the Customer, and that these have been accepted; ♦ ensure that where Ongoing Support, enhancement and maintenance is appropriate (and required), suitable provision has been made; ♦ identify any recommendations for Follow-on Actions and document; ♦ Capture “Lessons Learned” and publish these in a suitable report for the Project Board; ♦ Prepare an “End Project Report” for sign-off by the Project Board; ♦ Notify the Customer/Sponsor/Host Organisation, as appropriate, of the Intention to Close the project, disband the project organisation and release the resources. Obviously, it will be difficult to close down a project in an orderly manner if the expectations and criteria for completion and close-down have not been agreed at the outset and this will normally have been done and the final Acceptance Criteria included within the Project Initiation Document. Project staff and managers should be provided with as much notice as possible in order for them to plan their return to normal operations. Thanks to those who have contributed to the project are also in order! 238
  • 239. Ken Bradley’s Understanding PRINCE 2 CP1 - Decommissioning A Project The main aim of this Process is to bring the project to an orderly close, ensuring that the Customer is happy with the outcome and demonstrates this by providing a Customer Acceptance sign-off. Assurance that the outcome can be supported and that a proper audit trail exists for the project documentation, should it be needed in the future, must also be forthcoming. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP1 – De- Premature Close Project Closure Notification [C] Confirming Project Commissio (DP4) Closure (DP5) ning A Project Notification of Project End (CS5) Operational & Maintenance Confirming Project Acceptance [C] Closure (DP5) Product Status Account (CS5) Customer Acceptance [C] Confirming Project Closure (DP5) Issue Log (SB5) PID (IP6) (Project Draft communication to interested Confirming Project File) parties [C] Closure (DP5) Communication Project Files [R] Archives Plan (IP6) (Project File) Figure 111: CP1 Plus Inputs and Outputs Key features of CP1 are: ♦ Checking that all Project issues have been dealt with; ♦ Checking that all Products have been completed, documented and handed over; ♦ Confirmation that the Customer’s Specification has been addressed; ♦ Confirmation that the outcome can be supported, operationally; ♦ Archive of all project documentation (mainly for audit purposes); 239
  • 240. Ken Bradley’s Understanding PRINCE 2 ♦ Notify all concerned that the project is coming to a conclusion and resources will be returned. This Process is primarily the responsibility of the Project Manager in that it marks the conclusion of the work performed over what will often be a considerable period of time. There will be a need for close contact between the Project Manager and Project Board members to ensure there are “no surprises” at the final meeting to close the project formally. 240
  • 241. Ken Bradley’s Understanding PRINCE 2 CP2 - Identifying Follow-on Actions Essentially picking up any loose ends that remain at the conclusion of the project. In particular any outstanding changes in requirements, raised as Project Issues, which were not actioned for fear of prejudicing a contractual situation or because time and budget did not allow the changes to be introduced. There might also have been some general technical improvements that would benefit the project’s outcome that the Supplier wishes to bring to the Customer’s attention. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP2 - Business Case Post-Project Review Plan [C] Confirming Project Identifying (SB5) Closure (DP5) Follow-On Actions Risk Log (SB5) Follow-On Action Confirming Project Issue Log (SB5) Recommendations [C] Closure (DP5) Figure112: CP2 Plus Inputs and Outputs A major output from this Process is the Post-Project Review Plan which will be used to set up a future project to review whether the Business Benefits identified at the outset (and reviewed and updated at each formal review) of the project, have been achieved. This will usually take place between 6-12 months after the project has been formally closed. The follow-on Actions Recommendations will provide the basis for Project Mandates for any future projects which may arise from the recommendations made. 241
  • 242. Ken Bradley’s Understanding PRINCE 2 CP3 – Project Evaluation Review The lessons learned during the project must be captured as it progresses and disseminated to those in the host organisation that would benefit from it at the conclusion of the project. There is also a need to compare what was intended to be achieved by the project against what was actually achieved. This review addresses the project and its outcome rather than the outcome itself (which will the subject of a Post-Project Review (see CP2). PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP3 - Lessons Learned Lessons learned Report [U] Confirming Project Project Report (SB5) Closure (DP5) Evaluation Review Risk Log (SB5) Quality Log (SB5) Issue Log (SB5) End-Project Report [C] Confirming Project Closure (DP5) PID (IP6) (Project File) Figure 113: CP3 Plus Inputs and Outputs The Lessons Learned Report (Log) is a prime input to this Process, along with the various Logs needed to provide a comprehensive view of the performance of the project. The outputs are: ♦ An assessment of the project against its targets; ♦ An examination of the records to establish how well the Project Management and Quality Management Standards performed and to what extent they supported the project; ♦ Identify any lessons learned and to recommend changes to the existing standards. The Project Manager has responsibility to produce these analyses and present them to the Project Board 242
  • 243. Ken Bradley’s Understanding PRINCE 2 Summary of the Closing A Project Process Closing A Project provides the “housework” tasks for properly shutting down a project. Authority for closure can only be given by the Project Board. The Process is essential for an orderly and effective shut-down of the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED CP1 – De- Premature Close Project Closure Notification [C] Confirming Project Commissio (DP4) Closure (DP5) ning A Project Notification of Project End (CS5) Operational & Maintenance Confirming Project Acceptance [C] Closure (DP5) Product Status Account (CS5) Customer Acceptance [C] Confirming Project Closure (DP5) Issue Log (SB5) PID (IP6) (Project Draft communication to interested Confirming Project File) parties [C] Closure (DP5) Communication Project Files [R] Archives Plan (IP6) (Project File) CP2 - Business Case Post-Project Review Plan [C] Confirming Project Identifying (SB5) Closure (DP5) Follow-On Actions Risk Log (SB5) Follow-On Action Confirming Project Issue Log (SB5) Recommendations [C] Closure (DP5) CP3 - Lessons Learned Lessons learned Report [U] Confirming Project Project Report (SB5) Closure (DP5) Evaluation Review Risk Log (SB5) Quality Log (SB5) Issue Log (SB5) End-Project Report [C] Confirming Project Closure (DP5) PID (IP6) (Project File) Figure 114: Summary of the Closing A Project (CP) Process 243
  • 245. Ken Bradley’s Understanding PRINCE 2 Chapter 19 UNDERSTANDING THE PLANNING PROCESS 245
  • 247. Ken Bradley’s Understanding PRINCE 2 Planning (PL) - Introduction Planning embraces PRINCE Components, Processes, and Techniques and is an on-going activity throughout the project. Understanding of the tasks involved and the possible pitfalls will emerge from planning the project and stages; control can only be exercised in as much detail as the project plan allows; and the approaches to planning, using manual or software supported techniques is a matter of preference and choice for the implementing organisation. Planning for all but the smallest projects is best tackled using a software support tool as the time saved in the longer term will more than repay the initial outlay, especially where complicated inter-dependencies exist between Products and Activities. Defining Project Product Approach Plan Flow Design Diagrams SU5 (Identifying), Defining and Identifying Designing a Analysing Activities and Plan Products Dependencies Planning PL1 PL2 PL3 Quality Product Descriptions List of IP1 Activity dependencies Activities Draft Product Checklist Planning a Estimating Project PL4 IP2 Estimate d Assessed Activities Schedule Plan Planning an Initiation Stage Completing a Analysing Scheduling SU6 Plan Risks PL7 PL6 PL5 Planning a Stage Resourc SB1 Completed Product e Plan for Risk Log Checklist availabilit approval y Producing an Authorising a Reviewing Giving ad hoc Exception Project or Plan Stage Status Direction Plan SB6 DP2 or DP3 CS5 DP4 Figure 115: Planning (PL) Process The philosophy behind the PRINCE 2 planning concepts are: ♦ Plans are constructed by identifying the final Products/Deliverables and all associated intermediate Products/Deliverables; 247
  • 248. Ken Bradley’s Understanding PRINCE 2 ♦ Products/Deliverables are defined and specified by producing associated Product Descriptions; ♦ The Activities and associated Resources are identified; all Activities must be thought through to a level consistent with the control requirements identified in the Project Initiation Document; The planning framework incorporated in PRINCE 2 is intended to cater for any type or size of project - after given due consideration to the design of the plan (content, software tool to be used, levels of planning, detail of content required etc.) the steps are: ♦ Step 1: Identify and Define what Products/Deliverables are needed; ♦ Step 2: Determine the sequence in which each Product/deliverable should be produced; ♦ Step 3: Identify the Activities needed for the creation of the Products/Deliverables; ♦ Step 4: Estimate the Resource Requirements and calculate the durations (elapsed times) where appropriate; ♦ Step 5: Schedule the Activities (usually using a software planning tool; ♦ Step 6: Schedule the Resource Requirements (usually at the same time as scheduling the Activities); ♦ Step 7: Review the Plan especially in respect of Risks and determine the need for any contingency planning; ♦ Step 8: Finalise the Plan by assembling all the information and creating a Plan Text; ♦ Step 9: Print the Plan and obtain approval from the appropriate project authority. 248
  • 249. Ken Bradley’s Understanding PRINCE 2 PL1 - Designing A Plan PRINCE 2 defines the plan as “the backbone” of every project; essentially it is not possible to control in any more detail than that planned, so the best advice is to plan in detail and then select the level of control appropriate to the risk and understanding there is for the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL1 – Project Approach Plan Design [C] Relevant Process Designing A (SU5) (Project File) Plan Project Quality Plan (IP1) (Quality File) Project Brief (SU4) (Project File) Or Project Initiation Document (IP6) (Project File) Company Planning Standards Figure 116: PL1 Plus Inputs and Outputs The Process addresses the fundamental decisions that must be made about planning before any real planning can commence. Decisions must be taken about the approach to planning and the style of presentation. The required number of levels of plan (Project-level and Stage-level plans are required in PRINCE controlled projects) and the amount of information to be included to provide the Project Board with adequate decision-support must be clearly understood. Use of software tools for estimating and planning (and possibly for preparation of analysis tools such as Product Flow Diagrams) must be considered and decisions taken. Decisions on software tools will affect the means of establishing control, especially how “actuals” are to be captured and reflected in the approved plans as the project progresses (see “Controlling A Stage (CS2)” Process). 249
  • 250. Ken Bradley’s Understanding PRINCE 2 PL2 - Identifying, Defining And Analysing Products The benefits of Product-based planning is that management and the Project Management Team can be assured that all planned activity within the project is geared towards providing known, required Products or Deliverables that will all contribute towards the final outcome. As the activities within a project always consume resources (time, effort and money) then management can be confident that no resource is being wasted on carrying out unnecessary work. This Process requires the Project Manager to identify the required Products for the Project (A Product Breakdown Structure), Define each Product in terms of a Product Description, and then analyse the relationship of Products with each other (and the outside world) by producing a Product Flow Diagram. Each of these three Product Plans is described and illustrated in the Chapter on “Understanding The Product Based Planning Component and Technique”. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL2 – Project Approach Product Breakdown Structure [C] Relevant Process (Identifying) (SU5) (Project File) Defining & Product Descriptions [C] Identifying Activities & Analysing Project Quality Plan Dependencies (PL3) Products (IP1) (Quality File) Relevant Process Product Flow Diagram [C] Identifying Activities & Dependencies (PL3) Relevant Process Draft Product Checklist [C] Completing A Plan (PL7) Figure 117 : PL2 Plus Inputs and Outputs For a Project Plan it will not always be possible (or desirable) to identify and define all the Products for the life of the project. An attempt should be made, however, to present the most comprehensive information available to the Project Board. Often this will be limited to a statement of the name and a brief description of the expected Product. Planning at Management Stage level is quite different - a firm commitment in terms of Products, Activities and Resources required must be made and a fully-featured plan created. If this 250
  • 251. Ken Bradley’s Understanding PRINCE 2 is not possible, consideration must be given to moving the Management Stage boundary forward to the point where a firm commitment can be made. The Product Checklist is a useful means of identifying Products (at Project-level and Management Stage-level), showing their planned Milestone dates and, subsequently, the achievement dates. 251
  • 252. Ken Bradley’s Understanding PRINCE 2 PL3 - Identifying Activities And Dependencies The Product Flow Diagram can be put to use to identify the Activities within the plan and to provide an indication of the likely dependencies between them. PROCESS INPUT & PRODUCTS CREATED, OUTPUT TO SOURCE UPDATED, REFERENCED OR USED PL3 – Product Flow List of Activities [C] Scheduling (PL5) Identifying Diagram (PL2) Activities & and Dependencies Product Descriptions Activity Dependencies [C] (PL2) Risk Log (Project File) Figure 118: PL3 Plus Inputs and Outputs Each connection between Products (and external entities) on the Product Flow Diagram represents one or more potential activities to be carried out to create the Product. Armed with this principle, the Project Manager or planner can derive the raw data to plan the activities of the Project, Management Stage or Team Plan. The process of deriving activities from the Product Flow Diagram is also known as “Transformation”. 252
  • 253. Ken Bradley’s Understanding PRINCE 2 PL4 - Estimating Accuracy and consistency of estimating is perhaps the single most important aspect of project management. PRINCE 2 devotes little space to how to estimate the project activities as it relies on the availability of specific approaches and techniques being available within the organisations involved in the project. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL4 – All Planning Activity Estimates [C] Scheduling (PL5) Estimating Information Figure 119: PL4 Plus Inputs and Outputs Organisations wishing to formalise their estimating methods and procedures will wish to consider Function Points Analysis Mark 2 which is a license-free estimating method, owned by CCTA and placed in the public domain to support the PRINCE and Structured Systems Analysis and Design (SSADM) Methods. The Method is suitable only for IT projects but the principles can be adapted for other types of project if required. Other methods of estimating are “Delphi” which is essentially asking experienced people (oracles) to provide the answer! This approach can be structured and formalised by obtaining a “first-cut” estimate from each individual and gradually refining the estimates through filters until the most optimistic, most pessimistic, and most likely by consensus is obtained and using the following formula to create the final estimate: 1 x Most Optimistic + 1 x Most Pessimistic + 4 x Most Likely 6 This approach may not be very scientific but has been around and used effectively for many years! 253
  • 254. Ken Bradley’s Understanding PRINCE 2 PL5 - Scheduling Scheduling requires the creation of a Programme Evaluation and Review Technique (PERT) Network and a Gantt (Timescale) Plan. This will usually be done using a Software planning tool such as MS Project®. There is no requirement in the Method to use a software tool but it will be a great timesaver in all but the smallest of projects. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL5 – List of Activities Schedule [C] Scheduling (PL6) Scheduling (PL3) Relevant Process and Activity Dependencies (PL3) Activity Estimates (PL4) Figure 120: PL5 Plus Inputs and Outputs The techniques used in this Process are fully explained in the Chapter on “Understanding The Product-Based Planning Component and Technique”. At the same time that activities are being inserted into a software support tool, the planner will be prompted to enter resource availability and estimating information. The plan created in this Process addresses both the work to be done, including start and finish dates, and the people needed to work on them; it will also provide information on bought-in resources (such as fixed- price sub-contracted work) and equipment. From the information provided, Resources Reports can be generated for the Project Management Team and the Project Board members. Where a software support tool is not being used, a separate Resource Plan will need to be produced to inform the Project Board of the commitment of resources that is being asked of them. 254
  • 255. Ken Bradley’s Understanding PRINCE 2 PL6 - Analysing Risks Before a plan can be completed the risks must be re-visited to ensure that any appropriate contingency planning has been catered for. Risks should, of course, also be addressed at the outset of planning and through every step. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL6 – All Planning Risk Log [U] Completing A Plan Analysing Information (PL7) Risks Risk Log (Project File) Assessed Plan (Schedule) [U] Completing A Plan Schedule (PL5) (PL7) Figure 121 : PL6 Plus Inputs and Outputs Each of the resources planned for should be examined and considered for potential risk and action taken to include a contingency in the plan. Risks can arise from many sources including: ♦ Quality issues; ♦ Past ability to meet deadlines; ♦ Commitment from Management and Team members; ♦ Past Sub-Contractor performance; ♦ Sources of labour and skill types; ♦ Foreseen and unforeseen external events; ♦ Other initiatives currently under way; ♦ Deadlines set for the project; ♦ Self-belief. 255
  • 256. Ken Bradley’s Understanding PRINCE 2 PL7 - Completing A Plan The plans addressed in PL2 - PL5 are largely support documents for presenting information to those responsible for decision-making (mainly the Project Board). To conclude the plans the Project Manager or Team Manager must draw all the elements together and provide a brief summary addressing all the salient points; this is known as the “Plan Text”. PROCESS INPUT & SOURCE PRODUCTS CREATED, OUTPUT TO UPDATED, REFERENCED OR USED PL7 – Assessed Plan Plan Text [C] Relevant Process and Completing (Schedule)(PL6) Approval By Project A Plan Plus Board/Project Manager Draft Product Checklist (PL2) Completed Plan For Approval [U] Product Checklist [U] Project or Stage File Figure 122: PL7 Plus Inputs and Outputs A Plan Text describing the plan in straightforward language is created and the various plans and analysis sheets appended to it. The Product Checklist (initially created in “IP2 – (Identifying), Defining And Analysing Products”) is also completed by the insertion of planned start and completion dates for each of the Products. It is in this Process that consideration should also be given to creating a “Graphical Summary of the Plan” which, although not a part of the stated PRINCE 2 plan package, is an invaluable aid to the Project Board and other members of senior management in understanding what the plan is trying to achieve. 256
  • 257. Ken Bradley’s Understanding PRINCE 2 Summary of the Planning (PL) Process Planning is uses throughout the PRINCE 2 Method. In many ways it is unhelpful to view planning as a “Process” - it is essentially a “Technique” used on a day to day basis and coming into prominence at the beginning of the project and at the end of each Management Stage. PROCESS INPUT & PRODUCTS CREATED, OUTPUT TO SOURCE UPDATED, REFERENCED OR USED PL1 – Project Approach Plan Design [C] Relevant Process Designing A (SU5) (Project Plan File) Project Quality Plan (IP1) (Quality File) Project Brief (SU4) (Project File) Or Project Initiation Document (IP6) (Project File) Company Planning Standards PL2 – Project Approach Product Breakdown Structure [C] Relevant Process (Identifying) (SU5) (Project Defining & File) Product Descriptions [C] Identifying Activities & Analysing Dependencies (PL3) Products Project Quality Plan (IP1) Relevant Process (Quality File) Product Flow Diagram [C] Identifying Activities & Dependencies (PL3) Relevant Process Draft Product Checklist [C] Completing A Plan (PL7) 257
  • 258. Ken Bradley’s Understanding PRINCE 2 PL3 – Product Flow List of Activities [C] Scheduling (PL5) Identifying Diagram (PL2) Activities & and Dependencies Product Descriptions Activity Dependencies [C] (PL2) Risk Log (Project File) PL4 – All Planning Activity Estimates [C] Scheduling (PL5) Estimating Information PL5 – List of Activities Schedule [C] Scheduling (PL6) Scheduling (PL3) Relevant Process and Activity Dependencies (PL3) Activity Estimates (PL4) PL6 – All Planning Risk Log [U] Completing A Plan Analysing Information (PL7) Risks Risk Log (Project File) Assessed Plan (Schedule) [U] Completing A Plan (PL7) Schedule (PL5) PL7 – Assessed Plan Plan Text [C] Relevant Process and Completing A (Schedule)(PL6) Approval By Project Plan Plus Board/Project Manager Draft Product Checklist (PL2) Completed Plan For Approval [U] Product Checklist [U] Project or Stage File Figure 123: Summary of the Planning (PL) Process 258
  • 259. Ken Bradley’s Understanding PRINCE 2 Chapter 20 UNDERSTANDING THE PRINCE 2 FILING TECHNIQUE 259
  • 261. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Filing Technique - Introduction PRINCE 2 suggests a suitable filing structure based on three different types of file: ♦ The Management File (Broken down into an overall Project File and a series of Stage Files) ♦ The Specialist File ♦ The Quality File Files Project File Stage File(s) Specialist File Quality File Organisation Organisation Configuration Items Product Descriptions Plans Plans Configuration Log Quality Checks Business Case Control Documents CI Locations Project Issues Risk Log Daily Log Off-Specifications Control Documents Correspondence Products Checklist Products Checklist Figure 124: Summary of the PRINCE 2 Suggested Filing Structure There is no requirement in the Method to adopt the suggested filing structure - implementing organisations are free to retain their existing standards or to modify the suggested structure to suit their own requirements. The Management File This comprises the following components: The Project File (One File for the Whole Project): ♦ The Project Organisation Structure Chart and agreed/signed-off Job Descriptions; ♦ Project-level Plans: ♦ Project-level Product Breakdown Structure; 261
  • 262. Ken Bradley’s Understanding PRINCE 2 ♦ Project-level Product Flow Diagram; ♦ Timescale Plan (Project-level Gantt Plan); ♦ Project-level PERT Network; ♦ Project Resource Report; ♦ The Business Case: ♦ Business Benefits Assessment; ♦ Risk Assessment & Proposals; ♦ Risk Log; ♦ Control Documentation: ♦ the Project Initiation Document; ♦ End Project Report ♦ The Lessons Learned Report; ♦ Products Checklist; ♦ Products Status Account; ♦ Follow-On Items; ♦ Post-Project Review Plan; ♦ Project Closure Sign-off Document 262
  • 263. Ken Bradley’s Understanding PRINCE 2 Management File - Project File * Project Mandate * Product Checklist (Project Level Products) * Project Brief * Highlight Reports * Project Organisation Structure * Exception Reports (Project) * Project Organisation Roles & Responsibilities * Project End Notification * Project Approach * Project Board Approval For Initiation * Business Case (Initial & Updates) * Project Plan (Initial & Updates) * Baselined Project Initiation Document * Risk Log * Project Filing Structure Summary * Project Board Approval For The Project * Lessons Learned Report * Project Closure Recommendation * Record of End Stage Assessments * Post Implementation Review Plan * Record of Mid Stage Assessments * End Project Report Figure125: Comprehensive View of the Project File The Management Stage Files (one file or section for each Management Stage of the Project): ♦ Management Stage Organisation Structure Chart and agreed/signed-off Job Descriptions; this will relate to the Team Members. ♦ Management Stage and any lower-level Plans: ♦ Stage-level Product Breakdown Structure; ♦ Stage-level Product Descriptions (The Master Product Descriptions will be stored in the Quality File); ♦ Stage-level Product Flow Diagram; ♦ Stage-level Timescale Plan (Gantt Plan); ♦ Stage-level PERT Network; ♦ Stage-level Resources Report; ♦ Exception Plans and associated documentation. ♦ (nb: The Stage Plans should normally be up-dated to reflect “actuals” at least once every week) ♦ Management Stage-level Control Documentation: ♦ Copies of Work Package Authorisations; 263
  • 264. Ken Bradley’s Understanding PRINCE 2 ♦ Checkpoint Reports, Highlight Reports; ♦ Exception Reports; ♦ End Stage Assessment and Mid Stage Assessment records and formal Project Board sign-offs. ♦ Products Checklist for the Management Stage Products; ♦ Daily Log recording events, problems questions, informal discussions with Project Board members and other senior managers and resultant actions impacting on the Management Stage. ♦ Correspondence - management correspondence and other papers relevant to the Management Stage. 264
  • 265. Ken Bradley’s Understanding PRINCE 2 Management File - Stage File * Stage Organisation Structure * Work Package Authorisation (Contract) * Stage Organisation Roles & Responsibilities * Checkpoint Reports * Exception Reports (Stage Level) * Current Stage Plan * Product Checklist (Stage Level Products) * Project Board Approval For The Stage * End Stage Report * Daily Log * Correspondence Figure 126: Comprehensive View of the Stage File The Specialist File (One File for the whole Project): ♦ The Configuration Items for the project and the Configuration History (changes, version etc); log-out and in information. Correspondence relating to a specific Configuration Item will be associated with the item it addresses. ♦ Physical Location of each Configuration Item. ♦ A copy of the relevant Product Description for each Specialist Product may be included for completeness. (The Master Product Descriptions will be stored in the Quality File); ♦ Specialist General Correspondence especially where a number of Configuration Items are referred to. Specialist File * Configuration Items * Location of Configuration Items * Log of Configuration Items * Off Specifications For Configuration Items * Correspondence Relating To Specialist Products Figure 127: Comprehensive View of the Specialist File 265
  • 266. Ken Bradley’s Understanding PRINCE 2 The Quality File (One File for the Whole Project): • The Master Product Descriptions; • Quality Control Documentation • Selection Criteria for Quality Reviewers; • Invitations to Quality Reviews; • Error/Observations Lists; • Follow-up Actions List; • Reviewers’ Sign-offs for each Configuration Item will be stored either here or in the Specialist File, associated with the relevant product. • Project Issues; • Project issues Log. Quality File * Master Product Descriptions * Project Issues * Project Quality Plan - Issue Log * Stage Quality Plan * Quality Review Documentation - Project Issues - Invitations - Requests For Change * Quality Log - Error Lists - Off-Specifications - Follow-up Actions - Sign-offs/Results * Project Quality Plan Figure 128: Comprehensive View of the Quality File Physical Filing Considerations The files themselves may take on a variety of guises from a consolidated four-post binder for a small project to a whole room of filing cupboards for a major initiative. The Method has no views on the physical implementation of filing arrangements. It will often be sensible to establish an electronic filing structure to help standardise the filing arrangements within the implementing organisation. 266
  • 267. Ken Bradley’s Understanding PRINCE 2 Chapter 21 UNDERSTANDING THE QUALITY REVIEW TECHNIQUE 267
  • 269. Ken Bradley’s Understanding PRINCE 2 PRINCE 2 Quality Review Technique - Introduction In PRINCE projects, quality is controlled through a number of quality management procedures and techniques. Used correctly, in appropriate circumstances and in conjunction with Product Descriptions (see the Product-Based Planning Technique), the Quality Review is one of the most powerful of the techniques used within the Method. Quality within PRINCE 2 is embedded within each of the Components, Processes and Techniques; it is not perceived as something separate that can be applied after a Product or Deliverable has been produced, or even at isolated points during the product cycle. Quality Assurance and Quality Control It is well worth viewing the concepts of Quality Assurance and Quality Control as different, but mutually supportive, Quality Assurance will normally be present in the form of a published and defined Quality Management System, often implemented against the BS/EN/ISO9001 standard. A Quality Management System (QMS) provides the all important backdrop to managing quality throughout the whole organisation and provides an environment of confidence for staff and customers alike. This confidence manifests itself in a considered, professional approach to all tasks undertaken by all personnel - ensuring that the primary objective of the control functions - the Quality Review Technique, for example - is to confirm that all project deliverables meet their stated Quality Criteria (contained within the appropriate Product Description) rather than to identify perceived deficiencies and mistakes. Some organisations may find they are at odds with this approach, having spent many years using quality control techniques to pick up faults and planning re-work of deliverables as an inevitable outcome of the quality checks. But it does not have to be like this - given a sensibly written set of quality procedures, published in the form of a Quality Management System, reflecting the principles of BS/EN/ISO9001 and regularly audited by internal and external auditors, any organisation can enjoy a quality environment, where “getting it right first time” is the watchword for all staff. What is a Quality Review? PRINCE 2 describes a Quality Review as “an involved partnership designed to ensure a Product’s completeness and adherence to standards by a review procedure”. In essence a Quality Review is a review of a Product with the emphasis on checking for errors and omissions, and non-compliance with the stated Quality Criteria. The PRINCE 2 Quality Review has a clear and defined structure which when followed will produce the required results. 269
  • 270. Ken Bradley’s Understanding PRINCE 2 Quality Reviews - Formal and Informal Quality Reviews can be either formal, for example a scheduled meeting, or informal. The selection of the type of quality control is the responsibility of the Project Manager, endorsed by the Project Board at the Project Initiation or End Stage Assessment meetings. The Project Manager will consider the relative importance of each project deliverable in reaching a final decision on whether to recommend a formal or informal Quality Review but whatever the decision, the objective is the same - to confirm that the product or deliverable under review conforms to its stated and agreed Quality Criteria. An informal Quality Review may take many forms. A simple test or visual inspection to check out the Product may be both sensible and acceptable. A "desk-check" may be carried out. This might be performed by the author's line manager, or could be carried out by an expert Reviewer either within or outside the project, site or organisation. In many cases a physical test of the deliverable will be the obvious way to assure compliance with the Quality Criteria. In all circumstances, the documentation must be produced to record the review and to provide the essential “audit trail”. People Involved Those involved in the Quality Review process are: ♦ The Producer: who is usually the creator/ author of the Product being reviewed. ♦ The Review Chair: who may be the Producer’s line manager, the Project Manager, or any other competent person with authority (or perceived authority). ♦ The Reviewers: who must be competent to assess the Product from their particular specialist viewpoints. ♦ The Scribe: who will take notes of the agreed actions arising from the review. ♦ Project Support: providing administrative support for the Quality Review technique; this will typically include arranging the venue, sending out invitations and providing the scribe role, taking note of the follow-up actions during the meeting. ♦ Project Assurance and Quality Assurance: assuring the effective use of the Quality Management System and the techniques associated with it, and monitoring appropriate use of organisational, industry and ethical standards on behalf of the Project Board and senior managers. 270
  • 271. Ken Bradley’s Understanding PRINCE 2 The Quality Review Steps Detailed procedures for carrying out a Quality Review will normally be specified by the organisation’s own Quality Management System, but where such a system is not published, the following arrangements will be found to work successfully. Step 1 - Preparation The objective of this step is to examine the Product or Deliverable under review against its Product Description and to create a list of queries, possible errors, and topics that warrant re-examination. ♦ The Chair will check with the Producer that the product will be ready on time and ensure that the team of Reviewers is agreed and that they will all be available. ♦ An invitation to the Quality Review, indicating the Product, time and place for the review is sent with copies of the Product and the Product Description. Any specific Standards used in the production of the Product would normally be available to all project personnel - if not a copy of the relevant Standard used to produce the deliverable should be attached. This should dispatched between one and five days before the review. ♦ Each Reviewer will study the product and supporting documents (including the Quality Criteria included in the Product Description), and will complete a Quality Review Error List. ♦ The QR Error List will, wherever possible, be sent to the Producer before the review. Product Description Finished Product Reviewers of the Product Producer of the Product Error Lists Figure 129: Formal Quality Review Step 1 271
  • 272. Ken Bradley’s Understanding PRINCE 2 Step 2 - The Review Meeting The objective of the Quality Review is to agree a list of queries, observations and errors in the Product. The Chair and the Producer do not have to reconcile these errors at the meeting - it is sufficient for the QR Chairman and Reviewers to agree that a particular area needs re-examination. Provided that the point and follow-up action is logged, the Reviewers have an opportunity to confirm that action has been taken, after the review meeting. The procedure for the PRINCE Quality Review step is: ♦ The Quality Review Chair opens the meeting and introduces those present if necessary. The meeting Objectives and Timing (a maximum of 2 hours is recommended) is announced. ♦ The Chair asks each Reviewer for comments. The purpose of this is to identify the main areas for discussion that the review must focus upon. It also affords an opportunity for an overall reaction to the total Product and to consider premature closure of the meeting if appropriate. ♦ The Producer then "Walks-through" the Product in detail. This may be sentence-by-sentence or page-by-page and will be determined by the Reviewers' QR Error Lists already sent to the Producer, and by their general comments made earlier. ♦ The QR Chair controls the discussion during the Walk-through ensuring that no arguments or solutions are discussed (other than obvious and immediately accepted solutions!). Follow-up Actions are noted on the QR Follow-Up Action List by either the Scribe or Project Support. No minutes need be taken of the review. Reviewers’ comments are always related to the Quality Criteria contained in the Product Description - these are the measures used by all involved to determine the acceptability, or otherwise, of the Product under review. ♦ At the conclusion of the walk-through, the Chair summarises the Follow-up actions and determines responsibility for sign-off of specific points if required. The initials of the Reviewer who will sign-off any specific point is recorded on the QR Follow-Up Action Sheet. ♦ The Chair, after seeking the Reviewers' and Producers' opinions, will decide on the outcome of the review. A QR Result Notification will be completed and a copy of the Follow-Up Action List attached. These forms will be sent to Project Support (or the Project Manager) and/or Team Manager for the plans to be up-dated. ♦ The Reviewers' Error Lists, copies of the Product (typically containing the Reviewer's annotations) and any other relevant documentation is collected by the Chair and passed to the Producer to assist in the Follow-up. 272
  • 273. Ken Bradley’s Understanding PRINCE 2 Error Lists Quality Reviewed Product Follow-Up Actions Sign-off Chair-person Quality Review Meeting Figure 130: Formal Quality Review Step 2 Step 3 - Follow-up of Review Meeting The objective of the Follow-up step is to ensure that all items identified on the QR Follow-Up Action List are dealt with and signed off. ♦ The Producer takes the list away from the review and evaluates, discusses, and corrects, if necessary, all the items on the list. ♦ When an error has been fixed, the Producer will obtain sign-off from whoever is nominated on the QR Follow-Up Action List. This person may be the Reviewer who raised the query initially, or may be another Reviewer, the Project Manager, Team Manager, or the Quality Review Chair. ♦ When all errors have been reconciled and sign-off obtained, the Quality Review Chair will raise a QR Review Result Notification confirming that the Product is "Complete" and will attach the signed QR Follow-Up Action List. The documents will be sent to Project Support (or the Project Manager or Team Manager) to up-date plans. 273
  • 274. Ken Bradley’s Understanding PRINCE 2 Product Description Finished Product Reviewers of the Product Producer of the Product Error Lists Quality Reviewed Product Follow-Up Actions Sign-off Chair-person Quality Review Meeting Figure 131: Formal Quality Review Step 3 Summary of the Quality Review Technique The Quality Review technique is a structured way of running a meeting to ensure that all aspects are properly covered. It needs to be used with common-sense (to avoid the dangers of an over-bureaucratic approach) but with an intent to follow the procedures laid down (to ensure nothing is missed). If an organisation already uses existing effective standards for quality reviewing products, it will not be necessary to change these to reflect the PRINCE 2 Quality Review procedures. PRINCE 2 emphasises the need to ensure that all Products pass through a quality control process (as laid down in the Product Description); this ensures that only "reviewed - correct - products" are regarded as being complete. The PRINCE 2 Manual contains a fairly detailed step-by-step summary of the Quality Review Technique which should be consulted and modified to suit the required procedure within the implementing organisation. 274
  • 275. Ken Bradley’s Understanding PRINCE 2 Chapter 22 Ken Bradley’s Understanding PRINCE 2 Index 275
  • 277. Ken Bradley’s Understanding PRINCE 2 Index Configuration · 26, 31, 40, 43, 52, 53, 65, 74, 125, 129, 130, 131, 135, 136, 202, 218, A 265, 266 Configuration Librarian · 135 Acceptance Criteria · 155, 164, 202, 238 Configuration Management · 40, 43, 52, 74, Accepting A Work Package · 144, 217 129, 130 Accountability · 33, 36, 61, 74 Confirming Project Closure · 144, 155, 189 Activities · 77, 81, 82, 88, 89, 130 Context Diagram · 145, 146 Activity · 38, 77, 91 Control · 17, 25, 26, 34, 39, 42, 43, 44, 45, Actuals · 29, 200, 204, 218, 249, 263 51, 57, 61, 62, 64, 72, 74, 77, 84, 89, 90, Analysing Risks · 145, 255 94, 96, 124, 129, 130, 135, 136, 137, 182, Appointing A Project Management Team · 216, 224, 247, 248, 269, 270 144 Controlling A Stage · 29, 30, 31, 125, 141, Assembling A Project Initiation Document · 144, 157, 197, 210, 212, 218, 249 144 Controls · 44, 50, 52, 94 Assessing Progress · 144, 200, 204, 218 Critical Path · 19, 81 Authorised Work Package · 91, 124, 125 Customer’s Quality Expectations · 165 Authorising A Project · 108, 144, 184 Authorising A Work Package · 144, 199, 209 Authorising Initiation · 144, 154, 183 D decision points · 27, 181 B Decision-support · 224, 237 Decommissioning A Project · 144, 155, 164, Baseline · 44, 96, 164 239 Benefits · 25, 26, 44, 45, 58, 61, 88, 89, 96, Defining Project Approach · 144 163, 224 Deliverables · 25, 26, 27, 36, 38, 39, 40, 47, Benefits Statement · 88 60, 102, 146, 223, 237, 238, 247, 248 boundary · 27, 70, 71 Delivering A Work Package · 144, 219 BS/EN/ISO9000 · 42, 60, 123, 269 Dependencies · 27, 247 BS/EN/ISO9001 · 42, 123 Designing A Plan · 145, 249 BS6079 · 42, 123 Designing A Project Management Team · 144 Business Benefits · 29, 49, 50, 88, 108, 113, Directing A Project · 29, 30, 31, 58, 141, 135, 168, 227, 241, 262 144, 157, 177, 181, 191, 193 Business Case · 26, 45, 88, 89, 96 Business Case · 60, 87, 88, 113, 154, 163, 223, 224, 262 E Earned Value · 86, 87, 90 C End-Stage Assessment · 43, 64 Enhancement · 17, 19 CCTA · 2, 3, 17, 19, 20, 21, 53, 113, 253 ESA · 45, 64, 96, 264 Change Controls · 52 Escalating Project Issues · 203 Checkpoint · 264 Estimating · 38, 65, 249, 253, 254 Closing A Project · 29, 30, 31, 47, 102, 141, Estimating · 38, 145, 253 144, 187, 189, 237, 242 Evaluating A Project · 144, 242 CMM · 52, 129, 130 Exception · 38, 182, 224, 263, 264 Communication · 25, 57, 67, 68, 69 Exception Plan · 44, 45, 98, 144, 182, 185, Completed Work Packages · 125 186, 187, 208, 231 Completing A Plan · 145, 256 Exception Report · 44, 45, 98, 186, 187, 203, Components · 17 208, 231 Components · 28, 30, 31, 32, 54, 143, 247, Executing A Work Package · 144, 218 269 Executive · 30, 34, 59, 61, 71, 74, 89, 144, Concurrent Engineering · 72, 73 152, 153, 156, 183 277
  • 278. Ken Bradley’s Understanding PRINCE 2 External Assurance · 36, 60, 61 94, 96, 99, 102, 113, 123, 130, 135, 141, 145, 146, 176, 182, 197, 216, 264, 269 Management Products · 64, 65, 78 F Management Stage · 26, 29, 30, 38, 42, 45, 47, 48, 49, 50, 62, 80, 86, 89, 90, 98, 100, Feasibility · 88 102, 104, 108, 109, 110, 124, 125, 141, Feasibility Study · 88 155, 157, 163, 166, 167, 168, 174, 184, Filing · 32, 53, 65, 129, 171, 172, 261, 266 185, 186, 197, 198, 199, 200, 201, 203, Follow-on Actions · 48, 102, 144, 238, 241 204, 205, 208, 209, 217, 218, 220, 225, Formal Quality Review · 51, 65, 271, 273, 226, 227, 228, 229, 230, 231, 250, 251, 274 252, 257, 263, 264 Management Stages · 26, 28, 30, 31, 32, 35, 48, 49, 64, 103, 104, 107, 108, 109, 110, G 164, 169, 232 Managing Product Delivery · 29, 30, 31, 91, Gantt · 40, 41, 42, 43, 77, 82, 83, 84, 90, 91, 107, 125, 141, 157, 200, 215, 220 124, 262, 263 Managing Stage Boundaries · 29, 30, 31, Giving Ad-Hoc Direction · 144, 188 108, 115, 141, 157, 166, 167, 168, 174, Government Departments · 17 184, 186, 199, 223, 232, 233 Graphical Summary · 85, 86, 87, 90, 256 Manuals · 59 Mid Stage Assessment · 45, 98, 169, 186, H 231, 264 Milestone · 87, 251 Highlight Report · 62, 63, 68, 69, 182, 264 Highlight Reports · 30, 48, 73, 102, 188 O Hints and Tips · 33, 146 Objectives · 44, 94, 237 I Off-Specification · 135, 136, 137, 202 Operation · 18, 131 Identifying Activities And Dependencies · Organisation · 26, 32, 33, 34, 35, 36, 37, 39, 145, 252 44, 48, 51, 57, 58, 59, 60, 65, 67, 68, 69, Identifying, Defining And Analysing Products 70, 71, 72, 74, 76, 88, 96, 102, 114, 116, · 145, 250 124, 125, 135, 141, 146, 165, 170, 181, Initiating A Project · 27, 29, 30, 31, 42, 44, 197, 199, 200, 209, 217, 218, 224, 238, 47, 50, 96, 102, 108, 124, 125, 141, 157, 242, 247, 266, 269, 270, 271, 274 158, 163, 164, 166, 173, 175, 176, 184 Organisation · 17, 20, 25, 33, 238, 261, 263 Internal Assurance · 36, 60, 61 Ownership · 58 Issues · 52, 129, 136, 137, 198, 266 Issues Log · 48, 102, 202, 203, 204 P L PERT · 40, 81, 82, 90, 254, 262, 263 PID · 44, 50, 96, 115, 155, 157, 163, 164, Lessons learned · 242 173, 174, 177, 182, 183, 184 Lessons Learned · 47, 102, 224, 238, 242, Plan · 26, 38, 40, 41, 42, 43, 44, 61, 62, 71, 262 72, 76, 77, 83, 85, 87, 89, 90, 94, 182, 198, Lessons Learned Report · 47, 102, 262 224, 238, 247 Levels of plan · 249 Plan Description · 87, 89, 90 Lifecycle · 18 Plan Text · 89, 90, 248, 256 Planning · 19, 20, 27, 30, 31, 35, 38, 39, 40, 41, 42, 43, 44, 50, 53, 62, 65, 72, 74, 76, M 77, 78, 83, 84, 88, 89, 94, 108, 109, 110, 124, 125, 151, 153, 157, 164, 165, 166, Maintenance · 17 200, 228, 247, 248, 249, 250, 255, 257, management · 17, 19, 20, 25, 26, 27, 32, 33, 269 34, 35, 37, 38, 39, 42, 44, 45, 46, 47, 57, Planning · 17, 19, 25, 29, 30, 31, 32, 38, 40, 62, 64, 65, 67, 68, 69, 70, 72, 74, 81, 88, 41, 42, 43, 50, 76, 124, 141, 144, 145, 157, 278
  • 279. Ken Bradley’s Understanding PRINCE 2 165, 166, 174, 187, 225, 247, 250, 254, 60, 61, 62, 63, 64, 65, 67, 68, 70, 71, 72, 257, 258, 269 73, 74, 82, 83, 84, 85, 86, 87, 89, 90, 94, Planning A Project · 141 96, 98, 99, 100, 102, 103, 107, 108, 110, Planning An Initiation Stage · 144 113, 114, 124, 131, 136, 141, 144, 146, Planning levels · 76 151, 152, 153, 154, 156, 157, 164, 166, Plans · 76, 77, 89, 91 167, 168, 169, 171, 174, 175, 176, 177, Post Project Review · 29, 30, 177, 189, 241, 181, 182, 183, 184, 185, 186, 187, 188, 242 189, 190, 197, 198, 199, 200, 201, 203, Preparing A Project Brief · 144 204, 205, 206, 207, 208, 216, 217, 223, PRINCE · 15, 17, 19, 20, 25, 26, 27, 28, 32, 224, 225, 226, 227, 228, 229, 230, 231, 33, 34, 36, 37, 38, 39, 40, 42, 44, 47, 51, 237, 238, 240, 242, 243, 249, 250, 254, 52, 53, 54, 57, 58, 59, 60, 61, 63, 64, 65, 256, 264, 270 67, 69, 71, 72, 74, 76, 77, 79, 89, 90, 91, Project Brief · 31, 124, 152, 154, 155, 156, 94, 102, 113, 123, 129, 130, 135, 136, 137, 165, 168, 171 141, 145, 146, 216, 247, 261, 269, 272, Project Closure · 47, 102, 181, 182 274 Project Files · 64 PRINCE 2 · 1, 14, 20, 21, 26, 27, 28, 29, 30, Project Initiation · 19, 43, 44, 53, 61, 87, 94, 31, 32, 34, 36, 37, 38, 41, 42, 43, 47, 48, 96, 113, 163, 164, 182, 237, 238, 248, 262, 49, 50, 53, 54, 57, 58, 61, 64, 65, 66, 69, 270 72, 74, 76, 77, 79, 84, 85, 86, 87, 91, 99, Project Issue Report · 129, 135, 136 103, 107, 108, 109, 110, 123, 124, 129, Project issues · 239, 266 137, 139, 141, 142, 143, 145, 146, 151, Project Issues · 32, 48, 102, 129, 135, 136, 152, 153, 155, 158, 164, 165, 166, 168, 137, 144, 200, 202, 203, 208, 241 169, 170, 171, 172, 173, 174, 177, 202, Project Management Team · 29, 30, 58, 74, 210, 220, 227, 228, 231, 232, 248, 249, 78, 151, 152, 153, 166, 171, 174, 175, 198, 253, 256, 257, 259, 261, 269, 274 202, 207, 225, 228, 230, 250, 254 PRINCE Environment · 20, 53 Project Manager · 19, 29, 30, 32, 35, 36, 37, Process Models · 145, 146 39, 43, 45, 47, 48, 49, 50, 52, 53, 61, 62, Process-based · 33 63, 64, 68, 69, 70, 71, 72, 73, 74, 78, 83, Processes · 26, 27, 57, 125, 130, 141, 157 87, 88, 91, 98, 100, 102, 104, 107, 109, Processes · 26, 27, 28, 29, 30, 31, 32, 35, 44, 110, 113, 117, 124, 125, 131, 135, 136, 54, 65, 96, 141, 143, 144, 145, 146, 157, 141, 144, 146, 152, 153, 166, 169, 170, 163, 166, 181, 188, 247, 269 174, 181, 182, 184, 186, 188, 190, 197, Product Breakdown Structure · 40, 78, 80, 198, 199, 200, 201, 203, 204, 207, 208, 90, 261, 263 210, 215, 216, 217, 218, 224, 225, 226, Product Description · 32, 40, 42, 50, 51, 63, 230, 231, 240, 242, 250, 252, 256, 270, 78, 79, 80, 124, 125, 165, 217, 250, 265, 272, 273 269, 271, 272, 274 Project Mandate · 88, 151 Product Flow Diagram · 32, 40, 80, 81, 90, Project plans · 26, 71, 85 250, 252, 262, 263 Project Support · 36, 37, 53, 60, 61, 63, 64, Product Flow Diagrams · 249 65, 69, 71, 72, 74, 131, 135, 137, 270, 272, Products · 20, 26, 34, 35, 38, 40, 43, 49, 50, 273 52, 61, 62, 80, 125, 129, 131, 135, 186, PROMPT · 17, 18, 19, 20 274 Public Domain · 25 Products · 25, 26, 27, 36, 38, 39, 40, 43, 47, 52, 59, 60, 63, 64, 65, 72, 74, 77, 78, 80, 81, 84, 86, 90, 91, 102, 124, 129, 130, 131, Q 135, 146, 197, 215, 216, 223, 237, 238, 247, 248, 262, 264. See Outputs QMS · See Quality Management System Programme · 57, 62, 69, 70, 71, 72, 81 Quality · 17, 19, 26, 36, 38, 40, 42, 50, 51, Programme of work · 48, 103 60, 61, 63, 65, 70, 73, 78, 79, 87, 90, 102, Project Approach · 152, 156, 171 125, 135, 197, 215, 216, 223, 237, 261, Project Assurance · 35, 36, 60, 61, 64, 68, 263, 265, 266, 269, 270, 271, 272, 274 70, 73, 74, 137, 225, 270 Quality assurance · 17, 274 Project Assurance Team · 270 Quality criteria · 35, 43, 50, 51 Project Board · 30, 31, 32, 33, 34, 35, 36, 37, Quality Criteria · 31, 32, 51, 124, 125, 165, 39, 41, 43, 44, 45, 46, 47, 48, 50, 58, 59, 217, 230, 269, 270 279
  • 280. Ken Bradley’s Understanding PRINCE 2 Quality Management · 19, 26, 42, 50, 73, SPOCE · 113 119, 120, 123, 124, 125, 165, 242, 269, Stage · 18, 26, 27, 36, 38, 39, 40, 42, 43, 44, 270, 271 45, 46, 47, 50, 61, 62, 63, 77, 84, 85, 86, Quality Management System · 42, 73, 125, 89, 90, 96, 99, 102, 125, 137, 164, 223, 269, 270, 271 224, 264 Quality Review Technique · 32, 124, 269, Stage Manager · 83, 136 274 Stages · 18, 26, 27, 33, 64, 72, 89, 181, 224, Quality Reviews · 90, 266, 270 247 Stages · 18, 31, 35, 48, 49, 64, 103, 104, 107, 109, 223, 230 R Starting A Project · 44, 96, 141, 151 Starting Up A Project (SU) · 124 Rapid Application Development · 72, 73 Strategic Planning · 17 Receiving A Completed Work Package · 144, Supplier · 34, 57, 58, 59, 65, 67, 69, 71, 215, 209 216 Refining The Business Case and Risks · 144 System Development · 17 Reporting Highlights · 144, 205 Reporting Stage End · 144, 229 Request for Change · 135, 136, 137 T Request For Change · 136, 202 Resource · 17, 82, 83, 84, 85, 90 Taking Corrective Action · 144, 205, 207 Resource Plan · 40, 42, 84, 85, 90, 254 Team Leader · 36 Resources · 82, 83 Team Manager · 35, 36, 62, 63, 64, 69, 72, Resources Report · 41, 42, 85, 263 74, 78, 83, 136 responsibilities · 26, 33, 36, 58, 62, 63, 64 Team Managers · 35, 61, 62, 64, 72, 74 Review · 136, 271, 272, 273 Team Plan · 91, 252 Reviewing Stage Status · 144, 200, 204, 205, Teams · 36, 37 207 Technical · 18, 31, 35, 47, 48, 49, 61, 64, 84, Risk · 31, 36, 41, 43, 62, 69, 72, 87, 88, 89, 90, 99, 103, 104, 107, 109, 130, 271 110, 113, 114, 115, 117, 163, 168, 169, Techniques · 26, 33, 38, 39, 57, 65, 113, 125, 183, 206, 223, 228, 231, 249, 255 129, 143, 247, 253, 254, 269, 270 Risk Assessment · 65, 87, 88, 113, 115, 262 Techniques · 28, 32, 38, 51, 54, 129, 143, Risk Factor · 115, 117, 120 145, 247 Risks · 26, 27, 44, 45, 83, 87, 89, 90, 96, 113, Terms of Reference · 44, 94, 154 163, 224 Tolerance · 30, 43, 46, 47, 99, 100, 169, 182, Risks · 29, 49, 50, 60, 168, 248, 255 186, 198, 203, 204, 207, 208, 224, 231 Role descriptions · 58 Transformation · 252 Roles · 33, 34, 36, 58, 59, 61 U S UK Government · 17, 20 Scheduling · 145, 254 Updating A Project Business Case · 144, 227 Scoping Diagram · 27 Updating A Project Plan · 144, 226 Senior User · 59, 71, 136 Updating The Risk Log · 144, 227, 228 Setting Up Project Controls · 144, 169 User · 20, 34, 89, 135, 137 Setting Up Project Files · 144 User/Customer Group · 71 Significant deviation · 45, 98, 186 Smaller projects · 59 Software · 20, 65, 72, 76, 77, 83, 84, 90, 247 W Software support tool · 41, 78, 254 Software tools · 249 Walk-through · 51, 272 specialist · 25, 33, 34, 35, 36, 38, 39, 58, 59, Work Package · 263 62, 64, 65, 67, 69, 90, 91, 109, 130, 135, Work Packages · 109, 125, 197, 199, 209, 216, 270 218 Specialist Stages · 64 280