PRINCE2 for PMP^® & CAPM^® credential holders

PRINCE2 and the PMBOK Guide^®

If you’re based in the UK, then you’re probably already familiar with PRINCE2 ^[2]. It’s a UK-based project management framework, originally developed in 1996 by the UK government for use on public sector projects. Since then it’s become much more popular however and is now widely used internationally in both public and private sectors. Although it was first released in 1996, its predecessors have a much longer history dating back to the late 1970’s.PRINCE2 is a process-based framework which describes a flexible set of controls which can be used to help organizations plan, manage and control their projects. It provides a generic project management lifecycle which describes each step to be performed throughout a project.Coincidentally the Project Management Institute (PMI) also brought out the first edition of the PMBOK^® Guide in 1996. The PMBOK^® Guide documents a set of standard terminology, knowledge and guidelines for project management. In addition it describes a code of ethics which it recommends should govern the behaviour and conduct of professional project managers.Although the PMI started in the USA, it is very much now a global organisation with chapters (groups of members) in many countries in the world.

Competing global standards?

If you take an interest in these things then you might have heard people saying that both PRINCE2 and the PMBOK^® Guide are competing global standards. As we will see, they are nothing of the sort, but are in fact complementary tools which can both be used to bring about more successful projects. The PMBOK^® Guide describes the knowledge which project managers will generally find useful when managing a project. This invariably means a comprehensive description of tools and techniques is provided. Guidance is given on how each tool or technique is used within processes to support best practice in each knowledge area. PRINCE2 on the other hand describes only 2 techniques. Rather than being a body of knowledge like the PMBOK^® Guide, PRINCE2 is primarily concerned with describing what needs to be done on a project, by whom and when. PRINCE2 doesn’t focus on how to do it. Instead PRINCE2 describes a process model which can be easily applied to any project. So, rather than saying that PRINCE2 and the PMBOK^® Guide represent 2 competing standards, it’s probably better to say they are complementary approaches to project management: PRINCE2 providing a thorough description of the lifecycle steps and the PMBOK^® Guide providing the detailed knowledge of tools and techniques.

Some interesting observations

If you were to read both the PRINCE2 manual (Managing Successful Projects with PRINCE2) and the PMBOK^® Guide you will be struck by how much overlap there is between the two despite the differences in terminology. I guess this shouldn’t surprise us because they are both focused on project management. You can see this when looking at the PRINCE2 Quality and Risk themes. These map to both the Quality and Risk Management knowledge areas of the PMBOK^® Guide respectively. One thing you might notice however when comparing the two is how much emphasis PRINCE2 places on the benefits of the project i.e. the return on investment (whether financial or otherwise) when compared with the PMBOK^® Guide. In PRINCE2, understanding the benefits versus the costs, timescales and risks goes to the very essence of PRINCE2. It’s this understanding which drives the decision-making on a PRINCE2 project. You might also notice that in the introduction of the PMBOK^® Guide it talks about how the project manager needs to balance 6 competing constraints: schedule, budget, quality, scope, risks and resources. You can read I detail about each of these constraints in each of the 6 related knowledge areas of the PMBOK^® Guide. PRINCE2 on the other hand refers to the first 5 of these, but not to resources. In PRINCE2 resources are treated as part of the costs of doing the project. It does refer to a 6th item however; benefits. So benefits in PRINCE2 are given a prominence found lacking in the PMBOK^® Guide. The many tools and techniques which you might be familiar with from the PMBOK^® Guide are all very useful if you are a project manager. This is especially true when you understand and know how to apply them. PRINCE2 however only describes 2 techniques – the product-based planning technique and the quality review technique. In the PMBOK^® Guide, there are dozens of techniques either described or referred to. In this regard, the PMBOK^® Guide provides much more of a comprehensive ‘how to’ guide than does the PRINCE2 manual. The view taken by the authors of the PRINCE2 manual is that these generic tools and techniques are adequately described in other reference works (e.g. the PMBOK^® Guide) and therefore it’s not necessary to duplicate them in the PRINCE2 manual ^[3].

Structure of PRINCE2 and the PMBOK^® Guide

One of the first things you’ll learn about PRINCE2 is that it consists of 4 integrated elements: principles, themes, processes and tailoring to suit the needs of your project.

Principles

In PRINCE2, principles are the foundations upon which everything else is based. There are no principles in the PMBOK^® Guide.

Themes vs knowledge areas

In PRINCE2, there are 7 themes. Themes are defined as ‘aspects of project management which must be continuously addressed throughout the project’. The concept of themes is similar to the PMBOK^® Guide’s concept of ‘knowledge areas’ which group project management processes by subject matter. As you can see from the diagram, there isn’t a straightforward mapping between the 7 PRINCE2 themes and the 10 PMBOK^® Guide knowledge areas. In fact one knowledge area (Procurement) cannot be mapped to any theme in PRINCE2 because PRINCE2 does not cover this aspect.

Processes vs Process Groups

In PRINCE2, there are 7 processes. A process is defined as “a structured set of activities designed to accomplish a specific objective. It takes one or more defined inputs and turns them into defined outputs”. Each PRINCE2 process is sub-divided into several activities which may run in series or in parallel and are defined as “a set of recommended actions designed to achieve a particular result” ^[4]. There are 41 activities in total in PRINCE2. An activity in PRINCE2 therefore is very similar to the PMBOK^® Guide’s definition of a process as a “set of interrelated actions and activities performed to achieve a specified set of products, results, or services.” ^[5] The PMBOK^® Guide associates its 47 processes into 5 Process Groups depending upon the kind of work being done.Taken as a whole, the 7 processes in PRINCE2 form the complete project management lifecycle. You can apply them on any type or size of project. The processes clearly explain what you need to do at the beginning, during the middle and at the end of your project. At first glance you might think that Process Groups in the PMBOK^® Guide represent project lifecycle phases. After all, the names kind of imply they are performed in a sequence: Initiating, Planning, Executing, Monitoring & Controlling, Closing. However, on closer inspection, it’s clear that Process Groups are not to be confused with project lifecycle phases ^[6]. Another point of difference between processes in PRINCE2 and Process Groups in the PMBOK^® Guide is the treatment of what the former calls ‘technical stages’, but the latter calls ‘phases’. According to the PMBOK^® Guide, a project can be broken down into Phases and all Process Groups will be applied during each Phase ^[7]. PRINCE2 makes a distinction however between ‘technical stages’ and management stages ^[8]. It’s during the management stages (see the section below about the ‘manage by stages’ principle) where 6 of the 7 processes are performed (the 7th is performed before the project is initiated). Three of the processes in PRINCE2 are only ever performed once: one is performed pre-project, one during project initiation and one at the end of the project.

Project management principles

The PMBOK^® Guide has no mention of principles. PRINCE2 in contrast is principles-based. The simple test of whether or not your project is a PRINCE2 project is whether or not you are applying the 7 principles ^[9]. The PRINCE2 manual states that these principles are universal and therefore applicable to all projects, irrespective of culture ^[10]. They are self-validating in that they have been proven in practice over many years. The principles are also empowering, meaning that if you apply them your project will have a better chance of success. So let’s briefly summarize what each of the principles in PRINCE2 means.

Continued business justification

This first principle is all about the project being based upon sound investment decisions. This means having a Business Case which provides an understanding of the return on investment (the benefits) versus the costs and the risks. The PRINCE2 manual says that these benefits do not need to be financial (although this certainly helps the investment decision) but they must be measurable ^[11]. If you’ve ever worked on a PRINCE2 project you’ll know how important the concept of the Business Case is. Even a mandatory project (e.g. to comply with new legislation) needs to have a Business Case which outlines the different options considered and the relative costs, risks and benefits. In the PMBOK^® Guide, a business case is used to “determine whether or not the project is worth the required investment” and is “commonly used for decision making by managers or executives above the project level” ^[12]. This definition of the Business Case in the PMBOK^® Guide is very close to that of PRINCE2. However, the use of it is very different. In PRINCE2, an up to date Business Case is used to help inform all of the ‘go/no-go” decisions taken during the project. This ensures the project continues to be a worthwhile investment. The project should be closed prematurely if it is no longer worthwhile. In the PMBOK^® Guide, the Business Case “may be periodically reviewed to ensure that the project is on track” ^[13]. In the PMBOK^® Guide then, you are given far less guidance on how to use a business case on your project than you are in PRINCE2. Certainly, in the PMBOK^® Guide the Business Case does not drive the decisions in the way it does in PRINCE2.

Learn from experience

Some of you might have worked in organizations which try to continuously improve their project management. That’s what this principle is all about. It’s about ensuring we avoid repeating past mistakes and incorporate only the good things from previous projects. This is done via a Lessons Log and Lessons Reports. There is a direct correlation here with the PMBOK^® Guide’s lessons learned, one of its most important organizational process assets.

Defined roles responsibilities

You’ll also know just how important it is to be clear about your responsibilities at work. A clear job description is always useful. PRINCE2 takes the view that the people who take decisions about the project (i.e. the project management team) need to understand clearly what each of them is responsible and accountable for ^[14]. This is covered in the PMBOK^® Guide mainly by the Human Resource management knowledge area.

Manage by stages

PRINCE2 recommends that you divide up your project into ‘management stages’. These stages are sequential and coincide with ‘go/no-go’ decisions about the project i.e. continue to the next stage of the project, or close it down prematurely. PRINCE2 mandates that you will need at least 2 ‘management stages’ on your project. One of these is where most of the upfront planning for the project takes place (similar to the PMBOK^® Guide’s Planning Process Group) and at least one or more further stages is required whereby the deliverables (which are known as products in PRINCE2) are developed. You shouldn’t confuse PRINCE2’s management stages with what the PMBOK^® Guide calls ‘phases’. In the PMBOK^® Guide a phase is a way to break down a large complex project into small more manageable chunks. Such phases however do not necessarily coincide with any of the kind of ‘go/no-go’ decisions which occur at the end of a management stage in PRINCE2. PRINCE2 also refers to ‘technical stages’ which it sees as different from ‘management stages’ ^[15]. If you are running a technical project (let’s say an IT project), then you will inevitably have several technical stages (e.g. requirements analysis, design, construction, test etc.). These are driven by the technical nature of your project and they may often overlap.

Manage by exception

There is no correlation between ‘management by exception’ and anything in the PMBOK^® Guide. Whereas in the PMBOK^® Guide your authority as a project manager to plan and execute the project is granted from an approved Project Charter ^[16], in PRINCE2, your authority as a project manager is delegated to you on a stage-by-stage basis by the Project Board (collectively a group which represents business, user and supplier stakeholders). In PRINCE2, the Project Board is the main decision-making authority on the project ^[17]. This delegation of authority in PRINCE2 also occurs at each level of your project management team and is ‘delegated’ by the setting of ‘tolerances’. You can set tolerances on your project for time, cost, scope, risk, quality and benefits. If you forecast that these tolerances are likely to be exceeded, this is known as an ‘exception’ and you must escalate it to the next highest level of management. PRINCE2 also describes 3 levels of the project management team: the directing level (represented by the Project Board) which takes the major decisions about the project (e.g. ‘go’ or ‘no-go’), and commit the resources (people, money, equipment etc.); the managing level (represented by the Project Manager role) which manages each stage day to day, and; the delivering level (represented by Team Managers) which designs and builds the products (deliverables) which the users have specified ^[18]. These 3 levels are known as the project management team. There is a fourth, higher level, known as corporate or programme management which sets tolerances for the Project Board, but these are not regarded as being part of the project management team. The PMBOK^® Guide does not contain the concept of ‘levels of management’ although it refers to management hierarchies when discussing organizational structures ^[19]. For PRINCE2, ‘management by exception’ provides a major benefit to the individuals which form the Project Board because it saves their time ^[20]. The assumption in PRINCE2 is that Project Board members are themselves busy people, probably high up in the corporate/business hierarchy, and ‘management by exception’ enables them to still take major decisions but without the need for regular progress meetings. This is because regular reports are received from the Project Manager role in between the major decision points - i.e. the ‘go/no-go’ decisions taken at the end of a management stage. These decision points probably do require a meeting however.

Focus on products

PRINCE2 focuses on the definition and delivery of specialist products (deliverables in the PMBOK^® Guide). Planning and estimation of work, resources, time and cost can only occur after the definition of these products. Scope in PRINCE2 refers to the sum total of all of the specialist products being delivered. Scope forms one of the project’s baselines, just as it does in the PMBOK^® Guide. PRINCE2 defines a technique (the product-based planning technique) which helps the Project Manager role to define the scope and the products to be delivered. Only after performing this technique does PRINCE2 recommend using tools such as the Work Breakdown Structure (WBS) which is central to the PMBOK^® Guide’s guidance for the Scope Management knowledge area ^[21]. If you were to perform the product-based planning technique, the first thing you would do is define the Project Product. This is done in the form of a Project Product Description. This describes the final product (or deliverable) which will be handed over to the users or client at the end of the project. It is often composed of several smaller, subsidiary products. The Project Product Description describes the high level quality expectations of your customer (think of these as high level requirements) and from these, you derive a set of acceptance criteria. Acceptance criteria are contained within the project scope statement in the PMBOK^® Guide ^[22]. It also describes the scope of the project because it identifies all of the major products to be delivered ^[23].

Tailor to the project environment

Don’t believe the hype you might read, especially from Agile proponents that PRINCE2 is bureaucratic. It only becomes so when practitioners take an unthinking approach to applying the framework. If fact, PRINCE2 is a highly pragmatic approach to project management. It recognizes that all projects are different in scale, risk and complexity and that they also operate within different cultural, competitive and organizational contexts. Your projects are affected by such factors and you as a project manager need to take them into consideration when planning and managing your project. Hence the tailoring principle. PRINCE2 therefore can be viewed as a set of modern project management best practices, ones which need to be tailored to suit the specific needs of each project. The PMBOK^® Guide takes a similar view. The PMBOK^® Guide describes how ‘enterprise environmental factors’ (e.g. organizational strategy, structure and culture, and competitive and market pressures) need to be considered when setting up a project. It also states in its introduction that the knowledge described within is “generally recognized as good practice” which means that “the knowledge and practices described are applicable to most projects most of the time” ^[24]. It goes on to say that such good practice doesn’t mean that this knowledge should always be uniformly applied on all projects ^[25] but that it is the project management team’s responsibility for determining what is appropriate on any given project. In this way, both PRINCE2 and the PMBOK^® Guide share a common understanding about the need to tailor the guidance described.

Project management roles

One of the main ways in which PRINCE2 differs from the PMBOK^® Guide is its definitions of the different project management roles. In the PMBOK^® Guide, it is assumed that the project manager will do most of the day to day management and will report to the project sponsor ^[26]. The PMBOK^® Guide discusses a number of different stakeholders (sponsor, customers and users, sellers, business partners, organizational groups and functional managers) but doesn’t go into detail about any of their responsibilities on the project. PRINCE2 however defines a broad range of roles which collectively form the project management team, so let’s now take a look at these roles.

Project Board

The Project Board, as already mentioned is the main decision-making body on a project. It approves Project Plans and Stage Plans, commits the resources and gives direction to the Project Manager role. In turn, it communicates and reports to corporate or programme management. It’s important for you to recognize however that the Project Board, even if it is comprised of several individuals is not a democracy. The decisions are ultimately taken by the Executive with advice being given from both the Senior User and Senior Supplier roles ^[27]. This role does not exist in the PMBOK^® Guide.

Executive

The Executive represents the business interest on a project and is the most important role in PRINCE2. This is because it takes the main decisions about the project. The Executive delegates the day to day management of a stage to the project manager via tolerances. The Executive is responsible for providing the money to the project. In this way the Executive is analogous to the project sponsor role in the PMBOK^® Guide.

Senior User

The Senior User role represents the interests of users. These are either the people from the customer organization who are going to use the specialist products of the project to realize benefits, or will operate, support or maintain them in their operational lifetime ^[28]. It’s easy to see therefore that a business’s IT department will often be users on a project, providing they are operating, supporting or maintaining the IT system being delivered from the project. In PRINCE2 users play an important role in defining requirements and also in testing products (deliverables) against those requirements. This role does not exist in the PMBOK^® Guide.

Senior Supplier

PRINCE2 assumes the project is taking place within a ‘customer-supplier’ environment ^[29]. This means that the customer (users) specifies the needs of the project, pays for it, and expects to get a return on its investment (benefits). The supplier on the other hand is a person, group or organization which delivers the specialist products which have been specified by the customer. Suppliers can be part of the customer organization (for example your IT department at work) or they may be from a different organization if the work is being outsourced. This role does not exist in the PMBOK^® Guide.

Project Manager

This role in PRINCE2 performs the day to day management of the project and also will create and update most of the 26 management products. In the PMBOK^® Guide, the project manager is assumed to have more authority than in PRINCE2 because in PRINCE2 the Project Board has overall authority ^[30].

Project Assurance

This is another role which is not defined in the PMBOK^® Guide. Whilst the PMBOK^® Guide discusses project governance ^[31], unlike PRINCE2 this isn’t defined as a specific project management team responsibility. In PRINCE2 the Project Assurance role is all about project governance. According to PRINCE2, when the Project Board needs to take major decisions, it needs to be assured (independently of the project manager) that the project is being managed properly, and that the quality of the products is as it should be ^[32]. In PRINCE2, each of the 3 Project Board roles has its own responsibilities for performing Project Assurance. On a small project this is likely to be performed by the individual Project Board members themselves, but on bigger projects is likely to be delegated to others. The key thing about this role is that it must be independent of the project manager.

Project Support

The Project Support role is responsible for filing, configuration management, administrative tasks, and giving assistance with the use of tools. In PRINCE2 this role may be performed by the project manager or it could be delegated to others. In the latter case the assumption is that they come from a project management office (PMO) ^[33]. The PMO role is also defined in the PMBOK^® Guide.

Team Manager

The Team Manager role in PRINCE2 works for the supplier organization, and report to the project manager. They also report to the Senior Supplier on the supplier’s (seller’s in the PMBOK^® Guide) line management hierarchy. This role manages the people doing the specialist work and deliver the specialist products to the project on behalf of the supplier ^[34]. The PMBOK^® Guide does not define this role. Instead, it describes the need for the project manager to assemble, acquire and lead teams. This is covered by the Human Resource management knowledge area ^[35].

Change Authority

The Change Authority role means those individuals who take decisions about requests for change. This role will be performed by users and possibly people from the business side. Suppliers are likely to take part in discussions about changes, by providing forecasts for the effort, time and costs involved. By default in PRINCE2, the Project Board performs this role although it can delegate it if it becomes too much work ^[36]. This role equates to the Change Control Board (CCB) in the PMBOK^® Guide. Overall then, PRINCE2 defines 9 different roles on the project management team, compared with just 2 in the PMBOK^® Guide. One of these (the sponsor) however is only given a cursory description in the PMBOK^® Guide. In PRINCE2 the various roles come with detailed descriptions of their responsibilities, even to the level whereby it states which role is responsible for creating, reviewing, or approving management products. These responsibilities do not exist in the PMBOK^® Guide.

Management products and outputs

It’s possible to think of each of the activities in PRINCE2, and each of the processes in the PMBOK^® Guide as black boxes. If you were to perform one of them, you would require one or more inputs, which are then used in some way(s) to create one or more outputs. PRINCE2 refers to these outputs as ‘management products’ and there are 26 of them in PRINCE2. Don’t confuse management products in PRINCE2 with document templates. PRINCE2 does not specify their format and it is left up to you to decide the format depending upon the needs of your project (remember the ‘tailoring’ principle earlier). It does however make suggestions in the form of some outlines, but it is for you to decide whether these are suitable for your project. A report in PRINCE2 could just as easily be created as a Microsoft Word document or PowerPoint presentation or as an email. It could be printed, electronic or written on a whiteboard. It’s worth spending a few moments to discuss something which isn’t one of the 26 management products defined in PRINCE2 – and that’s a project mandate. A project mandate in PRINCE2 is a pre-requisite for performing the PRINCE2 process model ^[37]. In other words if you don’t have a project mandate then you don’t perform any of the processes. The project mandate could be anything including a conversation by the coffee machine, a phone call, a document, a management decision. Essentially it needs to describe why we should do the project and who should perform the Executive role. The closest thing which this maps to in the PMBOK^® Guide is the project statement of work which is one of the main inputs when developing the project charter.

Processes

Let’s now take a look at the 7 PRINCE2 processes and try to understand in a bit more detail how they map to the 5 Process Groups in the PMBOK^® Guide. We will start with the first process in PRINCE2 which is called Starting Up a Project.

Starting Up a Project

This is the first process to be performed in PRINCE2 and maps pretty well to the PMBOK® Guide’s Initiating Process Group. This is easiest to see if you look at the activities performed within Starting Up a Project:

1. Appoint the Executive and Project Manager
2. Capture previous lessons
3. Design and appoint the project management team
4. Prepare the outline Business Case
5. Select the project approach and assemble the Project Brief
6. Plan the initiation stage

The names of the activities have been well thought through. You can guess what happens in each one just by reading the names. In other words the names accurately reflect what actually takes place in each of them. The main output (management product) from the process is a Project Brief. This forms a high level (i.e. brief) overview of the project and answers some key questions such as: “Why we are doing it? Who will be involved? What will be delivered? How will it be delivered?” The answers to each of these questions are developed inside the activities. For example, “who will be involved?” is answered by the first and third activities in the list. “Why we are doing the project?” is answered by the 4th activity which is also where the Project Product Description is developed. Remember from our earlier discussion, the Project Product Description is where the customer’s quality expectations and acceptance criteria are documented. The Project Brief itself equates very nicely with the PMBOK^® Guide’s project charter which is the main output of the Initiating Process Group ^[38]. Many of the sections in a Project Brief can also be found in a project charter, albeit with slightly different names. The Project Brief also incorporates lessons learned from previous projects. Lessons learned are one of the inputs into the Develop Project Charter process in the PMBOK^® Guide ^[39]. The second main output from the Starting Up a Project process is a Stage Plan for the initiation stage. This plan covers all the work (essentially much more detailed planning work) to be performed in the first stage of the project. As you will see later, the work involved in a PRINCE2 initiation stage equates very closely to the work which is performed in the PMBOK^® Guide’s Planning Process Group. However, there is an important differences between the Starting Up a Project process in PRINCE2 and the Initiating Process Group in the PMBOK^® Guide’s. The PMBOK^® Guide’s Initiating processes may be performed for each phase of the project, and not just at the beginning of the project. In this case the Initiating Process Group is involved in “obtaining authorization to start the project or phase” ^[40]. Obtaining authorization to ‘start’ a project or stage is something which occurs in PRINCE2 at the end of the Starting Up a Project process. It is then subsequently re-requested at the end of each management stage. This means that Starting Up a Project in PRINCE2 is only performed once, whereas the Initiating Process Group may be performed multiple times - once for every phase. For PRINCE2 the actual authorization of the project or a stage is given by another process (Directing a Project) and is the responsibility of the Project Board. It is the same process where the Project Brief, the Project Plan, Stage Plans and the Project Initiation Documentation (PID) (more later) are approved. The outline Business Case which is incorporated into the Project Brief in PRINCE2 and is later refined into a more detailed version as part of the PID is a key input into the decisions taken by the Project Board in (Directing a Project). Finally, there’s one thing which also makes the Starting Up a Project process in PRINCE2 very similar to the Initiating Process Group in the PMBOK^® Guide. That is that the Project Brief in PRINCE2 may be given to the project by corporate or programme management ^[41]. Therefore the work which is normally performed in Starting Up a Project has already been performed at a higher level, such as by a Programme Manager if the project is part of a programme. In this case, the project manager simply needs to create the initiation Stage Plan. The way in which this is similar to the PMBOK^® Guide is that the Initiating Process Group may be performed at the “organizational, program, or portfolio level and therefore, would be outside of the project’s level of control” ^[42]. The PMBOK^® Guide then goes on to say the process of evaluating alternatives, feasibility and project objectives, and understanding the reasons why this option is the best, the high level requirements, scope and deliverables can all be conducted by this higher level. The content therefore of a project charter is provided to the project in the same way that the Project Brief is provided on a PRINCE2 project.

Directing a Project

Whereas the PRINCE2 Starting Up a Project process equates well with the PMBOK^® Guide’s Initiating Process Group, PRINCE2’s Directing a Project process doesn’t clearly equate to any of the Process Groups in the PMBOK^® Guide. It does however share one common attribute with the Initiating Process Group. As we have said earlier, the PMBOK^® Guide doesn’t really describe in much detail the involvement of the project sponsor. It is assumed, that after being given authority from the project charter, the project manager takes decisions. There is very little actual guidance given on the types of decisions which the sponsor is expected to make on a project however. Nor is there guidance in the PMBOK^® Guide about which project management documents the sponsor is expected to review and/or approve. This contrasts sharply with PRINCE2. In PRINCE2 the most important decisions on a project are taken by the Project Board (ultimately the Executive role). All of the decisions of the Project Board are taken within the Directing a Project process. PRINCE2 spells out clearly which management products the Project Board need to review and approve as part of the decision-making on the project. In the PMBOK^® Guide, the project manager is given authority by the sponsor within the Initiating Process Group ^[43]. In PRINCE2, this occurs within Directing a Project.

Initiating a Project

This process in PRINCE2 equates to the Planning Process Group in the PMBOK^® Guide. The main output from the process in PRINCE2 is a Project Initiation Documentation (PID). The purpose is to "establish solid foundations for the project, enabling the organization to understand the work that needs to be done to deliver the project’s products before committing to a significant spend" ^[44]. The PID itself documents the project’s reasons, benefits, costs, time, risks, scope, the products (deliverables), stakeholder management, the people who will take decisions, and how quality, scope, time, cost, risks, issues will be monitored and controlled. The key benefit of the Planning Process Group in the PMBOK^® Guide is to “delineate the strategy and tactics as well as the course of action or path to successfully complete the project or phase” ^[45]. It goes on to say that “the project management plan and project documents developed as outputs from the Planning Process Group will explore all aspects of the scope, time, cost, quality, communications, human resources, risks, procurements and stakeholder engagement” ^[46] As you can see from the diagram, PRINCE2’s PID contains several other baseline management products including the Risk Management Strategy, Quality Management Strategy, Configuration Management Strategy, Communication Management Strategy, Project Plan and Business Case. Most of these map easily to the deliverables recommended by the PMBOK^® Guide as outputs from the Planning Process Group. It’s worth discussing some of these things now in a bit more detail. The PMBOK^® Guide’s scope, schedule, cost and requirements management plans are covered in PRINCE2 by the Configuration Management Strategy. The three baselines in the project management plan map to the baseline Project Plan in PRINCE2 which is updated at the end of every stage. One key output from PRINCE2’s Initiating a Project process is the Benefits Review Plan ^[47]. As the name implies, this is a plan for measuring the achievement of benefits from a project. It has a life beyond the project lifecycle because for most projects, most benefits aren’t actually realized until after the project’s products’ have been handed over to users at the end of the project. In PRINCE2, the Initiating a Project process is performed once during a project – in fact it happens during the first management stage, also known as the initiation stage. However, the main output (the PID) gets updated at the end of every stage but this is done by another process – Managing a Stage Boundary. It’s in this process where updates to the project’s scope, cost and time baselines subsequently take place, prior to the end stage “go/no-go” decisions taken by the Project Board. In the PMBOK^® Guide, updates to the project management plan take place iteratively, as it is progressively elaborated. The PMBOK^® Guide’s concept of “progressive elaboration” is a very useful one. It’s where a plan gets continuously improved and detailed as more accurate estimates become available. This allows the project management team to define work and to manage it to a greater level of detail as the project evolves ^[48]. This concept is not unlike the concept in PRINCE2 of “levels of plan” whereby each level of the project management team has different needs for monitoring and control purposes. This means that the Project Board uses a high level Project Plan, the project manager uses a more detailed Stage Plan, and a Team Manager uses an even more detailed Team Plan. The lower the level of plan, the greater the detail and the shorter the timescale. Conversely, the higher the plan the longer in timescale but lesser in detail ^[49]. The baseline Project Plan containing the baseline scope, time and cost for the project is therefore updated at the end of each stage in PRINCE2. This ensures that before a ‘go/no-go’ decision is taken at the end of a stage, there is a full understanding of the scope, time and costs required to complete the project.

Controlling a Stage

In PRINCE2 the Controlling a Stage process involves the day to day management of the project by the project manager. It covers assigning and monitoring the work done by teams, managing issues and risks, reporting progress to the Project Board and taking corrective action. In this regard, it covers many of the same elements which are described in both the Executing and Monitoring and Controlling Process Groups.

Managing Product Delivery

In PRINCE2, the Controlling a Stage process runs in parallel with the Managing Product Delivery process, which is performed by a Team Manager working for the supplier organization. (Remember, in PRINCE2 the supplier organization may be the same organization as the customer. This is the case where the work is being done in-house.) In the Managing Product Delivery process, a Team Manager develops a Team Plan and manages the work done by their team members, the products get built, quality-controlled and handed over to the customer. This process therefore covers much of the work described in the Executing Process Group, but also some of the work described within the Planning Process Group in the PMBOK^® Guide.

Managing a Stage Boundary

In PRINCE2 this process is performed at the end of every stage except the final stage. It is where the project manager develops a new Stage Plan for the subsequent stage, updates the Business Case, Project Plan and PID, creates a Lessons Report and prepares an End Stage Report for review by the Project Board. In this regard, this process equates mostly with the Planning Process Group in the PMBOK^® Guide. This is especially the case when we consider that the main output of the Planning Process Group (the Project Management Plan) equates nicely with PRINCE2’s PID. During this process a Lessons Report is written which documents the lessons learned during the stage which is about to close. This also closely resembles what happens in the Close Project or Phase process in the PMBOK^® Guide. So, this process also overlaps with the PMBOK^® Guide’s Closing Process Group.

Closing a Project

In PRINCE2 this process occurs at the end of the project, irrespective of whether the project has come to the end of its final stage as planned, or has been prematurely closed. In both cases, the process is designed so that there is a formal close to the project, to avoid a situation whereby there is a long slow drift into operational use of the project’s deliverables ^[50]. It is clear to see how this process maps closely to the Closing Process Group in the PMBOK^® Guide. Much of the work is the same, such as documenting lessons learned, evaluating the project (or phase), and archiving all project documentation. In PRINCE2 this process requires confirming “acceptance of the project product” [51] whereas in the PMBOK^® Guide, the Closing Process Group may require gaining the acceptance of the customer or sponsor in order to formally close the project or phase ^[52].

Summary

In this article we’ve tried to look at some of the key differences and similarities between the PMBOK^® Guide and PRINCE2. Hopefully, if you already hold one of the PMI credentials (PMP or CAPM), then this article might have piqued your interest sufficiently in PRINCE2 to take the plunge to become certified.In another article, I will compare the PMBOK^® Guide and PRINCE2 and discuss the strengths and weaknesses of each. That way, practitioners are able to make a more informed choice about how they can use each of them to help bring about more successful results on their projects.