The PRINCE2 Practitioner

From Practitioner to Professional

Colin Bentley

• Publisher: Routledge
• Year: 2015
• ISBN:
  9781317581611
• Edition: 3
• Topic: Betriebswirtschaft
• Subtopic: Business allgemein

Struggling to apply the principles of PRINCE2 in practice?

Need guidance on adapting the process for smaller projects?

PRINCE2 for Practitioners provides the solution. This practical reference, matching the details and requirements of the 2009 PRINCE2 manual, contains new and updated real-life examples and case studies, links between related components and processes, and clear guidance on how to fine-tune the method to help you manage projects successfully, whatever the context and size.

An affordable alternative to expensive training, this best-selling handbook by PRINCE2 expert Colin Bentley is an indispensable addition to your project management bookshelf and a companion to the PRINCE2 for Beginners book. If you have passed the PRINCE2 exams, it will help you keep your knowledge and skills up to date to maintain registered status and enable you to apply the theory of PRINCE2 to everyday project work after certification.

Chapter 1
Introduction

PRINCE^® is a registered trademark of Axelos Limited.

PRINCE2^® is a registered trademark of Axelos Limited.

This book is a complete description of the PRINCE2 project management method. The method is owned by Axelos Limited, and has been put into the public domain, so there is no fee to be paid for its use. (If you want to make money from the method, for example, by offering training, products or consultancy, you need to be registered with Axelos Limited.)

This book is an in-depth explanation of PRINCE2 for those readers who want to proceed to the Practitioner level and beyond. It covers the whole method and provides insights into areas in the official manual that need further explanation.

Chapter 2
An Overview of PRINCE2

2.1 Project Performance Aspects

There are six aspects of project performance that always need to be managed:

• Costs: Estimating how much a project will cost is always a problem, followed by controlling efficiency and effectiveness to ensure that this cost is not exceeded.
• Time: How long will the project take? How effective will resources be? Have you made allowances for meetings, training, holidays, learning cycles?
• Quality: More important than getting cost and time right is getting the quality right. Do you know what quality the customer wants? Is that level of quality realistic in view of other constraints, such as time and cost? Have you allowed enough time and resources to achieve that quality?
• Scope: How precisely are the requirements known? Have you got an agreed cut-off point for finalizing requirements? Have you got a change control procedure in place to avoid ‘scope creep’? Does the customer understand that, after you have agreed a price and time frame, any changes to the specification must be paid for? If the customer’s detailed knowledge of the requirements is going to evolve slowly, is the cost and time needed to provide the changing requirements also allowed to ‘evolve’?
• Risk: Have you reviewed the project for risks at the outset? Are you regularly reviewing risks? Do you have a risk management procedure in place? Do you know what level of risk the customer is willing to accept?
• Benefits: Are there valid reasons for doing the project? Does the outcome fit with company strategy? Are the claimed benefits realistic? Do you have measurements of the situation now, before the outcome is delivered, in order to measure the achievement of benefits?

PRINCE2 contains the processes and themes that will keep these aspects of project performance under control.

2.2 Principles Of PRINCE2

There are seven principles on which PRINCE2 is founded, and these principles are unique to the PRINCE2 method (Figure 2.1).

Principles are characterized as:

• Universal: They apply to every project, any type, any size.
• Self-validating: They have been proved by use over many years.
• Empowering: They give users of the method the ability to shape the management of the project.

FIGURE 2.1 The seven PRINCE2 principles

The seven PRINCE2 principles are:

• Continued business justification;
• Learn from experience;
• Defined roles and responsibilities;
• Manage by stages;
• Manage by exception;
• Focus on products;
• Tailor to suit the project environment.

2.2.1 Continued business justification

(A project should be driven by its Business Case)

PRINCE2 emphasizes that a project should be driven by a viable Business Case. The existence of the Business Case should be proved before the project is given the go-ahead, and should be confirmed at all major decision points during the project. It should also be documented. (If a product fails to deliver all the expected benefits, those who originally claimed the benefits would be there may suffer from amnesia!) Remember, the benefits and their value should be defined by the customer (Senior User) at the outset. It is also the Senior User’s task to measure the achievement of the benefits after the end product has been in use for an agreed length of time.

So:

• You shouldn’t start a project unless there is a sound Business Case for it.
• Make sure that the potential benefits are realistic and measurements of the current situation have been documented.
• At regular intervals in the project you should check that the project is still viable.
• Stop the project if the justification has disappeared.

The Business Case:

• Should be documented and approved;
• Drives the decision-making processes;
• Ensures that the project remains aligned to the business objectives and benefits being sought.

Even projects that are compulsory require justification – there may be several options available that yield different costs, benefits and risks.

Justification for a project may change, but it must remain valid.

2.2.2 Learn from experience

Project management should never be ‘reinventing the wheel’. Those involved in the project may have previous experience; there will be earlier projects in the company from which lessons can be learned, and there are other sources of valuable lessons (e.g. the internet, suppliers, sister companies, and, of course, this book!) that can be used in the project.

Lessons should be sought at the beginning of a project (in the process Starting up a Project – see chapter 10), learned as the project progresses and passed on to other projects at the close. A Lessons Report should be issued at the end of a stage, without waiting until the end of the project, if a useful lesson is learned that could help other projects.

2.2.3 Defined roles and responsibilities

Project management is different to line management.

Projects require a temporary organization for a finite timescale for a specific business purpose. Managing the project staff can be a headache for a Project Manager. A project is temporary and may include staff who report to different line managers or even work for other organizations. The project may require a mixture of full-time and part-time resources. So how do we ensure that everyone knows who is responsible for what?

An explicit project management team structure is required. Good communication depends on people knowing not only what their own responsibilities are but also the responsibilities of others.

The roles and responsibilities are divided into three groups, the interests of which must be represented in any project (Figure 2.2). These are:

• Business;
• User;
• Supplier.

FIGURE 2.2 Business, user and supplier interests

PRINCE2 provides an organization structure that engages everyone involved: the business, user and supplier interests. Within the structure there are defined roles and responsibilities for every member of the project management team. The chosen people agree to a role description and sign their acceptance of that role. Roles can be split or combined, depending on the size of the project.

2.2.4 Manage by stages

This comes from two different thoughts:

• 1) If the Project Board is, in PRINCE2 terms, ultimately accountable for the project, and as PRINCE2 doesn’t like the idea of regular progress meetings, there must be some key points in a project when the Project Board needs to review progress and decide if it wants to continue with the project – i.e. that the project is still viable;
• 2) Very often a project will last longer and contain more detail than can be planned for with any accuracy at the outset.

Based on these thoughts, PRINCE2 divides a project into stages. PRINCE2 has a Project Plan, an overview of the whole project, but the Project Manager only plans the next stage in detail – i.e. only as much of the project as can be accurately judged – and the Project Board only approves one stage at a time, reviewing the status at the stage end and deciding whether to continue or not. One check that the Project Board can make when assessing its confidence level in the next Stage Plan (see section 5.2.2) is how close to reality the last Stage Plan was.

The number of stages depends on the size, complexity and risk content of the project.

At the end of each stage, a plan is presented, together with an updated view of the Business Case, the Project Plan, the risks and suggested tolerances for the next stage. Thus senior management can review progress so far and decide from the information presented to them whether or not to authorize the next stage.

2.2.5 Manage by exception

PRINCE2 recognizes four levels of authority in a project. Authority is delegated from one management level to the next. Each management level is allocated tolerances within which they can continue without the need to refer to the next higher level of management. This is what is meant by management by exception...