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) Defining 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) IT Architecture TOGAF, The Open Group Architecture Framework A Management Guide (English) The Open Group Architecture Framework 2007 Edition (English, official publication of TOG) TOGAF Version 8 Enterprise Edition Study Guide (English, official publication of TOG) TOGAF Version 8 Enterprise Edition Pocket Guide (English, official publication of TOG) Quality Management 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
Project Management Based on PRINCE2 P R I N C E 2 E D I T I O N 2 0 0 5 TM
Colophon Title: Project Management Based on PRINCE2 TM - PRINCE2 Edition 2005 Authors: Editors: Publisher: Bert Hedeman (Insights International b.v.) Gabor Vis van Heemst (Getronics PinkRoccade b.v.) Hans Fredriksz (ISES International b.v.) Jan van Bon (Inform-IT), chief editor Mike Pieper (Inform-IT), editor & final editor Van Haren Publishing (info@vanharen.net) 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. 4
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, Chief editor Mike Pieper, Editor 5
Contents 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 PRINCE2 characteristics............................................................................................21 2.5 PRINCE2 advantages.................................................................................................23 2.6 PRINCE2 overview....................................................................................................24 2.7 Changes to PRINCE2 - edition 2005........................................................................27 2.8 PRINCE2 terminology...............................................................................................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 6
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 PRINCE2 Foundation 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 PRINCE2 literature........................................................................231 8.2 References................................................................................................................232 8.3 Contact addresses....................................................................................................233 9 Index.............................................................................................................................235 7
Foreword Project Management Based on PRINCE2 TM - PRINCE2 Edition 2005 is an easy to read book that helps those who are seeking to further understand PRINCE2 TM. The authors have laid out in plain terms the principles of PRINCE2 TM and have provided some useful examples to help bring the theory alive. The book will be useful for those who are new to PRINCE2 TM and want to understand more about managing projects using PRINCE2 TM as well as an additional reference tool in the PMO s library. It will especially help those experienced project staff who are new to PRINCE2 TM and want to understand how their existing experiences map into it. Managing Successful Projects with PRINCE2 TM is 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 PRINCE2 TM you have to pass an exam and fill in forms. As this book demonstrates, PRINCE2 TM is 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 PRINCE2 TM and this book are for guidance only - the most effective use of PRINCE2 TM is 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. PRINCE2 TM is 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 PRINCE2 TM Registered Consultant Programme and Project Management Registered Consultant 8
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 PRINCE2 terminology has also been retained. This book deals not only with the PRINCE2 methodology, but also with activities and planning resources and the project environment. This complements the PRINCE2 methodology. 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. Bert Hedeman, Gabor Vis van Heemst and Hans Fredriksz 9
10
1 Introduction to project management 1.1 Why project management? Managing projects is as old as the hills. There are stories dating back 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 hunting ground 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 processbased 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 11
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 12
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). 13
Vision, strategy, objectives Stakeholders/ environmental factors Business planning Corporate or programme management Feasibility studies, Business Cases Projects 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). Project Approach Objective Problem or chance Result 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. 14
The 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. Idea Study Assignment Product Lifecycle Specify Design Develop Test Implement Project Lifecycle Use Realise the benefits Replacement/disposal 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? 15
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. 16
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. 17
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 PRINCE2? The reasons mentioned in paragraph 1.4 for the failure of projects led to the development of the PRINCE2 project 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. PRINCE2 places 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 PRINCE2 method, risk management is therefore an integral part of all processes to be carried out. 18
2 Introduction to PRINCE2 2.1 What is PRINCE2? 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 PRINCE2 method. The PRINCE2 method 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, PRINCE2 has 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 PRINCE2 PRINCE2 is 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. PRINCE2 is, 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. PRINCE2 is 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. PRINCE2 cannot be used as recipe book; it must be used in combination with common sense and the correct technical and social skills. Although PRINCE2 does 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 PRINCE2 and 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. 19