Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication...
Transcript of Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication...
![Page 1: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/1.jpg)
Ken Bradley’s
Understanding PRINCE 2
PRINCE is a Registered Trademark of CCTA
![Page 2: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/2.jpg)
Ken Bradley’s Understanding PRINCE 2
2
ISBN 1 902192 00 1
Published by:
SPOCE Project Management LimitedHomelife HouseOxford RoadBournemouth, DorsetBH8 8EZ
Telephone & Fax: 01202-780740Switchboard: 01202-319987E-Mail: [email protected]: www.spoce.com
PRINCE is a Registered Trademark of CCTA
© Ken Bradley 1997
First Published October 1997Revised and reprinted February 1999
All rights reserved by the copyright holder and the licensee. No part of this publication may bereproduced in any material form (including photocopying and/or storage in any medium byelectronic means and whether or not transiently or incidentally to some other use of thispublication) without the written permission of the copyright holder identified above, except inaccordance with the provisions of the Copyright Designs and Patents Act 1988. Applications forthe copyright holder’s written permission to reproduce any part of this publication should beaddressed to the publisher at the address above.
![Page 3: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/3.jpg)
Ken Bradley’s Understanding PRINCE 2
3
Dedication
This book is dedicated to the many clients and friends who over the past twodecades have put their trust and key projects into my hands, often for just the firstfew critical weeks of life and sometimes for support from cradle to grave. Thanksalso go to the “SPOCETTES” Carol and Livia who have used their charm andcharisma to ensure that this project was delivered on time, to the agreed plan andonly marginally over budget!
Ken Bradley
What Others Say About This Book
“An excellent companion to the CCTA PRINCE 2 Reference Manual. The manyclear diagrams and supporting text answer the questions What should I do now? –and Why?”
Martin ShepherdICL HR Consultancy
“This book provides a comprehensive and practical exposition of the PRINCE 2Method and truly lives up to its title. Ken Bradley’s practical experience ofmanaging projects, together with his understanding of the needs of ProjectManagers, whether new to the profession or old hands, gleaned from many yearsof providing consultancy and training is evident through the techniques and bestpractice tips that abound in this publication.”
Dave Rose, Principal ConsultantProject ManagementDevon IT Services
![Page 4: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/4.jpg)
![Page 5: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/5.jpg)
Ken Bradley’s Understanding PRINCE 2
5
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
![Page 6: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/6.jpg)
Ken Bradley’s Understanding PRINCE 2
6
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
![Page 7: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/7.jpg)
Ken Bradley’s Understanding PRINCE 2
7
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
![Page 8: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/8.jpg)
Ken Bradley’s Understanding PRINCE 2
8
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
![Page 9: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/9.jpg)
Ken Bradley’s Understanding PRINCE 2
9
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
![Page 10: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/10.jpg)
Ken Bradley’s Understanding PRINCE 2
10
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
![Page 11: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/11.jpg)
Ken Bradley’s Understanding PRINCE 2
11
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
![Page 12: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/12.jpg)
Ken Bradley’s Understanding PRINCE 2
12
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
![Page 13: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/13.jpg)
Ken Bradley’s Understanding PRINCE 2
13
FOREWORD
This publication is based on the PRINCE 2 Project Management Methodology. It hasbeen produced to help anybody involved in a PRINCE 2 controlled project to understandthe approaches used in the Method.
This re-print incorporates the additional material included in the new manual – “ManagingSuccessful 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 thiscertain assumptions have been made and these are based upon my own experience andunderstanding of the practical use of PRINCE.
I hope you will not only find this publication of practical use in managing your projectsbut will also enjoy reading and learning from it. If you have any questions or observationsabout the content of this publication, please contact me at SPOCE Project ManagementLimited direct at (UK +44) 01202-780740 (Telephone & fax) or E-Mail [email protected]
Ken BradleyFebruary 1999
Who This Publication Is Intended For
PRINCE 2 is the UK Government standard for managing large projects and has beenwidely adopted as the standard for project management for all types of projects within theprivate 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 toorganise, plan and control an undertaking using a structured project managementapproach.
Although primarily a summary and interpretation of the PRINCE 2 project managementmethod, this publication provides an excellent start point for anyone wishing to understandthe principles and use of structured project management in any activity. It is also aninvaluable aid for anyone wishing to take the CCTA/APMG PRINCE 2 examinations.
![Page 14: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/14.jpg)
![Page 15: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/15.jpg)
Ken Bradley’s Understanding PRINCE 2
15
UNDERSTANDING THEBACKGROUND
TO THE PRINCE METHODOLOGY
Chapter 1
![Page 16: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/16.jpg)
![Page 17: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/17.jpg)
Ken Bradley’s Understanding PRINCE 2
17
Origins of the PRINCE 2 Method
The PRINCE Methodology is a development of the PROMPT Methodology (ProjectResource Organisation Management Planning Technique) originally formulated in the mid1970s. A private sector company, Simpact Systems Limited, evolved the PROMPTMethodology to provide a suitable framework within which to manage the strategy,feasibility study, development and support of Information Technology systems through astructured 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 projectmanagement method to improve the management and control of government IT projects.Many different methods were proposed and evaluated, and the contract to license the useof the Method was awarded to Simpact Systems Limited.
CCTA (Central Computer and Telecommunications Agency) acting for the UKGovernment commissioned some changes in the basic methodology. Chief amongst thesewas the incorporation of the quality assurance aspects into the PROMPT II Methodologyto provide a product that was to become referred to as “Government PROMPT”.Although CCTA licensed all the PROMPT Methodology, PROMPT II was the onlyelement fully implemented.
The belief was that Government Departments were already well supported in theproduction of strategic plans, and that maintenance and enhancement aspects would beeasily handled providing development systems were properly supported by developmentand quality assurance documentation. PROMPT II was therefore considered to be the keyingredient for success. Government PROMPT, incorporating PROMPT II principles onlywas introduced into the major UK Government Departments in Spring 1983.
![Page 18: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/18.jpg)
Ken Bradley’s Understanding PRINCE 2
18
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 someproblems with its view that IT projects broke down into standard stages of workaddressing Initiation, Specification, Design, Development, Installation, and Operation.Many projects did not conform to this formula and inconsistencies were encountered.
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 aseries of Stage Managers, each responsible for a pre-defined stage within the standard sixstage lifecycle.
The philosophy was that this left the way open to appoint the most appropriate individualto manage each Stage of the project. The Specification Stage managed by aUser/Customer, the Design Stage by a Designer/Analyst, the Development Stage by aTechnical Programmer and the Installation and Operation Stages by User/Customers.
The Initiation Stage was typically managed by someone with sufficient technical expertiseto understand and plan the whole of the project.
Initiation Specification Design Development Installation Operation
The PROMPT II “Planning” Stages The PROMPT II “Action” Stages
![Page 19: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/19.jpg)
Ken Bradley’s Understanding PRINCE 2
19
Figure 2: The PROMPT Organisation Structure
PROMPT Planning
The Government PROMPT Methodology also made no mention or use of Critical PathAnalysis, which was used extensively in major projects. In practice these omissions didnot cause real problems as training courses and consultancy support filled the gaps.However the methodology was perceived as being not quite complete, or indeed, relevantto many projects.
The Enhancement Project and PRINCE
During 1987, CCTA determined to update the Methodology by reflecting the actual usageof PROMPT II and by introducing modern project management ideas. These elementswere 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 towork with the PROMPT User Group and CCTA to incorporate the changes.
Senior Management - Strategic Direction
The Project Board
Senior User Senior Technical Executive
Project Assurance Team
* Business Assurance Co-ordinator* Technical Assurance Co-ordinator
* User Assurance Co-ordinator
Stage 3 ManagerDesign
Stage 1 ManagerInitiation
Stage 5 ManagerInstallation
Project Resources & Development Teams
Stage 4 ManagerDevelopment
Stage 2 ManagerSpecification
Stage 6 ManagerOperation
Assurance
Work Direction Administrative Support
![Page 20: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/20.jpg)
Ken Bradley’s Understanding PRINCE 2
20
CCTA were keen to place the enhanced method into the public domain, as an openmethod, in order to enable suppliers of major IT systems (and their component parts) toadhere to consistent standards when fulfilling UK Government contracts.
The overall objective was to provide a high-level of consistency throughout governmentprojects and to improve project management generally.
Meanwhile, LBMS (Learmonth & Burchett Management Systems) a major managementconsultancy company, who had developed SSADM (Structured Systems Analysis andDesign Methodology) under a CCTA contract, had acquired the PROMPT products andname from Simpact Systems (which had ceased its commercial operations) and waslicensing the methodology successfully to the public and private sectors.
LBMS obviously could not agree to an enhanced version of PROMPT II being placed inthe public domain in direct competition with their own proprietary method, andnegotiations provided that the enhanced method be re-named PRINCE (Projects inControlled Environments) to meet this point.
PRINCE was introduced in April 1989 with full documentation and formal entry into thepublic domain in January 1990. The PRINCE Methodology is now the UK GovernmentStandard for managing major projects. It has been widely adopted by private sectorcompanies both for use in government projects, and in many cases for their own internaluse. CCTA, with its collaborative partners (The Association for Project ManagementGroup, IBM UK Limited, and The Stationery Office) continues to pursue the acceptanceof 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 extensiveconsultation 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 ofprojects (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) topromote PRINCE. One of the partners, IBM (UK) Limited, has developed a softwaresupport product based on their existing Process Integrator application, which provides afull 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 thathas to be created, updated, tracked and managed during the life of a project.
With PRINCE 2, CCTA has launched an accreditation and certification scheme providinga vehicle for assuring users of PRINCE 2 that training and consultancy providers areregistered as competent and that training courses reflect a common syllabus withexaminations and certification at its conclusion.
![Page 21: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/21.jpg)
Ken Bradley’s Understanding PRINCE 2
21
CCTA continue to support and develop the PRINCE 2 Method and a contribution is leviedfrom all those taking the APM Group Professional Examinations and registering as trainedPRINCE 2 Practitioners.
Future plans include companion volumes covering the “softer” aspects of projectmanagement (leadership, delegation, appraisal etc) and Programme Management, RiskManagement, including examinations on these topics.
Further information can be obtained from CCTA Information Services on telephone:
(UK +44) (0)1603 704787
![Page 22: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/22.jpg)
![Page 23: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/23.jpg)
Ken Bradley’s Understanding PRINCE 2
23
Chapter 2
UNDERSTANDING THE BASICS
![Page 24: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/24.jpg)
![Page 25: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/25.jpg)
Ken Bradley’s Understanding PRINCE 2
25
Introduction to PRINCE 2
PRINCE (PRojects IN Controlled Environments) is a structured method for effectivemanagement of any size or type of project. It is the standard method for use in UKGovernment Departments and is widely used in the private sector, NHS and LocalGovernment. A growing number of overseas Governments and multi-national companieshave adopted the method, or integrated it within their existing project managementapproaches. 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 structuredapproach to project management; among the benefits of using PRINCE 2 are that it:
♦ identifies management, technical (specialist) and quality Products or Deliverables andhelps 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, Planningand 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 undermanagement 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 andstrengthening of the method.
![Page 26: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/26.jpg)
Ken Bradley’s Understanding PRINCE 2
26
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 managementenvironment; ♦ 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 controlthe project and bring it to a successful conclusion. A PRINCE 2 project is divided into a number of Management Stages, each forming adistinct unit for management purposes. Like the project, a Stage is driven by a series ofProcesses, 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 qualitystandards, 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, theproject business case, all encompassed within a Quality Management framework, makeup 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 filedseparately. The PRINCE 2 framework provides the flexibility to set stage boundaries which areappropriate to the needs of the project. Management Stage boundaries are chosenaccording to:
![Page 27: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/27.jpg)
Ken Bradley’s Understanding PRINCE 2
27
♦ 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 theeventual outcome. Thus the stage boundaries are normally defined to correspond to thecompletion of the major Products to be built and key decisions concerning commitment ofresources that need to be made. Whatever the nature of the project, it is advisable todefine one or more planning and/or definition processes in the early part of the project'slife. 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 isproduced. The project is triggered by a “Project Mandate” which might take any formfrom 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. Theoutputs from one project may be used as input by another project. There may be otherdependencies 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 otherprojects. A high-level context diagram is a useful mechanism for defining theserelationships.
Figure 3: Scoping Diagram showing Inputs and Outputs for the Project The Scoping Diagram illustrated above is particularly useful when planning and managinga Programme of Work where individual projects inter-relate with each other and it isnecessary to ensure that expected outputs from individual projects are anticipated andplanned for. When all individual project Context Diagrams are assembled to complete the
The Project UnderDevelopment
Bullet List of the Main Functionsto be produced, developed or bought-in
Key User Groups
Central LogisticsProject
Business Processes Cleaned Data
Parts Requisitions
Current System
MIS Project
Information
![Page 28: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/28.jpg)
Ken Bradley’s Understanding PRINCE 2
28
programme “jigsaw” it will be apparent which outputs and inputs do not match, andappropriate 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 followingmodel showing the key elements should be studied:
Figure 4: Summary Model of the PRINCE 2 Method The PRINCE 2 methodology applies three key elements to each project and to theManagement Stages within a project. These are summarised in the above Model anddescribed, briefly, in the following tables. The three elements are the Processes whichdrive the project management, Components and Techniques, which are used by each of theProcesses to effect the management of the project.
PROCESSESTECHNIQUES COMPONENTS* Starting Up A Project (SU)
* Initiating A Project (IP)
* Directing A Project (DP)
* Controlling A Stage (CS)
* Managing Product Delivery (MP)
* Managing Stage Boundaries (SB)
* Closing A Project (CP)
* Planning (PL)
* Product-Based Planning - Product Breakdown - Product Description - Product Flow Diagram
* Quality Reviews - Preparation, Review, Follow-up
* Change Control - Capture, Logging, Assessment, Decision
* Project Filing Structure - Management File - Specialist File - Quality File
+ Existing Organisation Techniques already used within the host organisation
* Organisation - Structure & Role Descriptions
* Planning - Products, Activities, Resources
* Controls - Management, Team, Quality
* Stages - Management & Technical Stages
* Management of Risk - Risk Assessment & Management
* Quality in a Project Environment - Quality Requirements & Response
* Configuration Management - Tracking Products & Documentation
* Change Control - Capture & Assessment
PRINCE 2 SOFTWARE SUPPORT ENVIRONMENTEXPERIENCE, BEST PRACTICE, COMMONSENSE
ORGANISATION STANDARDS & APPROACHES; BUSINESS STANDARDS & ETHICSQUALITY MANAGEMENT SYSTEM (QMS) (ISO9001)
THE BUSINESS CASE * Business Benefits
RISK MANAGEMENT * Risk Analysis & Actions
* Risk Management
![Page 29: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/29.jpg)
Ken Bradley’s Understanding PRINCE 2
29
The PRINCE 2 Processes
DESCRIPTION
REF
EXPLANATION
Starting Up A Project SU Establishes the Objectives and Approach to theProject; Set up the Project Management Team;Plans for the Initiation Process. This is a pre-project Process, which looks to answer thequestion “do we have a worthwhile and viableproject?” before asking for commitment ofresources to set up a project environment.
Initiating A Project IP Plans the whole Project in terms of its Products,Activities, Resource Usage and Quality; Setsthe baseline for the Business Benefits & Risks.
Directing A Project DP Provides Authorisation for work to be carriedout and Resources to be committed.Authorisation for Project Initiation and ProjectClosure and, in some cases, its prematuretermination. The Process is “owned” by theProject Board – the ultimate authority for theProject - accountable for its overall success.
Controlling A Stage CS The basic day-to-day project managementProcess - authorising work to create or changeProducts (or Deliverables), collecting andreflecting “actuals”, assessing progress andreporting to senior management. Capturingproposed changes and errors and escalatingthese, where appropriate to management.
Managing Product Delivery MP The main “workshop” for the project where themajority of resources are consumed. ThisProcess is where the Products of the Project arecreated. Progress reports (Checkpoint Reports)are provided to the Project Manager. QualityReview and Delivery of Products occurs here.
Managing Stage Boundaries SB Reporting on the achievements of the CurrentManagement Stage and the impact on theoverall Project Plan and Business Case.Planning the Next Stage (Products, Activities,Resource Usage). Putting together ExceptionPlans when the Management Stage has suffereda significant departure from its approved plan.
Closing A Project CP Preparation for closing the Project in an orderlyway. Customer sign-off, preparation of an End-Project Report and identification of LessonsLearned 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 andits creation.
![Page 30: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/30.jpg)
Ken Bradley’s Understanding PRINCE 2
30
The PRINCE 2 Components:
DESCRIPTION
USEDBY
EXPLANATION
Organisation SU SB
Organisation Structure + Role Descriptions.Predominantly used in the “Starting Up AProject” Process where the Executive andProject Manager are appointed in the firstProcess, and the Project Management Team isdesigned and appointed. The ProjectManagement Team is reviewed at the end of eachManagement Stage within “Managing StageBoundaries”.
Planning SU IP CS MP SB CP PL DP
All Processes use the Planning Component. TheInitiation of the project is planned during“Starting Up A Project”; the project itself isplanned in “Initiating A Project”; Stage plansare prepared in “Managing Stage Boundaries”;and Product planning is carried out in“Controlling A Stage” and “Managing ProductDelivery”. Follow-on actions, includingpreparation of a Post-Project Review Plan are puttogether in “Closing A Project”. “Directing AProject” uses the approved plans throughout toconfirm the required progress.
Controls
SU IP CS MP SB CP PL DP
All the Processes use the Controls Component.The “control” Processes which make particularuse of this Component are “Initiating A Project”(which sets up the overall project controlstructure); “Controlling A Stage” (which usesCheckpoint Reports to capture progress, andrecords actual usage of resources. HighlightReports are used to inform the Project Board ofprogress); “Managing Product Delivery”generates Checkpoint Reports for controlpurposes. Stage approval is handled by“Managing Stage Boundaries” whereManagement Stages are approved via End StageAssessments. This Process also uses ExceptionReporting and Planning to control significantdepartures from plan. “Directing A Project” isthe Process within which overall authorisationsare made; this Process uses the key controls ofEnd Stage Assessment, Tolerance, ProjectInitiation and Project Closure.
![Page 31: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/31.jpg)
Ken Bradley’s Understanding PRINCE 2
31
The PRINCE 2 Components (Continued)
Stages
IP SB CS DP
Management Stages provide the key control forthe Project Board and are mainly used by“Directing A Project” when authorisingcommitment for expenditure. Technical Stagesoften overlap and run in parallel; ManagementStages may not. The key control Processes useManagement Stages in planning and control ofthe project.
Management of Risk SU IP SB DP
Risk Analysis is carried out initially in “StartingUp A Project” when the Project Brief is created.This is refined in “Initiating A Project” wherethe Business Case for the project is established.The Risk Analysis is updated during “ManagingStage Boundaries” to provide the basis fordecision support for the Project Board when theyreview the project at the End Stage Assessmentin “Directing A Project”. No specific riskanalysis tools or techniques are recommended. Management of risk has close ties with theBusiness Benefits which are measured andpresented as the Business case for the project.Both the Business Case and the Risk Analysisare up-dated, minimally, at the end of eachManagement Stage.
Quality In A ProjectEnvironment
SU IP CS MP PL
The Customer’s Quality Expectations are firstidentified in “Starting Up A Project” and qualityaspects are planned in “Initiating A Project”.When the project is approved, “Controlling AStage” and “Managing Product Delivery”enable specific Quality Criteria to be set for eachProduct or Deliverable via Product Descriptionsdescribed in the “Planning” Process.
ConfigurationManagement
IP CS MP CP
Configuration Management addresses the propersafeguarding and management of Products orDeliverables and their associated documentation.“Initiating A Project” sets up the Project Filesand “Controlling A Stage” and “ManagingProduct Delivery” executes the ConfigurationManagement arrangements. Project Files arearchived in “Closing A Project” mainly for auditpurposes.
Change Control CS Managing proposals for change is an importantaspect of project management and the Process“Controlling A Stage” is where such proposalsare captured.
![Page 32: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/32.jpg)
Ken Bradley’s Understanding PRINCE 2
32
The PRINCE 2 Techniques
DESCRIPTION
EXPLANATION
Product-Based Planning A “Product Breakdown Structure” which identifies theProducts or Deliverables to be produced during the project.A “Product Description” for each Product identified in theProduct Breakdown Structure, which defines and specifieseach Product; a key feature of the Product Description is theQuality 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 thateach Product has with others and external entities; theProduct Flow Diagram must “balance” with the ProductBreakdown Structure.
Quality Review Technique Used for measuring a Product or Deliverable against itspublished Quality Criteria. PRINCE 2 recognises InformalQuality Reviews (typically “Desk Checks”, Tests or Visualinspections) and Formal Quality Reviews (which are morestructured “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 changesrequired by the customer or anyone else who has an interestin the project’s outcome. All suggested changes, identifiederrors and departures from the agreed Specification must becaptured as “Project Issues, logged, analysed for technical,customer and business impact, and a decision made onwhether 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 seriesof Stage Files - one for each of the Management Stages ofthe project. A Specialist File housing the documentationrelating to the technical aspects of the project and a QualityFile housing the Quality Review documentation and theProject 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 ina PRINCE 2 compliant project. Exactly how the Processes are addressed within anyproject is the responsibility of the organisation’s senior management, represented by theProject Board, and the Project Manager, but the method requires that each of the eightProcesses is reflected within the project one way or another. All the Processes link to Components and Techniques some of which are described within
![Page 33: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/33.jpg)
Ken Bradley’s Understanding PRINCE 2
33
the method. It is anticipated that most organisations will already be using some specificTechniques and might wish to incorporate additional Components reflecting their businessenvironment and culture. PRINCE encourages this where they provide value to themanagement 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 downeach 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 mostdifferentiates 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 termsof identifying how to meet the requirements of any given Process. In most organisationsalready operating successful project management systems there will be little need to makechanges to the way they are operating, provided effective project management proceduresare already in place.
The Organisation Component
The organisation and effective use of people assigned to manage a project needs to beconsidered from the view point both of the specialist skills they bring to the project andtheir individual personalities. Responsibilities need to be defined within a team structure to ensure that management isboth efficient and responsive, and that individuals understand exactly what is expected ofthem. Within PRINCE 2, responsibilities are defined in terms of roles, rather thanindividual’s jobs. Assignment of roles to individuals is a decision for each Project Boardto take in the light of organisational circumstances, and the same individual may beassigned 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.
![Page 34: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/34.jpg)
Ken Bradley’s Understanding PRINCE 2
34
Corporate or Programme Management
The Project Board
Senior User Senior Supplier Executive
Project Assurance
Project Manager Project Support
Team ManagerTeam 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 theultimate authority for the project and is normally appointed by Corporate or ProgrammeManagement to take overall responsibility and control of a PRINCE 2 project. The ProjectBoard consists of three senior management roles, each representing major project interests. ♦ Executive: appointed by Corporate/Programme Management to provide overallproject guidance and assessment throughout. The Executive represents the interests of theCustomer and the Business and has overall responsibility for the project. ♦ Senior User: representing users (and, where appropriate, Customers) of the outcomeor the major products from the project. ♦ Senior Supplier: representing areas which have responsibility for providing thespecialist “know-how” and/or committing Supplier resources for the solution. The SeniorSupplier might be drawn from an external, commercial, organisation or from internalsources responsible for delivering the specialist “End Product” to the customer (or amixture of both).
![Page 35: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/35.jpg)
Ken Bradley’s Understanding PRINCE 2
35
There is a requirement within the Method to have a Project Board function and this cannotbe eliminated or delegated (although the terminology may be changed to suit theorganisation’s culture, for example “The Project Authority”). The Project Board’saccountability for Project Assurance cannot be delegated although the day-to-day work ofProject Assurance can if Project Board members do not have the time or expertise to carryout the tasks involved.
The Project Manager
A Project Manager will always be appointed to assume day-to-day responsibility forplanning and management of the project throughout all its Management Stages. TheProject 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 theproject, on-time, within budget, meeting the specialist/technical and quality criteria agreedwith the Project Board. As with the Project Board, the role of Project Manager is a required role within theMethodology and cannot be shared, delegated or eliminated.
The Team Manager
In a large or complex project, one or more Team Managers may be assigned theresponsibility for ensuring that the products of one or more particular Technical, orSpecialist, Stages of work are planned, controlled and produced on schedule, to thedefined and agreed quality standards, and within budget.
Figure 6: Project Manager and Team Manager Relationships The Team Manager role is optional and will only be present in large projects or where theProject Manager lacks the specialist skills to plan and control specific parts of the project.
Project Manager Project Support
Team ManagerTeam Manager Team Manager
Project Resources & Teams
![Page 36: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/36.jpg)
Ken Bradley’s Understanding PRINCE 2
36
Project Resources and (Specialist) Teams
The Project and/or Team Manager have responsibility for Teams of specialist staff, taskedto carry out the activities and produce the Products of the stage. The team organisation,responsibility definitions and the allocation of these responsibilities to individuals willdepend upon the size and nature of the project and the skill mix available. PRINCE 2recognises 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 today Project Assurance to others within the organisation. However, accountability forProject 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.
Figure 7: Project Board and Project Assurance Functions Although not specifically separated out in the PRINCE 2 Method, Project Assurance canbe found in two distinct forms: ♦ External Assurance to confirm that the project is following overall and corporatestandards (eg the published Quality Management System, or particular accountingconventions) and the organisation can be expected to have an audit function already inplace to check these aspects. ♦ Internal Assurance to verify that the project is delivering Products or Deliverablesthat meet the agreed Quality Criteria and that internal project standards are beingfollowed. Internal Assurance is ultimately the responsibility of the Project Board.
The Project Board
Senior User Senior Supplier Executive
Project Assurance
User Assurance Specialist Assurance Business Assurance
![Page 37: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/37.jpg)
Ken Bradley’s Understanding PRINCE 2
37
Project Support
Within PRINCE 2, Project Support, on a formal basis, will only exist where there is aperceived need for it. A Project Manager may well find that the Project Board see noscope for any administrative support, and that any day-to-day assistance might need to beon an “ad-hoc” basis.
Figure 8: Project Manager and Project Support Relationships
Where a project does warrant the appointment of a Project Support function, theindividual(s) selected will report directly to the Project Manager. Incidental support forthe Team Managers, where appointed, and Team resources will normally form part ofProject Support’s responsibilities.
The Project Support Office
A Project Support Office might well evolve in a Programme or multi-projectenvironment, to support a number of individual projects. The methodology supports thepossibility of a transition from several Project Support individuals to a central ProjectSupport Office where the number of projects under development warrants it. The resultantProject Support Office will be able to provide a centre of expertise for all projectmanagement aspects within the organisation/site, effectively delivering an internalconsultancy service where required by Project Board members, Project Managers andproject team members.
Summary of The Organisation Component
In the final analysis, it is the people who are responsible for the management of theproject and the creation of its deliverables who have its success in their hands. Cleardefinition of responsibilities and a tenacious commitment to achieving agreed goals willalways be the predominant factor in success.
The PRINCE 2 Method must always be tuned to suit the implementing organisation’sexisting standards, business approaches, culture and people; the latter two are arguablythe most important.
Project Manager Project Support
![Page 38: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/38.jpg)
Ken Bradley’s Understanding PRINCE 2
38
PRINCE 2 Planning
Estimating, planning and re-planning are constant and key activities when managing anyproject. PRINCE 2 provides a structure for preparing and maintaining plans at appropriatelevels throughout the life of a project. Plans are prepared for the Project as a whole, foreach stage within the project and, optionally, for the teams’ work within eachManagement Stage. There is also an Exception Reporting and Planning process to handledivergences from the original plan. The PRINCE 2 method include a Technique forProduct-Based planning incorporating Activity planning, Resource reporting and Qualityplanning.
Products or Deliverables and Related Activities
PRINCE 2 provides a set of planning techniques which give structure to the project. Thekey 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 theseproducts, and the sequencing of the work.
PRINCE makes a distinction between Management Products and Activities, SpecialistProducts and Activities, and Quality Products and Activities. This is partly because theseare usually the concern of different groups of people, but also to ensure that managementactivities are not overlooked in planning and estimating.
Figure 9: PRINCE 2 Plans Structure
PlanText
The Plan Text provides a high-level, overall view of the plan, summarising its key features
ProductBreakdownStructure
Identifying the Products/Deliverables that will be produced by the Project. The Products will be categorisedunder the headings of “Specialist”, “Management”, and“Quality” Products.
ProductDescriptions
Describing the Products/Deliverables that will be produced by the Project. There is a prescribed format for Product Descriptions
ProductFlow
Diagram
Describing the relationships that exist betweeneach Product/Deliverable, and external entities.
PERTor
ActivityNetwork
Showing the relationships that extist between the Activities that will be undertakento create the Products identified in the Product Breakdown Structure.
Ganttor
TimescalePlan
Derived from the PERT Network, this shows when Activities areplanned to start and end. Major Review points (End StageAssessments) are also shown on this plan.
![Page 39: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/39.jpg)
Ken Bradley’s Understanding PRINCE 2
39
Management activities are concerned with planning, monitoring and reporting the work ofthe project, in both normal and exceptional situations. They produce ManagementProducts in the form of plans, reports and other control documents. Management activitiesinclude the planning and control of all specialist activities on the project. Althoughinfluenced by the specialist content, a similar pattern of management tasks can beexpected to be present in any PRINCE 2 project.
Conversely, the Specialist activities undertaken by a project are determined entirely by thescope and objectives of the project. The Specialist activities describe the work needed toproduce the Specialist Products required from the project.
The Specialist Products required by the user/customer are identified and defined at thestart of the project by the Project Manager and accepted by the Project Board. AdditionalSpecialist Products may be defined by the strategy appropriate to a particular ManagementStage of the project; specialist activities may also be prescribed by an organisation’s ownparticular technical strategy. PRINCE 2 therefore acknowledges the need for flexibility inthe selection and definition of Specialist activities and the corresponding Products.
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 theProduct under review. Individuals within the project and host organisation as well aspeople external to the organisation are all appropriate. Quality activities must be plannedfor early in the life of the project.
The PRINCE 2 Product planning techniques require every project to be described and
Completed Feasibility Study
Specialist Products
FS 01 - Business reviewFS02 - Problem DefinitionFS03 - Options Identified & AgreedFS04 - Options AppraisedFS05 - Selected Option AgreedFS06 - Final Report
Quality Products
QP01 - Product DescriptionsQP02 - Quality Review DocumentationQP03 - Project Issues LogQP04 - Quality LogQP05 - Configuration Management
Management Products
MP01 - Project Initiation DocumentMP02 - Stage PlansMP03 - Lessons Learned LogMP04 - Risk LogMP05 - Business CaseMP06 - Product ChecklistMP07 - Highlight ReportsMP08 - Project Start NotificationMP09 - Project End NotificationMP10 - Project Filing Structure
The Project ManagementStandard for the
Project
The Quality ManagementStandard for the
Project
The Technical ManagementStandard for the
Project
![Page 40: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/40.jpg)
Ken Bradley’s Understanding PRINCE 2
40
defined in terms of its Products or Deliverables. This is a very effective way to ensure fullunderstanding of what is required and to ensure that, as far as possible, all resourceconsuming 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 activitiesnecessary to ensure that these Products emerge on time and to the required qualitystandards.
The project Products are identified as a first step in Product-Based Planning; definition ofeach product (via the PRINCE Product Description) allows its make-up and qualityrequirements to be documented and properly understood. A Product Breakdown Structureillustrates the hierarchical make-up of the complete set of project products and a ProductFlow Diagram provides a view of the relationship each product has with others, within andoutside of the project.
Figure 11: Product Flow Diagram (For A Feasibility Study)
The Project Timescale or Gantt Plan charts the major activities of the project. It is usuallyderived from the PERT (Programme Evaluation and Review Technique) or ActivityNetwork which shows the relationships that exist between project activities. It is used inconjunction with a Project Resources Report to monitor progress on the project as a whole.It also addresses planning requirements related to Quality Control and ConfigurationManagement. A Stage-level Gantt (or time-scale) Plan shows the products, activities andquality controls for each stage of the project. The Stage-level Gantt Plan is produced andapproved at the end of the previous stage (the plan for the first stage is prepared with theproject plan).
FS01
Business Review
FS02
Problem Definition
FS03
Options Identified& Agreed
FS04
Options Appraised
FS05
Selected Option Agreed
FS06
Final Report
Strategy PlanSolution Providers
![Page 41: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/41.jpg)
Ken Bradley’s Understanding PRINCE 2
41
Additional, lower-level Gantt Plans can be expected to exist in most projects, to give adetailed breakdown of particular major activities These are termed “Team Plans”.
InitiateSpecifyDesignBuildTestTrainHandover
ManagementStage 1
ManagementStage 3
ManagementStage 2
Figure 12: Gantt Plan (Time-scale Plan)
Lower level Plans (or Individual Work-to Lists), if required, are derived from the Stageand Team Plans to allocate detailed activities (and Products/Deliverables) to particularmembers of a Specialist Stage Team. Although this level of plan is not formally includedin PRINCE 2 they may be utilised if the size and/or complexity of the project requirestheir production.
Resource Planning & Reporting
Resource requirements are concerned with managing the funding and effort resources ofthe project. Specific resource plans are not produced for PRINCE 2 controlled projects, asthe 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 Planin 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 lowcost, short duration, low risk project) the format for a resources plan or report shown infigure 13 may be of use. Even where a software planning tool is in use, the presentation ofthe information might well benefit by adopting the format shown in figure 13 as it reflectsthe type and level of information required by the Project Board in reaching a suitablebusiness decision.
It is the decision-support information about the requested commitment of resources that isof most use to Project Board members in reaching their decision to start or continue withthe project and careful thought must be given as to the most appropriate presentation of thedata.
![Page 42: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/42.jpg)
Ken Bradley’s Understanding PRINCE 2
42
Figure 13: Typical Project Resources Report (or Plan)
The standard Resources Report drawn from any software-driven Project Plan will identifythe type, amount and cost of the resources required by the project related to eachManagement Stage of the work. It will also identify equipment, building, and fixed-pricecosts associated with the project. The intention is to provide a complete resource andfinancial picture of the undertaking.
A more detailed Resources Report, at Management Stage Level identifies the resourcesrequired by the particular stage. It defines the budget required by the stage and is used toreport actual expenditure and resource usage against plan More detailed Resource Plans atthe Team Level will be produced when required, to plan and control a particular majoractivity, 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 bedefined and agreed, and incorporated into a Product Description for each major Productidentified; a Project Quality Plan must be defined, published and adopted; QualityReview procedures must be established and staff trained; review activities must beproperly resourced. Whatever action is proposed to build quality into the project, themeasures must be consistent with any published Quality Management System (QMS) thatis already in effect.
PRINCE 2 has been designed to comply with the BS/EN/ISO9001 Quality ManagementStandard and the method contains a section relating its content to each section of the ISOStandard. 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
Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual
EFFORT (Staff Weeks)Skill Types
CustomersEngineersIT AnalystsOthers
COSTS (£K)Skill Types
CustomersEngineersIT AnalystsOthers
Equipment
Fixed Price Elements
Total Stage Costs
Total Project Costs
![Page 43: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/43.jpg)
Ken Bradley’s Understanding PRINCE 2
43
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 andresource plans at each level. Just as quality must be built into the Products, so mustquality control be built into the plans.
Figure 14: PRINCE 2 Planning Levels - Project, Stage & Team
♦ The Project Level plan (required) sets the overall quality approach for the entireproject. It defines the standards to be followed and the quality criteria for the majorproducts. It also identifies external constraints that may apply to the project, such as aspecific 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 arerequired; this decision will be endorsed by the Project Board at the Project Initiation orEnd-Stage Assessment meeting.
Tolerance and Planning
The Project Board Executive sets tolerances for Stage Plans. These define the limits oftime-scale and cost (or sometimes effort) within which the Project Manager can operatewithout further reference to the Project Board. Tolerance is variable and will be assignedto each Management Stage to reflect the respective business risk, but a general rule of
Project Plan (Mandatory Plan)
Stage PlanStage Plan Stage Plan
TeamPlan
TeamPlan
TeamPlan
TeamPlan
TeamPlan
TeamPlan
Project Resources Report(Effort, Costs, Equipment, Direct Costs)
![Page 44: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/44.jpg)
Ken Bradley’s Understanding PRINCE 2
44
thumb is that Time Tolerance of plus/minus 1 week and Cost Tolerance of plus/minus10% is about right.
An Exception Report and, subsequently, if required by the Project Board, an ExceptionPlan, is produced in situations where costs or time-scales are forecast to be exceededbeyond the tolerances set by the Project Board.
The Exception Report describes the cause of the deviation from plan and its consequencesand recommends corrective action to the Project Board. Once considered and approved bythe 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 toensure the timeliness, cost control and quality of the system or undertaking beingdeveloped. PRINCE 2 provides a support structure of Management and Product-orientedcontrols 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 theproject. These controls cover all aspects of project activity and, at the highest level, allowthe Project Board to assess project achievement and status prior to committing furtherexpenditure.
Controls are applied through measuring the progress towards production of a set ofpre-defined outputs (Products or Deliverables). The overall structure of ManagementControls 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, incorporatingagreed 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 thatthe terms of reference, objectives, plans and controls, business risks, benefits and financialreturn, organisation structure and job definitions are clearly defined, published, understoodand agreed.
This Management Product is very important to the project and is the result of twoProcesses - 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 theProject Board, is a “frozen” document used to baseline the project.
![Page 45: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/45.jpg)
Ken Bradley’s Understanding PRINCE 2
45
End Stage Assessment (ESA)
This is a required management control and occurs at the end of each stage. It typicallyconsists of a formal presentation to the Project Board of the current project status, andreviews the overall business case (benefits and risks).
The approval of the proposed plans for the next stage is also obtained. Project Boardapproval, with agreement by all the members, must be obtained before the project canproceed to the next stage.
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 ofthe project up to the next End Stage Assessment.
“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
Figure 15: Handling End Stage Assessments
Mid Stage Assessment (MSA)
This Project Board control is held only to review a significant deviation from anapproved Management Stage Plan and to approve an Exception Plan produced, at therequest of the Project Board, following an Exception Report.
An Exception Report is produced by the Project Manager to alert the Project Board assoon 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” fromthe approved plan, the impact on the Management Stage, overall Project and its BusinessCase. The plan will also recommend appropriate action to take the project to the end ofthe Stage and, where possible, recover the situation.
![Page 46: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/46.jpg)
Ken Bradley’s Understanding PRINCE 2
46
Figure 16: Handling Mid Stage Assessments
Tolerance
The measure of a “significant departure” is that the Tolerance stated by the Project Boardat 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 theProject Board to move away from the approved Management Stage Plan without needingto report the variance.
Tolerance is not time and money to be spent but should be thought of as “trigger” figureswhich help keep the Management Stage (and the Project Manager) within “tolerable”bounds.
Responsibility for Tolerance stems from the Project Board, with the Executive havingresponsibility for setting Management Stage Tolerance with the Project Manager. TheExecutive is also responsible for ensuring that an overall Tolerance is set for the project byCorporate or Programme Management and that it is suitably recorded in the Project Briefduring “Starting Up A Project (SU)”.
Tolerance should always be set in terms of both time and cost, as over-concentration onjust one aspect will imbalance the overall project resulting in an unexpected andunpredicted time or budget slippage.
Stage 1 - Planning & Definition Stage 2 - Design & Contract
Mid Stage Assessment (MSA)
“Directing A Project” Process •Consider theException Planat an unscheduled Mid Stage
Assessment.•Review the Problems with Stage1;•Review the Impact on the ProjectPlans;•Review the im[pact on the Business Case (Benefits &Risks);•Preview the revised Plans for the remainder of theStage.
•Endorse the Project & Approve continuationofthe Stage up to the next End Stage
Assessment.
“Controlling A Stage” Process •Deviation from approved Stage PlansForecast;•Exception ReportCreated - Reasons; Impact; Options;
Recommendation;•Direction from Project Board .... Create an ExceptionPlan;“Managing Stage Boundaries” Process •Produce an ExceptionPlan
![Page 47: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/47.jpg)
Ken Bradley’s Understanding PRINCE 2
47
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 onQuality, Technical Conformance, Scope, and Risk.
The level of Tolerance is decided by the Project Board and set by the Executive followingrecommendations by the Project Manager. Tolerance is most usually applied to aManagement Stage but is also be applied at Project level (set by Corporate or ProgrammeManagement) 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 aProject Board meeting. This is similar to a stage assessment but relates to the entire projectrather than a single stage. The objective is to ensure that all the projectProducts/Deliverables have been satisfactorily delivered to their stated quality standardand that the project documentation is complete.
A review of the project management standards and approaches used by the project will becarried out within the “Closing A Project (CP)” Process and a Lessons Learned Reportproduced for consideration by the Project Board. The Lessons Learned Report recordswhat has been learned from using the PRINCE 2 project management and qualitymanagement standards for the project and is created during the “Initiating A Project”
Cost
Time
Planned Delivery & Total Cost
2 4 6 8 10 12 14 16 18 Weeks
£110K
£100K
£90
£80K
£70K
£60K
£50K
£40K
£30K
£20K
£10K
Plus 10% Tolerance
Minus 10% Tolerance
Plus 1 WeekTolerance
Minus 1 WeekTolerance
o
STAGE PLAN
![Page 48: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/48.jpg)
Ken Bradley’s Understanding PRINCE 2
48
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 furtherwork which is recommended following the closure of the project. Follow-on Actions willusually 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 ofbenefits after the project’s output has been operating for a while (perhaps 9-12 monthsfollowing 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 theproject) against the approved plans via regular, time-related Highlight Reports. These areprepared by the Project Manager and are usually provided monthly, although theirfrequency will always be agreed with the Project Board.
Highlight Reports are usually sent through the post or by e-mail; the objective is toremove the need for unnecessary time-related Project Board meetings which consume theProject Board members’ valuable time, while still keeping them abreast of significantdevelopments. 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 thecurrent Management Stage. Some organisations specify that Highlight Reports should be kept to one side of A4 (or itsequivalent). Where the project is part of a Programme of work, separate Project andProgramme Highlight Reports will normally be produced.
Stages
Stages are partitions of the project with decision points at their conclusion, and sometimesduring their life. PRINCE 2 differentiates between “Management Stages” (which equate to the commitmentof resources by the Project Board and a decision to continue with the project and authorityto spend) and “Technical Stages” which comprise sets of technical activities leading to astated and required Product.
![Page 49: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/49.jpg)
Ken Bradley’s Understanding PRINCE 2
49
InitiateSpecifyDesignBuildTestTrainHandover
ManagementStage 1
ManagementStage 2
ManagementStage 3
TechnicalStages
Project Review of Management Stage atEnd Stage Assessment (ESA)
Project Initiation Project Closure
Figure 18: Management & Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned andmanaged 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 tolarger projects, the Activities will often combine to provide the Technical Stages under theimmediate control of a Team Manager. In only the most exceptional circumstances will authority be given for work to commenceon the next Management Stage before all the Products of the current Management Stage iscompleted.
Business Benefits and Risk Management
PRINCE 2 places emphasis on the Business Benefits for the project; they are describedby the Method as “…the driving force behind the project …”. The purpose of thePRINCE 2 Business Case is the identification and measurement of the Business Benefitsand the continued review of them as the project progresses through its ManagementStages. 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 productscapable of achieving the claimed and published Business Benefits (eg legislative changes,market changes, environmental issues).
![Page 50: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/50.jpg)
Ken Bradley’s Understanding PRINCE 2
50
♦ Project Risks which are concerned with the ability to deliver the project’s outcomewithin the required time and cost requirements (eg failure of third party suppliers, skillsshortages, technical problems). The Method does not specify any particular way of measuring Business Benefits orassessing Risks but whatever the chosen approach, PRINCE 2 requires the Business Caseand Risks to be updated on a regular basis - minimally at the end of each ManagementStage. This provides the Project Board with sufficient, up to date, information on which tobase their decision to continue with the project.
Planning For Quality
PRINCE 2 presumes that the project will be managed under the umbrella of a publishedQuality Management System (QMS) conformant to ISO9001. If such a QMS is notpresent the Method compensates by specifying that quality must be planned from theoutset. Planning Quality takes place in the “Initiating A Project (IP)” Process and theresultant 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 beemployed 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 closeassociation 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 astage or project. The aim is to identify and correct errors as early as possible in thedevelopment process. They will usually take the form of a formal or informal quality review, whichever isspecified in the Product Description.
![Page 51: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/51.jpg)
Ken Bradley’s Understanding PRINCE 2
51
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 allthat might be available - the selection of appropriate Techniques is left to theimplementing organisation. However, one of the most powerful Techniques is the Qualityreview which has been successfully used in a wide variety of projects for a number ofyears. The Formal Quality Review has three distinct steps: ♦ Preparation - where the Product or Deliverable is measured against the QualityCriteria contained in the Product Description, and Error Lists are created by selectedReviewers who are able to make a suitable contribution. ♦ Review - where the Product or Deliverable is “walked-through” by its Producer andan agreed list of Follow-up Actions is agreed. The Reviewers who prepared the originalError Lists attend this Review. ♦ Follow-up - where the identified faults, errors, omissions and inconsistencies in theProduct or Deliverable are fixed, agreed and signed-off.
At each Quality Review, appropriate Supplier and user/customer staff are designated toexamine 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 ProductDescription, which assures its technical integrity and its compliance with user or customerrequirements; It is thereafter an “Approved Product “subject to formal change controlprocedures. If any subsequent changes are made to Approved Products, there shouldalways be a reference back to the original Product Description to determine whether acorresponding change needs to be made. This procedure applies to informal qualityreviews (for example a test, visual inspection, or desk-check) and to formal qualityreviews where 2-3 reviewers meet with the author of the product under the chair of asuitably senior person to “walk-through” the product.
ProductDescription
•Composition•Quality Criteria•Type of Check•People Required
The Product
Quality ReviewChecking the Product againstthe Quality Criteria publishedin the Product Description
Activity (shown on the Gantt or Timescale Plan) consuming Resources (Time/Effort/Funding)
![Page 52: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/52.jpg)
Ken Bradley’s Understanding PRINCE 2
52
Change Control
Unplanned situations relating to changes to one or more Products need to be captured as“Issues” relating to the project.
* Good Ideas* Errors* Departures From Agreed Specification* Resource Changes* Specification Changes
Project Issue(Request for Changeor Off-Specification)
Originator Raises A
Sent to Project Support
Logged byProject Support
Reviewed by Project Manager
Project Issues Log
* 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.
Project Issues Log Up-dated
Notify OriginatorCopy returnedto confirm receipt
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 tocontain the impact and prevent wider divergence from plans. Issues are best handledwithin the framework of a formal Configuration Management scheme. An Issue will be raised to cover any situation which needs to be addressed within theproject 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 beraised to alert the Project Manager.
Configuration Management
A Configuration Management Method (CMM) controls the development of products byproviding a formal mechanism for labeling products, their development status, and therelationship between them. PRINCE 2 does not define or recommend a specific CMM butemphasises the need for a suitable system and clearly states that the presence of suitablearrangements for Configuration Management is not optional.
![Page 53: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/53.jpg)
Ken Bradley’s Understanding PRINCE 2
53
Configuration Management can be particularly useful in tracking back problems withdelivered, 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 backto source and appropriate action taken.
Filing Arrangements PRINCE 2 contains a recommended filing structure which implementing organisationsmay find useful as a start point. Where existing filing arrangements are in force, or whereorganisations wish to arrange things differently, this may be done without conflicting withthe Method.
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) havedeveloped a support tool called “The PRINCE 2 Environment”. This tool provides acomplete electronic support function which enables the Project Manager (or ProjectSupport) to keep track of the many project documents that are created during the life of theproject 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 PRINCE2 Environment also contains the full PRINCE documentation and “skeletons” for thecreation of the Project Initiation Document. Users can add extra options and incorporatetheir existing documentation to supplement the basic material supplied with the PRINCE 2Environment. An alternative – The Launch Pad – is available from SPOCE Project ManagementLimited, providing similar functionality to the PRINCE 2 Environment. An evaluationcopy can be downloaded from web site www.spoce.com
Project FileOrganisationPlansBusiness CaseRisk LogControl DocumentsProduct ChecklistLessons Learned Report
Files
Stage File(s)OrganisationPlansControl DocumentsDaily LogCorrespondenceProduct Checklist
Specialist FileConfiguration ItemsConfiguration LogCI LocationsOff-Specifications
Quality FileProduct DescriptionsQuality ChecksProject IssuesProject Issues LogQuality Log
![Page 54: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/54.jpg)
Ken Bradley’s Understanding PRINCE 2
54
Following This Introduction
The introduction to PRINCE 2 in this Chapter should be sufficient for the “incidentaluser” or senior manager to understand the basics of the Method. The rest of this bookprovides 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 andTechniques, the recommended starting point to understand what is going on within aPRINCE 2 project is the Components. The remaining Chapters deal with the PRINCE 2 Components, explaining theircomposition and progresses through Processes to Techniques, adding value to the basicdescriptions in the PRINCE 2 Manual.
![Page 55: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/55.jpg)
Ken Bradley’s Understanding PRINCE 2
55
UNDERSTANDING THE ORGANISATION COMPONENT
Chapter 3
![Page 56: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/56.jpg)
![Page 57: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/57.jpg)
Ken Bradley’s Understanding PRINCE 2
57
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, havethe will to make the venture successful, and understand exactly what is expected of them,then the project will have an excellent chance of success.
Figure 22: The Suggested PRINCE 2 Organisation Structure At the top of the organisation structure there will normally be a strategy body (PRINCE 2identifies this as Corporate or Programme Management) responsible for interpreting theoverall objectives of the organisation into working arrangements, systems or otheroutcomes. In private-sector organisations this body might well be the Board of Directors. The PRINCE 2 organisation model assumes a Customer:Supplier environment withinwhich the project management components, processes and techniques will operate. Thestructure assumes there will be a customer who will state and define the requirement, payfor the project and use the outcome, and a supplier who will provide the necessaryexperience, skills and know-how to create the End Product for the customer. This modelis used for all PRINCE 2 controlled projects - the supplier might be an external privatesector company or an internal division of the purchasing organisation - the approachesused are similar. The main emphasis within the PRINCE 2 organisation component isconcentration on direction, management, control and communication. The methodprovides a flexible framework which is capable of being mapped onto any organisationwith the minimum of disruption, and which provides the template to achieve the keyoutputs.
Corporate or Programme Management
The Project Board
Senior User Senior Supplier Executive
Project Assurance
Project Manager Project Support
Team ManagerTeam Manager Team Manager
Project Resources & Teams
![Page 58: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/58.jpg)
Ken Bradley’s Understanding PRINCE 2
58
Within any PRINCE project organisation, at least three interests must be represented: ♦ Business Interests - ensuring that the eventual output of the project meets (andcontinues to meet) a stated business need while at the same time representing good valuefor the time, money and other resources expended. ♦ User Interests - specifying the desired outcome and ensuring that the project actuallydelivers what is required. Essentially representing the interests of those who will use theoutcome to deliver the business benefits. ♦ Supplier(s) Interests - providing the necessary knowledge, skills, equipment andresources to produce the outcome in accordance with the specification and acceptancecriteria. 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 expectedto be placed on individuals working within the PRINCE environment. These are presentedin the form of Role Descriptions which should be used as input to discussions to secure thefinal definition of the roles and responsibilities for all members of the Project Board andthe Project Management Team. Tuning the role descriptions is best carried out in threepasses: ♦ Step 1 - Tune the role descriptions to suit the specific project (they should alreadyhave 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 doeshe/she bring to the project; ♦ Step 3 - Discuss each tuned role description with the individuals concerned andsecure their agreement and commitment to their organisational role. Following this simple three-step process will help secure the commitment of the ProjectBoard members and Project Management Team. Taking the role definitions directly fromthe PRINCE 2 manual is not recommended.
The Project Board
The Project Board is the overall authority for the project, having specific ownership forthe process “Directing A Project” and responsibility for delivering the required outcomeor 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 Boardmembers 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 Boardcomprises, as a minimum, representatives from the following three functional areas:
![Page 59: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/59.jpg)
Ken Bradley’s Understanding PRINCE 2
59
The Executive Role: Overall Responsibility: to be ultimately responsible for the project, supported by theSenior User and Senior Supplier. The Executive has to ensure that the project is delivering value for the time, effort, costsand resources being invested, confirming a cost-conscious approach to the project,balancing the demands of the Business, User and Specialist Provider Organisations. TheExecutive 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 withthe project team, the integrity of the desired outcome of the project and for monitoring thatthe 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 Productsarising from the project. The Senior User role commits User resources and monitorsProducts against the stated and agreed requirement. This role will often involve more thanone person to represent all the user interests. The User and Customer roles will sometimesbe 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 torepresent 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 theabove roles. These are split between the Specific Responsibilities and the AssuranceResponsibilities for each of the identified roles. The role definitions must be adapted tosuit the organisation, project and individual tasked with the responsibility. The three functional roles comprising the Project Board should not be interpreted as arequirement for three individuals. In smaller projects, for example, two functional rolesmay be combined in one person (although in normal circumstances it is not advisable forthe Project Board to be reduced to less than two individuals). In other circumstancesseveral individuals may take on a single functional role (eg where a number of user areasare being served by the eventual outcome of the project).
![Page 60: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/60.jpg)
Ken Bradley’s Understanding PRINCE 2
60
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 cannotbe delegated; the day to day tasks involving the assurance function may, however, bedelegated to appropriate individuals. There are two types of Project Assurance that can beexpected to be found within a project - External and Internal.
Figure 23: The Levels of Assurance ♦ External Assurance concerns itself with the assurance that the project is performingin accordance with overall standards and approaches either published or recognised insome way by the organisation. Examples might be that the project is conforming to theBS/EN/ISO9001 Quality Management Standard or following Accounting Conventions laiddown by a professional body or within legislation. Invariably some form of audit willalready be present within the organisation to verify that these standards are beingfollowed. ♦ Internal Assurance is ultimately the responsibility of the Project Board. Examples ofInternal Assurance are verifying that the Products/Deliverables output by the projectconform to their agreed Quality Criteria; that they perform in accordance with the User’sstatement of requirement; that schedule and cost budgets are being met; and that theBusiness Case (Business Benefits) and Risks remains viable.
Project Management FunctionProject Manager Project Support
Team Managers
Project Team Members- Product Creators
Project Assurance Function
Project Board Assurance Function
- Business- User- Supplier - Business
- User- Supplier
External Assurance & Audit FunctionStandards- Quality- Financial- Technical
![Page 61: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/61.jpg)
Ken Bradley’s Understanding PRINCE 2
61
Delegation of Day-to-Day Project Assurance
Although accountability for Project Assurance rests with the Project Board it might wellbe 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 Assurancefunction on their behalf. It is important to note, however, that this responsibility is onlydelegated - the Project Board retain full accountability. Delegation of the assurance function may be to any number of individuals, although thenumbers must obviously, be sensible. The selection of appropriate people for theassurance roles is also important - the assurance function must be independent of theProject Manager and it is not appropriate for any of the assurance function to be delegatedto the Project Manager or Team Manager(s). In practice, an existing Quality Manager orProject Support Office might be used to carry out either or both Internal Assurance andExternal Assurance - responsibility for getting it right rests with the Project Board (andultimately with the Executive Member).
The Project Manager
All projects need a focal point to plan, control and oversee the day to day work and toco-ordinate the total effort. The Project Manager fulfills this role. PRINCE 2 requiresthat 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 requiredstandard of quality, and within the specified constraints of time and cost. The Projectmanager is also responsible for the project producing a result which is capable ofachieving the benefits defined in the Project Initiation Document.
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 theProject Manager to plan, manage and control a specific Technical Stage. It is the
The Project Board
Senior User Senior Supplier Executive
Project Manager
User Assurance Specialist Assurance Business Assurance
Project Assurance Assurance
![Page 62: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/62.jpg)
Ken Bradley’s Understanding PRINCE 2
62
responsibility of the Project Manager to direct and co-ordinate the efforts of all TeamManagers. 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/orresources 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 theoverall 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 riskprojects. Where appointed the Team Manager is responsible for the day-to-daymanagement 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 specificspecialist team appointed to be responsible for a discrete part of the project; for examplethe supplier of key technical equipment, or a building contractor might be appointed as aTeam Manager for part of the customer’s project. In such circumstances it is quite normalthat the Team Manager is also the supplier’s Project Manager. The Team Manager worksto the defined and agreed plans for the stage products and activities and reports to theProject Manager. Team Managers may also be appointed where the project is large and the Project Managerrequires some experienced support at the management level. Also where there arepressing geographical reasons, a Team Manager might well be nominated to implement aparticular part of the solution within a geographic region.
![Page 63: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/63.jpg)
Ken Bradley’s Understanding PRINCE 2
63
The options described above are not exhaustive and Project Managers and their respectiveProject Boards should use imagination and creativity to determine where and when tomake the best use of this PRINCE 2 role.
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 anappropriate quality (ie conforming to the Product’s Quality Criteria agreed within theProduct Description), in a time-scale and at a cost acceptable to the Project Manager andthe Project Board. The Team Manager reports to and takes direction from the Project Manager. The TeamManager will work with the Project Manager to define responsibilities for the teammembers and provide plans, guidance, motivation and inspiration. All suggested changesrelating to the Products which are the responsibility of the Team Manager, raisedinformally or as Project Issues will be routed through the Team Manager forrecommendation or decision on further action. The Team Manager will work closely with his/her teams, providing advice and guidanceand taking decisions. The Team Manager will attend (and usually run) Checkpoints andraise Checkpoint Reports for the Project Manager at the frequency agreed in the WorkPackage, and may help the Project Manager to provide the regular Highlight Reports to theProject Board. Project Support may be used by the Team Manager where this is acceptable to the ProjectManager. At the discretion of the Project Manager, Project Support will provideadministrative assistance freeing the Team Manager from the day to day administration,and enabling provision appropriate support and guidance to the team members. In somecases, Project Support may act as a “Scribe” at Quality Reviews to help with the
Project Manager
Team ManagerTeam Manager Team Manager
Project Resources & Teams
![Page 64: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/64.jpg)
Ken Bradley’s Understanding PRINCE 2
64
administration and recording of this important control.
Team Managers and Technical Stages
PRINCE 2 draws a distinction between Technical Stages and Management Stages. ATeam Manager will take responsibility for one or more discrete Technical Stages of theproject. Technical Stages relate to the delivery of specific portions of the final solution (or EndProduct) for the project and there may well be a number of Technical stages, each underthe control of a different specialist Team Manager, running within one or moreManagement Stages. The Management Stages provide the basis for a series of major milestones during the lifeof 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 aperiod 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 theproject 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 existwhere 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 administrativehelp 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 nochange, although there will need to be a clear distinction drawn between the servicesprovided to the Project Manager by the Project Support Office staff and any ProjectAssurance function they might be performing on behalf of the Project Board. The ProjectSupport 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 TeamMembers in terms of advice and the interpretation of the project management, qualityand technical standards.
Project Support responsibilities comprise (among others as specified and agreed with theProject Manager) the following: ♦ Administer Change Control; ♦ Set up and maintain the Project Files; ♦ Establish Document Control Procedures for the Management Products;
![Page 65: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/65.jpg)
Ken Bradley’s Understanding PRINCE 2
65
♦ 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 theproject or through the creation of a Project Support Office) is important to the overallsuccess of the project. Typical knowledge and skills necessary for this key position mightinclude, among other areas:
♦ A broad understanding of estimating techniques (especially those used by theOrganisation);
♦ specialist knowledge and competence with the organisation’s chosen software support
tool, and other project management software support tools such as those for RiskAssessment and Management;
♦ any other specialist knowledge that might be needed to support and reflect theorganisation’s existing standards, approaches and professional ethics andapproaches;
♦ 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 thePRINCE 2 manual and shown in figures 26 and 27. PRINCE 2 assumes that the projectwill be a joint venture between a Customer and a Supplier, who might be an internal orexternal supplier of the specialist portion of the project.
![Page 66: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/66.jpg)
Ken Bradley’s Understanding PRINCE 2
66
Figure 26: The PRINCE 2 Customer:Supplier Organisation Structure
Figure 26 is as far as the PRINCE 2 Manual takes the Customer:Supplier Environment – afull view of the typical Customer:Supplier Organisation Environment to be found in aPRINCE 2 managed project is illustrated in figure 27 below.
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 fora number of years; it is similar to that proposed by PRINCE 2 as a suitable start-point, but
Customer ProjectBoard
n Senior Usern Executive
Supplier Project Boardn Customer Account Managern Supplier Skill Management
n Senior Supplier
Project Board•Executive
•Senior User•Senior Supplier
Customer Organisation Supplier Organisation
Customer Project Board Supplier Project Board
The Project Board(Joint Representation from
Customer & Supplier Project Boards)
CustomerProject Manager
SupplierProject Manager
SupplierTeam Manager
CustomerTeam Manager
CustomerResources
SupplierResources
![Page 67: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/67.jpg)
Ken Bradley’s Understanding PRINCE 2
67
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 communicationlinkages between the respective Project Managers and their respective teams, and thehigher level exchanges between each Project Board and has been used as an organisationalbasis for private sector companies Local Government; Central Government and NHSTrusts. A key element is to ensure that the customer and supplier organisations have anopportunity to take the necessary commercial and business decisions within the privacy oftheir own management organisations, but with the facility to meet to iron out difficultiesand problems on a “without prejudice” basis.
The Supplier Project Board
Supplier senior management will always need to represent the interests of their customersif the eventual business outcome is to be satisfactory to all parties involved.
Reflecting the “partnership” approach, it is tempting to include a User/Customerrepresentative on the Supplier Project Board. This approach is, however, flawed as thePRINCE Methodology places overall and ultimate responsibility and authority for theproject 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 aninvidious position, especially in times of trouble when hard decisions have to be madeabout the possibility of re-defining the project deliverables or re-negotiating the contractprice or terms and conditions, where the Customer‘s only realistic stance can be “nocomment” - indecisive and certainly not recommended at Project Board level!
A similar situation occurs where a Supplier is asked to provide a representative for aCustomer’s Project Board. Although commitment of the Supplier’s resources will be ableto be achieved, in times of difficulty where a specialist solution appears not to be workingin the way the Customer had expected, the supplier representative always experiences aconflict over whose interests should be protected.
The solution, endorsed by practical experience, is for the Supplier to providerepresentation from internal resources such as a Customer Account Manager to speak forthe customer and to ensure that, at the highest level within the project, due account istaken of the customer’s position.
For the customer, where there is an unwillingness to have a Senior Supplier from theorganisation they have contracted with on the Project Board, specialist technical expertisefor the project may be bought-in from outside if there is no specialist expertise alreadyresident or available from within. Such an appointment carries with it the disadvantagethat 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 ProjectBoard) will help smooth the path for communication between all the senior managersresponsible for the project.
![Page 68: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/68.jpg)
Ken Bradley’s Understanding PRINCE 2
68
Customer: Supplier Steering/Co-ordinating Group
Each individual Project Board will be primarily responsible for the management of theproject within its own organisation, but there is also the need to meet on a regular basis todiscuss issues and to enable communication at a senior level. The Steering/Co-ordinatingGroup (or Joint Project Board) pulls together all interested parties at Project Board, ProjectManager and, if appropriate, Project Assurance levels so that key decisions can be made.
Figure 28: The Customer & Supplier Management Structures
It is important to focus on the purpose of each meeting of the Steering/Co-ordinatingGroup 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 thesubject of separate arrangements (typically monthly Highlight Reports).
Within a contractual environment, it will always be advisable to set up each meeting withthe proviso that any discussions, views and agreements reached within theLiaison/Steering Group forum will always be “without prejudice to the agreed terms andconditions of the contract”. Failure to do this might well result in an unwillingness toenter into constructive debate and to provide mutually constructive suggestions to avoid orrepair problems.
Customer Organisation Supplier Organisation
Project Board Senior Management(Project Board Equivalent)
Steering/Co-ordinating Group(Joint Representation from
Customer & Supplier Project Boards)
CustomerProject Manager
SupplierProject Manager
SupplierTeam Manager
CustomerTeam Manager
CustomerResources
SupplierResources
![Page 69: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/69.jpg)
Ken Bradley’s Understanding PRINCE 2
69
Customer: Supplier Project Manager
The supplier will always appoint someone to take responsibility for day-to-daymanagement of the project - the Supplier Project Manager. The communication linesbetween the Customer Project Manager and the Supplier Project Manager are the strongestties between the two parties. This is reinforced where the Customer Project Managerregards the Supplier Project Manager as a (specialist) Team Manager within the customerproject.
The Project Manager will normally come from the Customer organisation and will take onresponsibility for managing the total project. This is because the Supplier’s role in theoverall 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 ofsupport will be established for the Project Manager. The communication links betweenthe support functions will be the regular reports (typically Highlight Reports) andresolution 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 andsupplier team members as this will always be routed through the Project Managers orProject Support.
Organising The Managing Of Programmes
Most projects will have inter-relationships with other undertakings within and outside thehost organisation. In larger, longer term and high risk projects, there will be a consciouseffort 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 thebasic principles of the PRINCE Methodology. The actual arrangements and structure willvary with each programme and will need to reflect the local approaches, culture and, ifappropriate, contracts. The PRINCE 2 manual provides a suggested structure whichshould 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 nearalternative for consideration:
![Page 70: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/70.jpg)
Ken Bradley’s Understanding PRINCE 2
70
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 theoverall 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 alsoresponsible for the overall programme integrity and the correct use of the organisation’sproject management and quality management standards. They will also, therefore, take onthe day to day role of Programme and individual Project Assurance on behalf of theProgramme Board members and individual Project Board members. Accountability forProgramme and Project Assurance remains, of course, with the individual roles on therespective bodies.
Quality Assurance is normally a separate function and vested in the Quality Manager; theappointment of a joint Programme/Quality Assurance function role is the responsibility ofthe Programme Board.
To avoid large numbers of individuals on Programme Boards, it is often convenient toestablish a Steering Group which is strictly speaking outside the project boundary. Such agroup may meet as frequently or infrequently as deemed to be appropriate and themembership need not be limited.
Programme BoardRepresentation from User/Customer, Supplier Function & Business Function
Programme ManagerProgramme Support
+ Project Support
CustomerGroup
Project Board - 1 Project Board - 2 Project Board - 3
Project Manager Project Manager Project Manager
Programme/Project Resources (some common; someowned by one project)
Corporate ManagementSteeringGroup
![Page 71: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/71.jpg)
Ken Bradley’s Understanding PRINCE 2
71
The Steering Group will be kept fully informed of the progress of the programme and willbe 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 ProgrammeManager, 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 iscatered for by having a separate Customer Group. This group will provide the SeniorUser/Customer on the Programme Board and the Senior User for each of the individualProject Boards. Each individual Project Board Senior User is responsible for appointingany necessary user/customer liaison resource, possibly coupled with assuranceresponsibilities, 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 2project. 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 itscontinuation and commit the resources. Each individual Project Board will comprise aSenior User/Customer representative, a Supplier representative, and an Executive/Businessrepresentative.
As mentioned above, the User/Customer Group will provide the Senior User. TheProgramme Manager is best positioned to chair each Project Board and represent thebusiness interests of the overall programme and the host organisation. The individualProject Board Supplier representative will be assigned/appointed by the Senior Supplier onthe Programme Board.
Project Support & Programme Assurance
Each individual Project Manager may be assisted by a Project Support function if this isdeemed to be necessary given the size, scope and complexity of the project and theexperience of the Project Manager.
Project Support will keep the project plans up to date and on a regular basis, usuallymonthly, will provide a summary of status and progress to Programme Support who willuse 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 toeach member of the Programme Board. Assurance for the whole programme of work andfor individual projects will primarily be the responsibility of Programme Support whose
![Page 72: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/72.jpg)
Ken Bradley’s Understanding PRINCE 2
72
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 theprogramme has within the organisation.
Programme And Project Resources
These are often shared over all projects and identification, use and monitoring of theresource pool is an important aspect of managing a programme of work. It is all too easyfor each individual project to plan to use the same resources to the full extent of theiravailability, thus ensuring over-utilisation and consequent slippage of the wholeprogramme. This can be avoided by the use of a suitable software planning tool whichallows 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 avariety of different projects. For example, many organisations are involved in ConcurrentEngineering or Rapid Application Development projects; a suitable PRINCE 2 compliantstructure has been produced and is included on the next page (Figure 30).
The model as presented is straightforward and conforms, generally, to the requirements ofPRINCE 2, with an owner with ultimate authority (The Project Board) reporting toCorporate Management to ensure that the development project resides within the overallstrategy for the organisation, reflecting corporate objectives.
The Project Team is totally enclosed within the project structure, with separate TeamManagers responsible for the discrete stages of the work.
The project is under the direction of a Project Manager, exercising management controlon a day to day basis through the Team Managers and through Project Support, as theProject Manager may be expected to be fully involved with the development, testing andinstallation 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.
![Page 73: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/73.jpg)
Ken Bradley’s Understanding PRINCE 2
73
Figure 30: Rapid Application/Concurrent Engineering Organisation Model
Project Support will provide an important co-ordination function within this type ofproject. Typical tasks will include:
♦ setting up regular (possibly 4-6 meetings between Team Managers and the ProjectManager 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 publishedQuality Management System and Project Assurance remains the responsibility of theProject Board, although this may be delegated (but not to anyone within the ConcurrentEngineering/Rapid Application Development team).
Specification, Analysis& Design Team
Team Manager
- User/Customer- Analyst- Design
Resources
Development Team
Team Manager
- Programmer- Analyst- Design
Resources
Implementation & UserTesting Team
Team Manager
- User/Customer- Analyst
Resources
Project Manager
Project Support& Administration
Project Resources
Corporate Management Project Board & Project Assurance
![Page 74: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/74.jpg)
Ken Bradley’s Understanding PRINCE 2
74
It should be stressed that the organisation structure shown does not form part of thePRINCE 2 Method but is included to illustrate how the principles within the method maybe 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 overalland ultimate responsibility for the successful delivery of the project. Initially theExecutive 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 providedwhere 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 ProjectBoard, 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, butthese would need to be assigned to separate individuals within the Project SupportOffice.
♦ 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 ConfigurationManagement System - the Project Manager is responsible for its integrity, which willbe audited by Project Assurance on behalf of the Project Board.
![Page 75: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/75.jpg)
Ken Bradley’s Understanding PRINCE 2
75
UNDERSTANDING THEPLANNING COMPONENT
ANDPRODUCT-BASED PLANNING
TECHNIQUE
Chapter 4
![Page 76: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/76.jpg)
Ken Bradley’s Understanding PRINCE 2
76
Planning - Introduction & Overview
The PRINCE 2 Method does not prescribe any particular type of plans which must beused on a project. The principles of “Product Based Planning” are incorporated in themethod within the “Techniques” section and the overall assumption is that some form ofsoftware 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 thereis no limitation on the number of levels which might be utilised. Typical levels of planare:
♦ 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 tomembers of the project team might also be utilised if this is appropriate.
Figure 31: Levels of Plan In PRINCE 2
Plans at Levels 1 and 2 are necessary for effective planning of a major project – both theProject Plan and the Stage Plan are mandated in the Method.
Project Plan (Mandatory Plan)
Stage PlanStage Plan Stage Plan
TeamPlan
TeamPlan
TeamPlan
TeamPlan
TeamPlan
TeamPlan
Project Resources Report(Effort, Costs, Equipment, Direct Costs)
![Page 77: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/77.jpg)
Ken Bradley’s Understanding PRINCE 2
77
Project Plans may provide sufficient detail for the early stage plans to be incorporatedwithin them. Plans at the lower Levels are optional but will usually be necessary toproduce in order to gain full understanding of the undertaking and to exercise effectivecontrol at team level.
The plan structures at all levels (including the Exception Plans, which are intended toreplace the plan which it has been necessary to up-date) are similar in content andstructure; at team level for the individual, if these are used, the only plan needed will be asimple Gantt Chart or Activity List covering either one or two elapsed weeks. This type ofplan is often available as a standard output from the planning support software.
Figure 32: The PRINCE 2 Plan Package
Project Level Plans
Construction of PRINCE plans should normally be on a top-down basis; this will providea logical and controlled descent into detail and will help to identify any grouping ofProducts 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 providea realistic picture of the total development. The more detailed activities will then need tobe grouped to provide an overall view at the project level.
PlanText
The Plan Text provides a high-level, overall view of the plan, summarising its key features
ProductBreakdownStructure
Identifying the Products/Deliverables that will be produced by the Project. The Products will be categorisedunder the headings of “Specialist”, “Management”, and“Quality” Products.
ProductDescriptions
Describing the Products/Deliverables that will be produced by the Project. There is a prescribed format for Product Descriptions
ProductFlow
Diagram
Describing the relationships that exist betweeneach Product/Deliverable, and external entities.
PERTor
ActivityNetwork
Showing the relationships that extist between the Activities that will be undertakento create the Products identified in the Product Breakdown Structure.
Ganttor
TimescalePlan
Derived from the PERT Network, this shows when Activities areplanned to start and end. Major Review points (End StageAssessments) are also shown on this plan.
![Page 78: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/78.jpg)
Ken Bradley’s Understanding PRINCE 2
78
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 Managerand the appropriate Team Manager where appointed. The resultant list should then becritically reviewed with the Project Management Team in the light of what is known aboutthe proposed project, to produce an agreed list of high-level Products to be produced. Thisis known as a Product Breakdown Structure and contains a list of the Specialist Products,Management Products, and Quality Products associated with the 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;
Management Information System
Specialist Products
SP01 - User SpecificationSP02 - Logical DesignSP03 - Physical DesignSP04 - ContractSP05 - HardwareSP06 - SoftwareSP07 - CommunicationsSP08 - Integrated SystemSP09 - Technically Tested SystemSP10 - User Accepted SystemSP11 - Trained StaffSP12 - Test Products
Quality Products
QP01 - Product DescriptionsQP02 - Quality Review DocumentationQP03 - Project Issues LogQP04 - Quality LogQP05 - Configuration Management
Management Products
MP01 - Project Initiation DocumentMP02 - Stage PlansMP03 - Lessons Learned LogMP04 - Risk LogMP05 - Business CaseMP06 - Product ChecklistMP07 - Highlight ReportsMP08 - Project Start NotificationMP09 - Project End NotificationMP10 - Project Filing Structure
The Project ManagementStandard for the
Project
The Quality ManagementStandard for the
ProjectThe Technical Management
Standard for theProject
![Page 79: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/79.jpg)
Ken Bradley’s Understanding PRINCE 2
79
♦ 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 2compliance.
Product Descriptions form a significant part of the Quality Plan for the project and arefundamental to its successful outcome. For these reasons Product Descriptions must not,in any circumstances be omitted from any PRINCE controlled project.
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) anddefined in terms of a published and baselined Product Description. Baselining of aProduct Description will take place when the plan it relates to is baselined (agreement bythe Programme Director/Executive (for Programme Plans), the Project Board (for ProjectPlans) and the Project Manager (for Team Plans)).
A Product Description, once approved and base-lined, may only be changed via theChange Control procedure.
SP01 - User Specification
User Requirements Enhancements
FunctionalRequirements
DataRequirements
EducationStrategy
TestingStrategy
Cut-OverStrategy
Fall-BackStrategy
Strategies
Short/MediumTerm
LongTerm
TechnicalTesting
UserTesting
ModuleTesting
SystemTesting
![Page 80: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/80.jpg)
Ken Bradley’s Understanding PRINCE 2
80
Product Flow Diagram
A Product Flow Diagram may then be drawn showing how the various products identifiedare derived, one from another and from external Products and Entities. This helps toconfirm that all the Products that need to be produced have, in fact, been identified; allProducts in the Product Flow Diagram must balance with those in the Product BreakdownStructure, and each must be supported by a Product Description.
Figure 35: Product Flow Diagram
The Product Flow Diagram helps set a basic approach and chronology for the completionof the Products. Stage beginnings and endings, and candidates for sub-project groupingscan also be determined from this diagram, although the final timings of Management Stageendings will not be able to be made until later when the Gantt Plan (or Timescale Plan) hasbeen produced.
Construction of the Product Flow Diagram helps the project planners to appreciate theoverall approach and strategy that underpin the project. Any "missing" Products will bemore easily identified (these must of course be incorporated into the Product BreakdownStructure and defined within Product Descriptions).
Less than obvious linkages between Products will be more clearly apparent at the time theProduct Flow Diagram is drawn, and the successive iterations will help to hone the overallapproach to a more realistic shape.
Another useful function of the Product Flow Diagram is the help it gives in identifyingActivities for inclusion in the activity plans.
SP01 - User Specification
SP02 - Logical Design
SP03 - Physical Design
SP04 - Contract
SP06 - SoftwareSP05 - Hardware SP07 Communications
SP12 - Test Products
SP08 - Integrated System
SP09 - Technically TestedSystem
SP10 - User AcceptedSystem
SP11 - Trained Staff
Users/Existing SystemFeasibility Study
Potential Suppliers
![Page 81: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/81.jpg)
Ken Bradley’s Understanding PRINCE 2
81
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 moreProducts 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 bederived from the Product Flow Diagram. Alternative names for the PERT Network are“Critical Path Network”, “Critical Path Method”, and “MIST - Minimum IrreducibleSequencing Technique”.
The Product Flow Diagram defines the data flow and relationships between Products to beproduced, 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 establishesthe dependency relationship between activities. The Timed Network provides additionalinformation on the elapsed time to be taken for each activity and allows the total projectcycle time to be predicted. The Timed Network will also provide information on start andfinish times, critical paths, sub-critical paths and float.
SP01 - User Specification
SP02 - Logical Design
SP03 - Physical Design
SP04 - Contract
SP06 - Software
SP12 - Test Products
Users/Existing System
Feasibility Study
* Prepare & Issue Tenders* Produce Tender Evaluation Criteria* Assess Offers & Select Supplier* Issue Contract
* Produce & Agree Program Designs* Write Programs (& Fixes)
* Unit Testing* Suite Testing
* Extract Test Data* Clean Data
* Produce Test Schedule
Produce Business (Logical) Design
Produce Business (Logical) Design
* Interview Users* Produce Specification
Review FS
![Page 82: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/82.jpg)
Ken Bradley’s Understanding PRINCE 2
82
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, anEarliest Start Gantt Plan can be produced. This chart will provide the basis for ProjectBoard approval. But first some tuning/resource smoothing has to be carried out.
Figure 38: Creating The Earliest Start Gantt Plan
Resource Smoothing
The Timed Network will have assumed unlimited resources were available andconcentrated solely on the underlying logic of the relationship between activities. This
Earliest Start Time Earliest Finish Time Latest Finish Time
Activity Total Float
0 3 3
10 Appoint The PB Executive
0 0 3
3 2 5
20 Appoint The Project Manager
9 6 11
11 5 16
30 Design & Appoint The Project Team
11 0 16
10 4 14
60 Prepare Board Position Paper 12 2 16
16 2 18
40 Produce The Project Brief
16 0 18
3 7 10
50 Review The Strategy Plan
5 2 12
3 8 11
70 Plan The Project Approach
3 0 11
0 3 3
10 Appoint The PB Executive
0 0 3
Earliest Start Time(EST) Earliest FinishTime
(EFT)
Latest Start Time(LST) Latest Finish Time
(LFT)
Duration
Total Float
![Page 83: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/83.jpg)
Ken Bradley’s Understanding PRINCE 2
83
does not, of course mean that any number of people are available to the project, but thatthose that are assigned to the project are assumed to be able to work at any time (even tothe extent of carrying out simultaneous multiple activities.
Figure 39: Creating The Resource Smoothed Gantt Plan
The Earliest Start Gantt Plan will clearly show overlapping activities where resource usagewill be over-stretched. To inject reality into the plan it will be necessary to smooth theresources.
Although not dealt with in the methodology, resource smoothing is an essential feature ofproject planning. Resource smoothing is best carried out using a software support package(such as Microsoft Project (MS Project), Project Manager’s Workbench (PMW), orPrimavera), initially, and then tuning "by hand". Full manual resource smoothing is a timeconsuming 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 projectmay have slipped back too far to be acceptable to the sponsor. In these cases it will benecessary to reconsider the logic of the Timed Network and to plan for overlaps of activitythat 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 properlyassessed and documented for a decision by the Project Manager or Team Manager andsubsequent endorsement by the Project Board.
Produce PlanId SourcesPrepare DocsPrepare I/VsAppointmentsInterviews
Un-smoothed Gantt Plan (Earliest Start)
Produce PlanId SourcesPrepare DocsPrepare I/VsAppointmentsInterviews
ManagementStage 1
ManagementStage 3
ManagementStage 2
Resource Smoothed Gantt Plan (With Stage Reviews)
![Page 84: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/84.jpg)
Ken Bradley’s Understanding PRINCE 2
84
Project Gantt Plan
The Gantt Plan is the result of the resource-smoothed earliest-start bar chart. and providesa view of the Products related to the envisaged time-scales for the total project, readilyshowing where "clusters" of Products will be ready and thus point to natural Stagebeginnings and endings. The Project level Gantt Plan has the End Stage Assessmentcontrol symbols added in, at appropriate key decision and resource commitment points andis then ready for approval by the Project Board.
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 aStage-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 resourceinformation required will be able to be drawn from the Project Plan and presented inwhatever format is required.
Information on the planned use of resources (and the subsequent record of actual usage) isan essential element of decision support for management and should not be omittedwithout good reason.
In projects where a software support tool is not being utilised, it may be produced bytaking a copy of the Project Gantt Plan and creating a "Transfer Sheet" for each resourcetype. The transfer sheet provides a statement of the resource usage against each activityfor the whole project; the planned effort usage for each stage is totalled and transferred tothe Project Resource Plan.
InitiateSpecifyDesignBuildTestTrainHand-over
ManagementStage 1
ManagementStage 3
End Stage Assessment(ESA)
Project InitiationProject Closure
ManagementStage 2
![Page 85: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/85.jpg)
Ken Bradley’s Understanding PRINCE 2
85
Stage 1 Stage 2 Stage 3 Plan Actual Plan Actual Plan Actual
EFFORT (Staff Weeks)Skill Types
CustomersEngineersIT AnalystsOthers
COSTS (£K)Skill Types
CustomersEngineersIT AnalystsOthers
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 byreference to capitation or charge-out rates. Direct costs (for purchase of equipment etc) isalso 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 beenidentified on the Project Resource Plan, they are cumulated in order to provide input to aGraphical 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 knowabout as it enables the project plans to be summarised on a single sheet in a graphicalformat. It summarises the planned expenditure using the vertical axis to illustrate costsand the horizontal axis for time. At the project level it is acceptable to show a cumulativesummary of each stage's planned costs , although the Project Board may require a moredetailed analysis. If this is required, the Project Resource Plan should be re-drawn to showinformation at a similar level as it is important that all plans should be consistent with eachother.
![Page 86: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/86.jpg)
Ken Bradley’s Understanding PRINCE 2
86
Figure 42: Graphical Summary Of The Plans
A useful feature on the Graphical Summary is the inclusion of delivery slots for majorProducts. This information provides essential technical progress data and enables theProject Board to assess the actual achievement against actual spend when reviewing theplans at the end of each stage. The headings used in the Graphical Summary to show thestatus of each Product may be used in conjunction with the Product Checklist. Thisdocument has planned and actual dates inserted to show progress of Products. It is mostuseful 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. Thistechnique takes performance measurement a step further, enabling a clear measurement ofthe project work accomplished and more disciplined forecasts of the likely task andProduct completion dates and associated costs. The concept of Earned-Value Analysis isnot incorporated into the PRINCE 2 Method, but is being used increasingly and may beexpected to be included in a subsequent revision.
Earned Value replaces the traditional practice which only compares Actual Cost withActual 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.
Time
Cost
Specification
Business D
esign
Agreed D
esign
Contract
Com
pleted System
Tested S
ystem
Trained S
taff
Initial Support C
omplete
Pilot H
andover
Custom
er Acceptance
Project C
lose-Out
Product Ready
Quality Reviewed
Work Finished
Work Started
Work Package Agreed
ManagementStage 1
ManagementStage 3
ManagementStage 4
ManagementStage 2
Stage£20K ....
Stage£14K ....
Stage£58K ....
Stage£18K ....
£20K£34K
£92K
£110K
![Page 87: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/87.jpg)
Ken Bradley’s Understanding PRINCE 2
87
Figure 43: Earned Value Analysis
The value is usually monetary but can be expressed in any appropriate unit such as staffhours or days. The value to be earned when a specific Milestone or Major Product isachieved is based on the planned cost of achieving the Milestone.
For example, if the plan showed that £100,000 was required to achieve a specifiedMilestone/Project Product, £100,000 worth of Earned Value would be credited to theProject Manager (as “owner” of the Product”) when achievement of the Product wasdemonstrated (ie that the Product had successfully met all its Quality Criteria). Again, it isworth emphasising that the plans described above, the Graphical Summary and the EarnedValue Analysis plan are not requirements of PRINCE 2, but are useful vehicles forillustrating 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 alwaysbe completed at Project Initiation and up-dated, minimally, when preparing for each EndStage Assessment/Project Board meeting.
PRINCE 2 requires that a Risk Log be kept to record the (hopefully reducing) risks facedas the project progresses. The risk analysis provides a complementary part of the BusinessCase for the Project and will be summarised in the Project Plan Description.
Time
Cost
Specification
Business D
esign
Agreed D
esign
Contract
Com
pleted System
Tested S
ystem
Trained S
taff
Initial Support C
omplete
Pilot H
andover
Custom
er Acceptance
Project C
lose-Out
Product Ready
Quality Reviewed
Work Finished
Work Started
Work Package Agreed
£200K
£110K
Time Now
Actual Cost
Planned Cost
Value Earned
PredictedRevised Cost
Predicted CostOver-Run
PredictedScheduleOver-Run
Projection ofActual Costs
OriginalPlanned Cost
![Page 88: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/88.jpg)
Ken Bradley’s Understanding PRINCE 2
88
The risk analysis will address other issues, of course, (eg staff turnover; projectmanagement expertise, third party suppliers etc) but if time is to be saved by thecompression of time-scales by overlapping naturally dependent activities, this presents avery real risk to the success of the undertaking and may well involve some nugatoryexpenditure. For these reasons the implications of resource smoothing at this point inplanning must be seriously considered.
Measuring The Business Benefits
When all the resource usage and cost information has been assembled, the ProjectBusiness Case can be created (“Initiating A Project”) or reviewed (“Managing StageBoundaries”).
Figure 44: Simplified Business Benefits - Costs:Benefits Analysis & Investment Appraisal
A high-level Business Case would normally have been produced during the Feasibility orPreliminary Study, based upon information contained in the organisation's Strategic Plan.This initial business case would have been subsequently refined and, following approvalby Corporate or Programme Management, passed with the Project Mandate to the ProjectManager for formal Start-up and, following approval at the Project Initiation Meeting, theInitiation of the project.
The main elements of the Business Case are the reasons for the project, and a Benefitsand Costs Statement. An optional Costs:Benefits Analysis and Investment Appraisal mayalso be created to measure the Business Benefits of the project’s outcome. If thought to benecessary a Sensitivity Analysis may also be produced. A Risk Analysis and proposalsarising from it, recorded in the Risk Log, is also closely linked to the PRINCE BusinessCase.
Essentially all costs are fed into the model and all tangible benefits added in. The resultwill 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:
Year 0 1 2 3 4 5
Costs : (10 0 ) (20) (20) (20) (40) (30)Benefit s : 0 40 8 0 10 0 10 0 10 0CashFlow: (10 0 ) 20 6 0 8 0 6 0 70Cumulat ed: (10 0 ) (80) (20) 6 0 120 190Discount Factor (@6 %) 1.00 .94 .8 8 .83 .78 .74Discount ed Cash Flow (10 0 ) 19 53 6 6 47 52Cumulat ed DCF (10 0 ) (81) (28) 38 85 137
![Page 89: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/89.jpg)
Ken Bradley’s Understanding PRINCE 2
89
♦ 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 theProject Board, a narrative statement of the Benefits should be produced. This lists all theanticipated 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 summaryof the planned work and expenditure.
To initiate the project (and to approve each successive Management Stage) the ProjectBoard will require a document which ties the complete plan package together anddescribes the approach and general philosophy. This document is the Plan Text (alsoknown as the Plan Description, Plan Narrative or Executive Summary) and will be mainlya 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 staffrecruited, 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 asimilar path to the Project Plan package. The Stage Plans are produced in the “ManagingStage Boundaries (SB)” Process.
Short horizon, limited commitment, planning is a fundamental feature of PRINCE. Theaim 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
![Page 90: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/90.jpg)
Ken Bradley’s Understanding PRINCE 2
90
Stage Plan documentation). The structure of the PRINCE 2 Stage Plan package is asfollows:
♦ 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 stageand 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 ofCheckpoints, 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 beprovided to identify the effort and costs to be approved by the Project Board. It isproduced by taking the Stage Gantt Plan and creating a Transfer Sheet for eachresource. The Stage Resource Plan is usually constructed on a week-by-weektimescale 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 EarnedValue Analysis Plan.
♦ Stage Plan Text - ties together and summarises the above plans and will essentiallycover the stage plan pre-requisites, assumptions and risks. This narrative might beincorporated into the Project Plan Description.
InitiateSpecifyDesignBuildTestTrainHandover
ManagementStage 1
ManagementStage 2
ManagementStage 3
Start-UpProject BriefProject ApproachPIDInterview UsersProduce SpecOutline DesignFinal DesignAgree Design
Figure 45: Stage Plan Derived From The Project Plan
![Page 91: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/91.jpg)
Ken Bradley’s Understanding PRINCE 2
91
Team Plans
Team Plans will usually (but not necessarily) be required for all but the smallest ofprojects. They drop the Stage Plans down to an increased level of detail in much the sameway 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 theywill normally be prepared by the Team Manager within the “Managing Product Delivery(MP)” Process, based on the authorised Work Package in consultation with the TeamMembers and agreed with the Project Manager.
The Team Plan Package, where produced, will be related to a specialist team working on aspecific Product or set of Products or they might be aimed at an individual working withinthe project. Team Plans will often reflect the work to be carried out in a Technical Stagewithin a Management Stage of the project.
Individual Plans
Individual Plans (sometimes referred to as Work-to Lists) are not required withinPRINCE 2 but may, at the Project Manager/Team Manager’s discretion, be drawn up forindividuals working on specified Products. The Individual Plans, where used, will bederived directly from the Detailed Gantt Plan and will form the basis for discussion ofprogress at the regular (usually weekly, but at the regularity agreed within the authorisedWork Package) Checkpoints.
The Individual Plan may comprise a detailed Bar Chart/Gantt Chart, Activity List, ormight 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 deriveunderstanding 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. Therecommended approach is to plan in detail to get a full understanding of what is involvedand then to select an appropriate level of control based on what is known about the project.
![Page 92: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/92.jpg)
![Page 93: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/93.jpg)
Ken Bradley’s Understanding PRINCE 2
93
Chapter 5
UNDERSTANDING THECONTROLS COMPONENT
![Page 94: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/94.jpg)
Ken Bradley’s Understanding PRINCE 2
94
Introduction To Controls
The main mission of any project management method is to enable management at alllevels to exercise control over what has been planned and approved. The approved plansreflect what is required to be achieved and the structure of controls enables managers toreach informed decisions about committing resources and giving approval to proceed.
Regular and formal monitoring of actual progress against the approved plan is essential toensure the timeliness, cost control and quality of the system or undertaking beingdeveloped. PRINCE 2 provides the essential support structure of Management andProduct-oriented controls to monitor progress, supported by a reporting procedure whichenables re-planning or other appropriate corrective action to be taken.
PRINCE 2 controls fall into three main categories – Management Controls, QualityControls and Configuration Controls; the latter two are covered in separate Chapters inthis 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 theproject. These controls cover all aspects of project activity and, at the highest level, allowthe Project Board to assess project achievement and status prior to committing furtherexpenditure.
Controls are applied through measuring the progress towards production of a set ofpre-defined outputs (Products or Deliverables). The overall structure of ManagementControls is defined at Project Initiation (IP4) to ensure that the project is set up with clearTerms of Reference, incorporating agreed and measurable Objectives and an adequatemanagement 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 TeamManagers. The main Project Board controls are:
♦ The Project Initiation Meeting (establishing whether there is a worthwhile andviable project);
♦ Project Initiation & the Project Initiation Document (PID) (fixing a baseline forthe project);
♦ End Stage Assessment (ensuring the project is still viable and authorising progressto the next Management Stage through the approval of the next Management StagePlan);
![Page 95: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/95.jpg)
Ken Bradley’s Understanding PRINCE 2
95
♦ Tolerance (providing time and cost margins within which the Project Manager hasdiscretion to deviate from the approved plan without seeking authority from theProject Board);
♦ Mid-Stage Assessment (where significant deviations from the approved plans areconsidered and an Exception Plan approved);
♦ Project Closure (authorising close-down of the project after ensuring that all theproject’s Products have been delivered to the required quality standards and thatcustomer acceptance has been obtained);
♦ Highlight Reports (regular, normally time-based, reports from the Project Managerto Project Board members to keep them informed of the progress and status of thecurrent Management Stage);
The Project initiation Meeting
The pre-project Process “Starting Up A Project (SU)” seeks to answer the question “Dowe have a worthwhile and viable project?”. Creation of the Project Brief, Risk Log,Project Approach, Initiation Stage Plans, Organisation Structure and Role definitionscontribute to answering this question and formal acceptance that there is a worthwhileproject 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 ameeting provides will be appropriate for major investments. The PIM is a control functionof “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 Projectmanager and team to begin to create the elements of the Project Initiation Document (PID)during the required Initiation Stage of the project.
Figure 46: Pre-Project and the Project Initiation Meeting
• Project Brief• Risk Log• Project Approach• Organisation• Initiation Stage Plan
InitiationStage
Project InitiationMeeting
Do we HaveA Worthwhile&viable Project?
Stage 2
End StageAssessment
End StageAssessment
The Project InitiationDocument Providesthe Project Baseline
Pre-Project ........ The Project Lifecycle .........................
The End Stage Reportconfirms the result of thelast Stage and reports on
the overall project viability.It also contains the plans
for the next Stage.
![Page 96: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/96.jpg)
Ken Bradley’s Understanding PRINCE 2
96
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, benefitsand financial return, quality plans, organisation structure and job definitions are clearlydefined, published, understood and agreed.
Every organisation using PRINCE 2 as the basis for its project management standardsshould 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 theoutline contained in Appendix A17 of the PRINCE 2 Method manual.
This Management Product is very important to the project and is the result of twoProcesses - “Starting Up A Project (SU)” and “Initiating A Project (IP)”. The key outputis the Project Initiation Document (PID) which, when approved, is a reference documentused to Baseline the project.
The PID is used throughout the project as a reference back to the original intentions andmanagement objectives. During the “Closing A Project” Processes, the PID is used toreference the original Acceptance Criteria and secure Customer Acceptance (CP1), and toprovide the statement of the original project objectives, scope and constraints for creationof the End Project Report.
End Stage Assessment (ESA)
This is a mandatory management control and occurs at the end of each stage. It typicallyconsists of a formal presentation to the Project Board of the current project status, andreviews the overall Business Case and risks. The vehicle used for this is the End StageReport.
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 ofthe project up to the next End Stage Assessment.
“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
Figure 47: Handling End Stage Assessments
The approval of the proposed plans for the next stage is also obtained. Project Board
![Page 97: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/97.jpg)
Ken Bradley’s Understanding PRINCE 2
97
approval, with agreement by all the members, must be obtained before the project canproceed 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 exceptin exceptional circumstances; where a Project Board member finds it necessary to send arepresentative rather than attend personally, the representative must be empowered to takedecisions on behalf of the Project Board member. Frequent delegation of attendanceshould provoke the Executive to consider replacement of the non-attending Project Boardmember).
The Project Manager (the Project Manager is not a member of the decision-makingProject 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 andthat “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 EndStage Assessment).
In addition to the above, the Project Board and Project Manager may invite any otherperson or representative of any organisation who may be able to assist in the ProjectBoard’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 followingsuggested 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.
![Page 98: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/98.jpg)
Ken Bradley’s Understanding PRINCE 2
98
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 FutureActions.
Item 7: Any Other Project Related Business (eg External Information WhichImpacts on the Project’s Future).
Item 8: Project Board Formal Sign-off of the Current Stage and Commitment tothe 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 Assessmentwill 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 anapproved Management Stage Plan and to approve an Exception Plan produced, at therequest of the Project Board, following an Exception Report.
An Exception Report is produced by the Project Manager to alert the Project Board assoon 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” fromthe approved plan, the impact on the Management Stage, overall Project and its BusinessCase. The plan will also recommend appropriate action to take the project to the end ofthe Stage and, where possible, recover the situation.
![Page 99: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/99.jpg)
Ken Bradley’s Understanding PRINCE 2
99
Figure 48: Handling Mid Stage Assessments
The Exception Report may be triggered by a number of different events, sometimeswithout much advance warning, but in most cases a deteriorating situation will be knownby the Project Manager and observed by Project Assurance. Where Project Assurancebecome aware of a Management Stage in decline an immediate report must be made to theappropriate Project Board member (or the Executive). The Project Manager shouldprovide advance warning to the Project Board members via the Highlight Report – it ismost important to “come clean” and not attempt to disguise or hide the situation in thehope that something will happen to improve matters – it invariably won’t happen! Whereappropriate the Project Manager should advise the Project Board members informally (bytelephone, 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 Boardat 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 onQuality, Technical Conformance, Scope and Risk. Tolerance need not necessarily beequal – for example, it may be appropriate to set differential Tolerance of +0 and –4weeks, coupled with cost Tolerance of +£10K and -£30K depending on where prioritieslie.
Stage 1 - Planning & Definition Stage 2 - Design & Contract
Mid Stage Assessment(MSA)
“Directing A Project” Process •Consider the Exception Planat an unscheduled Mid Stage Assessment.•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 ofthe Stage up to the next End Stage Assessment.
“Controlling A Stage” Process •Deviation from approved Stage Plans Forecast;
•Exception ReportCreated - Reasons; Impact; Options; Recommendation;•Direction from Project Board .... Create an Exception Plan;
“Managing Stage Boundaries” Process •Produce an Exception Plan
![Page 100: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/100.jpg)
Ken Bradley’s Understanding PRINCE 2
100
Figure 49: Tolerance - plus/minus 1 week; plus/minus 10%
The level of Tolerance is decided by the Project Board following recommendations by theProject Manager. Tolerance is exercised mainly for a Management Stage but is alsoappropriate at Project and Team Levels.
Project Tolerance is set by Corporate/Programme Management. The Executive memberof the Project Board is responsible for ensuring that Project Tolerance has beenestablished and recorded in the Project Brief. If at any time Project Tolerance is forecastto be exceeded it is the responsibility of the Executive to report to Corporate/ProgrammeManagement and to obtain new direction (possibly re-baselining the project andestablishing 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 ProjectBoard do not have any discretion to exceed Project Tolerance without authority fromCorporate/Programme Management. Where Tolerance is forecast to be exceeded theProject Manager will convey this to the Project Board via an Exception Report which willtypically be followed up by an Exception Plan; alternatively, the Project Board maydecide to prematurely close the project.
Product Tolerance will usually be recorded in the Work package agreed between theProject Manager and the Team Manager responsible for the Products addressed by theWork 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 theapproved Stage Tolerance.
Cost
Time
Planned Delivery & Total Cost
2 4 6 8 10 12 14 16 18 Weeks
£110K
£100K
£90
£80K
£70K
£60K
£50K
£40K
£30K
£20K
£10K
Plus 10% Tolerance
Minus 10% Tolerance
Plus 1 WeekTolerance
Minus 1 WeekTolerance
o
STAGE PLAN
![Page 101: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/101.jpg)
Ken Bradley’s Understanding PRINCE 2
101
Figure 50: Summary of the PRINCE 2 Exception Procedure
Tolerance is a major control for the Project Board, which allows its members to focus onexceptions rather than be swamped with information about work which is proceeding toplan. Similar benefits also accrue for Corporate/Programme Management who are able toleave responsibility for the project to the Project Board, sure in the knowledge that anymajor 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 thoseareas of the project which do need additional support. Project Assurance has a vital role toplay 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 toapprove 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 acceptableto the Project Board, then the Stage should be broken into more than one ManagementStage with an End Stage Assessment at each new break. The Mid-Stage Assessmentcontrol is not appropriate for breaking up long duration Stages. Neither is the MSAintended 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 Assessmentand the Mid-Stage Assessment are decision-based meetings and major Project Boardcontrols to ensure that all work being undertaken has the support and overt approval of thekey managers.
CS8Escalating
Project Issues DP4Giving
Ad-Hoc Advice
1: Exception Report
DP3Authorising A Stage or
Exception Plan
SB6Producing An
Exception Plan
2: Exception Plan Request)
3: Exception Plan
CS1 -Authorising A
Work Package
4: AuthorisationTo Proceed
Mid-StageAssessment
Premature Termination of Project
![Page 102: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/102.jpg)
Ken Bradley’s Understanding PRINCE 2
102
Project Closure
This provides a final review of the project's work is held, usually (but not necessarily) inthe form of a Project Board meeting. This is similar in structure to an End StageAssessment but relates to the entire project rather than a single stage. The objective is toensure that all the project Products/Deliverables have been satisfactorily delivered to theirstated quality standard and that the project documentation is complete.
A review of the contribution made by the project management standards and approachesused by the project will be carried out within the “Closing A Project (CP)” Process and aLessons Learned Report produced for consideration by the Project Board. The LessonsLearned Report records what has been learned from using the PRINCE 2 projectmanagement and quality management standards for the project and is first created duringthe “Initiating A Project – Setting Up Project Files (IP5)” process and “populated” as theproject progresses; it will eventually be sent, via Corporate/Programme Management tothe organisation’s manager responsible for quality.
Recommendations will also be made by the Project Manager for Follow-on Actions torecord and trigger any further work recommended following the closure of the project.Recommended Follow-on Actions will usually be derived from any outstanding ProjectIssues, recorded on the Issues Log and from recommendations impacting on operationaland maintenance of the delivered outcome.
Highlight Reports
The Project Board is kept informed of the progress of the Management Stage (and theproject) against the approved plans via regular, time-related Highlight Reports. These areprepared by the Project Manager using information derived from Checkpoint Reports andfollowing a review of the status of the Management Stage. They are usually providedmonthly, 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 toremove the need for unnecessary time-related Project Board meetings which consume theProject Board members’ valuable time, while still keeping them abreast of significantdevelopments. 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 thecurrent Management Stage. Some organisations specify that Highlight Reports should be kept to one side of A4 (or itsequivalent) and this makes very good sense.
![Page 103: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/103.jpg)
Ken Bradley’s Understanding PRINCE 2
103
Where the project is part of a Programme of work, separate Project and ProgrammeHighlight Reports will normally be produced and special attention must be paid toreporting on interfaces with associated projects. It is always good practice to agree a common format for Highlight Reporting where aProgramme Director (or Project Board responsible for a number of projects) hasresponsibility for assessing Programme progress. A graphical representation is a usefulmedium for achieving a common reporting structure, especially in a Programmeenvironment where the Programme Director may prefer to have a regular, time-basedmeeting where individual project Managers present their Highlight Report Summaries inshort time units. A suitable format which can be adapted for this purpose is the GraphicalSummary/Earned Value Analysis plan described in the “Understanding Planning” Chapterin this book.
Checkpoint Reports
Progress on the work of a Team against the agreed Work Package is the subject of theCheckpoint Report. Typically a Checkpoint Report will be created following aCheckpoint (meeting) in the “Managing Product Delivery Process – Executing A WorkPackage (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 toease the task of reporting. The Checkpoint Report is used to up-date the Management Stage Plans with “actuals” todate and will ultimately be used as an input to the Highlight Report to inform the ProjectBoard of progress made.
Stages
Stages are partitions of the project with decision points at their conclusion, and sometimesduring their life. PRINCE 2 differentiates between “Management Stages” (which equate to the commitmentof resources by the Project Board and a decision to continue with the project and authorityto spend) and “Technical Stages” which comprise sets of technical activities leading to astated Product.
![Page 104: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/104.jpg)
Ken Bradley’s Understanding PRINCE 2
104
InitiateSpecifyDesignBuildTestTrainHandover
ManagementStage 1
ManagementStage 2
ManagementStage 3
TechnicalStages
Project Review of Management Stage atEnd Stage Assessment (ESA)
Project Initiation Project Closure
Figure 51: Management & Technical Stages Technical Stages will often overlap and be run in parallel; they are normally planned andmanaged 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. Ofcourse, in a smaller project these might well be described as “Activities”; in medium tolarger projects, the Activities will often combine to provide the Technical Stages. In only the most exceptional circumstances will authority be given for work to commenceon the next Management Stage before all the Products of the current Management Stage iscompleted.
![Page 105: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/105.jpg)
Ken Bradley’s Understanding PRINCE 2
105
Chapter 6
UNDERSTANDING THESTAGES COMPONENT
![Page 106: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/106.jpg)
![Page 107: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/107.jpg)
Ken Bradley’s Understanding PRINCE 2
107
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 thecommitment of resources by the Project Board and a decision to continue with the projectand authority to spend) and “Technical Stages” which comprise sets of technical activitiesleading to a stated Product.
Figure 52: Management and Technical Stages
Technical Stages will often overlap and be run in parallel; they are normally planned andmanaged by Team Managers (within the “Managing Product Delivery (MP1)” Process)who report to, and take direction from, the Project Manager. Management Stages, on theother hand, will always run in series; they will overlap only in exceptional circumstancesand always only with the prior agreement of the Project Board.
In the above diagram, the Technical Stages have been planned to run in parallel. Ofcourse, in a smaller project these might well be described as “Activities”; in medium tolarger projects, the Activities will often combine to provide the Technical Stages. In onlythe most exceptional circumstances will authority be given for work to commence on the
InitiateSpecifyDesignBuildTestTrainHand-over
ManagementStage 1
ManagementStage 3
Project Board Review of Management Stage- End Stage Assessment
(ESA)
Project Initiation Project Closure
ManagementStage 2
Technical Stages
![Page 108: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/108.jpg)
Ken Bradley’s Understanding PRINCE 2
108
next Management Stage before all the Products of the current Management Stage iscompleted.
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 theproject and provide the major control for the project. This is known as “LimitedCommitment”.
Approval of each Management Stage commits the effort, cost and time resourcescontained 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 ofendorsing continuation of the overall project.
The important thing here is that Project Board members understand that the estimates ofeffort, cost and time within the Project Plan are “soft” estimates only and certainly not castin stone. The originally approved Project Plan will be embodied in the approved ProjectInitiation 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 AProject (IP)” Process. Each Management Stage will culminate in an End StageAssessment (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 nextManagement 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 maywell result in nugatory expenditure.
Updating The Business Case
At the conclusion of each Management Stage, the Business Case must be reviewed andupdated. Specifically this will mean up-dating the statement of Business Benefits toconfirm that the project remains on track to achieve them. Where the Business Benefitsare supported by a Cost:Benefit Analysis, this must be re-assessed and the results reportedto the Project Board.
![Page 109: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/109.jpg)
Ken Bradley’s Understanding PRINCE 2
109
The Risk Assessment must also be reviewed and the Risk Log updated, minimally at thecompletion of each Management Stage.
Technical Stages
Technical Stages are quite different from Management Stages in that they will invariablybe planned to run in parallel, within one or more Management Stages. This saves timewithin the Management Stage and enables the best use to be made of the availableresources.
Figure 53: Creating The Stage Plan From The Project Plan
In most major projects, Technical Stages will be present, planned and controlled by TeamManagers working directly for the Project Manager.
Typically Technical Stages will address specific specialist areas of the project such asWork 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 beingundertaken by internal resources, such as the creation of the Specification for the project’soutcome, as illustrated in the diagram. This work will best be planned and managed by acustomer or user.
Handling The End Of A Management Stage
Handling Management Stage endings is a straightforward task once the basic principlesof PRINCE 2 planning and control are properly understood. The main feature to bear in
InitiateSpecifyDesignBuildTestTrainHand-over
ManagementStage 1
ManagementStage 2
ManagementStage 3
Start-UpProject BriefProject ApproachPIDInterview UsersProduce SpecOutline DesignFinal DesignAgree Design
Management Stage 1
![Page 110: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/110.jpg)
Ken Bradley’s Understanding PRINCE 2
110
mind is that as Management Stages must not run in parallel, some degree of planning forthe next Management Stage must be included within the current Management Stage.PRINCE 2 planning allows any combination of activities to be planned and executedprovided authority for the work is obtained from the Project Board. It is, therefore, quiteacceptable to be working on Products which will be delivered in the next ManagementStage provided approval and authority has been given. This enables Management Stagesto “butt” against each other and avoids the need to stop work on the project while ProjectBoard members assess the content of the End Stage Report, updated Project Plans, updatedBusiness Case, and the Next Stage Plans.
Figure 54: Handling Management Stage Endings
The approach does mean that a risk is being taken that, should the project be terminated atthe End Stage Assessment, some nugatory costs would have been incurred - but this risk iswell worth taking.
If, as is likely, the Project Board is unwilling to accept up to two weeks’ delay to theproject at every Management Stage end, this approach is the only real alternative. Failureto plan for Management Stage endings will inevitably put pressure on the Project Managerto undertake some preliminary work on the next Management Stage without formalauthority to do so, and this must be avoided.
Stages - Summary
Management Stages are key control components within a PRINCE 2 project. Adequatereview procedures must be established to ensure that commitment of effort and fundingresources is fully under the control of the Project Board.
“Natural” Stage End
Time needed for the ProjectBoard to review the papers& prepare for End Stage Assessment
Work, Effort & Cost“at risk”
Stage 1 Stage 2
![Page 111: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/111.jpg)
Ken Bradley’s Understanding PRINCE 2
111
UNDERSTANDING THERISK MANAGEMENT
COMPONENT
Chapter 7
![Page 112: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/112.jpg)
![Page 113: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/113.jpg)
Ken Bradley’s Understanding PRINCE 2
113
Introduction
PRINCE 2 places stress on the need for a strong and visible Business Case with theBusiness Benefits and Risk Management being key features within this concept. Nospecific techniques are suggested by the Method, although there are some pointers tocommonly available packages which will help, especially in the identification andmanagement of risk.
The risks perceived for any individual project will be summarised by the Project Managerat 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 narrativestatement of the perceived risks. However for higher profile, higher value, contentiousprojects a more formal risk assessment may be required by the Project Board.
Version 1 of the PRINCE Methodology referred to a Risk Analysis Checklist, originallyput 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 clientimplementations, 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). Itprovides a simple and structured way to identify the main risk areas for the project. Itshould not be regarded as a definitive statement of the precise risks faced by the projectbut rather as an indicator of the areas that are more likely than not to cause problems! TheRisk Analysis Checklist expresses the project manager’s feelings about the likely risksfaced A completed example of the Risk Analysis Checklist is included at the end of thisChapter.
The final score derived from the Risk Analysis will provide guidance for the proposals putforward by the project manager. Any score in excess of 15 should be extracted andproposals made to the Project Board for reducing or managing the risk. A suggestedformat for risk management proposals recorded in a Risk Log is as follows:
Figure 55: Risk Log
Description of the Risk Risk Score Comment on the Risk Proposals
The Project Manager hasonly limited experience ofmanaging a major projectof this type.
The Project Manager isalso responsible for 3other mainstream projectsbeing developed concurrently
21 The Project Manager has manyon-going responsibilities whichare expected to take up muchtime and effort (about 4 dayseach week). He also has noprevious experience of planningor managing a project of thissize and scope.
Proposal 1:The Project Manager toattend a Project Mgt.training course.
Cost: £2,000
Proposal 2:Buy in an experiencedProject Managementconsultant to advise theProject Manager andprovide support during thefirst two weeks of theproject.
Cost: £4,000
![Page 114: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/114.jpg)
Ken Bradley’s Understanding PRINCE 2
114
Risk Ranges & Risk Factors
The risk factors of 2.00 and 2.60 within the Checklist relate to the assessed risk for theproject recorded in column (b) which is always rated on a scale of 0.10 to 4.00. The normfor this scale is 2.00; any higher assessment would point to a higher than norm risk andany lower assessment points to a lower than norm risk.
Figure 56: The Risk Management Analysis Ranges
Applying a risk factor of 2.00 to the assessed weighting in column (e) provides acomparative 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 therisk 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 riskfor 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 thecomponent (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 somewhatarbitrary, based on experience and actual situations. The factor may be reduced orincreased as experience with project risk within an organisation is gained.
The risk Analysis Checklist includes a simple calculation for identifying the risk factor forthe project. Regular assessment should indicate a downward movement in the calculatedrisk factor as the project progresses towards its conclusion. Any consistent upwardmovement should be investigated and reported to the Project Board Executive.
Lower Risk
Higher Risk
2.00“Norm Risk”
0.10 4.00
Recommended“Norm” Range
1.00 3.00
2.00“Norm Risk”
![Page 115: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/115.jpg)
Ken Bradley’s Understanding PRINCE 2
115
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 hadthe 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 threshold2.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 (possiblyweekly) for the first 4 to 6 weeks of the project following approval of the PID, especiallywhere the initial risk factor is in excess of 2.20.
(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
![Page 116: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/116.jpg)
Ken Bradley’s Understanding PRINCE 2
116
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 reflectthe business, culture and types of project which predominate within the implementingorganisation. It will be noted that the Risk Analysis Checklist is particularly relevant tothe initiation of projects and contains comparatively little assessment of the on-goingcontrol and management of the project. It may well be that amendments to the standardchecklist would benefit from focusing on the control aspects.
RiskFactor Score
2.60 = 114
2.50 = 110
2.40 = 105
2.30 = 101
2.20 = 97
2.10 = 92.4
2.00 = 88
Very High Risk
High Risk
Moderate Risk
Low Risk
At ProjectInitiation
At End ofStage 1
At End ofStage 2
Continuous Risk Assessment by the Project Manager
![Page 117: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/117.jpg)
Ken Bradley’s Understanding PRINCE 2
117
STANDARD RISK ANALYSIS CHECKLIST
The Risk Factors which affect the probability that the project will be completed on time and within theagreed time and budget, and will deliver a quality-compliant End Product arise from six sources - ProjectManagement, The Project Staff, The Nature of the Project, The Maturity of the Development/SupplierOrganisation (Internal and External Suppliers), The Customer and the Contract, and Third PartySuppliers.
The project risks associated with each of these Elements are itemised and estimated below in the form ofstatements typifying Low and High Risk on either side of a scale of 0.10 to 4.00. The “norm” range usedis 1.00 to 3.00 and values outside this norm have only been used exceptionally and an explanation isprovided.
The assessed risk score under column (b) has been multiplied by the weighting factor inserted undercolumn (e) to provide a total risk score (rounded) for each question posed. Individual risks scoring inexcess 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 ofmovements in the project risk. A Risk Factor of 2.00 is the neutral measurement, greater than 2.0indicates an increasing project risk; lower indicates a reducing project risk.
Element Ref(a)
Low Risk(b)
Score(c)
High Risk(d)
SuggestedWeight
(e)Weight
(f)Total
ProjectManagement
1 Full time, experiencedProject Manager
3.00 Part time, inexperiencedProject Manager
5 to 7 7 21
2 Customer Managementexperienced and likelyto be active
3.00 Inexperienced CustomerManagement - littleparticipation expected
4 to 6 5 15
ProjectStaff
3 Customer staff likely tobe supportive and fullyinvolved in the project
2.30 Little Customer staffinvolvement expected andlittle contribution
3 to 6 3 7
4 High standard ofsupervision & narrowspan of control in theproject team
1.50 Wide span of supervisionand control expected to bepoor
4 to 6 4 6
5 Good quality projectteam, experienced withthe right skills
1.50 Inexperienced project teamlacking the key skills
6 to 8 6 9
6 Staff assigned full timeto the project
3.00 Staff have many otherresponsibilities
3 to 6 5 15
7 Low turnover of projectstaff
2.00 High turnover of projectstaff
4 to 7 7 14
8 Staff experienced atQuality Reviews
1.8 No experience of QualityReviews among staff
4 to 6 6 11
9 An organisationalcommitment to qualityexists
2.20 Staff take little interest inachieving a QualityCulture
4 to 6 6 13
![Page 118: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/118.jpg)
Ken Bradley’s Understanding PRINCE 2
118
Element Ref(a)
Low Risk(b)
Score(c)
High Risk(d)
SuggestedWeight
(e)Weight
(f)Total
Nature oftheProject
10 Typical project with astraightforwardlifecycle
2.20 A project lifecycle that hasa number of inter technicalrelationships
4 to 6 5 11
11 The project has no, orfew novel features
2.30 Pioneering newapproaches are being triedout in the project
6 to 8 5 12
12 Equipment beinginstalled by the projectis well known, tried andtested
2.10 Equipment is untried andits use in uncertain
4 to 6 5 10
13 Current mainoperations will be onlyminimally affected bythe project
3.00 Significant impact oncurrent main operations bythe project
3 to 5 5 15
14 The Requirements are,or will be, wellestablished and welldocumented by theCustomer
2.00 Requirements are(expected to be) poorlyunderstood, documentedand presented by theCustomer
3 to 6 5 10
15 Little or nomodification needed toexisting technicalstandards
2.60 Extensive modificationneeded to existingtechnical standards will beneeded
3 to 6 5 13
16 Little project work isbeing undertakencurrently
2.80 Other project work isbeing carried out inparallel with this project
3 to 6 5 14
17 There is littledependence ondevelopment facilitiesnot under the control ofthe project team
2.80 There is a dependence ondevelopment facilitieswhich are outside thecontrol of the project team
3 to 7 6 17
18 Project duration is lessthan 6 months or thereis only a small numberof workdays required
2.60 Project duration is longerthan 6 months or there is ahigh number of workdays
2 to 5 4 10
19 There is little or noconstraint on thecompletion date
3.00 There is a mandatorycompletion date stated bythe Customer
4 to 7 6 18
20 Plans and estimates are(will be) based onreliable data fromsimilar projects
3.00 Plans and estimates are(will be) based onunreliable data -essentially “green field”
4 to 7 6 18
21 Estimates have beenprepared using welltried and documentedstandards
2.60 Approximations have beenused based on unreliablestandards
4 to 7 6 16
22 This is the first orsecond attempt at thisproject - ie there is nohistory of consistentfailure
2.90 There have been two ormore attempts to completethis project - ie it has ahistory of failure
4 to 8 7 20
![Page 119: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/119.jpg)
Ken Bradley’s Understanding PRINCE 2
119
Element Ref(a)
Low Risk(b)
Score(c)
High Risk(d)
SuggestedWeight
(e)Weight
(f)Total
23 Few CustomerDepartments will beaffected by the finaloutcome
3.00 Many CustomerDepartments will beaffected by the finaloutcome
4 to 6 5 15
24 The project work willaffect few Customersites
2.80 Many Customer sites willbe impacted by the projectwork
3 to 6 6 17
25 Sites which the projectteam will visit are easilyaccessible
2.90 Sites are remote andinaccessible
3 to 6 6 17
26 There will be onlyminor impact on theCustomer’s day to daywork during the projectcycle
2.50 There will be significantimpact on the Customer’sday to day work during theproject
3 to 6 4 10
27 Well developed andunderstood ProjectManagement Standardswill be available to theproject team
1.50 Few Project ManagementStandards will be availableto the project team
4 to 7 5 7
Maturityof theOrganisation
28 There is a welldeveloped andunderstood QualityEnvironment - ie anaudited QualityManagement System
1.80 Quality Management is illdefined and/or not visible
4 to 7 5 9
29 Clear delegation ofauthority is practised bymanagement
2.00 There is strict centralmanagement control withlittle empowerment ordelegation
3 to 6 5 10
30 Project Staff will wishto make use of thepublished ProjectManagement Standards
2.00 Project Staff are notexpected to utilise anyProject ManagementStandards that exist
3 to 6 5 10
TheCustomerand theContract
31 The Customerdemonstrates a fullunderstanding of theRequirement and itsimpact
1.90 The Customerdemonstrates a poorunderstanding of theimpact of the Requirement
4 to 7 6 11
32 There will be little or nomodification needed tothe Customer’s existingfacilities
2.20 Extensive modification tothe Customer’s existingfacilities is expected
3 to 6 5 11
33 An agreed contract is inexistence
3.00 No formal contract is yet inplace
4 to 7 6 18
34 There have beenprevious dealings withthe Customer andprevious contracts havebeen brought to asatisfactory conclusion
1.80 There have beendifficulties when dealingwith this Customer onearlier contracts
3 to 7 6 11
![Page 120: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/120.jpg)
Ken Bradley’s Understanding PRINCE 2
120
Element Ref(a)
Low Risk(b)
Score(c)
High Risk(d)
SuggestedWeight
(e)Weight
(f)Total
ThirdPartySupplier
35 Suppliers are known,approved and have asatisfactory trackrecord
2.00 The Suppliers are new andlittle is known about theircapabilities
4 to 8 6 12
36 Only one, wellestablished, approvedSupplier will be used toprovide the services
2.00 Multiple Suppliers (withSub-Contractor elements)are anticipated
3 to 6 6 12
37 Suppliers have anestablished StructuredProject ManagementMethod based onPRINCE or similar
2.00 Supplier projectmanagement arrangementsare ad-hoc with littlevisible definition
3 to 6 6 12
38 A Supplier contract is inexistence
1.50 Informal arrangementsonly exist
4 to 7 6 9
39 The main Supplier has afully audited QualityManagement System toISO9001
1.50 The main Supplier has nopublished QualityManagement System
4 to 7 6 9
40 The future level ofSupplier performance isexpected to be excellent
1.80 The future level of Supplierperformance is un-assessable because toolittle is known
3 to 6 6 11
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.
![Page 121: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/121.jpg)
Ken Bradley’s Understanding PRINCE 2
121
UNDERSTANDING THE
QUALITY MANAGEMENTCOMPONENT
Chapter 8
![Page 122: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/122.jpg)
![Page 123: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/123.jpg)
Ken Bradley’s Understanding PRINCE 2
123
PRINCE 2 & BS/EN/ISO9001
PRINCE 2 has been designed to comply with the BS/EN/ISO9001 Quality ManagementStandard and the method contains a section relating its content to each section of the ISOStandard.
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 apublished quality environment with defined standards and procedures. The PRINCE 2Manual contains a fairly detailed review of all parts of ISO9001 and states the extent towhich each of the parts of the full ISO standard is met by PRINCE 2.
Quality Management
Figure 59 : The Quality Structure
The prime aim of Quality Management within a project environment is to ensure that thequality expected by the customer is delivered within the project and extends beyonddelivery of the outcome.
Quality Management System
Organisation Structure
Procedures
Processes
Quality Policy Statement
Quality Manual
Quality AssuranceSet up & Audit of Quality Management System
Quality Planning Quality Control* Objectives & Requirements* Overall Approach* Project Quality Plan* Stage Quality Activities
* Measurement Against Quality Criteria* Measuring Against Requirements
![Page 124: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/124.jpg)
Ken Bradley’s Understanding PRINCE 2
124
Figure 53 summarises the main components of a quality structure. The PRINCE 2 Methodprovides 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 andplanning for quality within each Product or Deliverable being a major part of “Planning AStage (SB1)” as the project proceeds.
Specific Product quality planning occurs with the creation of a Product Description foreach project-level and Management Stage-level Product. The vehicle for this is theProduct Description which states the Quality Criteria, type of quality check and the peoplewho need to be involved.
Quality Control is effected in the most sensible way for the Product under scrutiny and theorganisation. PRINCE 2 includes the technique of Quality Review to provide the means ofassessing a Product against its stated Quality Criteria but leaves selection of the mostappropriate 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 firstplace, 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 statedwithin 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 ProjectInitiation Document (“Initiating A Project (IP)” Process).
The results of the quality planning activity must be integrated into the timescale andresource plans at each level. Just as quality must be built into the Products, so must qualitycontrol be built into the plans. Within PRINCE 2, Planning for Quality within the projecttakes place predominantly in the “Initiating A Project (IP1)” Process where the QualityManagement Systems of both the Customer and the Supplier are used to prepare afoundation of quality for the project.
This does not, of course, mean that quality matters are taken into account only during thisProcess; quality is a component which takes prominence throughout the life of the projectand 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 outcomemay be undertaken, under contract, by an external supplier; in most projects, there will bethe 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 carryout the quality control function is outside the direct control of the Project Manager. Theapproach used within the Method is to provide the “supplier” (internal or external) with aclear statement of what is wanted, the quality standard that must be adhered to and thereporting requirements, in the form of an authorised Work Package.
![Page 125: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/125.jpg)
Ken Bradley’s Understanding PRINCE 2
125
The authorised Work Package may take the form of a formal contract or, where thesupplier of the Product or service is internal, a memorandum. The typical content for anWork 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 WorkPackage; this will contain the specific Quality Criteria and checking arrangements thatmust 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 fordiscussion where necessary and agreement before work commences. Completed WorkPackages (Products/Deliverables) are delivered back into the commissioning organisationon completion of the work. Completed Work Packages should always be complete andQuality Reviewed in accordance with the agreed Work Package. Where there aredifficulties with the quality of supplier’s products, it will be necessary to set up additionalquality review/control arrangements within the customer’s organisation. In such cases asmoothly 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 requiredby the customer. Quality Criteria must be defined and agreed, and incorporated into aProduct Description for each major Product identified; a Project Quality Plan must bedefined, published and adopted; Quality Review procedures must be established and stafftrained; review activities must be properly resourced. Whatever action is proposed tobuild quality into the project, the measures must be consistent with any published QualityManagement System (QMS) that is already in effect.
![Page 126: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/126.jpg)
![Page 127: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/127.jpg)
Ken Bradley’s Understanding PRINCE 2
127
UNDERSTANDING THECONFIGURATION MANAGEMENT
COMPONENT
Chapter 9
![Page 128: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/128.jpg)
![Page 129: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/129.jpg)
Ken Bradley’s Understanding PRINCE 2
129
Configuration Management - Introduction
A configuration is a logically related set of products which need to be managed as acomposite set. The “Configuration” to be managed may, therefore, be summarised as thesum total of all the equipment, instructions, information used, and documentation whichtogether represent the total of the Products or Deliverables from the project.
Configuration Management Techniques
Configuration Management (CM) provides techniques and procedures to perform thefollowing functions:
♦ Identifying the individual items which are to be managed. These are referred to asConfiguration 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 andthe Product itself.
In PRINCE 2, Configuration Management is not optional. All the above functions arenecessary for successful projects. Without CM, managers would have little or no controlover 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 shouldbe observed; it should be possible to use the following list of criteria during the selectionprocess 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;
![Page 130: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/130.jpg)
Ken Bradley’s Understanding PRINCE 2
130
♦ 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 therelationships between the configuration items, so that no configuration item is changedwithout triggering a check for possible ramifications in its neighbours.
CM Activities
The word “configuration” has in the past been associated mainly with equipment and theterm “Configuration Management” was originally applied to the control of hardwaredevelopment and production. Nowadays, however, it is internationally accepted thatConfiguration 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 managementof project Specialist Products and the associated Documentation.
Configuration Management consists of four basic activities which together assist in themanagement and control of development projects:
♦ Configuration Identification; ♦ Configuration Control; ♦ Status Accounting; ♦ Configuration Audits.
Configuration Management is a service function which assists in making both thespecialist and managerial activities more effective. Effectiveness of the CM processesincreases in proportion to the degree that the discipline is part of the normal day-to-dayactivities of everyone involved in the project.
Configuration Management practices offer support to the specialist activities as well asproviding management with the information necessary for controlling Products as they areproduced by the project teams.
![Page 131: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/131.jpg)
Ken Bradley’s Understanding PRINCE 2
131
Configuration Management oversees all the Products of a project by controlling access tothem and by maintaining records of their status. Operation of Configuration Managementwill benefit from the appointment of a Configuration Manager or Configuration Librarianas custodian of master copies of all project Products. This role can be combined with theProject Support role where appointed. Where no specific appointment has been made, andwhere a Project Support role has not been confirmed by the Project Board, the ProjectManager is responsible for Configuration Management of the project’s Products.
![Page 132: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/132.jpg)
![Page 133: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/133.jpg)
Ken Bradley’s Understanding PRINCE 2
133
UNDERSTANDING THECHANGE CONTROL COMPONENT
ANDCHANGE CONTROL TECHNIQUE
Chapter 10
![Page 134: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/134.jpg)
![Page 135: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/135.jpg)
Ken Bradley’s Understanding PRINCE 2
135
Change Control - Introduction
There are three types of changes which can be raised within a project under a PRINCE 2controlled project; they are used to document desired change to, or some failure in, theproject's products; they are:
♦ Project Issue; ♦ Off-Specification; ♦ Request for Change.
This chapter is written on the assumption that exceptions will be controlled by aConfiguration Manager. If no such role has been allocated, control of exceptions will bethe 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 aProject 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 canbe raised by anyone, at any point during the project. Changes to Products after completionand hand-over of the project outcome (ie after project closure) will not be subject to theproject's change control procedures, but will be dealt with in accordance with the organi-sation's normal maintenance and enhancement procedure standards. Errors discovered ata Quality Review are only noted on a Project Issue (Report) if the error relates to an itemother than that which is being reviewed, or an error which is unlikely to be corrected viathe normal Follow Up procedures.
![Page 136: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/136.jpg)
Ken Bradley’s Understanding PRINCE 2
136
At the end of the project all Project Issues should be closed (ie signed off, indicating thatthe 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 referenceand provide a summary of the status of all Project Issues raised, should be provided to theSenior User/Customer at each End Stage review for prioritisation of outstanding ProjectIssues. This might involve the Senior User in “canvassing” the other Project Boardmembers 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 failsto meet its specification in some respect. The error(s) it describes are less likely to becorrected and, as a consequence, are more likely to remain in the delivered output of theproject. For this reason Off-Specifications are normally filed in the approvedConfiguration Items File.
Off-Specifications are normally raised by the Project Manager, Team Manager, or ProjectBoard after analysis of received Project Issue Reports. The method does, however allowthe 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 isin order to bring them forward as the basis for a separate enhancement project after themain 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 deliveredoutput of the project and is raised by the Project Manager, Team Manager or Project Boardas a result of either analysis of a Project Issue or the decision to rectify a deficiencycurrently recorded in an Off-Specification. As with the Off-Specification, the originator ofan issue may identify it as a Request for Change - this will be most appropriate incircumstances 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 Reportforms. 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; howeversuitable forms are available from within the IBM PRINCE Environment and the SPOCEProject Management Launch Pad.
![Page 137: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/137.jpg)
Ken Bradley’s Understanding PRINCE 2
137
Change Control - Summary
More information on the PRINCE 2 change control procedures are contained in thePRINCE 2 Manual. It is advisable, however to check with the Quality Manager, ProjectSupport Office or Project Assurance representative as existing, effective, change-controlprocedures 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 willnormally be through completion of all outstanding work on them but, exceptionally,Requests for Change still not started or incomplete may be transferred to an enhancementproject. This device can be used to effect customer and business sign-off of the mainproject. Some Off-Specifications may be present throughout the whole life of the outputof the project. Outstanding Off-Specifications should be considered for an enhancementproject, possibly on a year-by-year basis.
Figure 60: Suggested Change Control Procedure Based On PRINCE 2 Principles
A diagram summarising a suitable change control procedure is as follows. Each stage ofthe process is logged into the Issues Log. On completion of the project all the ProjectIssues must be resolved - either by rejection or conversion to a Request for Change, or anOff-Specification. However, the originator may identify the particular category of ProjectIssue at the time it is raised. The summary provides an enhancement of the PRINCE 2suggested procedure.
* Good Ideas* Errors* Departures From Agreed Specification* Resource Changes* Specification Changes
Project Issue(Request for Changeor Off-Specification)
Originator Raises A
Sent to Project Support
Logged byProject Support
Reviewed by Project Manager
Project Issues Log
* 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.
Project Issues Log Up-dated
Notify OriginatorCopy returnedto confirm receipt
![Page 138: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/138.jpg)
![Page 139: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/139.jpg)
Ken Bradley’s Understanding PRINCE 2
139
Chapter 11
UNDERSTANDING THEPRINCE 2 PROCESSES
![Page 140: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/140.jpg)
![Page 141: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/141.jpg)
Ken Bradley’s Understanding PRINCE 2
141
Introduction To Processes
PRINCE 2 focuses on the Processes that are needed to manage a successful outcome forany project. The Processes identified in PRINCE 2 represent the minimum content for aPRINCE-compliant project but this certainly is not intended to encourage slavishfollowing of any or all of them! The key to successful management of a project is toensure that each of the Processes identified within a PRINCE 2 controlled project areaddressed in one form or another; how each Process is actually interpreted as a projectmanagement procedure is left to the implementing organisation, or where anorganisational-wide implementation has not been made, the Project Board and ProjectManager.
Of course, the concept of a process-driven approach is not new; Project Managers havealways used the processes of starting, managing and closing their projects, and seniormanagers have always been involved in the processes of direction and decision makingwhether they realised it or not! PRINCE 2 formalises these implied processes and setsthem into the context of a successful management.
The Processes
There are eight major Processes in all, identified within the PRINCE 2 methodology; theeighth Process of “Planning (PL)” is used by all the other Processes. The eight majorProcesses 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 ProductDelivery” where the work of teams and each individual Team Member is planned. Inaddition to these Processes, “Planning” also makes a contribution to all others
![Page 142: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/142.jpg)
Ken Bradley’s Understanding PRINCE 2
142
The PRINCE 2 Process Model
The overall structure of the PRINCE 2 Process Model can be summarised as follows:
Figure 61: Structure Model of the PRINCE 2 Process Model And Major Product Flows
* Request for Exception Plan
* SU1 - Appoint Exec & PM* SU2 - Design A Team* SU3 - Appoint A Team* SU4 - Prepare Brief* SU5 - Prepare Approach* SU6 - Prepare Initiation Plan
* IP1 - Plan Quality* IP2 - Plan Project* IP3 - Refine Bus Case & Risks* IP4 - Set Up Controls* IP5 - Set Up Files* IP6 - Assemble PID
* DP1 - Authorise Initiation* DP2 - Authorise Project* DP3 - Authorise Stage or Exception Plan* DP4 - Give Ad-Hoc Direction* DP5 - Project Close
* CS1 - Authorise Work Package* CS2 - Assess Progress* CS3 - Capture Project Issues* CS4 - Examine Project Issues* CS5 - Review Stage Status* CS6 - Report Highlights* CS7 - Take Corrective Action* CS8 - Escalate Project Issues* CS9 - Receive Completed Work Package
* MP1 - Accept Work Package* MP2 - Execute Work Package* MP3 - Deliver Work Package
* SB1 - Plan A Stage* SB2 - Up-date Project Plan* SB3 - Up-date Business Case* SB4 - Up-date Risk Log* SB5 - Report Stage End* SB6 - Produce Exception Plan
* CP1 - Decommission A Project* CP2 - ID Follow-on Actions* CP3 - Project Evaluation Review
SU
IP
DP
CS
MP
CP
* Project Brief* Project Approach* Organisation* Plan for Initiation Stage
* Authorisation To Proceed
*Draft Project Initiation Document (PID) * Trigger forNext Stage Plan
* Next Stage Plan
* Exception Plan
* Trigger - Next Stage Plan
* Authorisation To Proceed
* Direction* Highlight Reports
* Customer Acceptance* End Project Report* Project Evaluation* Lessons Learned* Follow-on Items* Post-Project Review Plan
* Work Package + Confirmation of Acceptance
* Checkpoint Reports
* Project Start Notification* Project End Notification
* Premature Close
PL
* Completed Work Package
* Project Issues
* Project Mandate
Archive Files
* Trigger - End Project
* Product Based Planning
* Exception Reports
* Info from External Sources & Feedback
*Requests For Advice
SB
![Page 143: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/143.jpg)
Ken Bradley’s Understanding PRINCE 2
143
Each of the major Processes has associated Processes which drive the management of theproject through the use of Components and Techniques, The Processes do not link withany required way of achieving the required outcome; this enables the use of anytechniques which are appropriate to the business and reflects the flexibility which comesas 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 jobdone. A table relating each Process to its parent, major Process is useful to illustratewhere each Process resides within the overall Process Model and a summary of each majorProcess and its “children” is particularly helpful to anyone intending to take the APMGroup 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 isinvolved and obtaining agreement and commitment to a formal baseline for theproject.
♦ 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 bythe Project Manager, on behalf of the Project Board.
♦ Managing Product Delivery – Creating, modifying and obtaining the Products orDeliverables.
♦ Managing Stage Boundaries – Taking stock of the current situation and getting readyfor the next part (Management Stage) of the project.
♦ Closing A Project – Ensuring the project has properly completed prior to formalclosure of the project by senior management.
♦ Planning – Planning steps that are common to all the Processes except “ControllingA 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 2Method to provide a comprehensive “best practice” Project Management Method.
![Page 144: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/144.jpg)
Ken Bradley’s Understanding PRINCE 2
144
A summary chart of Processes and Sub-Processes is shown below:
Parent Process Sub-Process
Sub-Process Name
Starting Up A Project SU1 Appointing A Project Board Executive & Project Manager(SU) SU2 Designing A Project Management Team
SU3 Appointing A Project Management TeamSU4 Preparing A Project BriefSU5 Defining Project ApproachSU6 Planning An Initiation Stage
Initiating A project IP1 Planning Quality(IP) IP2 Planning A Project
IP3 Refining The Business Case and RisksIP4 Setting Up Project ControlsIP5 Setting Up Project FilesIP6 Assembling A Project Initiation Document
Directing A Project DP1 Authorising Initiation(DP) DP2 Authorising A Project
DP3 Authorising A Stage Or Exception PlanDP4 Giving Ad-Hoc DirectionDP5 Confirming Project Closure
Controlling A Stage CS1 Authorising A Work Package(CS) CS2 Assessing Progress
CS3 Capturing Project IssuesCS4 Examining Project IssuesCS5 Reviewing Stage StatusCS6 Reporting HighlightsCS7 Taking Corrective ActionCS8 Escalating Project IssuesCS9 Receiving A Completed Work Package
Managing Product MP1 Accepting A Work PackageDelivery MP2 Executing A Work Package(MP) MP3 Delivering A Work Package
Managing Stage SB1 Planning A StageBoundaries SB2 Updating A Project Plan(SB) SB3 Updating A Project Business Case
SB4 Updating The Risk LogSB5 Reporting Stage EndSB6 Producing An Exception Plan
Closing A Project CP1 Decommissioning A Project(CP) CP2 Identifying Follow-on Actions
CP3 Project Evaluation Review
![Page 145: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/145.jpg)
Ken Bradley’s Understanding PRINCE 2
145
Planning PL1 Designing A Plan(PL) PL2 Identifying, Defining And Analysing Products
PL3 Identifying Activities And DependenciesPL4 EstimatingPL5 SchedulingPL6 Analysing RisksPL7 Completing A Plan
Structure of the Individual Process Models
Each of the major Processes and Processes is described by reference to a commonformula:
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 itis trying to achieve.
Context
♦ The relationship with the other Processes and external activities. A Context Diagramis 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 andoutputs as a quick guide. Process Description ♦ An explanation of the objectives of the Process and a statement of the steps containedwithin it. The steps identified are in no particular order and are not intended to becomprehensive. This section contains the “meat” of the Process and provides a fair commentary on whatthe Process sets out to achieve, together with the means of achieving it. There is littleattempt to describe how the Process is expected to work in practice, as the PRINCE 2Method addresses mainly “What” and “Why” with a much restricted “How” confinedmainly to the “Techniques” Section.
![Page 146: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/146.jpg)
Ken Bradley’s Understanding PRINCE 2
146
Responsibilities ♦ Identification of who should be held accountable for the successful conduct of theProcess, and responsible for its management. Generic responsibilities (Project Board, Project Manager etc) only are provided andimplementing organisations need to look very carefully at assignment of key projectactivities to specified personnel. Information Needs ♦ The key information needed for the Process to function in such a way to meet itsobjectives. 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 ofthe Process. Read in conjunction with the Context Diagram, a good understanding of thecomplete Input/Process/Output cycle can be obtained. Key Criteria ♦ Identification of significant issues which will impact upon and affect the successfulworking of the Process. These criteria are generally straightforward and pose little difficulty in their understandingand implementation. They are important in that they represent the minimum standard forany PRINCE 2-compliant project. In essence, any PRINCE 2-compliant project willaddress all eight Processes in one form or another and each of the Processes will meet theKey Criteria stated here. Hints and Tips ♦ Guidance on the application of the Process within a PRINCE environment; the methodrecommends that this section be augmented by reference to specific situations encounteredduring the use of PRINCE on projects within the implementing organisation. The Hints and Tips contained throughout the PRINCE 2 Manual should not be viewed asan integral part of the Method but rather as helpful guidelines. Much of the PRINCE 2 Manual is given to describing the Processes using the aboveheadings. Understanding the structure of the Processes and their objectives is fundamentalto the successful use of the method. PRINCE may be likened to an organic structurewhich must be allowed to mature and adapt to fit changing circumstances and newknowledge 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.
![Page 147: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/147.jpg)
Ken Bradley’s Understanding PRINCE 2
147
Scalability ♦ All PRINCE controlled projects will address all eight major Processes in some formand the key question to be posed is “How extensively should this Process be applied onthis project?”. Each of the eight major Processes includes a section on “Scalability” which providessuggested approaches to scaling the major Process to reflect the size and scope of theparticular project. A “Scalability” section is not included within each Process definitionbut the principles established in the major Process may be used to provide a suitablesolution.
Individual Process Summary Models On the pages that follow are summaries of the inputs and outputs for each of the Processeswithin the PRINCE 2 Method. The summaries also indicate the action performed on aProduct 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 fromthe PRINCE 2 Manual, with minor amendments and corrections made.
![Page 148: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/148.jpg)
![Page 149: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/149.jpg)
Ken Bradley’s Understanding PRINCE 2
149
Chapter 12
UNDERSTANDING THE STARTING UP A PROJECT (SU)
PROCESS
![Page 150: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/150.jpg)
![Page 151: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/151.jpg)
Ken Bradley’s Understanding PRINCE 2
151
Starting Up A Project (SU) - Introduction
This is the first Process within a PRINCE 2 managed project. A Project Mandate in theform of a memo, formal or informal request will normally trigger this Process, althoughthere is no prescribed format.
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 oftenposed by managers who find that they are asked to carry out planning and preparatorywork 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 suitableProject Management Team, identify a realistic approach to the work to be done, andplanning for the next stage of the work (normally the Initiation Stage). The projectformally exists at the conclusion of this Process when the Project Board will be asked togive a “go/no-go” decision on whether there is the rationale, will and business need for theproposed project. This decision will normally take place at a “Project Initiation Meeting(PIM) which marks the formal start to the project.
Appointing aPB Executiveand PM
SU1
Designing aProjectManagementTeam SU2
Appointing aProjectManagementTeam SU3
Preparing aProject Brief
SU4
DefiningProjectApproach
SU5
Planning anInitiation Stage
SU6
AuthorisingInitiation
DP1
PlanningQuality
IP1
Assemblinga PID
IP6
ProjectBrief
ProjectApproach
ProjectManagement Teamstructure and jobdescriptions Project
Brief
ProjectMandate
Draft InitiationStage Plan
![Page 152: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/152.jpg)
Ken Bradley’s Understanding PRINCE 2
152
SU1 - Appointment of a Project Board Executive and a ProjectManager
To get any undertaking under way, there is a need for a decision-maker (the Project BoardExecutive) and a planner (the Project Manager). As soon as the project is “floated” by thereceipt of a Project Mandate, these two appointments must be made by CorporateManagement. Between them they will arrange to set up the proposed project in an orderlyand structured way by creating suitable decision-support documentation comprising TheProject Brief, The Project Management Team, The Project Approach, and the Plan for theInitiation Stage.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Board ExecutiveAppointment [C]
Designing A ProjectManagement Team(SU2)
SU1 –AppointingA ProjectBoardExecutive &ProjectManager
Project Mandate(CorporateManagement)
Project Manager Appointment [C] Designing A ProjectManagement Team(SU2)
Figure 63: SU1 Plus Inputs and Outputs
The appointment of the Project Board Executive and the Project Manager will allow anumber of Products to be started. Although the PRINCE 2 Manual indicates an order ofprecedence - 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 onthe Project Approach and the Project Brief. These two documents will have a majorinfluence on the design of the Project Management Team and identification of the mostappropriate individuals to make the project management actually work.
In practice, the Executive needs to have a close involvement with the production of theProject Approach and the Project Brief, as these are the two prime documents which willprovide the decision support information for the Project Board Members when they areasked to approve the Initiation Stage of the project.
![Page 153: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/153.jpg)
Ken Bradley’s Understanding PRINCE 2
153
SU2 & SU3 - The Project Management Team
The Project Management Team is the group of people who are responsible for theplanning, management , and control of the project. It might not always be possible toappoint the whole team at this early stage but as many of the key appointments as possibleshould be made.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
SU2 –Designing AProjectManagementTeam
Project Mandate(CorporateManagement)
Executive & ProjectManagerAppointment (SU1)
Project Management TeamStructure [C]
Appointing A ProjectManagement Team(SU3)
Job Definitions [C] Assembling A PID (SU6)
Authorising Initiation(DP1)
SU3 –Appointing AProjectManagementTeam
ProjectManagement TeamStructure (SU2)
Project Management TeamStructure [C]
Assembling A PID (SU6)
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 foreach member of the Project Management Team. A start point for these is included atAppendix C of the PRINCE 2 Manual. It is important to ensure that each member of theProject Management Team clearly understands the expectations that go with the job, andthe Role Descriptions ensure that this is clearly communicated. Role Descriptions willapply to all members of the Project Management Team including the senior managers whoare on the Project Board for the project.
Responsibility for establishing the Project Management Team rests jointly with theExecutive and Project Manager, the Executive taking the lead in identifying andappointing the Project Board Members. When the Project Management Team has beenestablished it will accompany the other outputs of SU to be endorsed by the newlyestablished Project Board during consideration of the Initiation Stage Plan in DP1. Thesource documentation will be used to assemble the Project Initiation Document in IP6
![Page 154: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/154.jpg)
Ken Bradley’s Understanding PRINCE 2
154
SU4 - The Project Brief and Its Relationship To The ProjectMandate
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, basedon the information contained in the Project Mandate
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Brief [C] Defining ProjectApproach (SU5
Planning An InitiationStage (SU6)
Planning Quality (IP1)
Planning A Project (IP2)
Refining The BusinessCase & Risks)
Assembling A PID (IP6)
Authorising Initiation(DP1)
SU4 –Preparing AProjectBrief
Project Mandate(CorporateManagement)
Risk Log [C] Planning An InitiationStage (SU6)
Planning A Project IP2
Refining The BusinessCase & Risks (IP3)
Figure 65: SU4 Plus Inputs and Outputs
The Project Brief is based on the Project Mandate which provides the “trigger” for theproject. The Project Mandate may take any form from an informal request by a seniormanager 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 ProjectBrief will take a fair amount of effort to complete. On the other hand, where the ProjectMandate 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 ProjectBoard, to decide whether the proposed project merits the time and effort needed to produce
![Page 155: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/155.jpg)
Ken Bradley’s Understanding PRINCE 2
155
a Project Initiation Document. It needs to address the fundamental reasons and constraintsthat support the proposal for the project - it is essentially a “first-cut” Project InitiationDocument.
The Customer’s Acceptance Criteria are contained within the Project Brief and althoughthe Product Outline for the Project Initiation Document , included in the PRINCE 2Manual , does not specifically mention the Acceptance Criteria within the “Composition”section, it makes sense to incorporate Acceptance Criteria within the PID as these can thenbe used for comparative purposes at each Management Stage review (End StageAssessment), at Project Closure (“Decommissioning A Project (CP1)”) where CustomerAcceptance is obtained, and in “Confirming Project Closure (DP5)” where the project isformally shut down.
![Page 156: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/156.jpg)
Ken Bradley’s Understanding PRINCE 2
156
SU5 - The Project Approach:
A suitable Approach to the project must be considered, discussed with the Project BoardExecutive Member and agreed before seeking authority to prepare a Project InitiationDocument (acceptance of which by the full Project Board will signal the formal start of theproject). 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,UPDATED, REFERENCED OR
USED
OUTPUT TO
SU5 –DefiningProjectApproach
Project Brief (SU4)
Risk Log (SU4)
Project Approach [C] Planning An InitiationStage (SU6)
Planning Quality (IP1)
Planning A Project (IP2)
Refining The BusinessCase & 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 theProject Brief (and possibly also the Project Initiation Document). It provides a majorcontribution to planning the project - Initiating A Project (IP2).
![Page 157: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/157.jpg)
Ken Bradley’s Understanding PRINCE 2
157
SU6 - The Initiation Stage Plan
A suitable plan for the Initiation Stage must be produced to enable the Project Board toauthorise the creation of a suitable Project Initiation Document (PID) to authorise thecommencement of the project. Production of the PID might well consume considerabletime, effort and cost and is a key document that will be used to Baseline the project. Ittherefore needs to be properly planned, resourced and authorised at a level appropriate tothe investment being proposed.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Draft Initiation Stage Plan [C]
Authorising Initiation(DP1)
SU6 –Planning AnInitiationStage
Project Brief (SU4)
Risk Log (SU4)
Project Approach(SU5)
Risk Log [U] Authorising Initiation(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 provideauthorisation 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 playduring the first Stage of the project - these include “Controlling A Stage (CS)”,“Managing Product Delivery (MP)”, “Managing Stage Boundaries (SB)”. Because of theinvolvement in the authorisation processes, the Project Board will also be in play withinthe “Directing A Project (DP)” Process.
The “Planning (PL)” Process, the “Planning A Stage (SB1)” Process, and the ProductBased Planning Technique, are all used in Planning An Initiation Stage. The planningaspects are straightforward as there is a need only to plan for a short time-scale and for avery simple series of Products and related Activities.
![Page 158: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/158.jpg)
Ken Bradley’s Understanding PRINCE 2
158
Starting Up A Project - Summary
This Process, with the next (“Initiating A Project (IP)”) is critical to the success of anyPRINCE 2 project as it sets the scene, expands the often flimsy Project Mandate, and laysdown the foundation for the organisational structure for the project. It will often becombined with the IP Process and others, especially where a smaller project is beingaddressed. If “Starting Up A Project (SU)” serves to put a brake on the understandableenthusiasm to commence development work before the basics of the project have beenthought through, then it will have served its purpose.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Board ExecutiveAppointment [C]
Designing A ProjectManagement Team(SU2)
SU1 –Appointing AProjectBoardExecutive &ProjectManager
Project Mandate(CorporateManagement)
Project Manager Appointment [C] Designing A ProjectManagement Team(SU2)
SU2 –Designing AProjectManagementTeam
Project Mandate(CorporateManagement)
Executive & ProjectManagerAppointment (SU1)
Project Management TeamStructure [C]
Appointing A ProjectManagement Team(SU3)
Job Definitions [C] Assembling A PID (SU6)
Authorising Initiation(DP1)
SU3 –Appointing AProjectManagementTeam
ProjectManagement TeamStructure (SU2)
Project Management TeamStructure [C]
Assembling A PID (SU6)
Authorising Initiation(DP1)
![Page 159: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/159.jpg)
Ken Bradley’s Understanding PRINCE 2
159
Project Brief [C] Defining ProjectApproach (SU5
Planning An InitiationStage (SU6)
Planning Quality (IP1)
Planning A Project (IP2)
Refining The BusinessCase & Risks)
Assembling A PID (IP6)
Authorising Initiation(DP1)
SU4 –Preparing AProject Brief
Project Mandate(CorporateManagement)
Risk Log [C] Planning An InitiationStage (SU6)
Planning A Project IP2
Refining The BusinessCase & Risks (IP3)
SU5 –DefiningProjectApproach
Project Brief (SU4)
Risk Log (SU4)
Project Approach [C] Planning An InitiationStage (SU6)
Planning Quality (IP1)
Planning A Project (IP2)
Refining The BusinessCase & Risks (IP3)
Assembling A PID (IP6)
Authorising Initiation(DP1)
Planning (PL)
Draft Initiation Stage Plan [C]
Authorising Initiation(DP1)
SU6 –Planning AnInitiationStage
Project Brief (SU4)
Risk Log (SU4)
Project Approach(SU5)
Risk Log [U] Authorising Initiation(DP1)
Figure 68: Summary of the “Starting Up A Project (SU) Process
![Page 160: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/160.jpg)
![Page 161: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/161.jpg)
Ken Bradley’s Understanding PRINCE 2
161
UNDERSTANDING THE
INITIATING A PROJECT (IP)
PROCESS
Chapter 13
![Page 162: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/162.jpg)
![Page 163: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/163.jpg)
Ken Bradley’s Understanding PRINCE 2
163
Initiating A Project (IP) - Introduction
The “Initiating A Project (IP)” Process is aimed at ensuring that a firm Baseline existsfor the project and that everyone involved understands what the project is seeking toachieve. In smaller projects, this Process might well be combined with the “Starting Up AProject (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 bothProcesses may be combined within the same Management Stage.
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 beused throughout the project to ensure that the work carried out and theProducts/Deliverables being produced are supporting the key objectives and meet thecustomer’s needs. The PID will always need to address the following:
♦ to identify the benefits and risks and to evaluate proposals for managing identifiedareas of risk, thus confirming that an acceptable Business Case exists for the project;
PlanningQuality
IP1
Planning aProject
IP2
Refining theBusinessCase andRisks
IP3
Setting upProjectControls
IP4
Setting upProject Files
IP5
Assembling aPID
IP6
Authorising aProject
DP2
AuthorisingInitiation
DP1AuthorisedStageInitiationPlan
ProjectBrief
Draft PID
Corporate QMS
![Page 164: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/164.jpg)
Ken Bradley’s Understanding PRINCE 2
164
♦ to provide a foundation for the project from which the Project Initiation Document canbe assembled or prepared.
♦ to provide decision support information to enable the Project Board to confirm theinitial (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 inprinciple 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 ofthe 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 willbe two, this principle ensures that there will always be at least one “planning” Stage andone “action” Stage.
The PID is used as a Baseline for the project. It is assembled from Products generated inthe “Starting Up A Project (SU)” Process and the “Initiating A Project (IP)” Process andwhen approved by the Project Board it signifies the official start of the project. Theapproved PID will be input to every formal review of the Project (ESAs and MSAs) tocheck progress against the agreed baseline. It is also used at Project Closure(“Decommissioning A Project (CP1)”) to measure the project outcome against theAcceptance Criteria; successful matching will generate a Customer Acceptance of theoutcome.
![Page 165: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/165.jpg)
Ken Bradley’s Understanding PRINCE 2
165
IP1 - Planning For Quality
Quality plays an important role in any PRINCE 2 project and as such it must beconsidered before any major planning activity takes place. The Customer’s QualityExpectations will have been identified in the “Starting Up A Project (SU)” at the time theProject Brief was prepared.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
IP1 –PlanningQuality
Quality Standards(Programme and/orCorporate QMS)
Project Brief (SU4)
Project Approach(SU5)
Project Quality Plan [C]
Planning A Project (IP2)
Setting Up ProjectControls (IP4)
Setting Up Project Files(IP5)
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 qualitystandards, usually resident in the Quality Management System (QMS).
A correlation between the International Standards Organisation BS/EN/ISO 9001 standardfor quality management and what is offered within the PRINCE 2 Method is provided inAppendix B of the PRINCE 2 Manual. This Appendix should be used to match thesupplier organisation’s QMS to the requirements of PRINCE 2 and is especially usefulwhere a QMS is being specified and introduced.
Where an organisation-wide QMS is not already in force, management should considerintroducing 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 effectiveQuality Reviews and to understand the significance of the Quality Criteria that will beincluded in the Product Description for each Product/Deliverable.
![Page 166: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/166.jpg)
Ken Bradley’s Understanding PRINCE 2
166
IP2 - Planning A Project
Although PRINCE 2 includes a separate Process for “Planning (PL)” and includesplanning as a Component and a specific Technique (Product-Based Planning), theactivities associated with planning for a specific project situation come into operationwithin the Process concerned with the specific plan required. For example, planning theproject is an activity which must be undertaken right at the start of the project and liesnaturally within the “Initiating A Project (IP)” Process. Similarly, planning for eachManagement Stage is a function of “Managing Stage Boundaries (SB)” as the ProjectManager prepares for the transition from the Current Stage to the Next Stage and preparesdocumentation for the Project Board to reach an informed decision.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Plan [C] Refining The BusinessCase & Risks (IP3)
Setting Up ProjectControls (IP4)
Setting Up Project Files(IP5)
Assembling A PID (IP6)
Planning A Stage (SB1)
Risk Log [U] Refining The BusinessCase & Risks (IP3)
IP2 –Planning AProject
Project Brief (SU4)
Risk Log (SU4)
Project Approach(SU5)
Project Quality Plan(IP1)
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 planswithin 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 theproject, but must make an intelligent stab at what the future holds and plan forcontingencies.
![Page 167: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/167.jpg)
Ken Bradley’s Understanding PRINCE 2
167
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)”) providesthe 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.
![Page 168: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/168.jpg)
Ken Bradley’s Understanding PRINCE 2
168
IP3 - Refining The Business Case
The Project Brief will have identified an outline Business Case for the project. Thispreliminary assessment will have been approved in principle by the Project Board whenconsidering the package put forward in support of investing resources into creating asuitable 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 startthe project can be made. The expected Business Benefits will need to be clearly specifiedand the risks associated with the project identified.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Risk Log [U] Setting Up ProjectControls (IP4)
Assembling A PID (IP6)
Business Case [C] Assembling A PID (IP6)
IP3 –RefiningTheBusinessCase &Risks
Project Brief (SU4)
Project Approach(SU5)
Project Plan (IP2)
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 inconcert. In the case of the Business Benefits, a Costs:Benefits Analysis/InvestmentAppraisal should be considered.
Risks can be measured in many ways; PRINCE 2 does not recommend any particularapproach from the many software-based risk assessment tools that are available but thereneeds to be a balance between creating an effective Risk Assessment, suitable as the basisfor Risk Management, and the time and effort that a comprehensive assessment is bound toconsume. A simple Risk Analysis Checklist has been in use in PRINCE projects for manyyears and an enhanced variant of this has been included at Chapter 7. Use of the RiskAnalysis Checklist is straightforward and an advantage is its visibility - it is well worth atry 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 StageBoundaries (SB)”).
![Page 169: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/169.jpg)
Ken Bradley’s Understanding PRINCE 2
169
IP4 - Setting Up Project Controls
Project controls are the key to the successful management of any project. It is onlypossible to control a project to the level of detail in which it has been planned so theProject (and later, the Stage) plans are critical to the successful management of the project.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Plan [U] Assembling A PID (IP6)
Project Controls [C] Assembling A PID (IP6)
Risk Log [U] Assembling A PID (IP6)
IP4 –Setting UpProjectControls
Project Quality Plan(IP1)
Project Plan (IP2)
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 controlfor the project. For large, high-risk projects it may be expected that all the controls listedbelow will be appropriate. For smaller, low-risk projects it will be necessary to considerboth 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. Themanagement controls that will be identified and used in any PRINCE 2 project fall intotwo 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)
![Page 170: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/170.jpg)
Ken Bradley’s Understanding PRINCE 2
170
♦ 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 thenumber, size and relationship of the projects that fall within the aegis of the PRINCE 2arrangements within a particular implementing organisation.
![Page 171: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/171.jpg)
Ken Bradley’s Understanding PRINCE 2
171
IP5 - Set Up Project Files
All projects will produce documentation which must be stored in an appropriate andsecure way. A fair amount of documentation will already have been produced in the“Starting Up A Project (SU)” Process and organisations implementing PRINCE 2 projectmanagement systems will wish to consider whether setting up the project filing structurewould best be carried out during the SU Process.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Filing Structure [C] Assembling A PID (IP6)
Issue Log [C] Controlling A Stage (CS)
Quality Log [C] Controlling A Stage (CS)
IP5 –Setting UpProjectFiles
Project Quality Plan(IP1)
Project Plan (IP2)
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).
![Page 172: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/172.jpg)
Ken Bradley’s Understanding PRINCE 2
172
PRINCE 2 suggests a filing structure but does not require an electronic format, a physicalfile or both. Perhaps the best approach is to have both electronic and physical filestructures sharing a common structure. This will enable Project Managers to maintaincopies of documentation in a format which is permanent, structured and flexible.
All files and their associated documentation, whatever their format, will need to bearchived at the conclusion of the project to allow for appropriate auditing.
Figure 75: PRINCE 2 Suggested Filing Structure
Project FileOrganisationPlansBusiness CaseRisk LogControl DocumentsProducts Checklist
Files
Stage File(s)OrganisationPlansControl DocumentsDaily LogCorrespondenceProducts Checklist
Specialist FileConfiguration ItemsConfiguration LogCI LocationsOff-Specifications
Quality FileProduct DescriptionsQuality ChecksProject Issues
![Page 173: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/173.jpg)
Ken Bradley’s Understanding PRINCE 2
173
IP6 - Assembling The Project Initiation Document
The key document to be output from the “Initiating A Project (IP)” Process is the ProjectInitiation Document. (PID) This document provides a comprehensive view of the projectas it is viewed from the outset of the project.
The PRINCE 2 concept of “assembling” a Project Initiation Document is understandablebut not necessarily realistic as there are always many additional elements that, at the pointthe PID is put together, are not available. To help with this, a Project Initiation DocumentTemplate should be prepared for use in all projects within the implementing organisation.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
IP6 –AssemblingA PID
Project Approach(SU5)
Project Brief (SU4)
ProjectManagement TeamStructure + JobDefinitions (SU3)
Project Quality Plan(IP1)
Project Plan (IP2)
Business Case(IP3)
Risk Log (IP3)
Project Controls(IP4)
CommunicationPlan (IP4)
Project FilingStructure (IP5)
Draft Project Initiation Document(PID) [C]
Authorising A Project(DP2)
Figure 76: IP6 Plus Inputs and Outputs
![Page 174: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/174.jpg)
Ken Bradley’s Understanding PRINCE 2
174
Completion of the PID will trigger the need to plan for the next Management Stage of theproject. The work for this activity will be carried out in the Process “Managing StageBoundaries (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 inthe Project Initiation Document, thereby putting the emphasis on this document beingconcerned 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 itcan 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 beshared. 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 Boardmembers where they can spare the time). Typically one or two days is sufficient, providedsome foundation work has been undertaken. Where this approach is taken, the ProjectInitiation Stage Plan should reflect the time and resources needed.
![Page 175: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/175.jpg)
Ken Bradley’s Understanding PRINCE 2
175
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 someunforeseen problem occurs during the project. The Project Board and ProjectManagement Team will have firm ground on which to base decisions about proposedchanges in direction and investment of resources.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
IP1 –PlanningQuality
Quality Standards(Programme and/orCorporate QMS)
Project Brief (SU4)
Project Approach(SU5)
Project Quality Plan [C]
Planning A Project (IP2)
Setting Up ProjectControls (IP4)
Setting Up Project Files(IP5)
Assembling A PID (IP6)
Project Plan [C] Refining The BusinessCase & Risks (IP3)
Setting Up ProjectControls (IP4)
Setting Up Project Files(IP5)
Assembling A PID (IP6)
Planning A Stage (SB1)
Risk Log [U] Refining The BusinessCase & Risks (IP3)
IP2 –Planning AProject
Project Brief (SU4)
Risk Log (SU4)
Project Approach(SU5)
Project Quality Plan(IP1)
Trigger(s) For Next Stage Plan [C] Planning A Stage (SB1)
Risk Log [U] Setting Up ProjectControls (IP4)
Assembling A PID (IP6)
Business Case [C] Assembling A PID (IP6)
IP3 –RefiningTheBusinessCase &Risks
Project Brief (SU4)
Project Approach(SU5)
Project Plan (IP2)
Risk Log (IP2) Project Plan [U] Assembling A PID (IP6)
![Page 176: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/176.jpg)
Ken Bradley’s Understanding PRINCE 2
176
Project Plan [U] Assembling A PID (IP6)
Project Controls [C] Assembling A PID (IP6)
Risk Log [U] Assembling A PID (IP6)
IP4 –Setting UpProjectControls
Project Quality Plan(IP1)
Project Plan (IP2)
Risk Log (IP3)
Communication Plan [C] Assembling A PID (IP6)
Project Filing Structure [C] Assembling A PID (IP6)
Issue Log [C] Controlling A Stage (CS)
Quality Log [C] Controlling A Stage (CS)
IP5 –Setting UpProjectFiles
Project Quality Plan(IP1)
Project Plan (IP2)
Lessons Learned Report [C] Controlling A Stage (CS)
IP6 –AssemblingA PID
Project Approach(SU5)
Project Brief (SU4)
ProjectManagement TeamStructure + JobDefinitions (SU3)
Project Quality Plan(IP1)
Project Plan (IP2)
Business Case(IP3)
Risk Log (IP3)
Project Controls(IP4)
CommunicationPlan (IP4)
Project FilingStructure (IP5)
Draft Project Initiation Document(PID) [C]
Authorising A Project(DP2)
Figure 77: Summary Of The Initiating A Project (IP) Process
Another major, but intangible output from this Process is the understanding thatindividuals 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.
![Page 177: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/177.jpg)
Ken Bradley’s Understanding PRINCE 2
177
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 orsize of the project. The PID itself will be used to provide a baseline for the projectthroughout its life and beyond, extending to the completion of a Post-Project Reviewsometime after the project is closed down (typically some 6-9 months after the Productfrom 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 ProjectBoard within the “Directing A Project (DP2)“ Process. The vehicle for this is an EndStage Assessment (at the completion of the mandatory Initiation Stage). Acceptance ofthe PID and approval by the Project Board signals the formal start of the project.
![Page 178: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/178.jpg)
![Page 179: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/179.jpg)
Ken Bradley’s Understanding PRINCE 2
179
UNDERSTANDING THE
DIRECTING A PROJECT (DP)
PROCESS
Chapter 14
![Page 180: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/180.jpg)
![Page 181: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/181.jpg)
Ken Bradley’s Understanding PRINCE 2
181
Directing A Project (DP) - Introduction
Directing A Project (DP) operates throughout all stages of the project, from the end ofProject Start-up through to Project Closure and is the primary concern of the ProjectBoard. They achieve this by managing by exception, monitoring through reports providedprimarily by the Project Manager, and controlling through a series of key decision points.
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 theapproved plans has occurred;
♦ Control of the Stage Boundaries, committing new and additional resources as theproject progresses towards its ultimate aim;
AuthorisingInitiation
DP1
Starting upa Project
SU
Authorisinga Project
DP2
Authorisinga Stage orExceptionPlan DP3
GivingAd hocDirection
DP4
ConfirmingProjectClosure
DP5
Initiating aProject
IP
Controllinga Stage
CS
ManagingStageBoundaries
SB
Closing aProject
CP
Project BriefDraft Initiation Stage PlanJob DefinitionsProject Management TeamstructureProject Approach
Authorisationto proceed
DraftPID
Authorisationto proceed
Authorisationto proceed
Highlight ReportException ReportsRequests for advice End Project Report
Project ClosureRecommendationDraft Post ImplementationReview PlanFollow-on ActionRecommendationsLessons Learned ReportOperational andmaintenance confirmationPID
Follow-on Action RecommendationsLessons Learned ReportPost Implementation Review PlanProject Closure Notification
Information from external sourcesProject Start-upNotification
PIDException PlanEnd Stage ReportNext Stage PlanProject Team changesUpdated Project PlanUpdated Business CaseUpdated Risk Log
Mobilisation of supportservicesApproved PID Exception Report
Request ForException Plan
![Page 182: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/182.jpg)
Ken Bradley’s Understanding PRINCE 2
182
♦ Ad-hoc Decision-making and Direction, monitoring progress and providing advice andguidance as necessary;
♦ When the project has achieved its outcome, or is no longer considered to be a viablebusiness proposition, arranging for Project Closure, bringing the whole undertaking toa controlled finish.
This Process does not cover the day-to-day activities of managing the project - these restwith the Project Manager. The Process is positioned at the level of management residingabove the Project Manager.
Information will be presented to the Project Board in a number of ways, from formalreport documents such as the Project Initiation Document (PID) through HighlightReports, usually prepared on a monthly basis, to requests for ad-hoc direction by theProject Manager where a gentle “touch on the tiller” is required and senior managementsupport is recommended. The Process is one of the busiest within the Process Model interms of potential and actual inputs and outputs and the physical interpretation of how todirect 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 whohave the organisational authority to commit the resources that will be needed to see theproject through to a successful conclusion. The ability to make decisions on commitmentof additional resources in the event of problems and the vision to see the wider picture arealso vital ingredients resident within this Process.
Management By Exception
A guiding principle at this level should always be the ability for senior managers to adopta “hands-off” approach and to become involved with the project only at those points intime when their input is needed and to adopt a Management by Exception approach.
Essentially this approach requires Project Board members to view the project strategicallyand to become involved only at planned review dates and at unscheduled meeting calledonly because the project has significantly departed from the approved plan. This ismeasured by a control known as “Tolerance” - essentially the scope a Project Manager hasto depart from an approved Stage Plan without needing to report the departure to theProject Board.
A forecast that the current Stage will not be able to complete within Tolerance (standardTolerance of Time and Cost) will result in an Exception Report being prepared by theProject Manager for consideration by the Project Board members. An Exception Plan willoften follow, this being produced by the Project Manager, which will be considered by theProject Board at a specially convened Mid-Stage Assessment.
![Page 183: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/183.jpg)
Ken Bradley’s Understanding PRINCE 2
183
DP1 – Authorising Initiation
The work carried out in the “Starting Up A Project (SU)” Process is designed to puttogether enough information for the Project Board to make a “go/no-go” decision onwhether to invest the necessary resources into the creation of a Project InitiationDocument (PID).
The Project Board will be presented with a set of decision support documentation andasked to approve the project in principle.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Authorisation To Proceed [C]
Stage Plan [U]
Project Brief [U]
Risk Log [R]
Project Management TeamStructure [R]
Project Approach [U]
Initiating A Project (IP)
DP1 –AuthorisingInitiation
ProjectManagement TeamStructure (SU3)
Job Definitions(SU3)
Project Brief (SU)
Risk Log (SU)
Project Approach(SU5)
Draft InitiationStage Plan (SU6)
Project Start-up Notification [C] Corporate orProgrammeManagement
Figure 79: DP1 Plus Inputs and Outputs
The project formally starts when this approval is gained (not when the Project InitiationDocument has been prepared and approved).
For low risk, smaller, projects a formal meeting of the Project Board may not be necessaryand approval may be given directly by the Executive member (having responsibility forthe overall business objectives).
![Page 184: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/184.jpg)
Ken Bradley’s Understanding PRINCE 2
184
DP2 – Authorising A Project
Following the creation of the Draft Project Initiation Document (PID) in “Initiating AProject (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 theproject as it proceeds towards its conclusion and to measure against the final out-turnalthough certain parts of the PID are reviewed and modified at the end of eachManagement Stage; these are the Project Plan, the Business Case and the Risk Log.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Authorisation To Proceed [C] Authorising WorkPackage (CS1)
DP2 –AuthorisingA Project
Draft ProjectInitiation Document(IP6)
Next Stage Plan(SB1)
Approved Project InitiationDocument [U]
Corporate orProgrammeManagement
Figure 80: DP2 Plus Inputs and Outputs
The above diagram shows how both the Draft Project Initiation Document and the plansfor the next Management Stage are input to this Process as decision supportdocumentation. Note that the plans for the next Management Stage are not included aspart 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 resourcesand triggers commencement of work, providing authorisation for the Project Manager tobegin using the resources in the plans.
A copy of the approved PID is lodged in the Project File and Corporate Management isnotified of the existence of the project by dispatch of a notification, or copy of the PIDwhatever is most appropriate.
![Page 185: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/185.jpg)
Ken Bradley’s Understanding PRINCE 2
185
DP3 – Authorising A Stage Or Exception Plan
As it proceeds, the project will be reviewed by the Project Board at the conclusion of eachManagement Stage. Essentially the Project Board will be looking for evidence that theManagement Stage has been completed to budget, on time and meeting the requirementsof 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 ManagementStage plans approved and resources committed.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Authorisation To Proceed [C] Controlling A Stage (CS)
Tolerances [C] Controlling A Stage (CS)
Business Case [U] Controlling A Stage (CS)
Project Plan [U] Controlling A Stage (CS)
DP3 –AuthorisingA Stage orExceptionPlan
Next Stage Plan(SB5)
ProjectManagement TeamChanges (SB5)
Product Checklist(SB5)
Business Case(SB5)
Risk Log (SB5)
End-Stage Report(SB5)
Request forAuthorisation ToProceed (SB5)
Exception Plan(SB6)
Project InitiationDocument (IP6)
Project Tolerances(Corporate orProgrammeManagement)
Progress Information [C] Corporate orProgrammeManagement and otherinterested parties.
Figure 81: DP3 Plus Inputs and Outputs
![Page 186: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/186.jpg)
Ken Bradley’s Understanding PRINCE 2
186
A number of products and documentation are needed for the Project Board to properlycarry out this responsibility and these are all created and/or updated within the “ManagingStage Boundaries (SB)” Process. Logs and on-going reports will be retrieved from theappropriate file and input to the Project Board either before or at the Project Boardmeeting. Care should be taken not to swamp the Project Board with too much paper orunimportant information.
Approval of Exception Plans
This Process is used also for approving Exception Plans. An exception occurs when asignificant deviation from an approved plan occurs; a “significant deviation” is measuredby whether Tolerance is exceeded and may occur as a result of a technical or qualityproblem 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 theProject Board members of the perceived problem. The Exception Report provides astatement of the problem, an analysis of its impact, the options available for recovery anda firm recommendation for recovery.
The Exception Report is considered by the Project Board and a decision taken on whetherthe project may continue without any further action, or whether the remainder of theManagement 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 ExceptionPlan is produced by the Project Manager. The Exception Plan will be considered by theProject Board at a Mid Stage Assessment and after its approval, substitutes the plan itreplaces.
![Page 187: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/187.jpg)
Ken Bradley’s Understanding PRINCE 2
187
Figure 82: Exception Reporting and Planning
Figure 76 summarises the procedure for notifying the Project Board of a significantdeparture from plan (via the Exception Report) and subsequently the creation of theException Plan. Also shown on the above diagram is the Project Board’s option toterminate the project prematurely if they do not wish to continue with the undertakingfollowing a major change in the approved plans (although this decision might have beentaken earlier, when the exception was first reported and considered in the Process “GivingAd-Hoc Direction (DP4)”. Where the cancellation option is preferred, the prematureclosedown of the project will be handled within the “Closing A Project (CP)” Process.
CS8Escalating
Project IssuesDP4
GivingAd-Hoc Advice
1: Exception Report
DP3Authorising A Stage or
Exception Plan
SB6Producing An
Exception Plan
2A: Direction
3: Trigger - (Copy of Exception Report)
4: Exception Plan
CS1 -Authorising AWork Package
5: AuthorisationTo Proceed
Premature Termination of Project
2B: Request forException Plan
Mid-StageAssessment
Problem … Forecast to Exceed Tolerance
![Page 188: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/188.jpg)
Ken Bradley’s Understanding PRINCE 2
188
DP4 – Giving Ad-Hoc Direction
This Process is the most powerful of all the Processes in that it includes provision toterminate the project prematurely if the Project Board are unhappy about the progressbeing 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 staffemployed on the project as and when it is needed and requested.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Exception Plan Request [C] Producing An ExceptionPlan (SB6)
Premature Close [C] De-Commissioning AProject (CP1)
Response to External Sources(Corporate & ProgrammeManagement)
Corporate & ProgrammeManagement
DP4 –Giving Ad-HocDirection
Information from &to External Sources(Corporate orProgrammeManagement)
Highlight Reports(CS6)
Requests forAdvice (CS7)
Exception Report(CS8)
CommunicationPlan (IP4)
Response to Requests for Advice Project Manager
Figure 83: DP4 Plus Inputs and Outputs
Highlight Reports, prepared by the Project Manager (usually monthly, but at the frequencyrequired by the Project Board) will provide much of the everyday input for the ProjectBoard’s advice, comments and direction. Information coming into the project fromexternal sources will also be filtered by the Project Board and acted upon, usually byproviding direction to the Project Manager.
![Page 189: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/189.jpg)
Ken Bradley’s Understanding PRINCE 2
189
DP5 – Confirming Project Closure
The responsibilities of this sub-process will usually (but not necessarily) be exercisedthrough the holding of a Project Closure Meeting where the project will be shut down inan 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 identificationof any follow up actions.
The approval of a plan for performing a Post-Project Review (usually some 9-12 monthsafter 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:
Project Closure Notification [U](Approved)
Corporate orProgrammeManagement
Follow0on ActionRecommendations [U] (Approved)
Corporate orProgrammeManagement
Post-Project Review Plan [U](Approved)
Corporate orProgrammeManagement
DP5 –ConfirmingProjectClosure
Operational &MaintenanceAcceptance (CP1)
CustomerAcceptance (CP1)
Project ClosureRecommendation(CP1)
Post-ProjectReview Plan (CP2)
Follow-on ActionRecommendations(CP2)
Lessons LearnedReport (CP3)
End Project Report(CP3)
Baselined ProjectInitiation Document(DP2)
Lessons Learned Report [U](Approved)
Corporate orProgrammeManagement
Figure 84: DP5 Plus Inputs and Outputs
![Page 190: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/190.jpg)
Ken Bradley’s Understanding PRINCE 2
190
Specifically, the Project Board will wish to satisfy themselves that the project has a clearlydefined end and that an orderly hand-over to operational use has been effected. TheProject Board will look to the Senior User for confirmation that an acceptable End-Productis 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 theProject Manager’s preparation for this very important Process, ensuring that there are nosurprises awaiting the members at the closure meeting.
![Page 191: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/191.jpg)
Ken Bradley’s Understanding PRINCE 2
191
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,UPDATED, REFERENCED OR
USED
OUTPUT TO
Authorisation To Proceed [C]
Stage Plan [U]
Project Brief [U]
Risk Log [R]
Project Management TeamStructure [R]
Project Approach [U]
Initiating A Project (IP)
DP1 –AuthorisingInitiation
ProjectManagement TeamStructure (SU3)
Job Definitions(SU3)
Project Brief (SU)
Risk Log (SU)
Project Approach(SU5)
Draft InitiationStage Plan (SU6)
Project Start-up Notification [C] Corporate orProgrammeManagement
Authorisation To Proceed [C] Authorising WorkPackage (CS1)
DP2 –AuthorisingA Project
Draft ProjectInitiation Document(IP6)
Next Stage Plan(SB1)
Approved Project InitiationDocument [U]
Corporate orProgrammeManagement
![Page 192: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/192.jpg)
Ken Bradley’s Understanding PRINCE 2
192
Authorisation To Proceed [C] Controlling A Stage (CS)
Tolerances [C] Controlling A Stage (CS)
Business Case [U] Controlling A Stage (CS)
Project Plan [U] Controlling A Stage (CS)
DP3 –AuthorisingA Stage orExceptionPlan
Next Stage Plan(SB5)
ProjectManagement TeamChanges (SB5)
Product Checklist(SB5)
Business Case(SB5)
Risk Log (SB5)
End-Stage Report(SB5)
Request forAuthorisation ToProceed (SB5)
Exception Plan(SB6)
Project InitiationDocument (IP6)
Project Tolerances(Corporate orProgrammeManagement)
Progress Information [C] Corporate orProgrammeManagement and otherinterested parties.
Exception Plan Request [C] Producing An ExceptionPlan (SB6)
Premature Close [C] De-Commissioning AProject (CP1)
Response to External Sources(Corporate & ProgrammeManagement)
Corporate & ProgrammeManagement
DP4 –Giving Ad-HocDirection
Information from &to External Sources(Corporate orProgrammeManagement)
Highlight Reports(CS6)
Requests forAdvice (CS7)
Exception Report(CS8)
CommunicationPlan (IP4)
Response to Requests for Advice Project Manager
![Page 193: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/193.jpg)
Ken Bradley’s Understanding PRINCE 2
193
Project Closure Notification [U](Approved)
Corporate orProgrammeManagement
Follow0on ActionRecommendations [U] (Approved)
Corporate orProgrammeManagement
Post-Project Review Plan [U](Approved)
Corporate orProgrammeManagement
DP5 –ConfirmingProjectClosure
Operational &MaintenanceAcceptance (CP1)
CustomerAcceptance (CP1)
Project ClosureRecommendation(CP1)
Post-ProjectReview Plan (CP2)
Follow-on ActionRecommendations(CP2)
Lessons LearnedReport (CP3)
End Project Report(CP3)
Baselined ProjectInitiation Document(DP2)
Lessons Learned Report [U](Approved)
Corporate orProgrammeManagement
Figure 85: Summary of the Directing A Project (DP) Process
![Page 194: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/194.jpg)
![Page 195: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/195.jpg)
Ken Bradley’s Understanding PRINCE 2
195
UNDERSTANDING THECONTROLLING A STAGE
PROCESS
Chapter 15
![Page 196: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/196.jpg)
![Page 197: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/197.jpg)
Ken Bradley’s Understanding PRINCE 2
197
Controlling A Stage (CS) - Introduction
Following the Project Board’s decision to approve a Stage, the Project Management Teammust be fully focused on delivery of the Products, to their stated Quality Criteria, withinthe approved time-scales and budget, within the stated Tolerances.
Figure 86: Controlling A Stage (CS) Process
This Process forms the main part of the Project Manager’s effort on the management of theproject, and provides the direction for the day-to-day management of the Stage and theoverall project. All through the Stage there will be an on-going cycle of:
♦ authorising Packages of Work that must be completed during the Management Stageand receiving Completed Work Packages (or Products) back into the hostorganisation;
♦ gathering Progress Information about the work carried out and the resources andeffort expended;
Closing aProject
CP
TakingCorrectiveAction
EscalatingProject Issues
CS8
AuthorisingWork Package
AssessingProgress
ReceivingCompletedWorkPackageCS1CS7 CS2 CS9
ReviewingStage Status
CS5
ReportingHighlights
CS6
ExaminingProject Issues
CS4
CapturingProject Issues
CS3
Directing aProject
DP
ManagingStageBoundaries
SB
ManagingProductDelivery
MP
Project EndNotification
Work Package
Checkpoint ReportQuality Log
CompletedWork Package
Exception ReportIssue Log
HighlightReport
Stage Plan
Risk LogBusiness Case
New ProjectIssues
Authorisation toproceedStage/ExceptionPlan
Copy of Exception Report
![Page 198: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/198.jpg)
Ken Bradley’s Understanding PRINCE 2
198
♦ watching for Changes to the approved plan; managing any changes raised formallyagainst the project (Project Issues) and making decisions on the introduction ofbeneficial changes provided these do not result in the Stage Plans exceeding theTolerance;
♦ reviewing situations for Stage and Project Impact;
♦ reporting to the Project Board and to other members of the Project ManagementTeam;
♦ approving and initiating any Corrective Action.
It may be expected that for much of the time events during a Management Stage willfollow a regular and predictable pattern. However, personal qualities and projectmanagement abilities need to combine to address situations which are not going accordingto plan and it is then that the Project Manager must use knowledge, political and peopleskills to bring things back on course.
![Page 199: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/199.jpg)
Ken Bradley’s Understanding PRINCE 2
199
CS1 – Authorising A Work Package
Work is released to Team Managers or directly to staff working on the project via theissue 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, ormuch less formal (for example by internal memorandum or discussion) where the provideris employed within the host organisation.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Plan Adjustments [C] Assessing Progress(CS2)
CS1 –AuthorisingWorkPackage
Stage or ExceptionPlan (DP3)
Authorisation ToProceed (DP3)
Proposed WorkPackage (CS5)
Work Trigger (CS7
ProductDescriptions (PL2)
Work Package [C] Accepting A WorkPackage (MP1)
Figure 87: CS1 Plus Inputs and Outputs
The Project Manager is responsible for the preparation, release and agreement of WorkPackages; authority for this responsibility stems from the Project Board’s approval of therelevant Management Stage Plan and for this reason Management Stage Plans (producedin the “Managing Stage Boundaries (SB)” Process) must be sufficiently detailed for theProject Board to understand to what they are committing.
Changes necessary as the Management Stage progresses must be reflected in the workbeing carried out on the relevant Work Packages – this demands a close associationbetween the Project Manager and the Team Manager(s) responsible for producing theProduct(s). Where a formal contract is in existence, care must be taken not to upset thecontract arrangements by demands for trivial changes.
This Process provides the Project Manager with the main vehicle for release of work andis a major control on a day to day basis.
![Page 200: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/200.jpg)
Ken Bradley’s Understanding PRINCE 2
200
CS2 – Assessing Progress
The Project Manager must keep track on how well the Management Stage, and theProject, is performing against the plan approved by the Project Board at the last End StageAssessment. This Process provides the mechanics for capturing “Actuals” and passingthe information forward to “Reviewing Stage Status (CS5)” where the Project Manager cantake stock of progress so far.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
CS2 –AssessingProgress
Checkpoint Reports(MP2)
Quality Log (MP2)
Plan Adjustments(CS1)
Stage Plan (CS5)
Work PackageStatus (CS9)
Up-dated Stage Plan [U] Examining ProjectIssues (CS4)
Reviewing Stage Status(CS5)
Figure 88: CS2 Plus Inputs and Outputs
The information needed to update the approved Management Stage Plan comes from threemajor sources:
♦ Checkpoint Reports (created within the “Managing Product Delivery (MP2)”Process);
♦ Timesheets (where these are in use within the host organisation – otherwise anassessment by the Project Manager of effort expended and financial liability incurred);
♦ Project Issues – especially where errors or departures from the agreed requirementhave been identified.
This Process is best carried out by Project Support, where appointed, with a presentationof the plans, updated to show “actuals”, to the Project Manager for overall assessment onat least a weekly basis.
Use of a suitable software planning tool (such as MS Project, Project ManagerWorkbench, Primavera etc) will simplify this Process especially if standard “actuals”
![Page 201: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/201.jpg)
Ken Bradley’s Understanding PRINCE 2
201
reporting forms generated within the package are fully utilised.
The output from CS2 goes towards the Project Manager’s review of how well theManagement Stage is progressing when measured against the Management Stage planapproved by the Project Board at the previous End Stage Assessment.
![Page 202: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/202.jpg)
Ken Bradley’s Understanding PRINCE 2
202
CS3 - Capturing Project Issues
As the project progresses there will be a need to capture and decide upon changes thatoccur. All changes within a PRINCE 2 project are treated as types of Project Issue. Theseinclude errors found in signed-off Products, departures from the agreed Specification,ideas and suggestions people have for improving the project’s outputs, resource changesthat need to be reflected in the project and stage plans.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
CS3 –CapturingProjectIssues
Issue Log (QualityFile)
New Project Issues(Any ProjectSource)
Up-dated Issue Log [U] Examining ProjectIssues (CS4))
Figure 89: CS3 Plus Inputs and Outputs
A Project issue can be raised by anyone associated with the project. Typicallyorganisations will have their own existing change control arrangements and these shouldbe adopted where they are performing satisfactorily.
The first job on receipt of a Project Issue is to record it on the Issue Log - this willnormally 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 AcceptanceCriteria; 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 ControlComponent and Technique.
![Page 203: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/203.jpg)
Ken Bradley’s Understanding PRINCE 2
203
CS4 - Examining Project Issues
This Process enables each Project Issue to be examined and its impact assessed; thisshould be carried out as soon as possible after receipt and logging of the Project Issue.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Issue Log [U] Reviewing Stage Status(CS5)
Risk Log [U] Reviewing Stage Status(CS5)
CS4 –EvaluatingProjectIssues
Business Case(SB3)
Stage Plan (CS2)
Issue Log (CS3)
Risk Log (SB4)
Project Plan (SB2)
Issue Log [U] Reporting Highlights(CS6)
Figure 90: CS4 Plus Inputs and Outputs
The examination and evaluation of Project Issues may take place via a regular meeting orby 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 Businessperspective; any action needed which would take the Management Stage over the agreedTolerance 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 usethe support services of Team Managers in helping arrive at an appropriate decision. TheSenior User member of the Project Board will prioritise and if necessary canvas theProject 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 ateach End Stage Assessment.
![Page 204: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/204.jpg)
Ken Bradley’s Understanding PRINCE 2
204
CS5 - Reviewing Stage Status
This Process provides for a regular check of how the Management Stage is performingagainst its approved plan. The intention is to allow the Project Manager to stand backfrom the day to day problem solving activities and take stock, prior to reporting thesituation to the Project Board.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Notification of Project End [C] De-Commissioning AProject (CP1)
Work Trigger(s) [C] Authorising WorkPackage (CS1)
Stage Status Information [C] Reporting Highlights(CS6)
Plan Deviation [C] Taking Corrective Action(CS7)
Stage Plan [U] Escalating ProjectIssues (CS8)
Planning A Stage (SB1)
Project Issue [R] Escalating Projectissues (CS8)
CS5 –ReviewingStageStatus
Stage Plan (CS2)
Issue Log (CS4)
Risk Log (CS4)
Tolerances (DP3)
Business Case(DP3)
Project Plan (DP3)
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 updatesthe approved plans with “actuals”. Inputs will also be needed from the Issues Log wheremodifications to the Management Stage plans may be brewing following the discovery oferrors and omissions or ideas for improvement., and the Risk Log which will enable theProject Manager to review emerging risks identified at the outset of the ManagementStage.
The overall outcome of the Process is to ensure on a regular basis (recommended weeklyat the minimum) that the Management Stage remains within Tolerance and that nothinguntoward is likely to occur without warning.
Information and knowledge gleaned from this Process will feed the creation of theHighlight Report for the Project Board.
![Page 205: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/205.jpg)
Ken Bradley’s Understanding PRINCE 2
205
CS6 - Reporting Highlights
Having approved a Management Stage Plan, the Project Board will need to be keptinformed 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, typicallyevery month but specifically at the frequency required by the Project Board.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Highlight Reports [C] Giving Ad-Hoc Direction(DP4)
CS6 –ReportingHighlights
CommunicationPlan (ProjectFile/PID)
Stage Plan (CS5)
Checkpoint Reports(CS5)
Issue Log (CS5)
Risk Log (CS5)
Tolerances (CS5)
Plan Revisions(CS5)
Communications To InterestedParties [C]
Corporate orProgrammeManagement
Figure 92: CS6 Plus Inputs and Outputs
The objective of the Highlight Report is to provide summary information to the ProjectBoard - one sheet of paper (or its equivalent) is all that is needed. The steps taken inperforming this Process are:
Assemble information from Checkpoint Reports and Project Issues received during theprevious 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)
![Page 206: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/206.jpg)
Ken Bradley’s Understanding PRINCE 2
206
♦ Distribute the Highlight Report to Project Board members and any other agreedrecipients.
The Highlight Report does not normally require a meeting of the Project Board althoughthis is an option for high-profile, high-risk projects where the Project Board areparticularly sensitive about the progress that is being made.
![Page 207: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/207.jpg)
Ken Bradley’s Understanding PRINCE 2
207
CS7 - Taking Corrective Action
In even the best managed projects, departures from the planned course of action will occurand remedial action must be taken to bring the work back into line. This Process enablesthe Project Manager to make small adjustments, within the agreed Tolerance, to the workbeing carried out.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Work Trigger [C] Authorising WorkPackage (CS1)
Up-dated Stage Plan [U] Reporting Highlights(CS6)
CS7 –TakingCorrectiveAction
Stage Plan (CS5)
Issue Log (CS5)
Plan Deviation(CS5)
Risk Log (CS5) Request For Advice [C] Giving Ad-Hoc Direction
(DP4)
Figure 93: CS7 Plus Inputs and Outputs
The main driver for the Process comes from “CS5 - Reviewing Stage Status” wheredeviations from the required and planned outcome will start to become apparent. Projectsseldom change course dramatically but rather significant slippage is prompted by manysmaller incidents and this Process aims to treat each incident as it occurs. Additional WorkPackages may be identified in this Process.
Advice and guidance may well need to be sought from Project Board members and thiswill usually be informal. The results of this Process will need to be considered forreporting to the Project Board by inclusion on the next Highlight Report but this should bethe exception rather than the rule.
The Project Manager is responsible for the operation of this Process helped by the ProjectManagement Team. Project Managers should always be aware of the build-up ofapparently minor problems being symptomatic of bigger trouble with the project.
![Page 208: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/208.jpg)
Ken Bradley’s Understanding PRINCE 2
208
CS8 - Escalating Project Issues
As soon as it is forecast that a Management Stage (or the Project) is likely to go outsidethe Tolerance the Project Manager must notify the Project Board by raising an ExceptionReport.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Exception Report [C] (+ Responseback from Project Board)
Giving Ad-Hoc Direction(DP4)
Producing An ExceptionPlan (SB6)
Project Board Response [R] Producing An ExceptionPlan (SB6)
CS8 –EscalatingProjectIssues
Business Case(CS5)
Issue Log (CS5)
Project Plan (CS5)
Stage Plan (CS5)
Risk Log (CS5)
Project InitiationDocument (IP6)
Stage Plan [R] Producing An ExceptionPlan (SB6)
Figure 94: CS8 Plus Inputs and Outputs
Although many things may contribute to or trigger this Process the most common situationis where a Project Issue has been raised to record an error or deficiency with one or moreProducts. 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 ExceptionReport for the Project Board
♦ Await the Project Board’s response
The expected outcome will be a request to produce an Exception Plan which will replacethe plan that has gone into exception. The Project Board’s views and advice shouldalways be sought before producing an Exception Plan and the effect on the overall ProjectPlan (including the Business Case and Risks) must always be evaluated.
![Page 209: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/209.jpg)
Ken Bradley’s Understanding PRINCE 2
209
CS9 - Receiving A Completed Work Package
This Process records the successful completion of a Work Package (or Product) anddelivery of it back into the host organisation. It is closely associated with “Authorising AWork Package (CS1)” discussed earlier.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
CS9 –ReceivingCompletedWorkPackage
Approved WorkPackage (MP3)
Work Package Status [C] Assessing Progress(CS2)
Figure 95: CS9 Plus Inputs and Outputs
The arrangements for delivering the Completed Work Package will have been agreedwhen the Work Package was accepted by the Supplier, Team Manager or personresponsible for its production in the Process “Accepting A Work Package (MP1)”.
Completed Work Packages or Products delivered into the host organisation will all havebeen Quality Reviewed (in Process “Executing A Work Package (MP2)”) in accordancewith 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 ascomplete and updating the Management Stage and project records accordingly.
![Page 210: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/210.jpg)
Ken Bradley’s Understanding PRINCE 2
210
Summary of the Controlling A Stage Process
Controlling A Stage (CS) is the main project management driver for a PRINCE 2controlled 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,UPDATED, REFERENCED OR
USED
OUTPUT TO
Plan Adjustments [C] Assessing Progress(CS2)
CS1 –AuthorisingWorkPackage
Stage or ExceptionPlan (DP3)
Authorisation ToProceed (DP3)
Proposed WorkPackage (CS5)
Work Trigger (CS7
ProductDescriptions (PL2)
Work Package [C] Accepting A WorkPackage (MP1)
CS2 –AssessingProgress
Checkpoint Reports(MP2)
Quality Log (MP2)
Plan Adjustments(CS1)
Stage Plan (CS5)
Work PackageStatus (CS9)
Up-dated Stage Plan [U] Examining ProjectIssues (CS4)
Reviewing Stage Status(CS5)
CS3 –CapturingProjectIssues
Issue Log (QualityFile)
New Project Issues(Any ProjectSource)
Up-dated Issue Log [U] Examining ProjectIssues (CS4))
![Page 211: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/211.jpg)
Ken Bradley’s Understanding PRINCE 2
211
Issue Log [U] Reviewing Stage Status(CS5)
Risk Log [U] Reviewing Stage Status(CS5)
CS4 –EvaluatingProjectIssues
Business Case(SB3)
Stage Plan (CS2)
Issue Log (CS3)
Risk Log (SB4)
Project Plan (SB2)
Issue Log [U] Reporting Highlights(CS6)
Notification of Project End [C] De-Commissioning AProject (CP1)
Work Trigger(s) [C] Authorising WorkPackage (CS1)
Stage Status Information [C] Reporting Highlights(CS6)
Plan Deviation [C] Taking Corrective Action(CS7)
Stage Plan [U] Escalating ProjectIssues (CS8)
Planning A Stage (SB1)
Project Issue [R] Escalating Projectissues (CS8)
CS5 –ReviewingStageStatus
Stage Plan (CS2)
Issue Log (CS4)
Risk Log (CS4)
Tolerances (DP3)
Business Case(DP3)
Project Plan (DP3)
Stage End Notification [C] Planning A Stage (SB1)
Highlight Reports [C] Giving Ad-Hoc Direction(DP4)
CS6 –ReportingHighlights
CommunicationPlan (ProjectFile/PID)
Stage Plan (CS5)
Checkpoint Reports(CS5)
Issue Log (CS5)
Risk Log (CS5)
Tolerances (CS5)
Plan Revisions(CS5)
Communications To InterestedParties [C]
Corporate orProgrammeManagement
![Page 212: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/212.jpg)
Ken Bradley’s Understanding PRINCE 2
212
Work Trigger [C] Authorising WorkPackage (CS1)
Up-dated Stage Plan [U] Reporting Highlights(CS6)
CS7 –TakingCorrectiveAction
Stage Plan (CS5)
Issue Log (CS5)
Plan Deviation(CS5)
Risk Log (CS5) Request For Advice [C] Giving Ad-Hoc Direction
(DP4)
Exception Report [C] (+ Responseback from Project Board)
Giving Ad-Hoc Direction(DP4)
Producing An ExceptionPlan (SB6)
Project Board Response [R] Producing An ExceptionPlan (SB6)
CS8 –EscalatingProjectIssues
Business Case(CS5)
Issue Log (CS5)
Project Plan (CS5)
Stage Plan (CS5)
Risk Log (CS5)
Project InitiationDocument (IP6)
Stage Plan [R] Producing An ExceptionPlan (SB6)
CS9 –ReceivingCompletedWorkPackage
Approved WorkPackage (MP3)
Work Package Status [C] Assessing Progress(CS2)
Figure 96: Summary of the Controlling A Stage (CS) Process
![Page 213: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/213.jpg)
Ken Bradley’s Understanding PRINCE 2
213
UNDERSTANDING THEMANAGING PRODUCT DELIVERY
PROCESS
Chapter 16
![Page 214: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/214.jpg)
![Page 215: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/215.jpg)
Ken Bradley’s Understanding PRINCE 2
215
Managing Product Delivery (MP) - Introduction
This major Process is aimed primarily at managing the interface between the CustomerProject Manager and the Supplier Project Manager ensuring that work is actuallyprogressing in accordance with the customer’s expectations and that all the plannedProducts are created and delivered within the agreed time-scales and contract price orinternally approved budget, and meet their approved Quality Criteria. The Process is alsoused for managing the delivery of Products where an external Supplier is not involved inthe project and where all resources managed by the project are internal; it is alsoappropriate where there is a mixture of both.
Figure 97: Managing Product Delivery (MP) Process
The Process comprises:
♦ making certain that work on Products allocated to each external Team or TeamMember resource is properly Authorised;
♦ ensuring that Packages of Work are identified, discussed, agreed, authorised andaccepted by those responsible for the creation of Products;
♦ checking that all Interfaces between the Customer and Supplier organisations areidentified, recorded, observed and handled in an appropriate way;
AssessingProgress
CS2
Checkpoint ReportQuality LogStage Plan
Work PackageClosureProduct Sign-off
Accepting aWork Package
MP1
Executing aWork Package
MP2
Delivering aWork Package
MP3
ReceivingCompletedWorkPackage CS9
AuthorisingWork Package
CS1
Work Package
Stage Plan
![Page 216: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/216.jpg)
Ken Bradley’s Understanding PRINCE 2
216
♦ 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 completionare 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 bythe Project Board at the end of each Project Stage. These levels of approval will bereflected in both the Customer and Specialist Supplier organisations, although it is notnecessary that either will be working within a PRINCE environment; it is essential,however, that all involved are working within a suitably controlled project managementenvironment.
This Process will operate continuously throughout each Stage; it provides a healthyseparation between the Customer Project Manager and the Supplier Project Manager andrequires the interface between the Supplier(s) (be they internal or external) and theCustomer to be identified, defined and operated. Care must be taken to ensure that theinterfaces are neither missed nor lost, and that bureaucracy is kept to the absoluteminimum consistent with effective control.
Where a Project Manager allocates work directly to individuals responsible for carryingout the work package, this Process will be informal but will always exist.
![Page 217: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/217.jpg)
Ken Bradley’s Understanding PRINCE 2
217
MP1 - Accepting A Work Package
The Process provides for the establishment of agreement between the Project Managerand the Team Manager, Team or individual who will be responsible for creating anddelivering the completed Work package (or Product) for the host organisation.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Risk Log [U] Up-Dating The Risk Log(SB4)
Work Package (Authorised) [C] Executing A WorkPackage (MP2)
MP1 –Accepting AWorkPackage
Work Package(CS1)
Team Plan [C] Executing A WorkPackage (MP2)
Figure 98: MP1 Plus Inputs and Outputs
The interface between the Project Manager and those responsible for creating the Productsof the project needs to be properly managed. This Process enables the agreement to beestablished before any work is commenced. The agreement/interface manifests itself inthe 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 theMethod 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 partof the Management Stage objectives; responsibility for agreement of the Work Packageresides with the Project Manager and the Team Manager, where appointed (and the ProjectManager where no Team Manager exists).
![Page 218: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/218.jpg)
Ken Bradley’s Understanding PRINCE 2
218
MP2 - Executing A Work Package
This Process addresses the creation of the Products of the project. It may be that thecreators of the Products are not using PRINCE or any other formal project managementmethod and where this is the case agreement of the Work Package in MP1 is even moresignificant.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Quality Log [U] Assessing Progress(CS2)
Checkpoint Reports [C] Assessing Progress(CS2)
Completed Work Package [C] Delivering A WorkPackage (MP3)
MP2 –Executing AWorkPackage
Work Package(Authorised) (MP1)
Team Plan (MP1)
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 costsin the Management Stage Plan and the Project Plan to be updated within the “ControllingA Stage - Assessing Progress (CS2)” Process.
The quality checking arrangements agreed within MP1 will be performed during thisProcess; the objective is to ensure that quality is integral to the Product(s) being built sothat Products delivered back into the host organisation are complete and ready to be placedinto the Configuration Management System as finalised Products. Indeed it might well bethat the Configuration Librarian may be the first recipient of completed Work Packages orProducts 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 inthe Work Package. Checkpoint Reports are used within CS2 to update the ManagementStage and Project Plans.
Responsibility for all activities within this Process is vested in the Team Manager whereappointed, or the Project manager where no such appointment has been made.
![Page 219: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/219.jpg)
Ken Bradley’s Understanding PRINCE 2
219
MP3 - Delivering A Work Package
Formalising the return of a completed Work Package is the focus for this Process.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
MP3 –Delivering AWorkPackage
Completed WorkPackage (MP2)
Approved Work Package [C] Receiving CompletedWork Package (CS9)
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 ofthe completion of work by the Team Manager or person responsible.
The arrangements for hand-over and notification should have been established in MP1 andwill often be embodied into a formal contract document.
Responsibility lies with the Team Manager where appointed.
![Page 220: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/220.jpg)
Ken Bradley’s Understanding PRINCE 2
220
Summary of the Managing Product Delivery Process
Managing Product Delivery is the “engine room” for the PRINCE 2 project, creating theProducts required for Management Stage; it is where the bulk of the project’s time, effortand financial resources will be spent. The Process will always be present in some formalthough 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 managementstandard and this Process may not, therefore be physically implemented or understoodwhere this is the case.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Risk Log [U] Up-Dating The Risk Log(SB4)
Work Package (Authorised) [C] Executing A WorkPackage (MP2)
MP1 –Accepting AWorkPackage
Work Package(CS1)
Team Plan [C] Executing A WorkPackage (MP2)
Quality Log [U] Assessing Progress(CS2)
Checkpoint Reports [C] Assessing Progress(CS2)
Completed Work Package [C] Delivering A WorkPackage (MP3)
MP2 –Executing AWorkPackage
Work Package(Authorised) (MP1)
Team Plan (MP1)
Team Plan [U] Stage File
MP3 –Delivering AWorkPackage
Completed WorkPackage (MP2)
Approved Work Package [C] Receiving CompletedWork Package (CS9)
Figure 101: Summary of the “Managing Product Delivery (MP)” Process
![Page 221: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/221.jpg)
Ken Bradley’s Understanding PRINCE 2
221
UNDERSTANDING THEMANAGING STAGE BOUNDARIES
PROCESS
Chapter 17
![Page 222: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/222.jpg)
![Page 223: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/223.jpg)
Ken Bradley’s Understanding PRINCE 2
223
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 ofeach stage, specific attention can be given to whether the Stage Products/Deliverableshave all been completed in accordance with their Quality Criteria, whether the remainingproject Products/Deliverables are still required, and whether the Business Case for theproject remains viable.
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 currentstage have been completed and meet their Quality Criteria;
♦ to provide the information on time-scale, technical achievement, and the budget neededto enable the Project Board to assess whether the overall project Business Case is stillviable, and whether the Benefits can be achieved within an acceptable level of risk;
ReportingStage End
SB5
Updating aProject Plan
SB2SB1
Updating aProjectBusinessCase SB3
Updating theRisk Log
Producing AnExceptionPlan
SB4
Authorising aStage orExceptionPlan DP3
Project Plan, Business Case,Project Brief
Issue Log
Risk Log
Business Case
Request for Authorisation to proceed
Next Stage Plan
End Stage ReportLessons Learned Report
Risk, Issue andQuality Logs
Current Stage Plan
Current PM Team
Risk & Issue Log
Project Plan
Updated PM team
Request ForException Plan+ Exception Report
Agreed Tolerance
CurrentStagePlan
Issueand RiskLog
Project Approach
ProjectQualityPlan
PlansIssueand RiskLogs
Plans Plans
Closing aProject
CP
Project Brief
Planning AStage
SB6
![Page 224: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/224.jpg)
Ken Bradley’s Understanding PRINCE 2
224
♦ to provide decision-support information on the status of the current stage and theoverall project, which will enable the Project Board to reach a decision on finalcompletion of the current stage, authorise the start of the next stage, and to endorse theoverall 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 theProject Manager may not progress without the approval of the Project Board.
♦ to record any information or Lessons Learned which might impact on later stages ofthe 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 andincorporates 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 asignificant departure from the approved plan has occurred and Tolerance is forecast to beexceeded. In order to reach a decision on the future of the project, the Project Board willneed to consider an impact analysis, options appraisal, and a recommendation for actionprepared by the Project Manager; these will all need to be supported by an up-datedBusiness Case confirming the benefits and re-appraisal of the risks.
![Page 225: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/225.jpg)
Ken Bradley’s Understanding PRINCE 2
225
SB1 - Planning A Stage
As the project progresses the Project Board will limit their commitment and risk exposureby releasing the commitment of effort and funding via End Stage Assessments at thecompletion of each Management Stage. A key input to these major Project Board controlsis the plan for the next Management Stage put together in SB1.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Next Stage Plan [C]
Up-Dating A ProjectPlan (SB2)
Project Plan [R] Up-Dating A ProjectPlan (SB2)
Project Management TeamChanges [U]
Reporting Stage End(SB5)
SB1 –Planning AStage
Current Stage Plan(CS5) (Stage File)
Stage EndNotification (CS5)
Project Plan (IP2)(Project File)
Trigger For NextStage Plan (IP2)
PID (IP6) (ProjectFile)
Current ProjectManagement Team(IP6) (Project File &Stage File)
Product Checklist [U] Reporting Stage End(SB5)
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 effortand 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 theyare summarised in the above diagram.
The Organisation Structure for the Project Management Team will also be reviewedduring this Process, to ensure that the most appropriate resources and management teamare available for the work to be undertaken.
Much of the work involved in creating the Next Stage Plan will be carried out by membersof the Project Management Team under the supervision of the Project Manager, who hasprime responsibility for the timely production of the plan.
Any individuals having responsibility for Project Assurance will need to be consultedduring this Process especially in respect of the proposed management controls and qualitycontrol structure.
![Page 226: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/226.jpg)
Ken Bradley’s Understanding PRINCE 2
226
SB2 - Updating A Project Plan
Information needed for decision support at the end of each Management Stage obviouslyincludes an updated view of the Project Plan to identify what impact work so far on theproject has impacted on the final delivery date and cost.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Up-Dated Project Plan [U] Up-Dating A ProjectBusiness Case (SB3)
Reporting Stage End(SB5)
Up-Dating The Risk Log(SB4)
SB2 – Up-Dating AProject Plan
Current & NextStage Plans (SB1)
Exception Plan(SB6)
Project Approach(IP6) (Project File)
Project Quality Plan(IP6) (Project File)
Next Stage Plan [R]
or
Exception Plan [R]
Reporting Stage End(SB5)
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 andany changes proposed in the Next Stage Plan are used to present an up-to-date view of thelikely final out-turn for the project.
Other inputs are also available to this Process from a number of sources; the mainobjective is to present a comprehensive view of what the Project Board is being asked tocommit to, long term, at the approaching End Stage Assessment.
Any significant changes in the Project Plan brought about by this Process should beincluded in the End Stage Report produced by the Project Manager for the Project Board.
![Page 227: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/227.jpg)
Ken Bradley’s Understanding PRINCE 2
227
SB3 - Updating A Project Business Case
The Business Case is the main driving force behind any PRINCE 2 controlled and thismust be kept up to date and reviewed at the completion of each Management Stage as aminimum requirement.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Business Case [U] Reporting Stage End(SB5)
SB3 – Up-Dating AProjectBusinessCase
Up-Dated ProjectPlan (SB2)
Exception Plan orNext Stage Plan(SB2)
Risk Log (SB4)
Issue Log (SB4)
Risk Log [R] Reporting Stage EndSB5)
Figure 105: SB3 Plus Inputs and Outputs
Many events would have occurred during the previous Management Stage which willimpact the Business Benefits which were used to justify the project initially and at the lastformal Project Board Review. For example, if the overall project plan has been extendedor its predicted out-turn cost increased then there will be a detrimental effect on theBusiness Benefits; the reverse is also true!
On the positive side, it can be expected that the risks faced by the project will be reducedas progress is made. This aspect is treated in SB4 - “Updating The Risk Log” but needs tobe considered here as the two topics are very closely related.
Changes requested (and made) during the Management Stage will also impact on theBusiness Benefits, especially where required changes for improved functionality haveincurred additional effort and costs.
![Page 228: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/228.jpg)
Ken Bradley’s Understanding PRINCE 2
228
SB4 -Updating The Risk Log
As the project proceeds towards its planned conclusion, the risks faced for delivering ontime, within budget and to the required specification should reduce. This must be recordedand presented to the Project Board when they are being asked to approve the nextManagement Stage Plan.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Risk Log [U] Up-Dating A ProjectBusiness Case (SB3)
Accepting A WorkPackage (MP1)
SB4 – Up-Dating TheRisk Log
Project Plan (SB2)
Next Stage Plan(SB2)
Exception Plan(SB2)
Issue Log CS4(Quality File)
Issue Log [U] Up-Dating A ProjectBusiness Case (SB3)
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 riskmanagement tool the Risk Analysis Checklist described in Chapter 6 can be used to updatethe risks. Whatever approach is used, the results must be logged and presented to theProject Board at the End Stage Assessment. The Risk Log should indicate a downwardtrend if the project is to proceed without any changes. Significant increases in the riskmeasurement must always be brought to the attention of the Project Board andrecommendations made.
Ownership of each identified risk should always be considered - the most appropriatemember of the Project Management Team being best placed to keep a watchful eye onmovements against the baseline.
Changes in approach, planning and resource usage will always have a potential impact onthe risks facing the project and so changes to the Project Plan or Next Stage Plan shouldalways be reviewed for their impact within this Process.
![Page 229: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/229.jpg)
Ken Bradley’s Understanding PRINCE 2
229
SB5 - Reporting Stage End
The results of a Management Stage needs to be reported back to those who have providedthe resources which have contributed to its completion
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
End Stage Report [C] Authorising A Stage orException Plan (DP3)
Request for Authorisation ToProceed [C]
Authorising A Stage orException Plan (DP3)
Next Stage Plan [R] Authorising A Stage orException Plan (DP3)
Exception Plan [R] Authorising A Stage orException Plan (DP3)
Risk Log [R] Authorising A Stage orException Plan (DP3)
Product Status Account [C] De-Commissioning AProject (CP1)
SB5 –ReportingStage End
Project Plan (SB2)
Current Stage Plan(SB2)
Next Stage Plan orException Plan(SB2)
Business Case(SB3)
Issue & Risk Logs(SB3)
Quality Log (CS5)(Quality File)
CommunicationPlan (IP4) (ProjectFile)
Communications to interestedparties [C]
Corporate orProgrammeManagement
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 theresult of the Management Stage; the report provides the following information to theProject Board:
♦ Planned vs out-turn costs
♦ Planned vs out-turn effort
![Page 230: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/230.jpg)
Ken Bradley’s Understanding PRINCE 2
230
♦ 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 NextStage Plan to the Project Board.
Responsibility for creation of the report rests with the Project Manager, with help andsupport from the Project Management Team as appropriate. It will be provided up to aweek in advance of the End Stage Assessment to allow Project Board members to considerits content; arrangements for handling Management Stage endings to allow for this arediscussed in the Chapter on Understanding The Stages Component.
![Page 231: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/231.jpg)
Ken Bradley’s Understanding PRINCE 2
231
SB6 - Producing An Exception Plan
As soon as it is forecast that a Management Stage is likely to deviate beyond theTolerance set by the Project Board at the previous End Stage Assessment, it is deemed tobe in Exception and an Exception Report must be prepared for the Project Board. Thelikelihood is that the Project Board will require an Exception Plan to be prepared and thisProcess is where such a plan is created.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
SB6 –ProducingAnExceptionPlan
Exception Report(CS8)
Stage Plan (CS8)
Exception PlanRequest (DP4)
Exception Plan [C] Up-Dating A ProjectPlan (SB2)
Authorising A Stage orException Plan (DP3)
Figure 108: SB6 Plus Inputs and Outputs
Standard Tolerance is measured in Time (Schedule) and Cost. For each ManagementStage Tolerance is recommended by the Project Manager, based on the latest assessmentof risk and the nature of the work, and confirmed by the Project Board at the End StageAssessment. There is a separate component within PRINCE 2 for Tolerance described inthe Controls Component. Additional Tolerances might be usefully considered – theseinclude Scope, Quality and Risks.
The Exception report, raised by the Project Manager as soon as it is forecast that Tolerancewill be exceeded, describes the nature of the exception, its impact on the ManagementStage and Project, the options open to recover the situation, and the recommendation bythe 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 thisconsideration is identified by PRINCE).
The Project Board will normally require an Exception Plan to be created to replace theapproved plan which has been departed from; they might, of course decide to prematurelyterminate the project or to just live with the departure but this could not be described asrealistic 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 MidStage Assessment.
![Page 232: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/232.jpg)
Ken Bradley’s Understanding PRINCE 2
232
Summary of the Managing Stage Boundaries Process
The “Managing Stage Boundaries Process (SB)” Process will always be present in aPRINCE 2 controlled project (since every PRINCE project will have a minimum of twoManagement Stages, and therefore at least one SB Process).
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Next Stage Plan [C]
Up-Dating A ProjectPlan (SB2)
Project Plan [R] Up-Dating A ProjectPlan (SB2)
Project Management TeamChanges [U]
Reporting Stage End(SB5)
SB1 –Planning AStage
Current Stage Plan(CS5) (Stage File)
Stage EndNotification (CS5)
Project Plan (IP2)(Project File)
Trigger For NextStage Plan (IP2)
PID (IP6) (ProjectFile)
Current ProjectManagement Team(IP6) (Project File &Stage File)
Product Checklist [U] Reporting Stage End(SB5)
Up-Dated Project Plan [U] Up-Dating A ProjectBusiness Case (SB3)
Reporting Stage End(SB5)
Up-Dating The Risk Log(SB4)
SB2 – Up-Dating AProject Plan
Current & NextStage Plans (SB1)
Exception Plan(SB6)
Project Approach(IP6) (Project File)
Project Quality Plan(IP6) (Project File)
Next Stage Plan [R]
or
Exception Plan [R]
Reporting Stage End(SB5)
![Page 233: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/233.jpg)
Ken Bradley’s Understanding PRINCE 2
233
Business Case [U] Reporting Stage End(SB5)
SB3 – Up-Dating AProjectBusinessCase
Up-Dated ProjectPlan (SB2)
Exception Plan orNext Stage Plan(SB2)
Risk Log (SB4)
Issue Log (SB4)
Risk Log [R] Reporting Stage EndSB5)
Risk Log [U] Up-Dating A ProjectBusiness Case (SB3)
Accepting A WorkPackage (MP1)
SB4 – Up-Dating TheRisk Log
Project Plan (SB2)
Next Stage Plan(SB2)
Exception Plan(SB2)
Issue Log CS4(Quality File)
Issue Log [U] Up-Dating A ProjectBusiness Case (SB3)
End Stage Report [C] Authorising A Stage orException Plan (DP3)
Request for Authorisation ToProceed [C]
Authorising A Stage orException Plan (DP3)
Next Stage Plan [R] Authorising A Stage orException Plan (DP3)
Exception Plan [R] Authorising A Stage orException Plan (DP3)
Risk Log [R] Authorising A Stage orException Plan (DP3)
Communications to interestedparties [C]
Corporate orProgrammeManagement
SB5 –ReportingStage End
Project Plan (SB2)
Current Stage Plan(SB2)
Next Stage Plan orException Plan(SB2)
Business Case(SB3)
Issue & Risk Logs(SB3)
Quality Log (CS5)(Quality File)
CommunicationPlan (IP4) (ProjectFile)
Product Status Account [C] De-Commissioning AProject (CP1)
SB6 –ProducingAnExceptionPlan
Exception Report(CS8)
Stage Plan (CS8)
Exception PlanRequest (DP4)
Exception Plan [C] Up-Dating A ProjectPlan (SB2)
Authorising A Stage orException Plan (DP3)
Figure 109: Summary of the “Managing Stage Boundaries (SB)” Process
![Page 234: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/234.jpg)
![Page 235: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/235.jpg)
Ken Bradley’s Understanding PRINCE 2
235
UNDERSTANDING THECLOSING A PROJECT
PROCESS
Chapter 18
![Page 236: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/236.jpg)
![Page 237: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/237.jpg)
Ken Bradley’s Understanding PRINCE 2
237
Closing A Project (CP) - Introduction
At its conclusion, the project must be closed down in an orderly and firm manner. Theend of a project may arise when all the planned work has been completed and theProducts/Deliverables finished and signed off as meeting their stated Quality Criteria.Alternatively a project might be brought to a premature conclusion because of changes torequirement, removal of resources or unacceptable slippage of time, effort or costs.
Figure 110: Closing A Project (CP) Process
Most of the work involved in this major Process is concerned with preparation ofinformation 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;
ProjectEvaluationReview
CP3
ConfirmingProjectClosure
DP5
De-commissioninga Project
CP1
IdentifyingFollow-onActions
CP2
ReviewingStage Status
CS5
ReportingStage End
SB5
Giving ad hocDirection
DP4
Follow-on ActionRecommendations
Post-ProjectReview Plan
Issue, Risk andQuality Logs
Lessons LearnedReport
Project Files
Notification ofapproachingProject End
PrematureClose
Product StatusAccount
PID
Project ClosureNotification
Operational andMaintenanceAcceptance
Customer Acceptance
Lessons LearnedReport
End Project Report
![Page 238: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/238.jpg)
Ken Bradley’s Understanding PRINCE 2
238
♦ obtain Formal Acceptance of the project Products/Deliverables;
♦ confirm that all Products/Deliverables have been handed over to the Customer, andthat these have been accepted;
♦ ensure that where Ongoing Support, enhancement and maintenance is appropriate (andrequired), 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 ProjectBoard;
♦ Prepare an “End Project Report” for sign-off by the Project Board;
♦ Notify the Customer/Sponsor/Host Organisation, as appropriate, of the Intention toClose 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 theexpectations and criteria for completion and close-down have not been agreed at the outsetand this will normally have been done and the final Acceptance Criteria included withinthe Project Initiation Document. Project staff and managers should be provided with asmuch 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!
![Page 239: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/239.jpg)
Ken Bradley’s Understanding PRINCE 2
239
CP1 - Decommissioning A Project
The main aim of this Process is to bring the project to an orderly close, ensuring that theCustomer is happy with the outcome and demonstrates this by providing a CustomerAcceptance sign-off. Assurance that the outcome can be supported and that a proper audittrail exists for the project documentation, should it be needed in the future, must also beforthcoming.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Closure Notification [C] Confirming ProjectClosure (DP5)
Operational & MaintenanceAcceptance [C]
Confirming ProjectClosure (DP5)
Customer Acceptance [C] Confirming ProjectClosure (DP5)
Draft communication to interestedparties [C]
Confirming ProjectClosure (DP5)
CP1 – De-Commissioning AProject
Premature Close(DP4)
Notification ofProject End (CS5)
Product StatusAccount (CS5)
Issue Log (SB5)
PID (IP6) (ProjectFile)
CommunicationPlan (IP6) (ProjectFile)
Project Files [R] Archives
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);
![Page 240: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/240.jpg)
Ken Bradley’s Understanding PRINCE 2
240
♦ Notify all concerned that the project is coming to a conclusion and resources will bereturned.
This Process is primarily the responsibility of the Project Manager in that it marks theconclusion 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 Boardmembers to ensure there are “no surprises” at the final meeting to close the projectformally.
![Page 241: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/241.jpg)
Ken Bradley’s Understanding PRINCE 2
241
CP2 - Identifying Follow-on Actions
Essentially picking up any loose ends that remain at the conclusion of the project. Inparticular any outstanding changes in requirements, raised as Project Issues, which werenot actioned for fear of prejudicing a contractual situation or because time and budget didnot allow the changes to be introduced. There might also have been some generaltechnical improvements that would benefit the project’s outcome that the Supplier wishesto bring to the Customer’s attention.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Post-Project Review Plan [C] Confirming ProjectClosure (DP5)
CP2 -IdentifyingFollow-OnActions
Business Case(SB5)
Risk Log (SB5)
Issue Log (SB5) Follow-On ActionRecommendations [C]
Confirming ProjectClosure (DP5)
Figure112: CP2 Plus Inputs and Outputs
A major output from this Process is the Post-Project Review Plan which will be used to setup a future project to review whether the Business Benefits identified at the outset (andreviewed and updated at each formal review) of the project, have been achieved. This willusually 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 forany future projects which may arise from the recommendations made.
![Page 242: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/242.jpg)
Ken Bradley’s Understanding PRINCE 2
242
CP3 – Project Evaluation Review
The lessons learned during the project must be captured as it progresses and disseminatedto 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 againstwhat was actually achieved. This review addresses the project and its outcome rather thanthe outcome itself (which will the subject of a Post-Project Review (see CP2).
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Lessons learned Report [U] Confirming ProjectClosure (DP5)
CP3 -ProjectEvaluationReview
Lessons LearnedReport (SB5)
Risk Log (SB5)
Quality Log (SB5)
Issue Log (SB5)
PID (IP6) (ProjectFile)
End-Project Report [C] Confirming ProjectClosure (DP5)
Figure 113: CP3 Plus Inputs and Outputs
The Lessons Learned Report (Log) is a prime input to this Process, along with the variousLogs 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 andQuality Management Standards performed and to what extent they supported theproject;
♦ 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 theProject Board
![Page 243: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/243.jpg)
Ken Bradley’s Understanding PRINCE 2
243
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 foran orderly and effective shut-down of the project.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Project Closure Notification [C] Confirming ProjectClosure (DP5)
Operational & MaintenanceAcceptance [C]
Confirming ProjectClosure (DP5)
Customer Acceptance [C] Confirming ProjectClosure (DP5)
Draft communication to interestedparties [C]
Confirming ProjectClosure (DP5)
CP1 – De-Commissioning AProject
Premature Close(DP4)
Notification ofProject End (CS5)
Product StatusAccount (CS5)
Issue Log (SB5)
PID (IP6) (ProjectFile)
CommunicationPlan (IP6) (ProjectFile)
Project Files [R] Archives
Post-Project Review Plan [C] Confirming ProjectClosure (DP5)
CP2 -IdentifyingFollow-OnActions
Business Case(SB5)
Risk Log (SB5)
Issue Log (SB5) Follow-On ActionRecommendations [C]
Confirming ProjectClosure (DP5)
Lessons learned Report [U] Confirming ProjectClosure (DP5)
CP3 -ProjectEvaluationReview
Lessons LearnedReport (SB5)
Risk Log (SB5)
Quality Log (SB5)
Issue Log (SB5)
PID (IP6) (ProjectFile)
End-Project Report [C] Confirming ProjectClosure (DP5)
Figure 114: Summary of the Closing A Project (CP) Process
![Page 244: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/244.jpg)
![Page 245: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/245.jpg)
Ken Bradley’s Understanding PRINCE 2
245
UNDERSTANDING THEPLANNINGPROCESS
Chapter 19
![Page 246: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/246.jpg)
![Page 247: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/247.jpg)
Ken Bradley’s Understanding PRINCE 2
247
Planning (PL) - Introduction
Planning embraces PRINCE Components, Processes, and Techniques and is an on-goingactivity throughout the project. Understanding of the tasks involved and the possiblepitfalls will emerge from planning the project and stages; control can only be exercised inas much detail as the project plan allows; and the approaches to planning, using manual orsoftware supported techniques is a matter of preference and choice for the implementingorganisation.
Planning for all but the smallest projects is best tackled using a software support tool asthe time saved in the longer term will more than repay the initial outlay, especially wherecomplicated inter-dependencies exist between Products and Activities.
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 associatedintermediate Products/Deliverables;
Completing aPlan
PL7
(Identifying),Defining andAnalysingProducts
PL2
Designing aPlan
PL1
IdentifyingActivities andDependencies
PL3
AnalysingRisks
PL6
DefiningProjectApproach
SU5
PlanningQuality
IP1
Planning anInitiation Stage
SU6
Planning aProject
IP2
Planning aStage
SB1
Scheduling
PL5
Estimating
PL4
Authorising aProject or Plan
DP2 or DP3
ReviewingStage Status
CS5
Giving ad hocDirection
DP4
PlanDesign
ProductFlowDiagrams
ProductDescriptions List of
Activities
EstimatedActivities
Resourceavailability
Risk LogCompletedPlan forapproval
ProductChecklist
AssessedPlan Schedule
Draft ProductChecklist
Activity dependencies
Producing anExceptionPlan
SB6
![Page 248: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/248.jpg)
Ken Bradley’s Understanding PRINCE 2
248
♦ Products/Deliverables are defined and specified by producing associated ProductDescriptions;
♦ The Activities and associated Resources are identified; all Activities must be thoughtthrough to a level consistent with the control requirements identified in the ProjectInitiation Document;
The planning framework incorporated in PRINCE 2 is intended to cater for any type orsize of project - after given due consideration to the design of the plan (content, softwaretool 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 theActivities);
♦ Step 7:
Review the Plan especially in respect of Risks and determine the need for anycontingency 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.
![Page 249: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/249.jpg)
Ken Bradley’s Understanding PRINCE 2
249
PL1 - Designing A Plan
PRINCE 2 defines the plan as “the backbone” of every project; essentially it is notpossible to control in any more detail than that planned, so the best advice is to plan indetail and then select the level of control appropriate to the risk and understanding there isfor the project.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
PL1 –Designing APlan
Project Approach(SU5) (Project File)
Project Quality Plan(IP1) (Quality File)
Project Brief (SU4)(Project File)
Or
Project InitiationDocument (IP6)(Project File)
Company PlanningStandards
Plan Design [C] Relevant Process
Figure 116: PL1 Plus Inputs and Outputs
The Process addresses the fundamental decisions that must be made about planning beforeany real planning can commence. Decisions must be taken about the approach to planningand the style of presentation. The required number of levels of plan (Project-level andStage-level plans are required in PRINCE controlled projects) and the amount ofinformation to be included to provide the Project Board with adequate decision-supportmust be clearly understood.
Use of software tools for estimating and planning (and possibly for preparation of analysistools such as Product Flow Diagrams) must be considered and decisions taken. Decisionson 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).
![Page 250: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/250.jpg)
Ken Bradley’s Understanding PRINCE 2
250
PL2 - Identifying, Defining And Analysing Products
The benefits of Product-based planning is that management and the Project ManagementTeam can be assured that all planned activity within the project is geared towardsproviding known, required Products or Deliverables that will all contribute towards thefinal outcome. As the activities within a project always consume resources (time, effortand money) then management can be confident that no resource is being wasted oncarrying 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) byproducing 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,UPDATED, REFERENCED OR
USED
OUTPUT TO
Product Breakdown Structure [C] Relevant Process
Product Descriptions [C] Identifying Activities &Dependencies (PL3)
Relevant Process
Product Flow Diagram [C] Identifying Activities &Dependencies (PL3)
Relevant Process
PL2 –(Identifying)Defining &AnalysingProducts
Project Approach(SU5) (Project File)
Project Quality Plan(IP1) (Quality File)
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 theProducts for the life of the project. An attempt should be made, however, to present themost comprehensive information available to the Project Board. Often this will be limitedto a statement of the name and a brief description of the expected Product. Planning atManagement 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
![Page 251: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/251.jpg)
Ken Bradley’s Understanding PRINCE 2
251
is not possible, consideration must be given to moving the Management Stage boundaryforward to the point where a firm commitment can be made.
The Product Checklist is a useful means of identifying Products (at Project-level andManagement Stage-level), showing their planned Milestone dates and, subsequently, theachievement dates.
![Page 252: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/252.jpg)
Ken Bradley’s Understanding PRINCE 2
252
PL3 - Identifying Activities And Dependencies
The Product Flow Diagram can be put to use to identify the Activities within the plan andto provide an indication of the likely dependencies between them.
PROCESS
INPUT &SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
PL3 –IdentifyingActivities &Dependencies
Product FlowDiagram (PL2)
ProductDescriptions(PL2)
Risk Log (ProjectFile)
List of Activities [C]
and
Activity Dependencies [C]
Scheduling (PL5)
Figure 118: PL3 Plus Inputs and Outputs
Each connection between Products (and external entities) on the Product Flow Diagramrepresents one or more potential activities to be carried out to create the Product. Armedwith this principle, the Project Manager or planner can derive the raw data to plan theactivities of the Project, Management Stage or Team Plan. The process of derivingactivities from the Product Flow Diagram is also known as “Transformation”.
![Page 253: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/253.jpg)
Ken Bradley’s Understanding PRINCE 2
253
PL4 - Estimating
Accuracy and consistency of estimating is perhaps the single most important aspect ofproject management. PRINCE 2 devotes little space to how to estimate the projectactivities as it relies on the availability of specific approaches and techniques beingavailable within the organisations involved in the project.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
PL4 –Estimating
All PlanningInformation
Activity Estimates [C] Scheduling (PL5)
Figure 119: PL4 Plus Inputs and Outputs
Organisations wishing to formalise their estimating methods and procedures will wish toconsider 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 StructuredSystems Analysis and Design (SSADM) Methods. The Method is suitable only for ITprojects 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 byobtaining a “first-cut” estimate from each individual and gradually refining the estimatesthrough filters until the most optimistic, most pessimistic, and most likely by consensus isobtained 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 formany years!
![Page 254: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/254.jpg)
Ken Bradley’s Understanding PRINCE 2
254
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 aSoftware planning tool such as MS Project. There is no requirement in the Method touse a software tool but it will be a great timesaver in all but the smallest of projects.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
PL5 –Scheduling
List of Activities(PL3)
and
ActivityDependencies(PL3)
Activity Estimates(PL4)
Schedule [C] Scheduling (PL6)
Relevant Process
Figure 120: PL5 Plus Inputs and Outputs
The techniques used in this Process are fully explained in the Chapter on “UnderstandingThe Product-Based Planning Component and Technique”. At the same time thatactivities are being inserted into a software support tool, the planner will be prompted toenter resource availability and estimating information. The plan created in this Processaddresses both the work to be done, including start and finish dates, and the people neededto 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 ProjectManagement Team and the Project Board members. Where a software support tool is notbeing used, a separate Resource Plan will need to be produced to inform the Project Boardof the commitment of resources that is being asked of them.
![Page 255: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/255.jpg)
Ken Bradley’s Understanding PRINCE 2
255
PL6 - Analysing Risks
Before a plan can be completed the risks must be re-visited to ensure that any appropriatecontingency planning has been catered for. Risks should, of course, also be addressed atthe outset of planning and through every step.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Risk Log [U]
Completing A Plan(PL7)
PL6 –AnalysingRisks
All PlanningInformation
Risk Log (ProjectFile)
Schedule (PL5)
Assessed Plan (Schedule) [U] Completing A Plan(PL7)
Figure 121 : PL6 Plus Inputs and Outputs
Each of the resources planned for should be examined and considered for potential riskand action taken to include a contingency in the plan. Risks can arise from many sourcesincluding:
♦ 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.
![Page 256: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/256.jpg)
Ken Bradley’s Understanding PRINCE 2
256
PL7 - Completing A Plan
The plans addressed in PL2 - PL5 are largely support documents for presentinginformation to those responsible for decision-making (mainly the Project Board). Toconclude the plans the Project Manager or Team Manager must draw all the elementstogether and provide a brief summary addressing all the salient points; this is known asthe “Plan Text”.
PROCESS
INPUT & SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
Plan Text [C]
Plus
Completed Plan For Approval [U]
Relevant Process andApproval By ProjectBoard/Project Manager
PL7 –CompletingA Plan
Assessed Plan(Schedule)(PL6)
Draft ProductChecklist (PL2)
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 variousplans and analysis sheets appended to it. The Product Checklist (initially created in “IP2 –(Identifying), Defining And Analysing Products”) is also completed by the insertion ofplanned start and completion dates for each of the Products.
It is in this Process that consideration should also be given to creating a “GraphicalSummary of the Plan” which, although not a part of the stated PRINCE 2 plan package, isan invaluable aid to the Project Board and other members of senior management inunderstanding what the plan is trying to achieve.
![Page 257: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/257.jpg)
Ken Bradley’s Understanding PRINCE 2
257
Summary of the Planning (PL) ProcessPlanning is uses throughout the PRINCE 2 Method. In many ways it is unhelpful to viewplanning as a “Process” - it is essentially a “Technique” used on a day to day basis andcoming into prominence at the beginning of the project and at the end of eachManagement Stage.
PROCESS
INPUT &SOURCE
PRODUCTS CREATED,UPDATED, REFERENCED OR
USED
OUTPUT TO
PL1 –Designing APlan
Project Approach(SU5) (ProjectFile)
Project QualityPlan (IP1)(Quality File)
Project Brief(SU4) (ProjectFile)
Or
Project InitiationDocument (IP6)(Project File)
CompanyPlanningStandards
Plan Design [C] Relevant Process
Product Breakdown Structure [C] Relevant Process
Product Descriptions [C] Identifying Activities &Dependencies (PL3)
Relevant Process
Product Flow Diagram [C] Identifying Activities &Dependencies (PL3)
Relevant Process
PL2 –(Identifying)Defining &AnalysingProducts
Project Approach(SU5) (ProjectFile)
Project QualityPlan (IP1)(Quality File)
Draft Product Checklist [C] Completing A Plan(PL7)
![Page 258: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/258.jpg)
Ken Bradley’s Understanding PRINCE 2
258
PL3 –IdentifyingActivities &Dependencies
Product FlowDiagram (PL2)
ProductDescriptions(PL2)
Risk Log (ProjectFile)
List of Activities [C]
and
Activity Dependencies [C]
Scheduling (PL5)
PL4 –Estimating
All PlanningInformation
Activity Estimates [C] Scheduling (PL5)
PL5 –Scheduling
List of Activities(PL3)
and
ActivityDependencies(PL3)
ActivityEstimates (PL4)
Schedule [C] Scheduling (PL6)
Relevant Process
Risk Log [U]
Completing A Plan(PL7)
PL6 –AnalysingRisks
All PlanningInformation
Risk Log (ProjectFile)
Schedule (PL5)
Assessed Plan (Schedule) [U] Completing A Plan(PL7)
Plan Text [C]
Plus
Completed Plan For Approval [U]
Relevant Process andApproval By ProjectBoard/Project Manager
PL7 –Completing APlan
Assessed Plan(Schedule)(PL6)
Draft ProductChecklist (PL2)
Product Checklist [U] Project or Stage File
Figure 123: Summary of the Planning (PL) Process
![Page 259: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/259.jpg)
Ken Bradley’s Understanding PRINCE 2
259
UNDERSTANDING THE
PRINCE 2 FILING
TECHNIQUE
Chapter 20
![Page 260: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/260.jpg)
![Page 261: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/261.jpg)
Ken Bradley’s Understanding PRINCE 2
261
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 StageFiles)
♦ The Specialist File
♦ The Quality File
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 thesuggested 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;
Project FileOrganisationPlansBusiness CaseRisk LogControl DocumentsProducts Checklist
Files
Stage File(s)OrganisationPlansControl DocumentsDaily LogCorrespondenceProducts Checklist
Specialist FileConfiguration ItemsConfiguration LogCI LocationsOff-Specifications
Quality FileProduct DescriptionsQuality ChecksProject Issues
![Page 262: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/262.jpg)
Ken Bradley’s Understanding PRINCE 2
262
♦ 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
![Page 263: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/263.jpg)
Ken Bradley’s Understanding PRINCE 2
263
Figure125: Comprehensive View of the Project File The Management Stage Files (one file or section for each Management Stageof 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 storedin 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;
Management File - Project File
* Project Mandate* Project Brief* Project Organisation Structure* Project Organisation Roles & Responsibilities* Project Approach* Project Board Approval For Initiation
* Baselined Project Initiation Document* Project Filing Structure Summary* Project Board Approval For The Project
* Record of End Stage Assessments* Record of Mid Stage Assessments
* Product Checklist (Project Level Products)* Highlight Reports* Exception Reports (Project)* Project End Notification
* Business Case (Initial & Updates)* Project Plan (Initial & Updates)* Risk Log
* Lessons Learned Report* Project Closure Recommendation* Post Implementation Review Plan* End Project Report
![Page 264: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/264.jpg)
Ken Bradley’s Understanding PRINCE 2
264
♦ Checkpoint Reports, Highlight Reports;
♦ Exception Reports;
♦ End Stage Assessment and Mid Stage Assessment records and formal ProjectBoard 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 theManagement Stage.
♦ Correspondence - management correspondence and other papers relevant to the
Management Stage.
![Page 265: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/265.jpg)
Ken Bradley’s Understanding PRINCE 2
265
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 specificConfiguration 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 theQuality File);
♦ Specialist General Correspondence especially where a number of Configuration Items
are referred to.
Figure 127: Comprehensive View of the Specialist File
Specialist File
* Configuration Items* Location of Configuration Items* Log of Configuration Items
* Off Specifications For Configuration Items
* Correspondence Relating To Specialist Products
Management File - Stage File
* Stage Organisation Structure* Stage Organisation Roles & Responsibilities
* Current Stage Plan* Project Board Approval For The Stage
* Work Package Authorisation (Contract)* Checkpoint Reports* Exception Reports (Stage Level)* Product Checklist (Stage Level Products)* End Stage Report
* Daily Log* Correspondence
![Page 266: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/266.jpg)
Ken Bradley’s Understanding PRINCE 2
266
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.
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 binderfor a small project to a whole room of filing cupboards for a major initiative. The Methodhas no views on the physical implementation of filing arrangements.
It will often be sensible to establish an electronic filing structure to help standardise thefiling arrangements within the implementing organisation.
Quality File
* Master Product Descriptions
* Quality Review Documentation - Invitations - Error Lists - Follow-up Actions - Sign-offs/Results
* Project Issues - Issue Log - Project Issues - Requests For Change - Off-Specifications
* Project Quality Plan
* Project Quality Plan* Stage Quality Plan
* Quality Log
![Page 267: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/267.jpg)
Ken Bradley’s Understanding PRINCE 2
267
UNDERSTANDING THE
QUALITY REVIEW
TECHNIQUE
Chapter 21
![Page 268: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/268.jpg)
![Page 269: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/269.jpg)
Ken Bradley’s Understanding PRINCE 2
269
PRINCE 2 Quality Review Technique - Introduction
In PRINCE projects, quality is controlled through a number of quality managementprocedures and techniques. Used correctly, in appropriate circumstances and inconjunction with Product Descriptions (see the Product-Based Planning Technique), theQuality 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 andTechniques; it is not perceived as something separate that can be applied after a Productor 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 asdifferent, but mutually supportive, Quality Assurance will normally be present in theform of a published and defined Quality Management System, often implemented againstthe BS/EN/ISO9001 standard.
A Quality Management System (QMS) provides the all important backdrop to managingquality throughout the whole organisation and provides an environment of confidence forstaff and customers alike. This confidence manifests itself in a considered, professionalapproach to all tasks undertaken by all personnel - ensuring that the primary objective ofthe control functions - the Quality Review Technique, for example - is to confirm that allproject deliverables meet their stated Quality Criteria (contained within the appropriateProduct Description) rather than to identify perceived deficiencies and mistakes.
Some organisations may find they are at odds with this approach, having spent manyyears using quality control techniques to pick up faults and planning re-work ofdeliverables as an inevitable outcome of the quality checks. But it does not have to belike this - given a sensibly written set of quality procedures, published in the form of aQuality Management System, reflecting the principles of BS/EN/ISO9001 and regularlyaudited by internal and external auditors, any organisation can enjoy a qualityenvironment, 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 aProduct’s completeness and adherence to standards by a review procedure”. In essence aQuality Review is a review of a Product with the emphasis on checking for errors andomissions, and non-compliance with the stated Quality Criteria. The PRINCE 2 QualityReview has a clear and defined structure which when followed will produce the requiredresults.
![Page 270: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/270.jpg)
Ken Bradley’s Understanding PRINCE 2
270
Quality Reviews - Formal and Informal
Quality Reviews can be either formal, for example a scheduled meeting, or informal. Theselection 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 inreaching a final decision on whether to recommend a formal or informal Quality Reviewbut whatever the decision, the objective is the same - to confirm that the product ordeliverable under review conforms to its stated and agreed Quality Criteria.
An informal Quality Review may take many forms. A simple test or visual inspection tocheck out the Product may be both sensible and acceptable. A "desk-check" may becarried out. This might be performed by the author's line manager, or could be carried outby an expert Reviewer either within or outside the project, site or organisation. In manycases a physical test of the deliverable will be the obvious way to assure compliance withthe Quality Criteria. In all circumstances, the documentation must be produced to recordthe 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 providingthe 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 monitoringappropriate use of organisational, industry and ethical standards on behalf of theProject Board and senior managers.
![Page 271: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/271.jpg)
Ken Bradley’s Understanding PRINCE 2
271
The Quality Review Steps
Detailed procedures for carrying out a Quality Review will normally be specified by theorganisation’s own Quality Management System, but where such a system is notpublished, 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 againstits Product Description and to create a list of queries, possible errors, and topics thatwarrant re-examination.
♦ The Chair will check with the Producer that the product will be ready on time andensure 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 specificStandards used in the production of the Product would normally be available to allproject personnel - if not a copy of the relevant Standard used to produce thedeliverable should be attached. This should dispatched between one and five daysbefore the review.
♦ Each Reviewer will study the product and supporting documents (including the
Quality Criteria included in the Product Description), and will complete a QualityReview Error List.
♦ The QR Error List will, wherever possible, be sent to the Producer before the review.
Figure 129: Formal Quality Review Step 1
Product Description
Finished Product
Error Lists
Producer of the Product Reviewers of the Product
![Page 272: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/272.jpg)
Ken Bradley’s Understanding PRINCE 2
272
Step 2 - The Review Meeting
The objective of the Quality Review is to agree a list of queries, observations and errorsin the Product. The Chair and the Producer do not have to reconcile these errors at themeeting - it is sufficient for the QR Chairman and Reviewers to agree that a particular areaneeds re-examination. Provided that the point and follow-up action is logged, theReviewers have an opportunity to confirm that action has been taken, after the reviewmeeting.
The procedure for the PRINCE Quality Review step is:
♦ The Quality Review Chair opens the meeting and introduces those present ifnecessary. The meeting Objectives and Timing (a maximum of 2 hours isrecommended) 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 anopportunity for an overall reaction to the total Product and to consider prematureclosure 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' QRError 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 acceptedsolutions!). Follow-up Actions are noted on the QR Follow-Up Action List by eitherthe Scribe or Project Support. No minutes need be taken of the review. Reviewers’comments are always related to the Quality Criteria contained in the ProductDescription - these are the measures used by all involved to determine theacceptability, 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 ofthe Reviewer who will sign-off any specific point is recorded on the QR Follow-UpAction 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 theFollow-Up Action List attached. These forms will be sent to Project Support (or theProject 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 andpassed to the Producer to assist in the Follow-up.
![Page 273: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/273.jpg)
Ken Bradley’s Understanding PRINCE 2
273
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 QRFollow-Up Action List are dealt with and signed off.
♦ The Producer takes the list away from the review and evaluates, discusses, andcorrects, 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 whoraised the query initially, or may be another Reviewer, the Project Manager, TeamManager, 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 toProject Support (or the Project Manager or Team Manager) to up-date plans.
Error Lists
Chair-person
Follow-Up Actions
Sign-off
Quality Reviewed Product
Quality Review Meeting
![Page 274: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/274.jpg)
Ken Bradley’s Understanding PRINCE 2
274
Product Description
Finished Product
Error Lists
Producer of the ProductReviewers of the Product
Chair-person
Follow-Up Actions
Sign-off
Quality Reviewed Product
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 allaspects are properly covered. It needs to be used with common-sense (to avoid thedangers of an over-bureaucratic approach) but with an intent to follow the procedures laiddown (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 Reviewprocedures. PRINCE 2 emphasises the need to ensure that all Products pass through aquality control process (as laid down in the Product Description); this ensures that only"reviewed - correct - products" are regarded as being complete. The PRINCE 2 Manualcontains a fairly detailed step-by-step summary of the Quality Review Technique whichshould be consulted and modified to suit the required procedure within the implementingorganisation.
![Page 275: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/275.jpg)
Ken Bradley’s Understanding PRINCE 2
275
Ken Bradley’sUnderstanding PRINCE 2
Index
Chapter 22
![Page 276: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/276.jpg)
![Page 277: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/277.jpg)
Ken Bradley’s Understanding PRINCE 2
277
Index
A
Acceptance Criteria · 155, 164, 202, 238Accepting A Work Package · 144, 217Accountability · 33, 36, 61, 74Activities · 77, 81, 82, 88, 89, 130Activity · 38, 77, 91Actuals · 29, 200, 204, 218, 249, 263Analysing Risks · 145, 255Appointing A Project Management Team ·
144Assembling A Project Initiation Document ·
144Assessing Progress · 144, 200, 204, 218Authorised Work Package · 91, 124, 125Authorising A Project · 108, 144, 184Authorising A Work Package · 144, 199, 209Authorising Initiation · 144, 154, 183
B
Baseline · 44, 96, 164Benefits · 25, 26, 44, 45, 58, 61, 88, 89, 96,
163, 224Benefits Statement · 88boundary · 27, 70, 71BS/EN/ISO9000 · 42, 60, 123, 269BS/EN/ISO9001 · 42, 123BS6079 · 42, 123Business Benefits · 29, 49, 50, 88, 108, 113,
135, 168, 227, 241, 262Business Case · 26, 45, 88, 89, 96Business Case · 60, 87, 88, 113, 154, 163,
223, 224, 262
C
CCTA · 2, 3, 17, 19, 20, 21, 53, 113, 253Change Controls · 52Checkpoint · 264Closing A Project · 29, 30, 31, 47, 102, 141,
144, 187, 189, 237, 242CMM · 52, 129, 130Communication · 25, 57, 67, 68, 69Completed Work Packages · 125Completing A Plan · 145, 256Components · 17Components · 28, 30, 31, 32, 54, 143, 247,
269Concurrent Engineering · 72, 73
Configuration · 26, 31, 40, 43, 52, 53, 65, 74,125, 129, 130, 131, 135, 136, 202, 218,265, 266
Configuration Librarian · 135Configuration Management · 40, 43, 52, 74,
129, 130Confirming Project Closure · 144, 155, 189Context Diagram · 145, 146Control · 17, 25, 26, 34, 39, 42, 43, 44, 45,
51, 57, 61, 62, 64, 72, 74, 77, 84, 89, 90,94, 96, 124, 129, 130, 135, 136, 137, 182,216, 224, 247, 248, 269, 270
Controlling A Stage · 29, 30, 31, 125, 141,144, 157, 197, 210, 212, 218, 249
Controls · 44, 50, 52, 94Critical Path · 19, 81Customer’s Quality Expectations · 165
D
decision points · 27, 181Decision-support · 224, 237Decommissioning A Project · 144, 155, 164,
239Defining Project Approach · 144Deliverables · 25, 26, 27, 36, 38, 39, 40, 47,
60, 102, 146, 223, 237, 238, 247, 248Delivering A Work Package · 144, 219Dependencies · 27, 247Designing A Plan · 145, 249Designing A Project Management Team · 144Directing A Project · 29, 30, 31, 58, 141,
144, 157, 177, 181, 191, 193
E
Earned Value · 86, 87, 90End-Stage Assessment · 43, 64Enhancement · 17, 19ESA · 45, 64, 96, 264Escalating Project Issues · 203Estimating · 38, 65, 249, 253, 254Estimating · 38, 145, 253Evaluating A Project · 144, 242Exception · 38, 182, 224, 263, 264Exception Plan · 44, 45, 98, 144, 182, 185,
186, 187, 208, 231Exception Report · 44, 45, 98, 186, 187, 203,
208, 231Executing A Work Package · 144, 218Executive · 30, 34, 59, 61, 71, 74, 89, 144,
152, 153, 156, 183
![Page 278: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/278.jpg)
Ken Bradley’s Understanding PRINCE 2
278
External Assurance · 36, 60, 61
F
Feasibility · 88Feasibility Study · 88Filing · 32, 53, 65, 129, 171, 172, 261, 266Follow-on Actions · 48, 102, 144, 238, 241Formal Quality Review · 51, 65, 271, 273,
274
G
Gantt · 40, 41, 42, 43, 77, 82, 83, 84, 90, 91,124, 262, 263
Giving Ad-Hoc Direction · 144, 188Government Departments · 17Graphical Summary · 85, 86, 87, 90, 256
H
Highlight Report · 62, 63, 68, 69, 182, 264Highlight Reports · 30, 48, 73, 102, 188Hints and Tips · 33, 146
I
Identifying Activities And Dependencies ·145, 252
Identifying, Defining And Analysing Products· 145, 250
Initiating A Project · 27, 29, 30, 31, 42, 44,47, 50, 96, 102, 108, 124, 125, 141, 157,158, 163, 164, 166, 173, 175, 176, 184
Internal Assurance · 36, 60, 61Issues · 52, 129, 136, 137, 198, 266Issues Log · 48, 102, 202, 203, 204
L
Lessons learned · 242Lessons Learned · 47, 102, 224, 238, 242,
262Lessons Learned Report · 47, 102, 262Levels of plan · 249Lifecycle · 18
M
Maintenance · 17management · 17, 19, 20, 25, 26, 27, 32, 33,
34, 35, 37, 38, 39, 42, 44, 45, 46, 47, 57,62, 64, 65, 67, 68, 69, 70, 72, 74, 81, 88,
94, 96, 99, 102, 113, 123, 130, 135, 141,145, 146, 176, 182, 197, 216, 264, 269
Management Products · 64, 65, 78Management Stage · 26, 29, 30, 38, 42, 45,
47, 48, 49, 50, 62, 80, 86, 89, 90, 98, 100,102, 104, 108, 109, 110, 124, 125, 141,155, 157, 163, 166, 167, 168, 174, 184,185, 186, 197, 198, 199, 200, 201, 203,204, 205, 208, 209, 217, 218, 220, 225,226, 227, 228, 229, 230, 231, 250, 251,252, 257, 263, 264
Management Stages · 26, 28, 30, 31, 32, 35,48, 49, 64, 103, 104, 107, 108, 109, 110,164, 169, 232
Managing Product Delivery · 29, 30, 31, 91,107, 125, 141, 157, 200, 215, 220
Managing Stage Boundaries · 29, 30, 31,108, 115, 141, 157, 166, 167, 168, 174,184, 186, 199, 223, 232, 233
Manuals · 59Mid Stage Assessment · 45, 98, 169, 186,
231, 264Milestone · 87, 251
O
Objectives · 44, 94, 237Off-Specification · 135, 136, 137, 202Operation · 18, 131Organisation · 26, 32, 33, 34, 35, 36, 37, 39,
44, 48, 51, 57, 58, 59, 60, 65, 67, 68, 69,70, 71, 72, 74, 76, 88, 96, 102, 114, 116,124, 125, 135, 141, 146, 165, 170, 181,197, 199, 200, 209, 217, 218, 224, 238,242, 247, 266, 269, 270, 271, 274
Organisation · 17, 20, 25, 33, 238, 261, 263Ownership · 58
P
PERT · 40, 81, 82, 90, 254, 262, 263PID · 44, 50, 96, 115, 155, 157, 163, 164,
173, 174, 177, 182, 183, 184Plan · 26, 38, 40, 41, 42, 43, 44, 61, 62, 71,
72, 76, 77, 83, 85, 87, 89, 90, 94, 182, 198,224, 238, 247
Plan Description · 87, 89, 90Plan Text · 89, 90, 248, 256Planning · 19, 20, 27, 30, 31, 35, 38, 39, 40,
41, 42, 43, 44, 50, 53, 62, 65, 72, 74, 76,77, 78, 83, 84, 88, 89, 94, 108, 109, 110,124, 125, 151, 153, 157, 164, 165, 166,200, 228, 247, 248, 249, 250, 255, 257,269
Planning · 17, 19, 25, 29, 30, 31, 32, 38, 40,41, 42, 43, 50, 76, 124, 141, 144, 145, 157,
![Page 279: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/279.jpg)
Ken Bradley’s Understanding PRINCE 2
279
165, 166, 174, 187, 225, 247, 250, 254,257, 258, 269
Planning A Project · 141Planning An Initiation Stage · 144Planning levels · 76Plans · 76, 77, 89, 91Post Project Review · 29, 30, 177, 189, 241,
242Preparing A Project Brief · 144PRINCE · 15, 17, 19, 20, 25, 26, 27, 28, 32,
33, 34, 36, 37, 38, 39, 40, 42, 44, 47, 51,52, 53, 54, 57, 58, 59, 60, 61, 63, 64, 65,67, 69, 71, 72, 74, 76, 77, 79, 89, 90, 91,94, 102, 113, 123, 129, 130, 135, 136, 137,141, 145, 146, 216, 247, 261, 269, 272,274
PRINCE 2 · 1, 14, 20, 21, 26, 27, 28, 29, 30,31, 32, 34, 36, 37, 38, 41, 42, 43, 47, 48,49, 50, 53, 54, 57, 58, 61, 64, 65, 66, 69,72, 74, 76, 77, 79, 84, 85, 86, 87, 91, 99,103, 107, 108, 109, 110, 123, 124, 129,137, 139, 141, 142, 143, 145, 146, 151,152, 153, 155, 158, 164, 165, 166, 168,169, 170, 171, 172, 173, 174, 177, 202,210, 220, 227, 228, 231, 232, 248, 249,253, 256, 257, 259, 261, 269, 274
PRINCE Environment · 20, 53Process Models · 145, 146Process-based · 33Processes · 26, 27, 57, 125, 130, 141, 157Processes · 26, 27, 28, 29, 30, 31, 32, 35, 44,
54, 65, 96, 141, 143, 144, 145, 146, 157,163, 166, 181, 188, 247, 269
Product Breakdown Structure · 40, 78, 80,90, 261, 263
Product Description · 32, 40, 42, 50, 51, 63,78, 79, 80, 124, 125, 165, 217, 250, 265,269, 271, 272, 274
Product Flow Diagram · 32, 40, 80, 81, 90,250, 252, 262, 263
Product Flow Diagrams · 249Products · 20, 26, 34, 35, 38, 40, 43, 49, 50,
52, 61, 62, 80, 125, 129, 131, 135, 186,274
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,135, 146, 197, 215, 216, 223, 237, 238,247, 248, 262, 264. See Outputs
Programme · 57, 62, 69, 70, 71, 72, 81Programme of work · 48, 103Project Approach · 152, 156, 171Project Assurance · 35, 36, 60, 61, 64, 68,
70, 73, 74, 137, 225, 270Project Assurance Team · 270Project Board · 30, 31, 32, 33, 34, 35, 36, 37,
39, 41, 43, 44, 45, 46, 47, 48, 50, 58, 59,
60, 61, 62, 63, 64, 65, 67, 68, 70, 71, 72,73, 74, 82, 83, 84, 85, 86, 87, 89, 90, 94,96, 98, 99, 100, 102, 103, 107, 108, 110,113, 114, 124, 131, 136, 141, 144, 146,151, 152, 153, 154, 156, 157, 164, 166,167, 168, 169, 171, 174, 175, 176, 177,181, 182, 183, 184, 185, 186, 187, 188,189, 190, 197, 198, 199, 200, 201, 203,204, 205, 206, 207, 208, 216, 217, 223,224, 225, 226, 227, 228, 229, 230, 231,237, 238, 240, 242, 243, 249, 250, 254,256, 264, 270
Project Brief · 31, 124, 152, 154, 155, 156,165, 168, 171
Project Closure · 47, 102, 181, 182Project Files · 64Project Initiation · 19, 43, 44, 53, 61, 87, 94,
96, 113, 163, 164, 182, 237, 238, 248, 262,270
Project Issue Report · 129, 135, 136Project issues · 239, 266Project Issues · 32, 48, 102, 129, 135, 136,
137, 144, 200, 202, 203, 208, 241Project Management Team · 29, 30, 58, 74,
78, 151, 152, 153, 166, 171, 174, 175, 198,202, 207, 225, 228, 230, 250, 254
Project Manager · 19, 29, 30, 32, 35, 36, 37,39, 43, 45, 47, 48, 49, 50, 52, 53, 61, 62,63, 64, 68, 69, 70, 71, 72, 73, 74, 78, 83,87, 88, 91, 98, 100, 102, 104, 107, 109,110, 113, 117, 124, 125, 131, 135, 136,141, 144, 146, 152, 153, 166, 169, 170,174, 181, 182, 184, 186, 188, 190, 197,198, 199, 200, 201, 203, 204, 207, 208,210, 215, 216, 217, 218, 224, 225, 226,230, 231, 240, 242, 250, 252, 256, 270,272, 273
Project Mandate · 88, 151Project plans · 26, 71, 85Project Support · 36, 37, 53, 60, 61, 63, 64,
65, 69, 71, 72, 74, 131, 135, 137, 270, 272,273
PROMPT · 17, 18, 19, 20Public Domain · 25
Q
QMS · See Quality Management SystemQuality · 17, 19, 26, 36, 38, 40, 42, 50, 51,
60, 61, 63, 65, 70, 73, 78, 79, 87, 90, 102,125, 135, 197, 215, 216, 223, 237, 261,263, 265, 266, 269, 270, 271, 272, 274
Quality assurance · 17, 274Quality criteria · 35, 43, 50, 51Quality Criteria · 31, 32, 51, 124, 125, 165,
217, 230, 269, 270
![Page 280: Understanding PRINCE 2 - WLV C Prince 2.pdf · Ken Bradley’s Understanding PRINCE 2 3 Dedication This book is dedicated to the many clients and friends who over the past two decades](https://reader033.fdocuments.in/reader033/viewer/2022042407/5f21d4505f85275591077fda/html5/thumbnails/280.jpg)
Ken Bradley’s Understanding PRINCE 2
280
Quality Management · 19, 26, 42, 50, 73,119, 120, 123, 124, 125, 165, 242, 269,270, 271
Quality Management System · 42, 73, 125,269, 270, 271
Quality Review Technique · 32, 124, 269,274
Quality Reviews · 90, 266, 270
R
Rapid Application Development · 72, 73Receiving A Completed Work Package · 144,
209Refining The Business Case and Risks · 144Reporting Highlights · 144, 205Reporting Stage End · 144, 229Request for Change · 135, 136, 137Request For Change · 136, 202Resource · 17, 82, 83, 84, 85, 90Resource Plan · 40, 42, 84, 85, 90, 254Resources · 82, 83Resources Report · 41, 42, 85, 263responsibilities · 26, 33, 36, 58, 62, 63, 64Review · 136, 271, 272, 273Reviewing Stage Status · 144, 200, 204, 205,
207Risk · 31, 36, 41, 43, 62, 69, 72, 87, 88, 89,
110, 113, 114, 115, 117, 163, 168, 169,183, 206, 223, 228, 231, 249, 255
Risk Assessment · 65, 87, 88, 113, 115, 262Risk Factor · 115, 117, 120Risks · 26, 27, 44, 45, 83, 87, 89, 90, 96, 113,
163, 224Risks · 29, 49, 50, 60, 168, 248, 255Role descriptions · 58Roles · 33, 34, 36, 58, 59, 61
S
Scheduling · 145, 254Scoping Diagram · 27Senior User · 59, 71, 136Setting Up Project Controls · 144, 169Setting Up Project Files · 144Significant deviation · 45, 98, 186Smaller projects · 59Software · 20, 65, 72, 76, 77, 83, 84, 90, 247Software support tool · 41, 78, 254Software tools · 249specialist · 25, 33, 34, 35, 36, 38, 39, 58, 59,
62, 64, 65, 67, 69, 90, 91, 109, 130, 135,216, 270
Specialist Stages · 64
SPOCE · 113Stage · 18, 26, 27, 36, 38, 39, 40, 42, 43, 44,
45, 46, 47, 50, 61, 62, 63, 77, 84, 85, 86,89, 90, 96, 99, 102, 125, 137, 164, 223,224, 264
Stage Manager · 83, 136Stages · 18, 26, 27, 33, 64, 72, 89, 181, 224,
247Stages · 18, 31, 35, 48, 49, 64, 103, 104, 107,
109, 223, 230Starting A Project · 44, 96, 141, 151Starting Up A Project (SU) · 124Strategic Planning · 17Supplier · 34, 57, 58, 59, 65, 67, 69, 71, 215,
216System Development · 17
T
Taking Corrective Action · 144, 205, 207Team Leader · 36Team Manager · 35, 36, 62, 63, 64, 69, 72,
74, 78, 83, 136Team Managers · 35, 61, 62, 64, 72, 74Team Plan · 91, 252Teams · 36, 37Technical · 18, 31, 35, 47, 48, 49, 61, 64, 84,
90, 99, 103, 104, 107, 109, 130, 271Techniques · 26, 33, 38, 39, 57, 65, 113, 125,
129, 143, 247, 253, 254, 269, 270Techniques · 28, 32, 38, 51, 54, 129, 143,
145, 247Terms of Reference · 44, 94, 154Tolerance · 30, 43, 46, 47, 99, 100, 169, 182,
186, 198, 203, 204, 207, 208, 224, 231Transformation · 252
U
UK Government · 17, 20Updating A Project Business Case · 144, 227Updating A Project Plan · 144, 226Updating The Risk Log · 144, 227, 228User · 20, 34, 89, 135, 137User/Customer Group · 71
W
Walk-through · 51, 272Work Package · 263Work Packages · 109, 125, 197, 199, 209,
218