OK, Maybe Prince2 Sucks Less Than I Thought

Yesterday I did a Scrum presentation for a group of Minions of The Dark Side: people from the Dutch PRINCE2 User Group. I had expected them to have horns, hooves and pointy teeth. But my perception turned out to be false. (Though it must be said that one guy wore large boots, so I'm not sure about the hooves.)

PRINCE2 can be described as some sort of a European interpretation of the PMBoK: a somewhat heavy collection of best practices for professional project managers. I'm quite certain that I am offending both PRINCE2 and PMBoK people with that description. It's like throwing Agile and Lean in the same corner. Neither the agilists nor the leanists would agree with that, though both camps would agree that PRINCE2 and PMBoK are in a corner at the other end of the world. It's like America and Canada versus China and Japan. They are all different, but some are neighbors and others are not.

I had invited the PRINCE2 people to talk about how SCRUM differs from PRINCE2, and what both frameworks could borrow from each other. I had at least six strong Scrum Masters and Product Owners as potential body guards with me, but that turned out to be unnecessary. In fact, we all had a very inspiring evening together with our guests! Let me summarize it for you:

These are often mentioned problems with PRINCE2/PMBoK in software development projects:

  • Resistance to changes in scope
  • Counterproductive devotion to a plan
  • Overemphasis on task-based planning
  • Imposing project manager
  • Excessive documentation

In our discussions we agreed that these problems are symptoms of incorrectly applying the framework and its principles. Well, doesn't that sound familiar? Agile software development has the same problem with people incorrectly applying the principles (or not at all), and doing Agile In Name Only (AINO). So we found some common ground there, agreeing that our favorite frameworks both get a bad name because other people make a mess of things. (Not we ourselves of course.)

On the other hand, most of us could agree that Scrum does a better job at explaining itself to its users. If you open the official PRINCE2 documentation, the first thing you see is a huge diagram that rapidly robs you of your will to live. The Scrum documentation is smarter in the way it conveys its message of simplicity, and which practices are essential and which ones are not.


We saw opportunities where Scrum projects could benefit from some PRINCE2 areas and practices, like: Project Initiation and Project Closure, roles on the customer's side, managing portfolios and programs, and Cost Management and Risk Management. We also saw the need for adaptation of PRINCE2 to the complexity of software development: like continuous customer availability, continuous change, and continuous process adaptation.

One of the most interesting parts was how to combine Scrum and PRINCE2 so that a Scrum project can live in a PRINCE2 world. I had borrowed some information from Scotty Wakefield, who has described four possible scenarios on his own blog, in Scrum and Prince2: working together? Scotty's conclusion (and mine) is that you should always use Scrum (or some other agile framework) for software development, and then augment it and interface it for PRINCE2 (or some other formal framework) when the rest of the business requires it. (This is scenario 4 in Scotty's blog post.)

So, maybe PRINCE2 itself doesn't suck as much as I once claimed. There's certainly a place for it in our universe, and perhaps even in software development. However, I still think that PRINCE2 communication and documentation suck like a Dyson cleaner.

(pictures by annia316 and Hiddenloop)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Checklist for an Agile Game
I Follow My Rules, You Follow Yours
Embrace Diversity, Erase Uniformity

  • Top 50 New Software Development Books
  • Communication = Information * Relationships
Related Posts
free book
“How to Change the World”
  • http://www.rallydev.com/agileblog Jean Tabaka

    Jurgen, Congratulations on surviving the Prince2 challenge! When I either initiate such discussions Scrum versus whatever (here in the US it is usually about RUP or a home-grown gated process) or get pulled into them, I like to soothe before I challenge. The truth is, Scrum doesn’t have a lot to help a very large product development effort kick-off (for instance no Project Charter or Team Agreements or concurrent design guidance). Nor does it provide a lot of guidance about large, cross-team product release. This is where I engage people in peering across the Agile Manifesto from the left side to the right side and say, “Okay, we DO value the items on the left more than the items on the right. And now, what can we take from the right of value (such as processes and tools) that could be of added value to us in our context.” Does that sound similar to what you have seen, heard, experienced. Again, great post!

  • http://profile.typepad.com/mcottmeyer Mike Cottmeyer

    Hey Jurgen, I think and write a lot on this, but more from an Agile/PMI perspective. One of the things I like to focus on is the cost of change. Traditional PM is supposed to be deliverables based (not activity based) and open to change. The problem is that the cost of change is much higher in traditional methods… thus leading to resistance to change… thus leading to inflexibility.

  • http://profile.typepad.com/galleman Glen Alleman

    Prince2 and PMBOK are orthogonal at best. PMBOK is a set of Knowledge Areas and Process Group (and not always the best), claims to be “best practice,” but is several years behind the curve, and is generally aimed at the lowest common denominator – someone with little project management experince, looking to get started with thje Basics. What CMMI would classify as Maturity Level 2.

  • http://profile.typepad.com/galleman Glen Alleman

    The statement “the cost of change is much higer in traditional methods…” needs to field gatehred paralle comparison data, before enteprise applications folks will take that as anything other than “selling.”
    A new presenattion for Dr. James Brown, http://www.sebasolutions.com/aboutdrjames.html, has a wonderful presentation that discusses the “real” cost of doing agile.
    This “real” cost still provided benefits to the customer in the right situation, so it’s not an anti-agile approach. But the sunk cost of change, developing, eliciting requirements, and deployment in agile is likley simialar.
    It is the DISTRIBUTION of those cost elements that is different. In mnay cases the total cost of agile is more. In some cases less. The the Cost Spreads (as we would say here in defense) are advantageous to agile in the presence of changing requirements.
    Agilist tend to not be that interested in the gory details of cost management – the way we who live and die by Earned Value do. But the assessment of the benefical cost processes to the program are the “cost profiles” which drive funding profiles, which drive funding needs.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Glen: Thanks for the clarification. From the Prince2 people themselves I got the impression that Prince2 is a more detailed implementation (with specific roles, processes), while PMBoK is more generic and covers a broader terrain.
    But again, that’s what I heard. Wouldn’t really know until I compared them myself.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Jean: Totally in agreement there. Even a Scrum of Scrums wouldn’t solve all issues of a big software development effort. Management and customers would still appreciate a project initiation document, some aggregated highlight reports, and perhaps even a Gantt chart here and there…

  • Marius van Dam

    Thanks for the great post.
    As a prince2 certified PM I am interested in combining the core ideas of Prince 2 with the simplicity and efficiency of Scrum.
    In the past I’ve read articles about combining Prince2 and RUP. (http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/apr03/Prince2RUP_TheRationalEdge_Apr2003.pdf)and I think the same may be possible with Prince2 and Scrum.
    The article draws among others the conclusion that within the ‘Managing Product Delivery’ process in Prince2 RUP principles can be applied. When looking at the subprocesses of Prince2, Scrum could be a good match as well:
    – MP1 Accepting a work package
    – MP2 Executing a work package
    – MP3 Delivering a work package
    Scrum is mainly concerned with ‘building software’ while prince2 deals with the larger project environment including complex organisations, stakeholders, aligning deliveries from external parties etc.

  • Marius van Dam

    When looking for a european counterpart for PMbok btw I’d have a look at the IPMA Competence Baseline (ICB) which covers a wide range of PM skills including hard skills like planning (borrows heavily form Prince2) but also soft skills.

  • http://thejaminthemiddle.wordpress.com/2009/03/05/religion-and-bigotry-in-software-development/ Gary

    Were you really as closed minded as you said? I am really uncomfortable with fundamentalism.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Gary: I never said I was close minded. 🙂

  • http://blog.brodzinski.com Pawel Brodzinski

    For me it’s the old lesson that:
    1. Prince-2 isn’t meant to be implemented as an indivisible whole and you actually can resign from things which aren’t suitable in your environment.
    2. When applied reasonably Prince-2 can brings a lot of order to projects and it doesn’t need to be an old crappy thing no one want to use.
    3. Every methodology can be implemented in a way which brings more harm than profits (Prince-2 and agile included).

  • http://www.betterprojects.net Craig

    I believe you have misread Scotty’s take on Scrum + PRINCE2.
    I read it as “Scrum uninhibited by PRINCE2 is most effective” and that as you get better at running projects you’ll migrate to pure scrum (and then off to lean?)
    It strikes me that if you are able to you’ll avoid PRINCE2 on top of scrum – after all it’s a duplication of effort having 2 project management processes.
    At the end of the day a scrum capable org should only run PRINCE2 on top where you need to offer this component to satisfy a client requirement.
    And if for a partiular project you NEED PRINCE2 controls in place, the you don’t really need to worry about scrum. (Just grab some comfortable and useful stand-alone artefacts and activities.)

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Craig: I don’t agree that Scrum and PRINCE2 duplicate each others processes. That’s what I said in the article.
    One example: there is no Project Initiation in Scrum. In Scrum a project just magically appears out of thin air. Prince2 has some guidelines for the Project Initiation phase.
    Therefore “Scrum uninhibited by PRINCE2 is most effective” is (IMHO) not true.

  • http://www.betterprojects.net Craig

    I look forward to hearing about your results from a pilot of a Prince2/Scrum Hybrid.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    We have several non-Scrum additions to our Scrum-process. We’re working on our pre-sales phase, weekly financial reports, and a workflow for transition of a project to maintenance.
    Prince2 has some things to say about those practices, though I wouldn’t dare to say our implementations follow Prince2.

  • http://www.betterprojects.net Craig

    Yep, I expct your home grown procsses are lighter and more pragmatic.
    Here is a talk on mixing in PRINCE2 you might find intresting.
    Link: http://www.youtube.com/watch?v=e-zdw1NuTDI

  • roy

    Hi Jurgen, I enjoyed your posts on Prince2. Here’s a very fair and useful review of Prince2 from an agile viewpoint, in case you hadn’t seen it:

  • niels.van.bemmelen@gmail.com

    Hi guys,
    I’m not SCRUM knowledgable, but do know a bit about PRINCE2, so I was quite surprised about the following:
    “These are often mentioned problems with PRINCE2/PMBoK in software development projects:
    •Resistance to changes in scope
    •Counterproductive devotion to a plan
    •Overemphasis on task-based planning
    •Imposing project manager
    •Excessive documentation”
    PRINCE2 streamlines decisions about scope by identifying requests for changes, clearly defining responsibility for a change authority and a lean and mean management by exception proces. Problem 1 – nicely solved.
    PRINCE2 is not devoted to a plan at all – it helps identifying tolerances for deviation and uses the same mean and lean management by exception for deciding about plan changes. 2nd problem tackled?
    Task-based planning? Ehh, I don’t know many other methods that focus explicitly on products and use a technique called product based planning. It’s clear, managable (because it’s clear what’s the baseline that can change) and easy for the step by step instructions. Problem 3 should not be a problem anymore.
    Imposing project manager. Hmm. PMbok maybe, but P2 PM’s delegate all the specialist work and have explicitly limited authority to take decisions – only within his stage-tolerances. Furthermore P2 PM’s explicitly are to decide how much authority to delegate to team managers, so if the PM is imposing, well that’s personality, not PRINCE2. I’d say problem 4 gone.
    Last, not least: implementation of documentation is scaled to size of the project. One of the 4 integrated PRINCE2 elements is ‘Tailoring to the Project Environment’ – we all know that small projects don’t need 3 layers of plans, don’t need 10 pages of risk management strategy etcetera. It’s up to the PM to tailor PRINCE2 to the size of the project, the organisation, type of business and so on. The standard documentation in PRINCE2 is for a complete middle sized project. Integrate it, simplify it, summarize it and choose where to use different communication formats, but use the headers in it to manage the information you need to manage. I don’t see problem 5.
    There are of course some limitations:
    Now a challenge is how to applicate PRINCE2. It’s a bit of a language and speaking it on your own doesn’t make much sense. Same with a lot of other methods, is my experience. PRINCE2 is a method for an organisation to run succesful projects, not for a single PM.
    Furthermore it’s wise not to think PRINCE2 prepares you to be a good project manager (as PMBok pretends – therefor it includes more PM fields than PRINCE2 does). It’s like a driver’s license – it takes years to learn to drive well, but it’s nice to know the theory.
    Kind regards,
    Niels van Bemmelen

  • http://citadel-enterprise.webs.com Marcus

    Interesting that you also found Scotty Wakefield’s list with the four options for using PRINCE2 and Scrum. I’m a PRINCE2 artifact so the Mountainbiking analogy he links to was very useful to understand Scrum.
    I have blogged a little about my first meeting with Scrum here:
    “Scrum & PRINCE2 – burning the backlog”: http://citadel-enterprise.webs.com/apps/blog/show/4386855-scrum-prince2-burning-the-backlog

  • http://trusted.md/blog/glangoohtiweb/2012/12/06/weight_loss_will_not_take_place_until_you_want_it_to Elana


    OK, Maybe Prince2 Sucks Less Than I Thought – Agile Management | NOOP.NL

How to Change the World - free Workout - free