Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: ITIL

PMBOK or PRINCE2 … which one is better?


I often see debates on project management forums on LinkedIn, blogs and even at the water cooler around the office regarding what project management methodology is best. I have often wondered about the wisdom of such discussions. The two that are always compared are PMBOK (Project Management Body of Knowledge) and PRINCE2 (Projects in Controlled Environments Version 2 – 2009). One such discussion with a fellow professional led me to have a little bit of a think.

PMBOK Process Model – Credit: PMI

I will declare my hand at the outset. I have squarely gone for certification route through the Cabinet Office products for project, programme and service management (PRINCE2, MSP and ITIL). This is not necessarily because I was convinced these were the best frameworks, but my assessment of what the market around me considered more valuable. With the Australasian market following that of the United Kingdom and Europe, it made more sense for me to pursue this line, than the PMBOK based certifications from the Project Management Institute (PMI) in PMP and PgMP.

PRINCE2 Process Model – Credit: ILX

Genesis of PMBOK is in the engineering sector in North America. I can see that has led to significant emphasis on the tools and techniques of how to manage projects. I find it has excellent guidance in what it calls the knowledge areas. For example, it provides techniques for monitoring and controlling projects through Earned Value Analysis (EVA), estimation through the Program Evaluation and Review Technique (PERT) analysis. It elaborates on Precedence Diagramming Method (PDM) to identify sequencing and various lag options. It has tools and techniques for scheduling using Schedule Network Analysis, Critical Path and Critical Chain, discusses Resource Levelling and What-if Scenario Analysis. Tools and techniques is where PMBOK has it all over PRINCE2, which goes very little into the skills required to be a project manager.

PRINCE2 began with a desire to control capital IT projects in the United Kingdom. Interestingly, a methodology that began in such a technical sphere has very little in the form of guidance through tools and techniques. PRINCE2 is very strong on project governance. Its strength is in the focus on the continued business justification through a living Business Case. In managing by exceptions, it removes the temptation for death by project reports, but at the same time provides a mechanism for escalating when necessary. In managing by stages, it builds in regular reviews of whether the business case the project is trying to deliver to be still valid. The biggest outcome of this is the assertion that a project unlikely to deliver to business case is better cancelled than meandering along. Project structure and principles also ensure projects are delivering to strategic initiatives of the organisation.

I have previously posted about the challenge in implementing PRINCE2 as the project framework for supplier organisations. I have used the principles rather than exact implementation as described in the text. It is much easier to take the PMBOK tools and techniques and implement directly into your projects in a supplier context. PRINCE2 however does a better job of risk identification and management techniques with the various response options and planning. There are also pros and cons about the accreditation methods. PRINCE2 is often criticised for allowing potential non-practitioners to get certified because of its examination only method. In order to get a PMP accreditation, you have to go through a significant effort to prove hours under the belt. That is a good idea. But you have to accumulate Professional Development Units (PDU) to stay current. I have seen plenty of mickey mouse outfits dispensing PDUs like confetti to have any meaning to these.

When I consider all of this, it appears a futile argument from those in either camp. In my view the best option is to use PRINCE2 to understand “how” to run the project and PMBOK for guidance on “what” to do in the specific scenarios. The question is not one of PMBOK or PRINCE2, but how to use both in your projects.

PRINCE2, ITIL, Agile … can I have the best of all?


There is a lot of discussion about what the best methodology is to adopt for an organisation. As soon as the discussion moves in that direction, it moves away from realities of any Software Development Life Cycle (SDLC). Projects simply do not mushroom out of thin air. Something causes a realisation in the organisation that moves them to  mobilize and start a project. The project than needs monitoring and control to bring the desired transformation in the organisation. Read more of this post

Is agile and PRINCE2 compatible?


My project management experience is in the field of software development. I deal daily with developers that espouse the value of agile development methodologies. Having come from a development background myself, I am skeptical about all that is said about agile. In saying that, I do see some benefits – especially the first principle of continuous and incremental delivery of software. However, a question arises … is PRINCE2 compatible with such methodologies, and vice versa.

For subsequent post on use of Agile and PRINCE2 together refer to this.

Let us quickly review the highlights of the agile manifesto

Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan.

Now let us consider the realities of bespoke software development. The project cycle starts with your organization given a set of requirements from a client and you having to provide an estimate to deliver to the requirements. As soon as you commit to a fixed price, scope and duration, there is effectively no room for agile. Depending on feedback, you cannot adjust the behaviour of the application – you will likely blow price, scope or duration – most likely all of them.

In PRINCE2, there is emphasis on the business case being continually evaluated to ensure the outcome is still desirable. PRINCE2 is also very process oriented – as evidenced by the 7 processes. It cannot therefore accept the first principle of agile development. There must be a process that states the requirements and any changes to the baselines and their impact. This can then be evaluated by the project board to evaluate whether the project is still desirable.

Working software over comprehensive documentation is a dangerous prospect in my opinion. Whenever there is squeeze on project time, documentation is usually the first casualty. This may produce working software at the time; however, it adds untold grief once it has been delivered. Anyone maintaining the system, whether it be your support team, the client’s IT team, or a third party will come to regret it. While I never enjoyed documentation as a developer, I learned to live with it as a necessity of quality work.

Responding to change is often trumpeted as a major gain of agile approach. Self organizing teams are put forward as a strong productivity source and one that can do away with a traditional project manager. These however do not take into account the inter-relationships between the projects, ability to analyze the impact of the changes to baseline, ability to hand over to an IT organization from project to Business As Usual (BAU).

One striking similarity between agile and PRINCE2 is how both treat the planning horizon. Both recognize that you can only plan so far in advance. Agile approaches do it by planning sprint content, PRINCE2 does it by planning by the stages. In that respect, there is some compatibility between the two. I see great value in utilizing some of the agile principles during the development phase of the project. Once I as a project manager assign the work package to the development team leader, if they use agile techniques to deliver within their tolerance levels, who am I to object?

PRINCE2 makes a distinction between the management products of a project and the specialized ones. Development of software here is a specialized product and therefore not specifically included in PRINCE2. Beyond the delivery stage of the project, I do not see agile meeting the requirements and expectations of executives and management to contract development services for a fixed fee.

In comparison, ITIL is probably more aligned to agile approach – especially during service operation stage. Once software is delivered into BAU, there is a continuous requirement to keep it running in an optimal mode, include additional functionality or evolve with the changing requirements of the organization. A programme of work can be created with continuous service improvement goals.

Tailoring is what makes or breaks your PRINCE2 project. Make sure you tailor it to suit your requirements. Pick from agile methodologies what you want and in which stages. Do not get locked into a specific one. When used, go more by the principles of agile manifesto, rather than a prescribed, particular method.

%d bloggers like this: