Project Management Based on PRINCE2® 2009 edition
Description
More details
Other editions
Additional editions
Content
1.1 - 1.1 Why project management? [Seite 12]
1.2 - 1.2 What is a project? [Seite 12]
1.3 - 1.3 What is project management? [Seite 14]
1.4 - 1.4 What is the job of the Project Manager? [Seite 15]
1.5 - 1.5 What aspects are managed? [Seite 15]
1.6 - 1.6 What is a successful project? [Seite 16]
1.7 - 1.7 Why do projects fail? [Seite 17]
1.8 - 1.8 Why PRINCE2 ? [Seite 18]
2 - 2 Introduction to PRINCE2 [Seite 20]
2.1 - 2.1 What is PRINCE2? [Seite 20]
2.2 - 2.2 The structure of PRINCE2 [Seite 20]
2.3 - 2.3 Relationship to other OGC guidelines [Seite 20]
2.4 - 2.4 What is not in PRINCE2? [Seite 21]
2.5 - 2.5 PRINCE2, benefi ts [Seite 22]
2.6 - 2.6 Differences in PRINCE2 v2009 versus v2005 [Seite 22]
2.7 - 2.7 Spelling of PRINCE2 words [Seite 26]
2.8 - 2.8 About this book [Seite 27]
2.9 - 2.9 Preparation for exams [Seite 27]
3 - 3 PRINCE2, principles [Seite 30]
3.1 - Principle 1 [Seite 30]
3.2 - Principle 2 [Seite 31]
3.3 - Principle 3 [Seite 31]
3.4 - Principle 4 [Seite 32]
3.5 - Principle 5 [Seite 32]
3.6 - Principle 6 [Seite 33]
3.7 - Principle 7 [Seite 33]
4 - I Introduction to PRINCE2 themes [Seite 36]
5 - 4 Business Case [Seite 38]
5.1 - 4.1 Introduction [Seite 38]
5.2 - 4.2 Conceptual framework [Seite 38]
5.3 - 4.3 Business Case, types [Seite 39]
5.4 - 4.4 Business Case, PRINCE2 approach [Seite 40]
5.5 - 4.5 Business Case, content [Seite 43]
5.6 - 4.6 Business Case, roles&responsibilities [Seite 44]
6 - 5 Organization [Seite 46]
6.1 - 5.1 Introduction [Seite 46]
6.2 - 5.2 Conceptual framework [Seite 46]
6.3 - 5.3 Project management structure [Seite 47]
6.4 - 5.4 Project Management Team (PMT) [Seite 48]
6.5 - 5.5 Size of the Project Board [Seite 53]
6.6 - 5.6 Involving stakeholders [Seite 53]
6.7 - 5.7 Preparing the Communication Management Strategy [Seite 54]
7 - 6 Quality [Seite 56]
7.1 - 6.1 Introduction [Seite 56]
7.2 - 6.2 Conceptual framework [Seite 56]
7.3 - 6.3 Quality management [Seite 56]
7.4 - 6.4 PRINCE2 quality approach [Seite 58]
7.5 - 6.5 Quality planning [Seite 59]
7.6 - 6.6 Quality control [Seite 62]
7.7 - 6.7 Quality review [Seite 63]
7.8 - 6.8 Quality, roles&responsibilities [Seite 66]
8 - 7 Planning [Seite 68]
8.1 - 7.1 Introduction [Seite 68]
8.2 - 7.2 What is a plan? [Seite 68]
8.3 - 7.3 Benefi ts of drawing up a plan [Seite 68]
8.4 - 7.4 Elements of a plan [Seite 68]
8.5 - 7.5 Plan approach [Seite 69]
8.6 - 7.6 Planning levels [Seite 70]
8.7 - 7.7 Planning, PRINCE2 approach [Seite 72]
8.8 - 7.8 Planning, roles&responsibilities [Seite 83]
9 - 8 Risk [Seite 84]
9.1 - 8.1 Introduction [Seite 84]
9.2 - 8.2 Conceptual framework [Seite 84]
9.3 - 8.3 Risk [Seite 85]
9.4 - 8.4 Risk Management Strategy [Seite 86]
9.5 - 8.5 Risk Register [Seite 87]
9.6 - 8.6 Risk management procedures [Seite 87]
9.7 - 8.7 Risk owner and risk actionee [Seite 93]
9.8 - 8.8 Risk budget [Seite 93]
9.9 - 8.9 Risks, roles&responsibilities [Seite 94]
10 - 9 Change [Seite 96]
10.1 - 9.1 Introduction [Seite 96]
10.2 - 9.2 Conceptual framework [Seite 96]
10.3 - 9.3 Approach to change [Seite 97]
10.4 - 9.4 Confi guration management procedures [Seite 100]
10.5 - 9.5 Issue control procedures and change control procedures [Seite 101]
10.6 - 9.6 Change Authority and change budget [Seite 102]
10.7 - 9.7 Roles and responsibilities [Seite 103]
11 - 10 Progress [Seite 104]
11.1 - 10.1 Introduction [Seite 104]
11.2 - 10.2 Conceptual framework [Seite 104]
11.3 - 10.3 Management by exception [Seite 105]
11.4 - 10.4 Progress, control [Seite 106]
11.5 - 10.5 Roles and responsibilities [Seite 112]
12 - II Introduction to processes [Seite 116]
12.1 - II.1 Why a process-based approach? [Seite 116]
12.2 - II.2 Four management levels [Seite 116]
12.3 - II.3 The management processes [Seite 117]
12.4 - II.4 PRINCE2 processes in a temporal framework [Seite 117]
12.5 - II.5 The structure of the process descriptions [Seite 118]
13 - 11 SU, Starting up a Project [Seite 120]
13.1 - 11.1 SU, basic principles [Seite 120]
13.2 - 11.2 Context [Seite 121]
13.3 - 11.3 SU, process description [Seite 122]
13.4 - 11.4 Overview of SU activities [Seite 126]
14 - 12 IP, Initiating a Project [Seite 128]
14.1 - 12.1 IP, basic principles [Seite 128]
14.2 - 12.2 Context [Seite 129]
14.3 - 12.3 Process Description [Seite 129]
14.4 - 12.4 Overview of IP activities [Seite 134]
15 - 13 DP, Directing a Project [Seite 136]
15.1 - 13.1 DP, basic principles [Seite 136]
15.2 - 13.2 Context [Seite 136]
15.3 - 13.3 DP, process description [Seite 137]
15.4 - 13.4 Overview of DP activities [Seite 142]
16 - 14 CS, Controlling a Stage [Seite 144]
16.1 - 14.1 CS, basic principles [Seite 144]
16.2 - 14.2 Context [Seite 145]
16.3 - 14.3 CS, process description [Seite 146]
16.4 - 14.4 Overview of CS activities [Seite 152]
17 - 15 MP, Managing Product Delivery [Seite 156]
17.1 - 15.1 MP, basic principles [Seite 156]
17.2 - 15.2 Context [Seite 157]
17.3 - 15.3 MP, process description [Seite 157]
17.4 - 15.4 Overview of MP activities [Seite 160]
18 - 16 SB, Managing a Stage Boundary [Seite 162]
18.1 - 16.1 SB, basic principles [Seite 162]
18.2 - 16.2 Context [Seite 163]
18.3 - 16.3 SB, process description [Seite 163]
18.4 - 16.4 Overview of SB activities [Seite 167]
19 - 17 CP, Closing a Project [Seite 170]
19.1 - 17.1 CP, basic principles [Seite 170]
19.2 - 17.2 Context [Seite 171]
19.3 - 17.3 CP, process description [Seite 171]
19.4 - 17.4 Overview of CP activities [Seite 175]
20 - 18 The Project Environment [Seite 178]
20.1 - 18.1 Project versus programme [Seite 178]
20.2 - 18.2 Multi-project management [Seite 179]
20.3 - 18.3 Managing a project portfolio [Seite 179]
21 - 19 Tailoring [Seite 182]
21.1 - 19.1 Introduction [Seite 182]
21.2 - 19.2 Projects within programmes [Seite 185]
21.3 - 19.3 Project, scale [Seite 186]
21.4 - 19.4 Lifecycle models [Seite 190]
21.5 - 19.5 Different kinds of projects [Seite 191]
21.6 - 19.6 Project types [Seite 193]
22 - Appendix A Management products, set-up [Seite 198]
23 - Appendix B Roles and responsibilities [Seite 222]
24 - Appendix C Example of Product-based Planning [Seite 229]
25 - Appendix D Health check [Seite 232]
26 - Appendix E Glossary [Seite 240]
27 - Appendix G Additional information [Seite 252]
28 - Index [Seite 254]
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 challenges facing building the pyramids 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 infrastructure works. At that time, project management involved little more than planning the work. In the 1970s, attention switched to controlling 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. In recent decades, there has been more and more focus on the environment in which projects are implemented. More and more projects are (or are starting to be) part of portfolios or programmes within organizations.
Project management is increasingly becoming a profession. In the past project management was a task taken on in addition to regular work, whereas nowadays project management is a separate profession from which many people earn a living. However, despite the increased professionalism, projects still frequently fail. Some failed projects hit the headlines, but most are never heard of again. There is no simple reason why projects fail, but a lack of an effective method for managing projects is one of the major causes.
Without a project management method various stakeholders may have differing expectations for organizing and completing a project or the amount of responsibility and authority they have. Rarely are such projects delivered to the satisfaction of those involved. This particularly applies to projects with a long lead time or projects in a changing environment.
A good project management method should not be static. The environment and the market are subject to change, Executives and users take up new positions. In other words, projects have to be managed in a changing environment. It is still too often assumed that a project can be managed in a 'frozen' environment. This may make things easy, but it is just not how things are in the world of today.
An effective project management method helps the Project Manager to organize and manage a project in a continually changing environment while still involving all the stakeholders. PRINCE2 is such a method and uses the fundamental principles of good project management.
1.2 What is a project?
It is important to recognize the difference between a project and the 'business as usual' of an organization. Lack of clarity as to what a project actually is can lead to a lot of friction and frustration.
Definitions of a project, PRINCE2 definition
One frequently used definition of a project is: "A project is a time and cost constrained operation to realize a set of defined deliverables up to quality standards and requirements." (Source: ICB version 3.0)
In the context of the above, PRINCE2 describes a project as:
A temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case.
A temporary organization entails staff temporarily being given a different set of responsibilities and authority. Line management has to delegate certain responsibilities and authority to the project organization, otherwise a project organization cannot function properly. Business products are products that provide added value for the customer. A Business Case is a justification for initiating and delivering a project. In a Business Case, the anticipated benefits and estimated costs for the project are recorded, as well as the time over which the benefits will be realized.
Why are projects important?
One of the most important reasons for working with projects is that the desired results simply cannot be achieved, or can be achieved only with difficulty, within the existing line organization or organizations. The existing (corporate) structures and processes are primarily geared toward efficiency and much less suited to dealing quickly and properly with change. The project organization is temporary. In other words, it has been created for the duration of the project and differs in that respect from the line organization. Unsurprisingly, the style and nature of projects differs from the line activities.
Working with projects is a good way of safeguarding support for and commitment to use the end result as early as possible by involving the different stakeholders in the initiation and delivery of the project. In this regard, projects have become an indispensable way of implementing changes within organizations.
What makes projects so 'different'?
Projects have specific characteristics compared to standard business operations work. These include:
Change - A project always means a change from the status quo - sometimes a minor one, but sometimes also a major one - and this creates resistance to the change.. A temporary project organization provides a good way of developing and safeguarding support for and commitment to use the end result early in the development stage by involving the different stakeholders in the initiation and implementation of the project. In this way, a broad-based grounding in the line organizations involved is assured at an early stage.
Temporary - This is a distinguishing feature of projects. Project have a defined start and end date. The project finishes as soon as the pre-agreed products and/or services have been delivered and handed over to the customer.
Cross-functional - A project has an organization specially set up for this purpose. What characterizes a project organization is that it comprises the different competencies and roles required for the project. This renders the project organization effective. In this regard, it does not matter whether the team members come from the same (line) organizations or different ones.
Unique - Every project is different because every change is different. The result to be produced is different or there are different objectives. Different people are involved in the project organization, there are different stakeholders or the context is different. No two projects are the same.
Uncertainty - All the specified characteristics of projects result in uncertainties. They can produce both opportunities and threats. There is no getting around this, but it is an inextricable fact with which projects are faced. In this regard, projects are often much more risk-laden than normal activities and risk management is an indispensable component of project management.
Relationship between projects and programmes
The need for a change in the organization can be defined from the perspective of the corporate objectives. To this end, projects can be initiated. In such cases, the project provides the necessary products and services required by the business organization in order for it to achieve its objectives and the benefits associated with these. However, achieving business objectives and benefits is, and remains, one of the business organization's responsibilities and is not the project's responsibility.
A programme is sometimes set up to develop one or more corporate objectives. In such cases, the programme serves to initiate the different projects. The products and services required for the programme are then produced in the projects in order to fulfill the agreed goals and benefits. A programme has a less well-defined path and also a much longer lead-time than the separate projects within the programme, for a programme must consciously be finished, whereas projects automatically come to an end on delivery of the output of the project. After all, if everything is running as it should, benefits will continue each year (see table 1.1). Consequently, programmes are not large projects but one of the operational management's own responsibilities. Projects are, of course, driven by the corporate or programme management.
Projects
Program
Driven by deliverables
Driven by vision of 'end state'
Finite - defined start and finish
No pre-defined path
Bounded and scoped deliverables
Changes to business capabilities
Deliver product or service
Realizing objectives
Ends by handing over output
Must be closed formally
Benefits accrue outside the project
Benefits realized as part of the program and afterwards
Shorter timescale
Longer timescale
Table 1.1 Projects versus programmes (Source: Managing Successful Projects with PRINCE2, produced by OGC)
1.3 What is project management?
Project management is planning, delegating, monitoring and controlling all aspects of a project and motivating all parties involved to achieve the...
