Pin Me

Best of Both Worlds: The Marriage of PRINCE2 and PMBoK

written by: Ray Ahern • edited by: Michele McDonough • updated: 12/31/2014

Oh dear, perhaps it’s the grumpy old man coming out in me again. But here I sit, all flustered and hot under the collar, wondering just how many times I have to read and hear vigorous, heart-felt comparisons of PRINCE2 and PMBoK -- and a number of other supposed project management methodologies.

  • slide 1 of 6

    Another Day at Two Churches

    Instead of choosing between the two methodologies, use the best parts of PRINCE2 and PMBoK. It’s as if I have to choose between being a good person or being spiritually sound.

    Here’s the background: I just stepped out of a high tension meeting between two Gen Y project management method evangelists who both wanted to sell me their version of project management religion. Little did one of them realize I’ve been a member, perhaps even an elder, of both churches. It was tedious discussion in the extreme and I think they failed to get why I kept banging my head on the conference room table.

    Now let’s get this clear, neither PRINCE2 nor PMBoK demand that you take a set of instructions out of the box and implement them verbatim and in absolute exclusion of all others. Neither approach includes anything resembling the 1st Commandment here (for the non-Christian amongst us, that’s the "exclusivity clause" in more Gen Y speak).

  • slide 2 of 6

    A Marriage of Ideologies

    In fact, both PMBoK and PRINCE2 demand that you tailor usage to suit your organization. PRINCE2 certainly acknowledges that it does not cover everything you’ll ever need to know or do when you’re running a project.

    In my humble opinion – and all who know me will assert to my humility, at risk of copping a lecture about how my humility is my greatest asset... Um, anyway, in my humble opinion, PMBoK and PRINCE2 have complementary strengths.

    Therefore, it only makes sense that, if one is to establish a project management methodology for an organization, then we should look to harvest the strengths of both approaches. It’s equally important that we don’t lose the intent of either.

    Do you, PMBoK, promise to love and respect PRINCE2 as long as you both shall live?

  • slide 3 of 6

    The Prenuptial Agreement

    Before we try to help these two young lovers live together in harmony, it's important we understand their relative strengths, and also the type of housework they won't do!

    PMBoK is strongest as a repository of knowledge, particularly of techniques and practices that can be applied to a wide variety of project situations. It is, after all, a "body of knowledge." I don’t like to say it’s a weak point, but PMBoK does not make a strong attempt to dictate the flow of processes, nor does it spell out detailed roles and responsibilities for many of the stakeholders in a project.

    Now, PRINCE2 on the other hand has a strong, but flexible, set of processes that actually work. Most of the process steps relate in some way to items that can be found in PMBoK somewhere. There isn’t that much new about the ideas. That said, PRINCE2 is strongest in the way it deals with benefits management and stakeholder relationships … again, that’s just my humble opinion. I’m also a huge fan of PRINCE2 product descriptions.

    So here’s a natural thing to do. If PRINCE2 has a strong process model and project lifecycle, why not set your project up based on that lifecycle? Indeed there are several gems in that process model that tend to make me get all evangelistic.

    PRINCE2’s concept of separating "Start Up" from "Initiation", for example, is one of the Angel Choruses from my early project management days. All that this amounts to is having everyone agree on the basics of the project before we waste mind-numbing and expensive months planning out delivery for the wrong project. It is so blindingly obvious but something I needed PRINCE2 to tell me (and my executives) before its importance sank in.

    In the diagram below, I show the outline of a simplified representation of a model I've now used successfully for a number of clients. The Execution Phase (and sometimes other phases such as Planning) can be divided into PRINCE2 Stages and, obviously, detail is needed for each organization.

  • slide 4 of 6

    The Seating Plan for the Wedding

    Integrated Project Management Model
  • slide 5 of 6

    A Workable Agreement

    When we move to blending the two methods, we need to lay out an agreed project lifecycle. This needs to work for the organization, so it may vary from place to place. For my recent clients, I have tended to add a couple of "phases" to the PRINCE2 lifecycle; one at the beginning called the Concept Phase and one after the project closes called the Benefits Realization Phase. In laying out that lifecycle, you can use any language you like for the phase names. The arguments one can have over whether to use PRINCE2’s "Start Up and Initiation" or the PMBoK alternative "Initiation and Planning" is just too tedious to bother with, make a decision and run with it!

    I’ve said before that as a body of knowledge, PMBoK is substantial and essential. PRINCE2 also contains some fantastic advice on how to approach some critical problems that can be found in projects. So, now that you’ve laid out a broad lifecycle, you can arrange the PMBoK and PRINCE2 processes below as things to read and broadly follow. Seriously, I’ve seen a lot of people try, but the flow between various processes within each phase is not all that important to enforce. The logical dependencies between products will typically lead most intelligent people to an iterative approach to development and that flow will vary slightly for every project.

    Now speaking of products, I must say I tend to like the way PRINCE2 describes its artifacts, so I tend to base my products around the PRINCE2 product descriptions. That is where PRINCE2 and PMBoK products are similar; I tend to favor the PRINCE2 variant. However, where PMBoK suggests a product such as a Procurement Plan, you should include that and, I would suggest, describe it in the PRINCE2 style.

  • slide 6 of 6

    Getting to Know the In-Laws

    Of course, nothing can ruin a marriage faster than interference from outside parties. If our young lovers are to survive marriage, then we need to build a suitable approach to dealing with outsiders.

    So that makes this next opinion not so humble. This is mandatory. If you’re setting up a project management approach in an organization, it is essential that you put all of the other corporate requirements into the project context. That is, you shouldn’t try to repeat all of those finance, legal and safety requirements (for example), you reference them. This leaves accountability with the subject matter experts and helps to ensure there is only one source of each "truth." Failing to do this will mean each of your "in-laws" will want to tell you how to run projects. By adopting this approach, we can say to the finance people, for example, "Hey, you run the books, we'll run the projects."

References

  • In this article I refer to the following two manuals and draw on my own experience in implementing their contents.

    OGC (Office of Government Commerce) (2009). Managing Successful Projects with PRINCE2 (2009 ed.). TSO (The Stationery Office) -ISBN 9780113310593

    PMI (Project Management Institute) (2008). A Guide to the Project Management Body of Knowledge (Fourth Edition). PMI - ISBN 9781933890517

    Both of these are essential reading for any budding project manager!