Forward
This article was written as a guide to those project management professionals who want to compare the Guide to the Project Management Body of Knowledge (PMBOK®), otherwise known as the PMBOK® Guide with PRINCE2. It is assumed that most readers will already be familiar with the PMBOK® Guide but not with PRINCE2.
It will focus on the strengths and weaknesses of both. This will help the reader judge which is appropriate for their own needs whether they work as a project manager, project sponsor, or work in a project management office (PMO).
Overview
The Project Management Institute (PMI) brought out its first edition of the PMBOK® Guide in 1996 although it was derived from an earlier work simply known as the ‘Project Management Body of Knowledge’. Since then it has been updated and expanded to reflect recent developments in project management. It’s most recent edition (5th edition) was released in 2013.
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 [1].
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 PRINCE2 manual was also first released by the UK government in 1996, and its most recent 5th edition was released in 2009. 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.
The PMBOK® Guide is often described as descriptive, whereas PRINCE2 is often described as prescriptive. As you will see, the PMBOK® Guide contains lots of descriptions of tools, techniques and processes. It also describes the outputs of each process, but does not try to explain what information might be useful to record in such outputs.
PRINCE2 on the other hand does explain what information might be useful to record in the outputs of its processes, and it also describes who is responsible for recording such things.
The PMBOK® Guide: structure
The PMBOK® Guide structures its guidelines into 47 different processes, which are grouped into 5 categories known as Process Groups. A process is a set of related actions performed to achieve some pre-specified product, service or result [2]. Each process is described in terms of the inputs required, a set of tools and techniques which can be performed and the expected outputs.
The same processes are also grouped into Knowledge Areas. It defines a Knowledge Area as representing a “complete set of concepts, terms and activities that make up a professional field, project management field, or area of specialization” [3]. It’s actually within the Knowledge Areas where the details of each process are described.
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 119 tools and techniques referenced in the PMBOK® Guide.
The PMBOK® Guide also contains a brief summary of the inter-personal skills which are useful for project managers, along with a list of external references for readers wanting to find out more about such skills.
PRINCE2: structure
PRINCE2 is composed of 4 integrated elements: principles, themes, processes and tailoring to suit the needs of the project environment. The 7 principles are the building blocks upon which everything is based. By applying all 7 to your project, your project can be classed as being a PRINCE2 project.
There are 7 themes, 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.
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 closely resemble the processes in the PMBOK® Guide.
Finally, 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.
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.
The 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, its covers the same topics as 6 of the 7 PRINCE2 themes. The only one it doesn’t cover from PRINCE2 is the Business Case (more about this later). It does however cover Procurement management which is not covered at all by PRINCE2.
I’d probably say the main strength of the PMBOK® Guide is that it provides a comprehensive range of useful tools and techniques. In total there are 119 tools and techniques described or referred to. For example, the Time 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 Time management Knowledge Area in the table below. If we take a 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.
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
Whilst I wouldn’t suggest that simply managing the cost aspect of the project is sufficient, their project would nevertheless still benefit from the application of the Earned Value techniques contained within the PMBOK® Guide. The PMBOK® Guide therefore is an extremely useful reference tool for many different aspects of project management.
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 [4].
This contrasts sharply with the PMBOK® Guide which assumes the business case assessment, approval and funding are handled externally to the project’s boundaries. Project boundaries in this case meaning the point at which the start or completion of a project (or project phase) is authorized [5]. The PMBOK® Guide goes on to say that the business case may be periodically reviewed on multi-phase projects to check that the project is on track to deliver the business benefits [6].
The PMBOK® Guide therefore places much less emphasis on the business case compared with PRINCE2. It is easy to see that using the PMBOK® Guide a project could be authorized based upon an approved business case. The project could then deliver the project’s products on time, within budget and according to specification, yet still not deliver anything of value for its customers because insufficient attention was paid to the changing forecasts of the benefits to be expected. This is especially likely to be the case the longer the project takes.
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 [7] 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.
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 particular needs of your project, but all the defined responsibilities must be allocated to someone.
These roles in PRINCE2 are divided up into 3 levels. The bottom level is represented by the Team Manager role, the middle level by the Project Manager, and the highest 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 to complete the project management team include Project Support, Change Authority and Project Assurance roles.
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.
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.
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.
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.
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 is 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.
The next process is known as Initiating a Project. It 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) which is not dissimilar to the project management plan in the PMBOK® Guide. It contains strategies for managing issues, changes, risks, communications and configuration management, along with the controls for the project, the Project Plan and detailed Business Case. The PID contains everything required for the Project Board to decide whether to authorize the project.
Before moving to the next stage however, the Managing a Stage Boundary process is performed. This is performed at the end of every stage except the final stage and it 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.
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.
At the same time, 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, 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 akin to the Executing and Monitoring & Controlling Process Groups in the PMBOK® Guide.
At the end of the stage the Managing a Stage Boundary process is performed again to update the Business Case and Project Plan and to write the End Stage Report. These become inputs into the Project Board’s ‘go/no-go’ decision.
If it’s the final stage, then 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 Review Plan.
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® Guidee 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.
The PMBOK® Guide: weaknesses
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 [8].
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.
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.
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 at all to many common, modern project team structures composed of virtual teams working in different time zones and languages.
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 [9].
Summary
A worker doing any skilled trade always requires a number of tools in their tool bag. 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.
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.
However, if you want a whole 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.
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.
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.
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. I therefore recommend using PRINCE2 as your project management methodology due to its relative simplicity and applicability to all projects.
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” [10]. On that point I would wholeheartedly agree.
References
[1] PMBOK® Guide, p418
[2] PMBOK® Guide, p47
[3] PMBOK® Guide, p60
[4] PRINCE2, pp22-28
[5] PMBOK® Guide, p54
[6] PMBOK® Guide, p69
[7] PRINCE2, pp269-275
[8] PMBOK® Guide, p555
[9] PRINCE2, p9
[10] PMBOK® Guide, p2
“PMP” is a registered mark of Project Management Institute, Inc.
“PMBOK® Guide” is a registered mark of Project Management Institute, Inc.
PRINCE2® is a registered trade mark of AXELOS Limited.