Other publications by Van Haren Publishing
Van Haren Publishing (VHP) specializes in titles on Best Practices, methods and standards within IT and business management. These publications are grouped in the following series: ITSM Library (on behalf of ITSMF International), Best Practice and IT Management Topics. VHP is also publisher on behalf of leading companies and institutions, eg The Open Group, IPMA-NL, CA, Getronics, Pink Elephant). At the time of going to press the following books are available:
IT (Service) Management / IT Governance ITSM, ITIL® V3 and ITIL® V2
Foundations of IT Service Management – based on ITIL V3 (English and Dutch versions Autumn 2007, French, German, Japanese and Spanish editions: Winter 2007)
IT Service Management – An Introduction (English and Dutch versions Autumn 2007, French, German, Japanese and Spanish editions: Winter 2007)
IT Service Management based on ITIL V3 – A Pocket Guide (English and Dutch versions Autumn 2007, French, German, Japanese and Spanish editions: Winter 2007)
IT Service Management based on ITIL V3 – A Pocket Guide (English and Dutch versions Autumn 2007, French, German, Japanese and Spanish editions: Winter 2007)
Foundations of IT Service Management based on ITIL® (ITIL V2),
(English, Dutch, French, German, Spanish, Japanese, Chinese, Danish, Italian, Korean, Russian, Arabic; also available as a CD-ROM)
Implementing Service and Support Management Processes (English) IT Service Management - een samenvatting, 2de druk (Dutch) Release and Control for IT Service Management, based on ITIL®
-A Practitioner Guide (English)
ISO/IEC 20000
ISO/IEC 20000 - A Pocket Guide (English, Italian, German, Spanish, Portuguese)
ISO/IEC 20000 – An Introduction (English: Autumn 2007) Implementing ISO/IEC 20000 (English: Autumn 2007) ISO 27001 and ISO 17799
Information Security based on ISO 27001 and ISO 17799 - A Management Guide (English)
Implementing Information Security based on ISO 27001 and ISO 17799 - A Management Guide (English) COBIT
IT Governance based on CobiT4® - A Management Guide
(English, German) IT Service CMM
IT Service CMM - A Pocket Guide (English) ASL and BiSL
ASL - A Framework for Application Management (English, German)
ASL - Application Services Library - A Management Guide (English, Dutch)
BiSL - A Framework for Business Information Management (Dutch, English)
BiSL - Business information Services Library - A Management Guide (Dutch; English edition due Autumn 2007) ISPL
IT Services Procurement op basis van ISPL (Dutch)
IT Services Procurement based on ISPL – A Pocket Guide (English) IT Topics & Management instruments
De RfP voor IT-outsourcing (Dutch; English version due autumn 2007)
Decision- en Controlfactoren voor IT-Sourcing (Dutch) Defi ning IT Success through the Service Catalog (English) Frameworks for IT Management - An introduction
(English, Japanese; German edition Autumn 2007)
Frameworks for IT Management – A Pocket Guide (Winter 2007)
Implementing leading standards for IT management (English, Dutch)
IT Service Management Best Practices, volumes 1, 2, 3 and 4 (Dutch)
ITSM from hell! / ITSM from hell based on Not ITIL (English) ITSMP - The IT Strategy Management Process (English) Metrics for IT Service Management (English) Service Management Process Maps (English) Six Sigma for IT Management (English)
Six Sigma for IT Management – A Pocket Guide (English) MOF/MSF
MOF - Microsoft Operations Framework, A Pocket Guide (Dutch, English, French, German, Japanese) MSF - Microsoft Solutions Framework, A Pocket Guide
(English, German)
TOGAF, The Open Group Architecture Framework – A Management Guide (English)
The Open Group Architecture Framework – 2007 Edition (English, offi cial publication of TOG)
TOGAF™ Version 8 Enterprise Edition – Study Guide (English, offi cial publication of TOG) TOGAF™ Version 8 Enterprise Edition –Pocket Guide
(English, offi cial publication of TOG)
Quality Management IT Architecture
ISO 9000
ISO 9001:2000 - The Quality Management Process (English) EFQM
The EFQM excellence model for Assessing Organizational Performance – A Management Guide (English)
Project/Programme/Risk Management
ICB
NCB – Nederlandse Competence Baseline (Dutch on behalf of IPMA-NL)
Handboek Projectmanagement voor IPMA-C en IPMA-D (Dutch, early 2008)
PRINCE2™
Project Management based on PRINCE2™- Edition 2005 (English, Dutch, German)
PRINCE2™ - A No Nonsense Management Guide (English) PRINCE2™ voor opdrachtgevers – Management Guide (Dutch) MINCE®
MINCE® – A Framework for Organizational Maturity (English)
MSP
Programme Management based on MSP (English, Dutch) Programme Management based on MSP - A Management Guide
(English) M_o_R
Risk Management based on M_o_R - A Management Guide (English)
For the latest information on VHP publications, visit our website: www.vanharen.net
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Project Management
Based on PRINCE2
P R I N C E 2 E D I T I O N 2 0 0 5 TM
Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
Colophon
Title: Project Management Based on PRINCE2TM- PRINCE2 Edition 2005
Authors: Bert Hedeman (Insights International b.v.)
Gabor Vis van Heemst (Getronics PinkRoccade b.v.) Hans Fredriksz (ISES International b.v.)
Editors: Jan van Bon (Inform-IT), chief editor
Mike Pieper (Inform-IT), editor & final editor
Publisher: Van Haren Publishing ([email protected])
ISBN: 978 90 77212 83 7
Edition: First edition, November 2004
Second edition, September 2005
Third edition, first impression, June 2006
Third edition, second impression, November 2007
Design & layout: CO2 Premedia, Amersfoort – NL
© Crown copyright material taken from the Office of Government Commerce publication, Managing Successful Projects with PRINCE2, is reproduced with the permission of the Controller of HMSO and Queen’s Printer for Scotland.
© All rights reserved. No part of this publication may be reproduced in any form by print, photo print, microfilm or any other resources without written permission of the publisher.
Acknowledgements
We would like to thank the authors Bert Hedeman, Gabor Vis van Heemst and Hans Fredriksz for their enthusiasm and persistence, and their willingness to listen to the reviewers and seriously consider their issues.
A special thanks goes to our reviewers who have contributed their collective experience and knowledge to this book. Their encouragement, criticism and useful ideas were invaluable. Review team for the first and second edition:
David Atkinson
Colin Bentley (Hampshire Training Consultants) Review team for the third edition:
Colin Bentley (Hampshire Training Consultants) Emma Jones (Interactive Methodologies) Elaine Sharkey
Andy Taylor (Aquila Business Services Ltd) Review team Dutch editions:
Ad van den Akker (Lagant Management Consultants) Rolf Akker (AtosOrigin)
Peter van Gijn (LogicaCMG)
Brigit Hendriks-van Winden (Ministerie van Verkeer en Waterstaat)
Gerrit Koch (PMI-NL)
Martin Liefting (ING OPS&IT) Tanja Muis (Odysseus)
Mart van der Niet (NIMO)
Arie den Ouden (Ambidexter Management)
John Roos - PRINCE2 Practitioner IPMA Award Assessor (AtosOrigin ECM)
Guido Schouten (Good Sense)
Ron Seegers (Getronics PinkRoccade Educational Services) Cleo van der Stap (Markov Solutions)
Fred Vermeulen (Getronics PinkRoccade)
Jan van Bon, Mike Pieper,
Colophon . . . .4
Acknowledgements . . . .5
Foreword . . . .8
Preface . . . .9
1 Introduction to project management . . . .11
1.1 Why project management? . . . .11
1.2 What is a project? . . . .12
1.3 What is a successful project? . . . .15
1.4 Why do projects fail? . . . .17
1.5 Why PRINCE2? . . . .18 2 Introduction to PRINCE2 . . . .19
2.1 What is PRINCE2? . . . .19
2.2 Scope of PRINCE2 . . . .19
2.3 Basic points of PRINCE2 . . . .20
2.4 PRINCE2characteristics . . . .21
2.5 PRINCE2advantages . . . .23
2.6 PRINCE2overview . . . .24
2.7 Changes to PRINCE2- edition 2005 . . . .27
2.8 PRINCE2terminology . . . .28 3 Processes . . . .31 3.1 Introduction to processes . . . .31
3.2 Starting Up a Project (SU) . . . .34
3.3 Initiating a Project (IP) . . . .40
3.4 Directing a Project (DP) . . . .47
3.5 Controlling a Stage (CS) . . . .54
3.6 Managing Product Delivery (MP) . . . .65
3.7 Managing Stage Boundaries (SB) . . . .69
3.8 Closing a Project (CP) . . . .76 3.9 Planning (PL) . . . .82 3.10 Small projects . . . .91 4 Components . . . .95 4.1 Business Case . . . .96 4.2 Organisation . . . .100 4.3 Plans . . . .107 4.4 Controls . . . .111
4.5 Risk management . . . .122
4.6 Quality . . . .129
4.7 Configuration management . . . .134
4.8 Change control . . . .137
Contents
5 Techniques . . . .139
5.1 Introduction . . . .139
5.2 Product-based planning . . . .139
5.3 Technique for planning activities and resources . . . .147
5.4 Change control technique . . . .153
5.5 Quality review technique . . . .156
6 Project environment . . . .163 6.1 Various terms . . . .163
6.2 Programme management . . . .165
6.3 Projects in programmes . . . .167
6.4 Managing change . . . .168 6.5 Different project types . . . .170
7 Appendices . . . .175
7.1 Glossary of terms . . . .175
7.2 Management products . . . .183 7.3 Preparation for the PRINCE2Foundation exam . . . .221
7.4 Health check . . . .221
7.5 Example of a Project Brief . . . .225
7.6 Lessons learned . . . .226
7.7 Management file structure . . . .228 8 Further Information . . . .231 8.1 Recommended PRINCE2literature . . . .231
8.2 References . . . .232
8.3 Contact addresses . . . .233
Foreword
“Project Management Based on PRINCE2TM- PRINCE2 Edition 2005” is an easy to read book that helps those who are seeking to further understand PRINCE2TM. The authors have laid out in plain terms the principles of PRINCE2TMand have provided some useful examples to help
bring the theory alive. The book will be useful for those who are new to PRINCE2TMand want to understand more about managing projects using PRINCE2TM as well as an additional reference tool in the PMO’s library. It will especially help those experienced project staff who are new to PRINCE2TMand want to understand how their existing experiences map into it. Managing Successful Projects with PRINCE2TMis a set of guiding principles. Used correctly, it adds value to you and your organisation. Used poorly, it may result in the organisation adopting bureaucratic and unworkable processes. Many individuals and organisations fall into the trap of thinking that to use PRINCE2TMyou have to “pass an exam” and “fill in forms”. As this book demonstrates, PRINCE2TMis quite logical and shows why it is often referred to as “structured common sense” and the biggest surprise of all - there are no forms or templates within the method. These are often created by the organisation to obtain consistency of brand or when the first person who has been trained comes back from the course with the examples used to teach. The product outlines in PRINCE2TMand this book are for guidance only - the most effective use of PRINCE2TMis when you create your own product descriptions that describe how you will use the method.
The authors Bert Hedeman, Hans Fredriksz and Gabor Vis van Heemst first wrote this book for the Dutch market place and I am pleased it has been translated into English. PRINCE2TMis a truly global method and it is important that the market place shares best practice thinking
around the world. Eddie Borup
Director Best Practice User Group PRINCE2TMRegistered Consultant
Preface
The book “Project Management Based on PRINCE2 -PRINCE2 Edition 2005” is a practical
book for the user working on projects on a daily basis. In this book, the process-based approach to project management is described and the components and techniques necessary for this are dealt with.
The description of the processes, components and techniques is based on the PRINCE2
methodology. The same process sequence has been maintained and the same components and techniques are described. The PRINCE2terminology has also been retained. This book deals not only with the PRINCE2methodology, but also with activities and planning resources and the project environment. This complements the PRINCE2methodology. In the appendices you will find an example of a Project Brief and a paragraph on how to deal with lessons learned in a project.
The contents of this book largely meet the theoretical requirements set for successfully passing
the PRINCE2 Foundation exam. For the PRINCE2 Practitioner exams, however, practical
experience is also necessary. Unfortunately, a book can never deliver practical experience. This book does not presume to deal with all the competency areas of project management. For many other competency areas there are numerous books available. It is the area of process-based project management in particular, where there is a lack of a good book for the user.
This book is written for Project Managers, Project Leaders and Team Managers and all other people who privately or in work are involved with the starting up and management of projects. We trust that this book meets their need for a useful book in the area of process-based project management.
Finally, we would like to point out that where reference is made in this book to “he” or “his” (in reference to persons), “she” or “her” can, of course, be understood.
We would also like to thank all reviewers who have contributed with their comments to the quality of this book.
1 Introduction to project management
1.1 Why
project
management?
Managing projects is as old as the hills. There are stories datingback to ancient times about activities we would now call projects. Just think of the mammoth task of the pyramid builders
in Egypt and South America. Even the way our forefathers moved encampments from one
huntingground to another can be seen as a project.
The concept of a “project”, however, originated in the 1960s and was mainly applied to major infrastructures. At that time, project management involved little more than planning the work. In the 1970s, attention began being paid to managing the work and after that the personal skills of the project manager came under scrutiny. In the 1990s, attention shifted towards a
process-based approach to project management.
Project management is increasingly becoming a profession. Where in the past project
management was a task you took on in addition to your own work, nowadays project
management is a separate profession by which many people earn a living. However, despite the increased professionalism, projects still often fail. Some failed projects hit the headlines, but most are never heard of again. There is no simple reason why projects fail; however, an effective method for managing projects is of vital importance in order to succeed.
Without a project management method, the Executives of a project may have different ideas about organising and completing a project from those who are managing the project and working on it. The people involved do not, for instance, know how much responsibility and
authority they have, and thus the project is shrouded in obscurity. Without a project
management method, projects are only seldom delivered to the satisfaction of those involved. This mainly applies to projects with a long duration time.
A good project management method must not be static. The environment alters, the market changes, Executives and users take up new positions. In other words, projects have to be managed in a changing environment. Too often it is assumed that a project can be managed in a “frozen” environment. That makes things easy, but quickly outdated.
An effective project management method helps the Project Manager to organise and manage a project in a continually changing environment, while still involving all the stakeholders.
PRINCE2 is such a method and uses the principles of good project management. These
principles are:
• A project is a process with a clear beginning and end. • Projects always have to be managed to be successful.
• To involve stakeholders in the best possible way, they have to know: - why the project is needed
- what the aim of the project is - how the result will be achieved - what their responsibilities are
1.2 What is a project?
It is vitally important to identify the difference between a project and the normal activities that take place within an organisation. Vagueness about what a project actually is can lead to a lot of friction and frustration.
1.2.1 Definitions of a project
A frequently used definition of a project is: “a project is a unique assignment, limited in time and resources, which ends with a project outcome”. Although this definition gives specific characteristics of a project, this definition makes no distinction between project activities and the normal activities in an organisation. Many activities in an organisation have a clear
beginning and end, also make use of a limited quantity of resources and people and also produce an agreed result, but they are still not projects.
PRINCE2 describes a project as “A temporary management environment created for the
purpose of delivering one or more business products according to a specified Business Case”. A Business Case is the practical rationale for the development of a product.
A project is a temporary management environment created for the purpose of delivering one or more business products according to a specified Business Case.
This definition adds a new element: working in a temporary management environment or a temporary organisation. And that is exactly what distinguishes a project from the normal activities within an organisation. This is also the reason why working with and in projects is so complicated. A temporary organisation implies that employees are temporarily given a different set of responsibilities and powers. Line management has to delegate certain responsibilities and powers to the project organisation, otherwise a project organisation cannot function properly. This is, however, a threat to many line managers. The more experience people gain of working
in projects, the less significant this threat will become.
1.2.2 Reasons for working in projects
A good and often the best reason for carrying out work in the form of a project is that the work can be carried out more efficiently: the necessary staff and resources can be made available;
various disciplines from different departments and businesses can work directly with one another; the burden on lines of communication can, within the corporate organisation, be relieved of having to be intensively tuned into one another as is otherwise necessary for developing the project result.
A second reason for carrying out work in the form of a project is creating support. Several parties are involved in the end result of the project. This always means a change in the status quo for these parties, which will nearly always leads to resistance. A temporary project organisation is a
good way of guaranteeing support and involvement for the use of the end result as early as the development stage by involving stakeholders in the starting up and carrying out of the project. This will guarantee a wide grounding in the respective line organisations at an early stage. The project organisation is, however, temporary. In other words, the project organisation is created for the duration of the project and differs from line management, which is permanent
in nature and responsible for the basic activities of the organisation. The style and nature of project management, too, differs from that of line management. Line management is aimed more at continuity. Project management is aimed more at the onetime development of a certain result. These differences can result in friction and frustration.
Corporate management must be aware of the advantages and disadvantages of working in projects. Corporate management must regulate the links between projects and the permanent organisation so that minimum friction occurs between both worlds and the project result can be developed as effectively as possible.
1.2.3 Essence of a project
The essence of a project is: • a temporary organisation • an outcome defined in advance
• a pre-defined approach as to how the project result must be achieve • a specified Business Case
The Executive, the Project Manager and basically the rest of the project organisation must be appointed before the project can commence. Also at least the outlines of the project outcome must be defined and the scope and the approach as to how the project outcome is to be developed must be agreed, and it must be clear why the project must be carried out.
These aspects can be worked out further during the planning stage of the project before the project is started. These basic agreements are, however, necessary for defining the project - for authorizing the start of the project and in order to commence the planning stage.
1.2.4 Relationship between the corporate or programme organisation and projects
Corporate aims form the basis for the need for a change in the organisation. However, this often requires new products and/or services. Projects can be initiated to develop these. A programme is sometimes set up to develop one or more corporate aims (see chapter 6). The programme then initiates the various projects.
The products or services defined are developed in the projects. The project delivers the project
outcome to the relevant corporate or programme management. Corporate or programme
management is then responsible for ensuring that the aims management had in mind for the
outcome are actually achieved through the project outcome. Corporate or programme
management therefore, not the project management, is responsible for achieving the corporate aims. The project management is solely responsible for delivering the project outcome with which corporate or programme management can achieve its aims (see figure 1.1).
Figure 1.1 Project environment
1.2.5 Aims of a project
The aim of a project is that which corporate or programme management wants to achieve with the outcome the project delivers. This aim is the main element as to why the project outcome must be developed and is also important in starting up and managing the project. This aim must therefore also be known before the order is given to start a project (see figure 1.2).
Figure 1.2 Project summary
1.2.6 The difference between a product lifecycle and a project lifecycle
To be able to define responsibilities, it is important to understand the difference between the lifecycle of a product and that of a project.
The lifecycle of a product begins with the idea for the product and continues on through its development and use until the product is replaced or discontinued. The lifecycle of a project is however more limited. The lifecycle of a project begins with the approval of the project assignment and continues on through specification, development, testing and implementation up until delivery of the project outcome.
Business planning
Feasibility studies, Business Cases Corporate or programme management
Projects Vision, strategy, objectives Stakeholders/ environmental factors
Project Approach
Project Approach
Problem or chance Result ObjectiveThe first phases, those of forming ideas and carrying out a feasibility study, and the final phases of use up until ultimate discontinuation are not part of the lifecycle of a project. The project organisation cannot take any responsibility for these phases, as they are in the hands of the corporate or programme management.
Implementation of the project outcome in the corporate organisation may or may not be part of the project, depending on the scope of the project.
Figure 1.3 Product lifecycle and project lifecycle (Source: OGC)
If a study is first required to examine what needs to happen, the best approach is to treat this study as a separate project and then to set up a new project to develop the results of the study. Several projects can be carried out during the lifecycle of a product. In addition to the feasibility study and the development project, there are often interim revisions and “upgrades” and, in the same way, both the discontinuation and the replacement of the product are carried out in the form of a project.
1.3 What is a successful project?
In the last few years there have been regular discussions about the results recorded with the use of projects. Not so long ago, enormous investments were made in IT projects that promised “the earth”. Many of these projects were unable to fulfil their promise and there were increasingly strident calls for a critical look to be taken at the results actually achieved.
But this is also the case in other sectors. Research results are regularly published showing that many projects are completed too late and/or are too expensive. There have also been situations in which a project is concluded prematurely without producing any result, or projects whose outcome is never used in practice. How does this happen? So much experience has been gathered about carrying out projects. Where do projects go wrong? And furthermore, what are the factors that ought to be taken into account to complete a project successfully?
Idea Study Assignment Project Lifecycle Product Lifecycle Use Realise the ‘benefits‘ Replacement/disposal Specify Design Develop Test Implement
In the first place, it is important to have a common definition of the success of a project. The IPMA Competence Baseline (ICB) states that the success criteria should be defined for each project distinctly. The ICB identifies three basic sets of criteria for the success of a project: those of the sponsoring organisation, the traditional or classic project management one of “on time, in budget to specifications”, and the project participants profitability. Within the sponsoring
organisation the ICB distinguish users and owners.
If the users are dissatisfied with the results of the project, they will not be inclined to get the
maximum return from the product (or service) that has been delivered. Eventually,
dissatisfaction of the users can even lead to the project result no longer being used at all and relations between parties in the corporate organisation being disrupted in the long-term. Another definition of a successful project is: “if all the parties involved are satisfied with the outcome”.
A project is successful if all the parties involved are satisfied with the result achieved.
This definition clearly goes further than that of the ICB and involves the project staff and all other parties who will be affected by the outcome too. How can you speak of a successful project if the other parties involved are not at least satisfied to a certain level with the result achieved? This is also why, in the context of this book, we use this definition of success as a necessary extension of the ICB definition.
The term “all parties” in the definition above covers: • the Executive
• the users • the suppliers • the project staff
The Executive represents the sponsors. He wants to get certain benefits from the project outcome and is the one who pays for it. The users are those who will have to work with the outcome. These may be end users, but could also be the people who are responsible for management and support of the end product. The suppliers supply the staff and resources needed to produce the outcome. The project staff includes those who achieve the result. In practice, the users are the most important factor when it comes to determining the extent to which a project has been successful as they have the most influence on the satisfaction of the other parties, followed by the Executive and subsequently the suppliers and the staff.
So we see that there are several parties that determine the success of a project. It is therefore essential throughout the entire project to look at the stakeholders and the criteria for success that they employ. These may be different for each one of them and can differ from project to project. The absence of the criteria that one of the stakeholders considers to be important can be a reason for loss of motivation and can be a reason for halting the project.
Possible success factors for the various stakeholders are:
• The benefits of the project outcome exceed the cost of the project and are in line with expectations - of importance to the Executive.
• The outcome meets the criteria laid down in advance and is “fit for purpose” - of importance to users.
• A positive return on spending - of importance to the supplier.
• The work is enjoyable and contributes to personal development - of importance to project staff.
1.4 Why do projects fail?
Some of the reasons given for the failure of projects are: • the lack of a clear Business Case;
• a lack of support for the project on the part of the Executive and management of the corporate organisation;
• not having a clear outcome or an outcome that has been defined in insufficient detail;
• the lack of quality criteria and quality control and the lack of easily measurable acceptance criteria;
• change of scope and lack of efficient change control;
• lack of involvement on the part of the user from the start of the project.
A clear Business Case forms the basis for a project. After all, this is where the Executive gives his reasons for wanting to have the project carried out and what the benefits of the project’s result are for the organisation in relation to the costs and efforts of realising the outcome. If it is not clear what the contribution of the project is for the corporate organisation, it may be that the Executive and management of the corporate organisation will reduce their support during the course of the project. Important decisions will be delayed or not taken at all. There will be problems financing the project. Other projects and initiatives will suddenly seem more important. Without a good Business Case and without management support, there will certainly
be resistance from the users as soon as they become aware of exactly what the project is going to mean to them. And with less involvement by the Executive and management and the increase in resistance by users, project staff will get the feeling their work is not important and unwanted - they will seek other work or, worse still, lose motivation, which is a dramatic chain reaction. Another issue is that of a poorly defined outcome. How can you make something satisfactorily for someone else if you do not know what that other person wants? It is important here too that not only quality criteria are drawn up for the deliverables and that the necessary quality controls are carried out, but that the Acceptance Criteria are described. The better all this is described, the more realistically the costs can be estimated for work that has to be carried out, the easier it will be to aim towards the desired result and the more efficiently users’ expectations of the end result can be managed.
Failing to effectively manage the scope or the changes can also play an important role in the failure of projects. Any change for the benefit of one will have consequences for another. Poorly managed changes are, therefore, often the cause of frustration for other parties concerned and often also have serious unforeseen consequences for the project. Managing the scope and the changes is therefore a must.
Finally, it sometimes seems like an attractive option not to involve the users in the project: no nagging, the ability to make progress and fast decisions are positive prospects. However, not involving users from the start of a project often also means insufficient specifications, no intermediate checks as to whether you are on the right track, no interim indications that the project result to be delivered must be adjusted and major resistance as soon as the users realise exactly what the project is going to mean for them the latter according to the motto “What others do cannot be good”. Results with which you yourself are involved are always better even if the result is less “objective”. This can lead to the result not being accepted, or being accepted
but then not being used or in the worst case, the project being prematurely stopped after a great deal of frustration and cost for all concerned and the “culprits” being stigmatised.
It is therefore better to have prior insight into the Business Case, efficiently define the result, manage the process, manage changes and involve the users, even if by doing these things it
becomes clear that the project is no longer viable. The project can then be adjusted or prematurely stopped in a professional manner without unnecessary capital loss and unnecessary damage to those concerned.
1.5 Why
PRINCE
2
?
The reasons mentioned in paragraph 1.4 for the failure of projects led to the development of the PRINCE2project management method. This method aims to manage projects in a changing
environment with the Business Case as a leading element, envisaging the involvement of all concerned and managing the process. PRINCE2places more emphasis on managing the process than holding on to original starting points.
Here, project organisation and risk management are important areas of consideration. In the
project organisation, the connection and the interaction between the project and the
environment are established. Risk management deals with the control of uncertainties and in and around the project. In the PRINCE2method, risk management is therefore an integral part of all processes to be carried out.
2 Introduction to PRINCE
2
2.1 What is PRINCE
2
?
PRINCE is a project management methodology and stands for “Projects in Controlled
Environments”. Prince was designed in 1989 by the former British Government agency CCTA, Central Computer and Telecommunication Agency, and is based on PROMPT II. PRINCE was at that time based on IT projects and was not suitable for other sectors.
PRINCE2 was introduced in 1996 as a generic standard for all types of project in all
environments and for all sizes. PRINCE2 is based on a process-type approach to project management and also the years of practical experience from many projects, Project Managers and project teams.
The Office of Government Commerce (OGC) currently holds the copyright to the trademark
and the PRINCE2method. The PRINCE2method is freely in use as a method of managing
projects. A licence is required for providing publications and training. OGC has transferred the management of licences and the taking of examinations to the APM Group Ltd.
Over the years, PRINCE2has developed into the de facto standard for project management for
both the public and the private sector in England and several other countries.
2.2 Scope of PRINCE
2
PRINCE2is aimed at managing a project, the deployment of staff and resources in a project and the connection and interaction between the project and its environment. PRINCE2is, however, not meant to cover all aspects of project management. Social and communicative skills, techniques such as network planning and Gantt charting and supporting software packages are not part of the method, which is also to the method’s advantage. PRINCE2is not bound by a specific interpretation of these aspects, allowing the methodology to be used for all types of projects, for all types of organisations and in combination with all types of techniques and supporting software packages.
Project management is about people. PRINCE2cannot be used as recipe book; it must be used in combination with common sense and the correct technical and social skills. Although PRINCE2does not involve social skills, it does support the desired social behaviour needed to effectively manage projects: a good structure supports the desired behaviour.
Interaction is an important aspect of PRINCE2and is secured in the tasks, responsibilities and authorities stated in the project roles. These can be controlled more efficiently and colleagues can understand and relate to each other’s responsibilities as these roles have been explicitly established.
Figure 2.1 PRINCE2scope (Source: OGC)
PRINCE2 distinguishes eight processes and eight components (areas of knowledge) but only three techniques, i.e., product-based planning, the change control technique and the quality review. If an organisation already has an effective change control technique and/or a good technique for checking the quality of project documents, then these can be used in place of the relevant PRINCE2 techniques. However, use of the product-based planning technique is strongly recommended, as this supports so many good project features. Other procedures and techniques are, however, kept outside the method.
A fourth technique has however been added in this book, i.e., a technique for planning activities and capacity. Experience shows that the planning of activities and capacity is essential for many projects and that a good technique for this is often lacking.
PRINCE2 deals with managing the project and does not insist on any specific technical
approach, which can vary from project to project. The PRINCE2 method can be used in
combination with any other design and/or development technology even if the association of the management method to the technology has to take a different form of design technology. Purchasing and outsourcing are other aspects not covered by PRINCE2. The method assumes the project will proceed within the limits of a contract. This contracting process is not part of PRINCE2 but is part of the technical activities that can be managed using the method. The
information established in various management documents within PRINCE2 provide an
excellent, intrinsic basis for the preparation and monitoring of contracts.
2.3 Basic points of PRINCE
2
There are four assumptions in PRINCE2that form the basis of the complete method. • Projects are carried out in a changing environment- the market changes, the internal
organisations changes, users’ insight increases, etc. Projects initiate changes and these changes again affect the project. Projects must be set up so that they can anticipate change in a controlled manner.
• A project is only successful if all stakeholder parties are satisfied with the project outcome- stakeholder parties are the users, the Executive, the suppliers and the project staff.
PROJECT BUSINESS Tools Techniques Staff Mission Programmes Expectations Operations Strategy Maintenance Output PRINCE
2
It is often not sufficient to supply that which was originally agreed on time and within budget. It is not only the opinion of the Executive that plays a role, but the experience of all stakeholder parties. Managing the expectations of the stakeholder parties is therefore also an extremely important part of project management.
• Successful projects are business driven - there must be a basic business requirement for carrying out a project. This basic business requirement (Business Case) must be set at the start of the project. Regular checking of the basic business requirement must take place as the project progresses. If there is not a clear basic business requirement, this will almost certainly form an obstacle for maintaining the involvement of management, generating the necessary
funds and “promoting” the project in the environment. The Business Case gives the
framework within which users specify their wishes and requirements with regard to the use and support of the result to be delivered.
• Cooperation of all stakeholder parties in the project leads to more successful projects -projects are set up in order to implement change. Cooperation is an essential factor in this. If all parties are involved in the setup and management of the project, the acceptance of the outcome will almost always be higher than when this is not the case.
These four assumptions affect the setup and management of projects and are translated into the organisation of a project, the project processes to be carried out and the components and techniques to be applied.
2.4 PRINCE
2
characteristics
PRINCE2distinguishes itself in a number of ways from other project management methods: • The creation of stakeholder involvement at project management level - besides the
involvement of users and suppliers in the implementation of a project, it is important that the
users and the supplier(s) are also represented at project management level. Good
communication between all stakeholder parties is essential for the “commitment” between these parties. PRINCE2interprets this by including the users and suppliers as representatives on the Project Board in the role of Senior User and Senior Supplier.
• Focus on justification (Business Case) - the Business Case forms the justification for undertaking the project. The Business Case forms the basis for starting and carrying out a project. The Business Case is also updated for every go/no go decision of the Project Board. After the project outcome has been delivered and put into service, an evaluation takes place to determine whether the project outcome has actually delivered the benefits the Customer had in mind.
• Management of risk completely integrated into the life cycle of the project- management of risk within PRINCE2is not in itself an independent approach but is an integral part of the PRINCE2management process. It indicates precisely how risks must be managed during the entire project process and who is responsible for what.
• A defined organisation structure- characteristic of a project is that it consists of a temporary organisational form. The project is set up to bring about change. It is not simply the intention to perform tasks as effectively and efficiently as possible, but also, during the project, to create a basis for the outcome and for the change that must be carried out. In order to achieve this, a broad grounding of the project is necessary within the line organisations involved, and clear, unequivocal agreements are necessary about who does what and who is responsible.
PRINCE2 provides a defined organisational structure in order to determine an individual project’s organisation.
• Division between technique and management- PRINCE2 divides tasks, responsibilities and authority within the various roles of a project organisation, a division between technique and management. The Project Manager is responsible for the daily management of the project within the framework provided by the Project Board, and is therefore responsible for the process rather than the content. The various Team Managers are responsible for putting into practice the products agreed with the Project Manager, including their agreed content, specifications, time and budget.
• A controlled start, middle and end - projects are often started too quickly. During the project people focus too much on what they have to do, but not on working according to the agreement. The termination of a project and the hand-over of the outcome to the line organisation are often unclear. These important reasons are why projects fail. PRINCE2
assumes a controlled start, whereby the project, the project organisation and the first tasks to
be carried out are clearly and well defined, before starting with the project itself. During the project the Project Manager has the daily management of the project within the framework provided by the Project Board. With the closure of the project the Project Manager must not only ensure that the outcome is delivered, but that the projection organisation is also decommissioned, that the project is properly evaluated and closed by the Project Board, that the outstanding actions are delivered to the line organisations involved and that a date and plan is set for a post-project review.
• Management by exception by the Project Board- PRINCE2employs this principle. The Project Board do not need to meet to receive updates on progress, rather they receive regular Highlight Reports at a frequency on which they decide. This characterises the “best practice” character of PRINCE2. If an “exception” situation arises then the Project Board will be informed via an Exception Report. At the end of a stage the Project Board receive an End Stage Report. This does not mean, however, that regularly planned meetings may not take place.
• Management stages - PRINCE2 distinguishes between management stages and technical stages. Management stages are divisions in time coupled with an explicit go/no go decision about the progress of the project. The setup of management stages is an important part of putting “management by exception” into practice.
• Instruments for managing the commitment of staff and resources - often a budget is available for a project but the project cannot start or go any further because the necessary staff and resources are not made available or because staff and resources are taken off the project. PRINCE2links the authorisation to carry out work in the next stage to the actual availability of the required staff and resources. Management stages ensure that the Project Board commit the necessary staff and resources required for the next stage.
• Contracting out based on Work Packages- the direction of the work that must be carried out by Team Managers is based on Work Packages. This applies both to the activities carried out by internal staff and to the activities that must be carried out by third parties. Work Packages give a defined description of the products to be supplied and the necessary information important for the development of these products, the assessments to be carried out, the interim reports, process management and the manner in which the products realised must finally be delivered.
working in projects. As a basis for the various plans this PRINCE2technique forces all those involved to base their thinking on the deliverables: what is to be delivered (possibly early) and what requirements must it meet? From this the necessary activities are planned for developing
the products.
• Quality reviews- if the products to be developed are only tested at the point of delivery, it is too late to make adjustments to the quality of the product. The most important decisions for determining the end quality of the product are taken at the start of the project. The documents required for these decisions must therefore be critically checked with the question: to what extent does what is laid down in these documents actually lead to that which must be achieved? The quality review is a technique for the controlled evaluation of documents and other products.
• Controlling change is managed in the PRINCE2 method - PRINCE2 assumes that projects do not stand in isolation, but must be managed in a changing environment. It is therefore logical that change control is essential and completely embedded in the methodology.
2.5 PRINCE
2
advantages
PRINCE2 is a methodology that gives directors and managers of projects the advantage through
better control of the commitment of staff and resources. They are continually kept up-to-date on the progress and can limit themselves to managing exceptions. PRINCE2stimulates active involvement of the user and the stakeholders throughout the complete project with an integrated and structured approach to problem definition, changes and risks. PRINCE2 has a project organisation in which roles are defined with clear agreements for tasks, authority and responsibilities.
For the company management and the project Executives the focus is on the added value for the organisation, management of company risks and the hold on current projects, which is valuable, both at the start of a project and during its execution.
The combination of a thorough theoretical basis with “best practices”, a process-based approach and intensive participation of users, appeals to project management.The Project Manager is able to employ a set structure for delegation, authorisation and communication based on PRINCE2. PRINCE2provides a clear structure divided into manageable stages, coupled with the allocation of the staff and resources to execute the work. Furthermore, PRINCE2provides a transparent reporting structure, so that management and stakeholder meetings can be limited to a minimum.
For the supplierit is important that PRINCE2is a standard project management methodology with uniform terminology, structure and “templates”. This increases the quality of the service and eases the possible exchange of Project Managers or employees due to sickness or absence. PRINCE2forms a good base for ensuring the quality of the project management process and for professional project management in the organisation. The method is free for individual use. The international PRINCE2training and certification is also considered as important. The usersare involved from the start with the decision-making in the project. The users are
responsible for the quality requirements within the framework of the Business Case and take part in quality reviews throughout the project.
For those executing the work/Team Managers in the project the method gives a clear description of the Work Package to be carried out and all the relevant information and agreements. This gives a clear division of tasks, responsibilities and the authority of the Project Manager and the Team Manager and the work area of the Team Manager is defined.
PRINCE2can be used for all projects. The method can be scaled and adjusted to every specific circumstance within which a project must be carried out. This does not mean that parts of the method are missed, but that various parts can be combined or done informally and that various parts of the ‘documentation’ may be achieved by word of mouth.
2.6 PRINCE
2
overview
PRINCE2is a structured project management method based on best practice. PRINCE2has a process-based setup, which means that the method assumes that a project is carried out as a process rather than in a linear form. Some processes are in principle only gone through once in a project, other processes may be gone through more times. This depends upon the size, complexity and setup of the project.
In addition, PRINCE2has eight components and three techniques. This book contains a fourth technique: the Planning of Activities and Resources is added to the three PRINCE2techniques. Figure 2.2 gives an overview of the processes and components.
Figure 2.2 Processes and components (Source: OGC)
Organisation Plans Quality Controls Risk management Business Case Change control Configuration management Directing a Project Starting Up a Project Initiating
a Project Controllinga Stage
Managing Product Delivery Managing Stage Boundaries Closing a Project Planning
2.6.1 Processes
The PRINCE2 processes cover the complete route from the start up of a project through controlling and managing progress, to the conclusion of the project. In chapter 3 of this book the processes are expanded and explained in detail.
• Starting Up a Project (SU)- this is the first PRINCE2process. It has the objective of creating
all the conditions for starting a project. During this process the Project Brief, provisional project organisation, Project Approach, Risk Log and a Plan for the Initiation Stage are produced.
• Directinga Project (DP)- this process runs throughout the duration of the project - from project preparation to delivery and Closing a Project. Directing a Project describes the processes used by the Project Board. The process focuses on maximising the chance of a successful project and delivers what the customer and the user expect. Important decisions for the project are also taken in this process.
• Initiatinga Project (IP)- this process is the most important process in the initiation stage and indicates how the Project Initiation Document (PID) is worked out in detail and set up, so that the Project Board can decide whether to implement the project. The PID also gives the
basis for executing the project and provides the foundation for controlling the project progress. The IP process is the first formal process once the project has been started and begins after the Project Board has approved the execution of the initiation stage.
• Controlling a Stage (CS) - this process describes the daily management by the Project Manager during a stage. This process begins when the staff and resources are made available for the stage and the Stage Plan has been approved by the Project Board. This process is aimed at the delivery of the agreed products within tolerances agreed between Project Manager and Project Board. This process is essential for the project’s success.
• Managing Product Delivery (MP)- this process makes it possible for the Team Managers to reach an agreement with the Project Manager about the work to be carried out, in order to plan and execute the work as well as supplying the completed Work Package to the Project Manager. This process must be approached carefully in order to avoid bureaucracy.
• Managing Stage Boundaries (SB)- the aim of this process is to review the previous stage and plan the next to enable the Project Board to take a go/no go decision about the progress of the project. This process gives the Project Board the security that the products in the current stage have been delivered according to plan, gives the Stage Plan for the next stage and indicates the consequences for the Project Plan and the Business Case.
• Closing a Project (CP)- if all project objectives have been met or if the Project Board has decided to prematurely end a project, this process will be used to close the project and archive the documentation. Recommendations will also be prepared for follow-on actions and the End Project Report and the Lessons Learned Report will be prepared. The Post-Project Review Plan will also be prepared in this process so that after a period of use of the final product it can be ascertained whether the project result has also actually delivered the benefits envisaged (post-project review).
• Planning (PL) - the Planning process supports many other processes. A plan is not only a time schedule, but a document that describes how, when and by whom a specific objective or result must be reached and the consequences for time, money and quality.
2.6.2 Components
The components are the ingredients of the project that the Project Manager needs to manage with the processes. Chapter 4 describes and explains the components in detail.
• Business Case- the Business Case gives an indication of what the expected benefits of the use of the project result are for the organisation in relation to the expected costs and efforts in realising the project. PRINCE2 calls this the added value of a project or the driving force
behind the project.
• Organisation- PRINCE2provides an organisational structure for the project management team with the job descriptions, tasks, authority, and responsibilities as well as their interrelationships. The roles can be combined or divided depending upon the size of the project.
• Plans- PRINCE2involves a number of levels defined for planning that, depending upon the size and complexity and can be adapted to the project’s requirements. PRINCE2assumes a plan is based on the deliverables.
• Controls- using a number of controls, each level can be measured against how the project is progressing. Progress is compared with the plans made and provides an input for decision-making. Controls are applied throughout the project to ensure that the project is carried out in a controlled manner from the start to the delivery of required products.
• Management of Risk- PRINCE2defines a risk as “uncertainty about the future”. Risks must
be identified and evaluated. Effective measures must be taken in order to avoid or reduce risks. Risks must be managed throughout the project. PRINCE2defines a number of key moments when risk analysis should be carried out and provides indications for risk analysis and controlling risks.
• Quality control - quality plays an important part in a PRINCE2 project and is a fully integrated part of the method. Quality is assessed for both the processes and the products. The
basis for quality control is set at the start of the project by the Customer’s Quality Expectations and Acceptance Criteria by the representative of the user organisation.
• Configuration management- all products that are produced must be managed throughout the duration of the project. Configuration management enables the Project Manager to check the status, content and location of products at any time and to check who has access to these products.
• Change control - changes in the size of the project or in the product specifications can considerably affect a project (in costs and time). It is important to implement structured changes and to know the consequences for the whole project and the Business Case.
2.6.3 Techniques
PRINCE2describes the techniques Product-Based Planning, the change control technique and quality review. This book, in addition to discussing these three techniques, also includes a technique for planning of activities and resources. The authors of this book view this as an important aid when going through the planning process. In chapter 5, the techniques are elaborated upon and explained in detail.
• Product-based planning - PRINCE2 provides for a product-based approach to planning,
before a start is made on planning activities. The product-based planning technique involves: preparing a Product Description of the end result, producing a Product Breakdown Structure, writing Product Descriptions for the individual products and producing a Product Flow Diagram.
• Planning of activities and resources- the Precedence network is a method usually used for planning activities. Planning this network is converted into a Gantt chart, from which finally the staff and resources needed are properly planned.
• Change control technique - the change control technique provides the procedure for managing change. In PRINCE2all potential changes are treated as Project Issues. These may
be raised at any time during the project. PRINCE2makes a distinction between a Request for Change, an Off-Specification, questions and observations.
• Quality review technique- a quality review is a structured procedure for assessing the quality of products, in particular using subjective quality criteria and ensuring that the products meet the expectations of the all interested parties.
2.6.4 Connection between PRINCE2processes, components and techniques
PRINCE2 involves processes, components and techniques. Components and techniques are
used to carry out processes effectively. Each process uses a defined number of components and techniques. Table 2.1 shows this connection between the processes, components and techniques.
Table 2.1 Connection between PRINCE2processes, components and techniques
2.7 Changes to PRINCE
2
- edition 2005
The second edition of this book is entirely based on the latest edition of the PRINCE2Manual (2005 edition).
In the latest edition of the PRINCE2Manual (2005), there are a number of changes compared with the previous version. The aim of the changes is to make the manual more useful and clear. This was achieved by making the text clear in parts, improving the intrinsic consistency between the various parts and including extra explanations on specific aspects. The basics and the main points of the method however remain the same.
There have been a few minor changes to the terminology. More consistent use is made of capital letters, the term “sub-process” has been consistently implemented and some connections have
been changed regarding the process diagrams. The input and output tables have been updated. The list of definitions and the organisation of management products have been extended and
Processes SU IP DP CS MP SB CP PL Components Business Case V V V V V Organisation V V V Planning V V V V Controls V V V V V V Risks V V V V V V Quality V V V V V V Configuration management V V V V V Change control V V V V Techniques Product-based planning V
Planning of activities and resources V Change control technique V V V
parts have been updated and the text in the component organisation has been highlighted. This will further emphasize the dynamics and composition of the Project Board. The product-based planning technique has been extended by a fourth step.
The summary of the management aspects has been extended. The quality path has been adjusted. There are extra explanations on Project Assurance, configuration management and product-based planning. The product breakdown of the product-based planning technique now includes a distinction between product groupings (ideas) and integration products (‘real’ products requiring assembly or testing). The terms “Customer Expectations” and “Product Status Reports” have been added.
For all planning levels - Project, Stage or Team - any potential exceeding of agreed tolerances is escalated to the next level via an Exception Report. Exception Plans may now be prepared at all these levels.
A few changes in the latest edition of the PRINCE2Manual were already provided and included in the first edition of this book. Other changes have been implemented accordingly.
2.8 PRINCE
2
terminology
The following terms are very important for understanding the definitions of the PRINCE2
methodology:
• Business Case - information that justifies the setting up, continuation or termination of the project. The Business Case answers the question: “Why this project should be done?” The Business Case is monitored and updated throughout the project.
• Project Board- the platform that is finally responsible for the project. The Project Board is made up of representatives from the business, the users and the supplier. The Project Board is chaired by the Executive.
• Customer- the person or group, who has commissioned the project, invested in the project and will benefit from the project.
• User- anyone who will be influenced by the outcome. They are the ones who will work with it, receive the product produced, who must reach their objective with the project outcome, be handicapped or helped by the project outcome and who must maintain the project outcome. • Supplier- those who are responsible for providing the staff and resources to the project and
responsible for creating the project outcome.
• Product, end product or outcome- is used for everything that the project must deliver. The project outcome can vary enormously from physical items, such as buildings and machinery, services such as a new support service or sales department to intangible things such as culture change and public perception.
PRINCE2 also involves a number of processes, products and roles described as PRINCE2
Glossary. All PRINCE2words and the project management terms important for understanding
the methodology are explained in appendix 7.1.
A product description for all PRINCE2 products has been included in the organisation of management products in appendix 7.2
2.8.1 Spelling of PRINCE2words
All PRINCE2words begin with a capital letter: • PRINCE2roles such as:
- Senior User
• PRINCE2products such as: - Work Packages
• With compound PRINCE2words in processes and sub-processes all verbs and independent nouns begin with a capital letter such as:
