Published here July 2006.

Musings Index

PMBOK® Guide 2004 and PRINCE2™ 2005 Compared

This month we have published an important Guest paper. Written by Colin Bentley, a principal author of the UK's project management methodology, PRINCE2, the paper draws A Comparison of Project Management Methodologies: Managing Successful Projects with PRINCE2™ 2005 Edition and The PMBOK® Guide 2004 Edition. As many readers already know, The US Project Management Institute's ("PMI") publication: A Guide to the Project Management Body of Knowledge, also known as the PMBOK® Guide ("The Guide"), is PMI's view of that knowledge of project management that is "generally accepted".

As such, The Guide is a descriptive document. In contrast, the UK Office of Government Commerce's ("OGC") document has been deliberately written as a project management methodology and is therefore a prescriptive document. PRINCE2 has not only been established as the standard for project management in the UK but is the document of choice in Europe and countries that do business with the European Union.

Because one is descriptive and the other is prescriptive, the two documents are not strictly comparable. Nevertheless, they have much in common since they both deal with the details of managing a project.

We should also add that in the case of PRINCE2, this document must be read in conjunction with its companion publication, Managing Successful Programmes (MSP), to complete the link from project management back to the sponsoring organization's corporate strategy. As we viewed this paper, we could not help but have some thoughts of our own on where all this is leading.

In his Introduction, Colin states that:

"The treatment of project organization is very different in the two approaches. The Guide places projects in a larger program environment and includes the concept of a Project Management Office (PMO). However, it is difficult to see a clear project organization structure or understand the relationship between the project manager, the PMO and senior management. In fact, the composition of the PMO is rather shadowy, being a mixture of management higher than the project manager, a pool of project managers and project support, and having responsibility for staff allocation. Another major difference is the apparent or potential exclusion of the project manager from the work to define the project charter (Project Initiation Document in PRINCE2 terms)."

We are inclined to agree and in our view, unlike PRINCE2, The Guide is very weak in this area. Specifically, the Foreword to PRINCE2 states: "The focus throughout PRINCE2 is on the Business Case, which describes the rationale and business justification for the project. The Business Case drives all the project management processes, from initial project set-up through to successful finish."[1]

In contrast, The Guide makes one mention of the Business Case as an input to the Project Charter.[2] It also makes one reference to business plan but that is in relation to a product life cycle.[3]

Later Colin observes that:

"The Guide's concept of the PMO seems to be a combination of Program Coordination, PSO and a managerial level on the lines of the independent reviewers at a 'gate review' or 'end stage assessment'."[4]

We suspect that the author/committees of the two documents likely come from different backgrounds. In the case of The Guide, the majority of contributors are probably from the IS/IT, business administration and/or R&D sectors where the experience is in a large number of relatively small "hi-tech" projects. In this arena, project portfolio management, typically under some "project office" label, is an emerging requirement, but is not yet well or consistently established or even understood. There is consequently some ambiguity in The Guide over the responsibilities of a PMO. The background of PRINCE2, on the other hand, probably comes from experience in major investment projects, including building and engineering construction.

On The Guide's infamous Chapter 3's attempt to describe the Project Management Processes for a Project,[5] Colin has this to say:

In The Guide the processes start with a Statement of Work and Contract from the Sponsor, but in real life there is very often too little information in this statement (Project Mandate in PRINCE2 terms) to be sure that you are making a start in the right direction. And certainly one would have to ask how a contract could have been made - and by whom - when the project has not yet started. Clearly there is a large amount of critical work to be done before The Guide process model begins. There is also no mention in The Guide's process diagram of how and when the project management team is appointed. Strangely, in The Guide's process diagram there is no mention of risk detection or quality planning either, though one assumes that some work is going on in these areas from entries elsewhere such as "implemented corrective actions", "defect repair" and "implemented preventive actions".

There can be little argument that The Guide's Chapter 3, touted as "The Standard for Project Management of a Project"[6] is not clear, complete nor practical. Even the included flow diagrams and the inputs and outputs with redundancies need serious reworking as we've highlighted elsewhere,[7] to say nothing of the lack of identification of the various classes of processes and their confusing labels. That said, however, the PRINCE2 processes and components relationships are not so easy to grasp either. And, aside from process complexity that some would argue is inherent in project management at the best of times, there appears to be duplication or overlap in the number of process documents that we think could be simplified. In both documents we have to ask: Is all this complexity really necessary and justifiable?

In our view, both The Guide and PRINCE2 have room for improvement, and that improvement is at a high level, i.e. in the basic philosophy of the documents rather than in the details. With this in mind, we see two major issues: typology and hierarchy.

Projects are different by definition but they can be grouped into various types. Those types are not based on the industries from which they originated - a distinction that is quite meaningless from the perspective of project management - but on how they should be managed, the subject of the two documents. Therefore, the first point of departure should be a robust project typology and a statement as to which type, or types, of project each document is addressing.

Certainly there are commonalities in how projects should be managed, but only in concept at some high level as an over arching, idealized methodology. One that clearly runs forward from beginning to end with essential milestone control points along the way. Just like in real life. It therefore comes as a disappointment that whereas the 2002 version of PRINCE2 spoke of a project's "life span", it now speaks of "life cycle"[8]. This is a retrograde step indeed! On the plus side, we were pleased to see that PRINCE2 recognizes the difference between managing the project and managing the technology. For, as Colin says: "PRINCE2 concentrates on the concept of [project] management stages being different from technical [management] stages ..."[9]

Both documents speak of the need to tailor the information presented to suit the individual project needs. But these vague statements are hardly enough for those seeking specific guidance. What is needed is a hierarchy, perhaps something like a work breakdown structure that responds to size and content. This might even emulate the true professions where students start off with some general course knowledge and progressively specialize, pursuing their specific interests as they move up the ladder to full professional practice.[10]

In fact, we have long since suggested simple solutions to both the typology and the hierarchy challenges.[11] One wonders why generic documents like The Guide and PRINCE2 are unable to embrace such simple concepts, concepts that provide basic foundations that can be built upon to suit various project conditions. But one suspects that there are two obstacles to this simple view.

Average academics don't like simplicity because it appears to undermine their worth. Consensus-by-committee is incapable of embracing simplicity because consensus means satisfying everyone. After all, who cares if the committee-developed camel has more than one hump? The more humps there are, the more seats there are to sit on, and the more backrests to rest on!

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page