In 2014, the PRINCE2 accreditation body, AXELOS, relaxed its pre-requisites for taking the PRINCE2 Practitioner exam. Nowadays, if you hold one of the 2 PMI® qualifications (PMP or CAPM) you can take the PRINCE2 Practitioner exam without having PRINCE2 Foundation certification. Read this article for in-depth information about PRINCE2 if you are aPMP or CAPM certificate holder. Essential if you want to gain PRINCE2 Practitioner certification and are wondering how PRINCE2 differs to the PMI method.PRINCE2 Practitioner exam without having to sit the PRINCE2 Foundation exam beforehand. Previously you would have needed to sit the PRINCE2 Foundation exam prior to sitting the higher PRINCE2 Practitioner exam. This means that if you are a PMP or CAPM credential holder you now have a potentially fast-track route to gaining your PRINCE2 certification.This article is useful if you already hold either the PMP or CAPM credentials and are considering taking the PRINCE2 Practitioner examination to add to your professional qualifications. It therefore assumes that you already have a good level of knowledge about the Guide to the Project Management Body of Knowledge (PMBOK®)  (“PMBOK® Guide” is a registered mark of Project Management Institute, Inc.) upon which both the PMP and CAPM examinations are based. However, even if you don’t have such knowledge you might also find the article useful to help you develop an understanding of project management best practices.
PRINCE2 and the PMBOK Guide®If you’re based in the UK, then you’re probably already familiar with PRINCE2 . 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 observationsIf 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 .
Structure of PRINCE2 and the PMBOK® GuideOne 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.
PrinciplesIn PRINCE2, principles are the foundations upon which everything else is based. There are no principles in the PMBOK® Guide.
Themes vs knowledge areasIn 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 GroupsIn 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” . 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.”  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 . 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 . PRINCE2 makes a distinction however between ‘technical stages’ and management stages . 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 principlesThe 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 . The PRINCE2 manual states that these principles are universal and therefore applicable to all projects, irrespective of culture . 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 justificationThis 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 . 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” . 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” . 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 experienceSome 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 responsibilitiesYou’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 . This is covered in the PMBOK® Guide mainly by the Human Resource management knowledge area.
Manage by stagesPRINCE2 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’ . 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 exceptionThere 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 , 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 . 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 . 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 . For PRINCE2, ‘management by exception’ provides a major benefit to the individuals which form the Project Board because it saves their time . 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 productsPRINCE2 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 . 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 . It also describes the scope of the project because it identifies all of the major products to be delivered .
Tailor to the project environmentDon’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” . It goes on to say that such good practice doesn’t mean that this knowledge should always be uniformly applied on all projects  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 rolesOne 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 . 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 BoardThe 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 . This role does not exist in the PMBOK® Guide.
ExecutiveThe 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 UserThe 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 . 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 SupplierPRINCE2 assumes the project is taking place within a ‘customer-supplier’ environment . 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 ManagerThis 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 .
Project AssuranceThis is another role which is not defined in the PMBOK® Guide. Whilst the PMBOK® Guide discusses project governance , 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 . 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 SupportThe 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) . The PMO role is also defined in the PMBOK® Guide.
Team ManagerThe 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 . 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 .
Change AuthorityThe 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 . 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 outputsIt’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 . 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.
ProcessesLet’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 ProjectThis 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:
- Appoint the Executive and Project Manager
- Capture previous lessons
- Design and appoint the project management team
- Prepare the outline Business Case
- Select the project approach and assemble the Project Brief
- Plan the initiation stage