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