Are You Foolish For Believing In PRINCE2 As A Project Management Methodology?

April 28, 2011 | Author: PM Hut | Filed under: PRINCE2

By Bjarne Dedenroth

Whether or not you are foolish is not for me to determine, but chances are you have some preconceived notions that are potentially flawed, especially if you work within the field of Business Intelligence (BI), sometimes referred to as Data Warehousing (DW or DWH), but most accurately depicted as Decision Support Systems (DSS). The nearly omnipresent and often indiscriminate popularity - possibly due to equal parts of misconceptions and hype - of PRINCE2 as the project management methodology of choice seems to indicate a near blind faith in PRINCE2 as the answer to all prayers. Quite a few organizational decision makers insist on utilizing PRINCE2 as a foundation for implementing projects. I’ll show you why this is a fatal decision with potentially catastrophic implications.


At the top end, the International Project Management Association (IPMA) controls international standards. These are then administered via various national bodies through their respective BoK (Body of Knowledge). It is often stated that if project managers do not work within the defining parameters of the Bok, they are effectively not performing project management; regardless of how successful their efforts are!

One of the national bodies is the British Association for Project Management (APM), underneath which you will find industry-specific models as well as PRINCE2, which is an acronym for PRoject management IN Controlled Environments (PRINCE). You would think that the name alone would make people tremble with fear, but they don’t. Instead, they throw caution to the wind and head dip into the wave; only to find themselves waking up with a thundering headache at the bottom of the sea. Didn’t you notice the part where it said Controlled Environments? Okay, enough of the sarcasm, but DSS is anything but controlled; it is rather an untameable beast perpetually mutating into a blurry picture of hope depicting a pathway that is bound to be virgin territory for your organization.

More specifically, PRINCE2 was initiated for governmental project implementation in Information Technology (IT) and controlled environments. It is an alternative - not a complementary - methodology to, for instance, BS 6079 (British Standard 6079), which is a generic benchmark just like ISO 10006, etc.

The Dilemma Of A Methodology

Methodologies - and PRINCE2 is no exception - can be viewed as being placed somewhere within a continuum of being 100 % rigorous (following the letter of the law) and 100 % lax (eat all you can buffet… blindfolded). That’s an inherent problem with any methodology, i.e. if they are too rigorous, they stifle implementation; if they are too lax… then why do we need them?

Critical Misconceptions

Below is a list of the key misconceptions surrounding the PRINCE2 methodology as it is applied to DSS (or BI) projects:

  1. Processes galore: DSS is, just like PRINCE2, process-oriented and therefore many people, erroneously, conclude that they go well together. Nothing could be farther from the truth, and it may well be the single most misunderstood factor. Is it true that both PRINCE2 and DSS are process-driven? Yes, it is true, but they represent two completely different paradigms. One is a project management methodology and the other is a system for implementing strategic business solutions. One implements projects based on 40 separate activities grouped into seven different processes, the other implements strategic business solutions that takes - AS INPUT - business processes (from the transactional systems). It is highly likely that people who promote PRINCE2 are very capable individuals, but they may not fully realize the nature of the beast (DSS)!
  2. Project management as a discipline: Isn’t it true that both PRINCE2 projects and DSS projects are projects? Hopefully, you didn’t expect me to answer ‘no’ to this one. Yes, of course it’s true, but just like you should never apply PRINCE2 to, for instance, on a construction project, you should refrain from applying PRINCE2 to DSSs. Why is PRINCE2 not a feasible methodology for a construction project, you may ask? If you have found a way to tame nature (i.e. to control it), then you should share it with the world. Otherwise, it may be time to acknowledge that one size does not always fit all. Also, it is important to note that PRINCE2 works more or less solely in bureaucratic organizations. Surely, you - or someone out there - could argue the case that a kangaroo is the same as a human being in that they are both mammals. I would, however, cautiously argue that the nature of the two are not quite the same. It’s a different kind of animal altogether!

  3. Transactional vs. Analytical(or DSS or BI or DW… don’t you just love it when people keep changing the names, just to find out they mean the same?!): You can split up IT into two different worlds, one is based on transactional systems (e.g. Billing, Order, etc.) and the other is your DSS (Data Warehouse, Business Intelligence). They are conceptually opposites and quite often, but not necessarily, physically separated. All transactional systems are also process-oriented. Order Management, for instance, is definitely a process. To cut a long story short, and as indicated above: the process-oriented nature of PRINCE2 as a project management methodology is a completely different paradigm than the process-oriented nature of DSS. You can apply DSS functionality to a transactional system. Often times these are referred to as OLTPs (OnLine Transactional Processing)… I just happen to think it’s a questionable acronym: aren’t DSS systems typically onliine?! Anyway, you can even apply transactional functionality to a DSS, although you should be very cautious about this. The DSS system is getting fed by the transactional systems (plural!), hence the expression an Enterprise Data Warehouse or Enterprise Business Intelligence. Here, we’ll just refer to it as a DSS… I know you love acronyms!

  4. All for one and one for all: While electing to create a DSS for just one transactional system is possible, it is architecturally and strategically unsound and conceptually nonsense. Do assume a DSS to run across multiple transactional systems, and certainly across multiple business processes (note: often a transactional system represents a business process). Whether the transactional systems are created by the same vendor (e.g. a suite of products split up into modules) is immaterial. Think of it as business processes represented by any number of transactional systems. Key are the underlying business processes despite the self-proclaimed supremacy of any one vendor!

  5. I.T. Phone Home: Any type of technology you may or may not buy, is something any of your competitors can easily buy as well, so relying on technology is a bit like falling asleep on a three-legged stool… it’s bound to hurt at some point! It’s easy, and very tempting, to fall down in the trap of regarding a DSS solution as an IT solution: after all, the DSSs around the world are based on IT, aren’t they? Sure, and so is writing this article on my computer!

A Strategic Business Solution

A project for implementing DSS solutions should be viewed as implementing change to ensure the execution of strategic business solutions. Hence, it is implied that such DSSs are, by their very nature, of an enterprise-wide character. However, it does not imply that you cannot develop something locally (i.e. in a department or division); sometimes - not very often though - it even makes sense, as long as it is aligned with the overall strategic and enterprise-wide plans and architecture. All too often, it is viewed as just another IT project: a misnomer of such proportions that it ought to make entire organizations blush. Instead, it just leaves them crying… from the pain of prolonged, costly, and ineffective management!

Advices For Your Vices

Completing a project, any project, is a daunting task. Additionally, completing a DSS project successfully could be considered an art form; mastered by a surprisingly few number of organizations, so here are a couple of advices to help you along the way:

What separates a novice from a master is that a true artist knows what to steal!

Dealing with DSS is like looking through a kaleidoscope on drugs; dealing with transactional systems is like staring at a wall…. from time to time, the wall needs a repaint, but then it’s as good as new. So, isn’t the “wall” necessary, you may ask? Of course; of course it is, but you hardly need to stare at it all the time!

Bjarne Dedenroth specializes in strategic architecture and the optimization of system structures regardless of context; focusing on the ability to analyze, define, transform, plan, and execute strategies based on scientific research.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

2 people have left comments

Wow, I’ve never seen such a clear expose of a lack of knowledge in how to apply a methodology. (I thought it was ‘Projects IN…, not ‘Project Management IN… I must check the old red book. Or the slightly newer, light blue one).

Of course you can apply PRINCE2 to a construction project.

Look up stage planning, tolerances and, what will likely apply if I understand the hint correctly; the exception process. The whole point of a methodology is that you apply what works for the problem situation. PRINCE2 is only bureacratic if you erroneously believe that you should apply every single aspect of it to every part of the project. Even a basic understanding of products you’re responsible for delivering and issuing work packages to suppliers to deliver these is applying the methodology.

You’d monitor and control delivery of products. If risks occurred, you’d manage them. You’d report highlights to whoever is paying the bills and regularly check the status of what is being delivered. You’d have a pre-project stage where you’d get approval to start the project. You’d have a customer and supplier representative to discuss progress with and someone would check that you’re managing the project according to your client’s requirements. Wouldn’t you?

It’s all in there.

Don’t take everything literally. If it’s useful, use it. If it isn’t (such as the suggested directory structure in the 2000 version), don’t.

Kev wrote on February 19, 2012 - 11:06 pm | Visit Link

In defense of the author Bjarne, the reader should not miss to read between the lines:
There’s a difference between methodology and method. Methodologies describe the ‘how’ and they can contain methods that describe the ‘what’. (IT) Project Governance and Process Implementation require a methodology; software development and IT delivery require a method. Reason why every IT consulting firm has developed their own delivery methods, while a PM methodology like Prince2 is often used for governance aspects in conjunction with a practical delivery method.

Roger Teuwsen wrote on May 6, 2014 - 2:55 am | Visit Link

feel free to leave a comment



All fields marked with " * " are required.

Project Management Categories