PRINCE2 vs the PMBOK Guide: A comparison

Background

Project management today is an ever-growing profession. According to the American-based Project Management Institute (PMI)^® between 2017 and 2017, over 20 million new project management roles will be created globally across seven project-intensive industries ^[3].As the competition associated with globalization increases, more organizations are becoming projectized. This is happening as organizations seek to become more efficient - 'to do more with less' - and to bring new products to market quickly and cheaply. This is a phenomenon affecting both private and public sector organizations, especially those whose governments have chosen 'austerity' as their preferred approach to overcoming economic problems.These organizations therefore perceive clear advantages to helping them achieve their objectives if they apply project management best practices too help them deliver their projects both more quickly, within budget and according to specifications.

Best-known publications

The two best known project management publications are the Guide to the Project Management Body of Knowledge (PMBOK^®) 6th Edition, (otherwise known as the PMBOK^® Guide) and Managing Successful Projects with PRINCE2^®. Both publications are claimed to embody best-practices in project management and are often seen as two different variations of the same thing. As this article will explain, this is a false comparison.

PMBOK^® Guide

The PMBOK^® Guide documents a set of standard terminology, knowledge and guidelines for project management. It describes its processes as a standard for project management. This is because the PMI itself was approved by the American National Standards Institute (ANSI) to be a standards developer in 1998 ^[4]. Now in its 6th edition, the PMBOK® Guide comes in at a weighty 756 pages.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.The PMBOK^® Guide is often described as descriptive. That means it describes project management techniques, the inputs and outputs to processes, and knowledge areas, but it does not describe how they should be used.

PRINCE2

The PRINCE2 manual was also first released by the UK government in 1996, and its most recent (6th) edition was released in 2017. It was based upon an earlier incarnation known as PRINCE (meaning PRojects IN Controlled Environments). Although initially confined to use within the UK public sector, it has grown to become widely used by both public and private sectors around the world.PRINCE2 is often described as prescriptive - i.e. it describes what should be done, by who and when on a project.

Previous comparisons

Probably the most-widely cited article which compares PRINCE2 with the PMBOK^® Guide is Max Wideman's article written in 2002 ^[5]. However, the article now is considerably out of date because both the PRINCE2 and PMBOK^® Guide publications have each undergone several revisions since then.However, even back in 2002 Wideman astutely observed: "PRINCE2 and the Guide take very different approaches to the presentation of their material. Indeed, they really serve different purposes and are therefore not directly comparable. We believe that the Guide takes the best approach for purposes of teaching the subject content of each knowledge area, but is not so affective when it comes to providing guidance for running a particular project" ^[6].In a 2013 article by Sandra Matosa and Eurico Lopes ^[7] the authors wrongly claim both the PMBOK^® Guide and PRINCE2 to be project management methodologies. This does seem to be a recurring theme amongst practitioners in the project management field but one which will be clarified during this article.

PMBOK® Guide structure

Process Groups

The PMBOK^® Guide structures its guidelines into 49 different processes, which are grouped into 5 categories known as Process Groups. A Process Group is a logical grouping of project management inputs, tools and techniques, and outputs ^[8]. Each process is described in terms of the inputs required, a set of tools and techniques which can be performed and the expected outputs.

Knowledge Areas

The same processes are also grouped into Knowledge Areas. It defines a Knowledge Area as an “identified area of project management defined by its knowledge requirements and described in terms of its component processes, practices, inputs, outputs, tools, and techniques” ^[9]. It’s actually within the Knowledge Areas where the details of each process are described.In the 6th edition, some new sections were added to the Knowledge Area chapters. These explain the key concepts for the topics discussed in the chapter, and trends and emerging practices. This is recognition of the fact that project management is constantly changing with new practices becoming best practices over time. New sections on tailoring and considerations for agile/adaptive environments are also recognition that many projects today utilize agile methods and projects cannot simply be run as they were in the past based upon a waterfall approach.

Tools and techniques

Embedded within the descriptions of the processes are references to, or detailed descriptions of, the tools and techniques which the project manager might find useful during the process. In total there are 132 tools and techniques referenced in the PMBOK^® Guide.

Project manager role

The PMBOK^® Guide also contains a chapter about the role of the project manager. Much of this is based upon the PMI Talent Triangle^®. It places much greater emphasis on softs skills such as leadership ability and business skills, rather than purely technical project management skills.Since the release of the 6th edition, PMI members now get a copy of Agile Practice Guide ^[10] bundled with the PMBOK^® Guide. The Agile Practice Guide was developed with people from the Agile Alliance^®.

PRINCE2 structure

Principles

PRINCE2 is composed of 4 integrated elements: principles, themes, processes and tailoring to suit the needs of the project environment ^[11]. The 7 principles are the building blocks upon which everything is based. Applying all 7 principles to a project is one of the requirements required to cosider a project a 'PRINCE2 project'.

Themes

There are 7 themes in PRINCE2, which are aspects of project management which must be continuously addressed throughout the lifetime of the project. Themes are very much like Knowledge Areas in the PMBOK^® Guide.

Processes

The themes are applied throughout the 7 processes, which describe who is responsible and accountable for what, and when. PRINCE2 processes are similar to Process Groups in the PMBOK^® Guide. Each PRINCE2 process is divided into a number of activities. There are 41 in total. These activities closely resemble the 49 processes in the PMBOK^® Guide.

Tailoring

The PRINCE2 manual provides some guidance on how to tailor the method to different projects, depending on their size, level of risk, complexity and other factors. Each theme and process chapter contains guidance on tailoring in different project situations.

Roles & responsibilities

Appendix C of the PRINCE2manual provides a very detailed set of responsibilities for the 9 different project management team roles.

Checklist

The PRINCE2 manual also contains an appendix providing a checklist which can be used to assess the health of your project, although this is not a part of the method itself.

PRINCE2	PMBOK® Guide
7 principles	None
7 themes	10 Knowledge Areas
7 processes	5 Process Groups
41 activities	49 Processes
40 tools & techniques referenced	132 tools & techniques referenced

PMBOK® Guide strengths

The main thing which strikes you if you read the PMBOK^® Guide is its comprehensive treatment of a range of Knowledge Areas. As you can see from the comparison below, it covers the same topics as all the PRINCE2 themes. It also covers Procurement Management which is not covered at all by PRINCE2.

PMBOK® Guide Knowledge Area	PRINCE2 theme
Project Integration Management	Business case, change, progress
Project Scope Management	Plans, progress
Project Schedule Management	Plans, progress
Project Cost Management	Plans, progress
Project Quality Management	Quality
Project Resource Management	Plans
Project Communications Management	Organization
Project Risk Management	Risk
Project Procurement Management	Not covered
Project Stakeholder Management	Organization

Main strength

The main strength of the PMBOK^® Guide is that it provides a comprehensive range of useful tools and techniques. In total there are 132 tools and techniques described or referred to.For example, the Schedule Management Knowledge Area alone lists 25 different tools and techniques. That compares with only about 40 which are referred to in the whole of the PRINCE2 manual. In this regard, the PMBOK^® Guide can act as a great reference manual for project managers wanting to learn about the many different tools and techniques.You can see the list of tools and techniques which are described for the Schedule Management Knowledge Area in the table below. If we look at just one of these – analytical techniques – we find that it appears in 7 different processes across all 5 Process Groups. In each process, there is a description of how different analytical techniques can be used to help develop the process’s outputs.

Schedule Management Knowledge Area: Tools and techniques
expert judgement	bottom-up estimating
analytical techniques	analagous estimating
meetings	parametric estimating
decomposition	three-point estimating
rolling wave planning	reserve analysis
precedence diagramming method (PDM)	schedule network analysis
dependency determination	critical path method
leads and lags	critical chain method
alternative analysis	resource optimization
published estimating data	schedule compression
project management software	scheduling tool
group-decision-making	modeling
performance reviews

Many of the tools and techniques are not described in any detail – for example, the Delphi technique warrants only one short paragraph - but the strength of the PMBOK^® Guide is that it describes when it might be useful to use such a technique on a project.A further strength is that the knowledge areas in the PMBOK^® Guide can each be treated in isolation from one another. So, if a project manager requires a better understanding of earned value analysis in order to better manage cost on a project, they could focus on the Cost Management Knowledge Area in the PMBOK^® Guide

PRINCE2 strengths

Business case

Perhaps the single greatest strength of PRINCE2 is its expectation that the major decisions about a project must be based upon a robust business case. This means that a clear understanding of the benefits versus the costs, timescales and risks are required. This understanding is developed prior to the project and is refined in more detail during its initiation stage. It is then maintained and updated on a stage-by-stage basis as revised forecasts for the project become known.This ensures that the project is always seen as a means to an end, rather than an end in itself. PRINCE2 describes explicit responsibilities for developing, maintaining and approving the business case ^[12].Prior to the 6th edition of the PMBOK^® Guide, the business case was only described in a cursory way. Since the 6th edition, the PMBOK^® Guide has taken on board much of the guidance about the business case which has been in PRINCE2 since its inception.In its business case theme, PRINCE2 also describes the importance of measuring the performance of the project’s products in their operational life. This helps the organization understand whether the forecasted benefits are, in fact, being realized. To help the organization plan how to measure and who will measure the benefits after the project closes, a benefits management approach is recommended to be created whilst initiating the project.Similar to how it has adopted much of what PRINCE2 describes in relation to the business case, the 6th edition of the PMBOK^® Guide also has introduced the concept of a Project Benefits Management Plan, very similar to the benefits management approach in PRINCE2.

Project management team roles

A second major strength of PRINCE2 is its detailed and wide-ranging description of multiple project management team roles. Whereas in the PMBOK^® Guide the emphasis is mainly on what the project manager does, in PRINCE2 there is a whole chapter ^[13] providing detailed descriptions of the responsibilities for a total of 9 different project management team roles. The different roles can be seen in the diagram below.

PRINCE2 project management team roles	PMBOK® Guide equivalent
project board	No equivalent
executive	Project Sponsor
senior user	No equivalent
senior supplier	No equivalent
project assurance	No equivalent
project manager	Project Manager
team manager	No equivalent
project support	Project Management Office (PMO)
change authority	Change control board (CCB)

Sharing and combining roles

Some of these roles can be shared i.e. performed by 2 or more individuals, and some of the roles can be combined i.e. one individual can perform 2 or more roles. Whether or not roles are shared and/or combined in PRINCE2 depends upon the needs of your project, but all the defined responsibilities must be allocated to someone.

Levels of management

These roles in PRINCE2 are divided into 3 levels. The bottom (delivering) level is represented by the team manager role, the middle (managing) level by the project manager, and the highest (directing) level by the project board role. The latter role is comprised of 3 separate roles, each representing the major project stakeholders of business, user and supplier.The project board in turn, reports to a 4th higher level known as corporate or programme management, although this latter level is not regarded as being part of the project management team.

Other roles

Other roles to complete the project management team include project support, change authority and project assurance roles.

Customer/supplier environment

PRINCE2 is based upon a simple assumption – that a project is based upon a customer/supplier relationship. This means every project is commissioned and paid for by the customer, who also specify what is required. The supplier delivers what is required within the agreed constraints of cost and time. PRINCE2 doesn’t care if the supplier is internal or external to the customer organization.

Team manager role

The team manager role, which is responsible for delivering products to the project, therefore works for the supplier organization. The project manager, who works for the customer organization, controls the work done by team managers via the use of work packages.

Project manager role

The project manager manages day-to-day within agreed constraints, known as tolerances in PRINCE2. These exist for time, cost, scope, quality, risk and benefits. In addition to controlling the work done by teams, the project manager is also responsible for managing issues and risks, taking corrective action (within tolerance) and reporting progress to the project board.

Project board role

The project board is responsible for approving plans for each stage of the project and also for the project as a whole. PRINCE2 recommends a project is broken up into a minimum of 2 management stages, each one coinciding with a ’go/no-go’ decision. This decision is based upon reviewing and approving an updated business case which outlines the benefits versus the costs, timescales and risks. So long as the project remains a worthwhile investment, the next stage can be authorized. The project board informs corporate management of progress.If a plan or any other project management document or artefact needs approving, PRINCE2 clearly defines the responsibility.

Processes

A third major strength of PRINCE2 are its processes. The first thing to say here is that a process in PRINCE2 is not the same as a process in the PMBOK^® Guide. A PRINCE2 process is more akin to a Process Group in the PMBOK^® Guide and there are 7 of them. The processes are integrated with the 7 PRINCE2 themes to form a methodology which can be used to manage any type of project.You can see from the diagram below the 7 PRINCE2 processes. The diagram also shows which aspects of the process model are covered by the PMBOK^® Guide (essentially just the managing level performed by the project manager). The processes in PRINCE2 cover all 4 management levels.

Starting up a project

The first process, called ‘starting up a project’ is actually done before the project begins and is closely related to the Initiating Process Group in the PMBOK^® Guide.It’s where an understanding is developed of several things: the reasons for doing the project and how the project fits in with any corporate strategies; who will be involved in taking decisions; what will be delivered and how. These things get written into a project brief. The project management team is appointed. A plan for the first (initiation) stage is developed.The project brief and stage plan then go to the project board for approval. If the project sounds like a sensible idea, the project board can approve the project brief and stage plan and proceed to the first (initiation) stage. Otherwise, no further work is done. The decision by the project board to authorize this first stage is taken in the ‘directing a project’ process. It is the only process performed by the project board.

Directing a project

The ‘directing a project’ process does not have an equivalent process group in the PMBOK^® Guide. That’s because ‘directing a project’ is performed by the project board which does not have an equivalent role in PMBOK^® Guide. The main decision-maker on a PRINCE2 project board is the executive role, which equates to the Project Sponsor.In PRINCE2, the project board are responsible for taking the major decisions on the project including approving the project plan and stage plans and committing the required resources, approving the project brief (equivalent to Project Charter) and approving the project initiation documentation (equivalent to Project Management Plan). It is also responsible for taking decisions about escalated issues and risks, and for directing the project manager.The project board ‘manages by exception’ by delegating day-to-day management to the project manager. It does this by setting tolerances for the main project targets of time, cost, scope, quality, benefits and risks. Providing the plan can be achieved within the delegated tolerances, the project manager does not need to defer to the project board for a decision. This therefore is a very efficient use of senior manager’s time because there is no need for regular progress meetings. Instead the project board is kept informed of progress via regular reports.

Initiating a project

The ‘initiating a project’ process is where much more detailed planning work is done and is akin to the Planning Process Group in the PMBOK^® Guide. The main output is the project initiation documentation (PID) (equivalent to the Project Management Plan in the PMBOK^® Guide). It contains management approaches for change control, risk, quality and communications, the project controls, the project plan and detailed business case. The PID contains everything required for the project board to decide whether to authorize the project.

Controlling a stage

Assuming the project and next stage are authorized, the next process to be performed is controlling a stage. This is performed by the project manager who manages issues and risks, manages the work done by teams, reports progress to the project board and takes corrective action within tolerances.

Managing product delivery

At the same time as the project manager is performing the ‘controlling a stage’ process, the team manager performs the ‘managing product delivery’ process. It’s in this process where the deliverables (products) specified by the customer are developed, tested and, where required, are handed over to the customer.The team manager role is employed by the supplier and PRINCE2 does not try to prescribe the detailed steps which are often performed by such suppliers. PRINCE2 describes the project management processes to be performed, not the development processes. This means that the team manager could be managing the development work of his/her team using agile approaches such as Scrum, and this fits in easily with the PRINCE2 model.Both the ‘controlling a stage’ and ‘managing product delivery’ processes taken together are equivalent to the Executing and Monitoring & Controlling Process Groups in the PMBOK^® Guide.

Managing a stage boundary

Before the end of evert stage except the final stage, the Managing a Stage Boundary process is performed. This is where the project manager revises the project plan and business case and writes an end stage report. The first time this process is performed, there won’t be any revisions to the project plan or business case, so it will mainly focus on the report. The outputs of this process are given to the project board for a ‘go/no-go’ decision about whether to proceed to the next stage or not. If the decision is ‘no go’ then the project is prematurely closed.

Closing a project

If it’s the final stage, the project manager performs the ‘closing a project’ process rather than the ‘managing a stage boundary’ process. Closing a project is where products are formally accepted by the customer, lessons are reported, the performance of the project is evaluated, and follow-on actions are documented. The ‘closing a project’ process is akin to the Closing Process Group in the PMBOK^® Guide.The final decision to authorize project closure is for the project board. The newly handed-over products then become part of the operational environment and benefits are now expected to be realized. The measurement of these benefits is covered by a benefits management approach.You can see then from this short summary that PRINCE2 very clearly defines which role is responsible and when. Each process is broken down into several activities (akin to processes in the PMBOK^® Guide), each one stating the outputs expected, which role is responsible and when.I have delivered quite a lot of PRINCE2 training courses in Asia over recent years and many of my students were already familiar with the PMBOK^® Guide. Whenever I have asked them which process model they find easiest to understand and to apply, the answer always has been PRINCE2.The general view after attending a 5-day PMP^® training course was that students were no nearer understanding what they should do on their project when they returned to work the following week than they were before the course. Maybe that’s down to the poor quality of the teaching of the subject matter, but I suspect it is due to the lack of clear responsibilities in the PMBOK® Guide and the confusing and overly-complex nature of the processes defined within it.

Management products

One further strength of PRINCE2 is its definition of its 26 management products. These might be reports, registers, logs and plans which are used by the project management team to help plan, manage and control the project. These management products contain useful project management information that is used when taking decisions on the project.PRINCE2 makes recommendations and gives guidance about what information is useful to include in these management products. This guidance is also closely integrated with the process descriptions in that it is clearly described which member of the project management team is responsible (and when) for creating, updating, reviewing or approving such management products.If desired, the descriptions of the 26 management products can be used as templates for creating these products on projects. However, as one of the 4 integrated elements of PRINCE2 is to tailor the method to suit the needs of the project, care must be taken to ensure that these templates do not get used robotically and thought must be given as to how they can be tailored to suit the needs of a project.

Tailoring

When the most recent version of PRINCE2 was released in 2017, it contained much more practical guidance about tailoring the method to suit the needs of the project. A lot of the guidance was in relation to managing agile projects. This further strengthened PRINCE2 as the project management methodology of choice since it reflected changes which have happened in project management over recent years.

PMBOK® Guide weaknesses

Project management team

One of the weaknesses of the PMBOK^® Guide is the lack of specific responsibilities for the members of the project management team. This is vaguely defined as those members of the project team who are directly involved in project management activities ^[14].We have already seen how in PRINCE2, 9 different project management team roles are defined, each one with a clearly defined list of responsibilities. The trouble with the PMBOK^® Guide’s approach is that many of these responsibilities might be left undone, simply because it is not clearly defined which individual is responsible.

Overly complex

A second weakness is the overly-complex and overly-detailed descriptions of some of the elements. Complexity is always a hindrance not a help and as has just been mentioned above, anecdotal evidence might suggest that the PMBOK^® Guide is doing itself no favours in that regard.One small example is within the section describing the cost management plan where it indicates that the plan might establish the level of precision to be used when rounding up/down activity estimates. In my view this is overly detailed and not important in the grand scheme of things. On the other hand, being a body of knowledge, the authors probably thought that they couldn’t leave it out.

An American standard

Written primarily by North American writers (after all the PMI is a North American institution) the PMBOK^® Guide inevitably is written from a North American perspective and doesn’t always so easily translate to different cultures.Human resources practices often differ between countries and cultures and trying to apply some of the recommendations in the PMBOK^® Guide won’t work so easily outside of its North American home. The reference to the Tuckman ladder which refers to a model used to describe how teams develop through 5 stages is another example. The model itself is very old (1965) and doesn’t transpose to many common, modern project team structures composed of virtual teams working in different time zones and languages. It certainly doesn't transpose itself to modern agile approaches to team self-organization.

PRINCE2 weaknesses

The biggest weakness of PRINCE2 is its lack of tools and techniques. In fact, PRINCE2 describes 2 techniques in a lot of detail: the quality review technique and the product-based planning technique. The latter technique is built into PRINCE2’s activities for developing plans.On the other hand, PRINCE2 states clearly in its introduction chapter that there are many proven planning and control techniques (such as critical path analysis and earned value analysis) which are well documented elsewhere and so do not need repeating in the PRINCE2 manual ^[15].

Summary

A worker doing any skilled trade always requires a range of tools in their tool kit. Project management is no different. As I have tried to explain in this article, there are strengths and weaknesses with both the PMBOK^® Guide and PRINCE2 and project practitioners should learn which tool is best to use in which circumstances. I would summarize these as follows.

Use PMBOK® Guide as a reference

If you want a detailed description of many extremely useful tools and techniques to help you better manage your project, then you should use the PMBOK^® Guide as a reference manual.

Use PRINCE2 as a methodology

However, if you want a project management methodology to help guide the decision-making on your project, then PRINCE2’s relatively simple process model clearly states what project management decisions need to be taken, by whom and when.The 26 management products in PRINCE2 are closely integrated into the process model, providing guidance on what project management information is required to support the decision-making throughout the project.

Business case-driven

One of the key strengths of PRINCE2 is its focus on a business case to drive the decision-making on the project. This helps to ensure that projects do indeed realize the benefits they set out to deliver, so ensuring a return on investment. The ‘go/no-go’ decisions taken as a result of reviewing an updated business case requires the use of management stages. Applying the PRINCE2 process model will assist projects by ensuring that major decisions are driven by having a robust business case.

Easier introduction

The PRINCE2 themes are similar to the PMBOK^® Guide’s Knowledge Areas. They cover much of the same areas. I would say that the PRINCE2 themes are less comprehensive, but on the other hand they are probably simpler to understand than the comparative Knowledge Area in the PMBOK^® Guide.PRINCE2 is probably an easier introduction therefore to learning about project management than the PMBOK^® Guide. Furthermore, because PRINCE2 is principles-based, it can be condensed down essentially to the 7 core principles, which again is an aid to understanding for people new to project management.

Comprehensive team roles

For defining a detailed list of responsibilities for a broad range of project management roles PRINCE2 is again the preferred choice simply because the PMBOK^® Guide doesn’t define most of these roles. By defining these responsibilities for a broad range of project management roles, it is more likely that the right decisions are taken by the right people throughout the project.As we noted earlier, PRINCE2 is composed of 4 integrated elements: principles, themes, processes and tailoring. It forms a comprehensive methodology which can easily be applied on any project, of any scale and type.Finally, the challenges involved in managing modern projects are many. There are lots of books and methodologies available to assist and this article has focused on just 2 of these: the PMBOK^® Guide and PRINCE2.Even the PMBOK^® Guide says in one of its earliest pages: “this standard is a guide rather than a specific methodology. One can use different methodologies and tools (e.g. agile, waterfall, PRINCE2) to implement the project management framework” ^[16]. On that point I would wholeheartedly agree.