Hedeman / Heemst / Fredriksz Project Management Based on PRINCE2® 2009 edition

1. Auflage 2012
ISBN: 978-90-8753-583-4
Verlag: Van Haren Publishing
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Englisch, 262 Seiten

Reihe: Best Practice

An increasing number of companies are working in a project-like manner, using the PRINCE2™ project management method. The advantages of a standard method are great: a uniform method of working and terminology makes projects comparable, transferable and orderly. Moreover, PRINCE2 has additional qualities, such as the standard no go/go decision with each stage, the Business Case at the centre of the project and clear agreements about who is responsible for what.

The book gives a faithful representation of the 2009 Edition of the PRINCE2 methodology, with many lists serving as reference material for all project types and sizes. Furthermore, as the content of the book covers all specs for the PRINCE2 Foundation exams, it can serve as a good basis for the PRINCE2 Foundation exams.

The three authors of this title have successfully combined their tremendous experience and made this available in a structured manner to those who are involved in controlling, designing or managing projects. And whatever they missed was added by a team of expert reviewers.

The content for this book is also intended for everyone doing projects in real world, it covers more than the minimum reference that is necessary for the Foundation exam. Therefore it is also very useful as a solid starting point for anyone studying for the PRINCE2 Practitioner exam.

Available in English and Dutch.

By this book is a separate file (free, via internet) available:

• All images in the book, in Powerpoint format. Click on the button Training Material by the book on our website.

Autoren/Hrsg.

Hedeman, Bert

Heemst, Gabor

Fredriksz, Hans

Inhaltsverzeichnis

1;1 Introduction to project management;12
1.1;1.1 Why project management?;12
1.2;1.2 What is a project?;12
1.3;1.3 What is project management?;14
1.4;1.4 What is the job of the Project Manager?;15
1.5;1.5 What aspects are managed?;15
1.6;1.6 What is a successful project?;16
1.7;1.7 Why do projects fail?;17
1.8;1.8 Why PRINCE2 ?;18
2;2 Introduction to PRINCE2;20
2.1;2.1 What is PRINCE2?;20
2.2;2.2 The structure of PRINCE2;20
2.3;2.3 Relationship to other OGC guidelines;20
2.4;2.4 What is not in PRINCE2?;21
2.5;2.5 PRINCE2, benefi ts;22
2.6;2.6 Differences in PRINCE2 v2009 versus v2005;22
2.7;2.7 Spelling of PRINCE2 words;26
2.8;2.8 About this book;27
2.9;2.9 Preparation for exams;27
3;3 PRINCE2, principles;30
3.1;Principle 1;30
3.2;Principle 2;31
3.3;Principle 3;31
3.4;Principle 4;32
3.5;Principle 5;32
3.6;Principle 6;33
3.7;Principle 7;33
4;I Introduction to PRINCE2 themes;36
5;4 Business Case;38
5.1;4.1 Introduction;38
5.2;4.2 Conceptual framework;38
5.3;4.3 Business Case, types;39
5.4;4.4 Business Case, PRINCE2 approach;40
5.5;4.5 Business Case, content;43
5.6;4.6 Business Case, roles&responsibilities;44
6;5 Organization;46
6.1;5.1 Introduction;46
6.2;5.2 Conceptual framework;46
6.3;5.3 Project management structure;47
6.4;5.4 Project Management Team (PMT);48
6.5;5.5 Size of the Project Board;53
6.6;5.6 Involving stakeholders;53
6.7;5.7 Preparing the Communication Management Strategy;54
7;6 Quality;56
7.1;6.1 Introduction;56
7.2;6.2 Conceptual framework;56
7.3;6.3 Quality management;56
7.4;6.4 PRINCE2 quality approach;58
7.5;6.5 Quality planning;59
7.6;6.6 Quality control;62
7.7;6.7 Quality review;63
7.8;6.8 Quality, roles&responsibilities;66
8;7 Planning;68
8.1;7.1 Introduction;68
8.2;7.2 What is a plan?;68
8.3;7.3 Benefi ts of drawing up a plan;68
8.4;7.4 Elements of a plan;68
8.5;7.5 Plan approach;69
8.6;7.6 Planning levels;70
8.7;7.7 Planning, PRINCE2 approach;72
8.8;7.8 Planning, roles&responsibilities;83
9;8 Risk;84
9.1;8.1 Introduction;84
9.2;8.2 Conceptual framework;84
9.3;8.3 Risk;85
9.4;8.4 Risk Management Strategy;86
9.5;8.5 Risk Register;87
9.6;8.6 Risk management procedures;87
9.7;8.7 Risk owner and risk actionee;93
9.8;8.8 Risk budget;93
9.9;8.9 Risks, roles&responsibilities;94
10;9 Change;96
10.1;9.1 Introduction;96
10.2;9.2 Conceptual framework;96
10.3;9.3 Approach to change;97
10.4;9.4 Confi guration management procedures;100
10.5;9.5 Issue control procedures and change control procedures;101
10.6;9.6 Change Authority and change budget;102
10.7;9.7 Roles and responsibilities;103
11;10 Progress;104
11.1;10.1 Introduction;104
11.2;10.2 Conceptual framework;104
11.3;10.3 Management by exception;105
11.4;10.4 Progress, control;106
11.5;10.5 Roles and responsibilities;112
12;II Introduction to processes;116
12.1;II.1 Why a process-based approach?;116
12.2;II.2 Four management levels;116
12.3;II.3 The management processes;117
12.4;II.4 PRINCE2 processes in a temporal framework;117
12.5;II.5 The structure of the process descriptions;118
13;11 SU, Starting up a Project;120
13.1;11.1 SU, basic principles;120
13.2;11.2 Context;121
13.3;11.3 SU, process description;122
13.4;11.4 Overview of SU activities;126
14;12 IP, Initiating a Project;128
14.1;12.1 IP, basic principles;128
14.2;12.2 Context;129
14.3;12.3 Process Description;129
14.4;12.4 Overview of IP activities;134
15;13 DP, Directing a Project;136
15.1;13.1 DP, basic principles;136
15.2;13.2 Context;136
15.3;13.3 DP, process description;137
15.4;13.4 Overview of DP activities;142
16;14 CS, Controlling a Stage;144
16.1;14.1 CS, basic principles;144
16.2;14.2 Context;145
16.3;14.3 CS, process description;146
16.4;14.4 Overview of CS activities;152
17;15 MP, Managing Product Delivery;156
17.1;15.1 MP, basic principles;156
17.2;15.2 Context;157
17.3;15.3 MP, process description;157
17.4;15.4 Overview of MP activities;160
18;16 SB, Managing a Stage Boundary;162
18.1;16.1 SB, basic principles;162
18.2;16.2 Context;163
18.3;16.3 SB, process description;163
18.4;16.4 Overview of SB activities;167
19;17 CP, Closing a Project;170
19.1;17.1 CP, basic principles;170
19.2;17.2 Context;171
19.3;17.3 CP, process description;171
19.4;17.4 Overview of CP activities;175
20;18 The Project Environment;178
20.1;18.1 Project versus programme;178
20.2;18.2 Multi-project management;179
20.3;18.3 Managing a project portfolio;179
21;19 Tailoring;182
21.1;19.1 Introduction;182
21.2;19.2 Projects within programmes;185
21.3;19.3 Project, scale;186
21.4;19.4 Lifecycle models;190
21.5;19.5 Different kinds of projects;191
21.6;19.6 Project types;193
22;Appendix A Management products, set-up;198
23;Appendix B Roles and responsibilities;222
24;Appendix C Example of Product-based Planning;229
25;Appendix D Health check;232
26;Appendix E Glossary;240
27;Appendix G Additional information;252
28;Index;254

Leseproben

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...