Earlier this week, I was reviewing proposed abstracts for the PMOZ project management conference in Australia. One paper proposed comparing the PRINCE2 Methodology with the PMBOK Methodology.
The paper did not get accepted because its basic premise is completely wrong! The PMBOK® Guide is not and never has been a methodology.
Methodologies define the processes, responsibilities and workflows needed to achieve an objective. PRINCE2 is a good project methodology for managing projects with a large internal component. Agile and Waterfall are two different software development methodologies that incorporate elements of project management.
The PMBOK® Guide is an international standard. To give it its full name, it is A Guide to the Project Management Body of Knowledge. The processes described in the PMBOK® Guide are generally accepted good practice that apply to most project most of the time. This is the foundation for a good project management methodology but the PMBOK® Guide is not, and cannot ever be a methodology without adaptation.
The step between the PMBOK® Guide and a methodology is determining what, who and how:
- What of the processes should be applied in you organisation, to what extent and with how much rigour?
- Who is responsible for the implementation of the processes, including; generic roles and responsibilities, project org. structures and governance committees
- How the processes will be applied, templates, guidelines and workflows.
These are critically important issues.
- If a PMO sets out to ‘implement the PMBOK’ you are heading for disaster.
- If the same PMO sets out to develop a tailored methodology based on the good practices described in the PMBOK you are potentially on the right road.
Certainly in my business, if someone does not know the difference between a standard and a methodology, I tend to start asking a lot more questions about their competence. Having been involved in the last two upgrades of the PMBOK® Guide I consider it to be a very valuable resource to underpin the development of any project management methodology but you still need to do the hard work of determining the what, who, how and ‘how much’ for yourself to build the methodology and optimise the outcomes for your organisation.
Happy Easter.
Pat Weaver
Lynda Bourne
Mosaicproject's Blog 
Hi There, what an interesting reflection, I have had a lot to do with PRINCE2 as the project methodology and people always talk about PMBOK as something similar, thanks for clarifying this. I’m not a great fan of PRINCE2, but I have managed to report Agile type project outcomes to PRINCE2 gate reviews without any huge drama. I realized a few years ago that PRINCE2 has extensions for IT projects, but people don’t seem to use them, may be we should!
Recently I saw a reference to Schedule Compression in PMBOK and was amazed to discover that this covers two totally different techniques, one that I refer to as ‘throwing money at the problem’, which I have (almost) never seen work in an IT project and the other is overlapping tasks, which is tried an true Agile.
This didn’t seem like a good idea to group a high and low risk option under the same headin without a big ‘DANGER’ sign, but then as you so rightly pointed out, it’s not a methodology; but isn’t it supposed to be a ‘Guide’?
You raise a couple of interesting topics Mike.
PRINCE was developed by the UK Government to try to overcome some of the massive problems they were experiencing in delivering major IT projects. Its use has spread from there. My personal view is it is a useful methodology when the client/customer and the performing organisation are essentially the same. This is typical of most major IT projects run by governments. PRINCE is not so useful where the organisation ‘doing the project’ is different to the client/customer (eg, a typical major construction project with a builder and a client).
As with any methodology though, the trick is to tailor it to the needs of the project and the organisation. PRINCE2 consultants I know call organisations that hide behind the PRINCE2 bureaucracy to avoid making timely decisions PINOs (Prince In Name Only).
You are right on your other comment regarding crashing and/or fast tracking schedules. Fredrik Brooks in his book ‘The Mythical Man Month’ (first published over 30 years ago in 1975) highlighted the problem that “Adding manpower to a late software project makes it later.” This is true of most projects involving knowledge workers, it is not so true if the project involves bulk mechanical work (eg, trucking a few million tones of dirt) where additional resources may help.
What is always true though is accelerating a project increases the risk and should be balanced by increased contingencies. All we need now is sensible senior managers…..
Hi Patrick,
What do you mean by “the PMBOK is not, and cannot ever be a methodology without adaptation”?
The PMBOK defines itself as a guide to generally accepted good practices applicable to most projects most of the time. The referenced tools and techniques are sometimes mutually exclusive, for example,, you can choose to use Critical Chain for scheduling or CPM but not both, a methodology defines which option your organistion chooses to use. The basics of what is required to define a business process within a methodology include:
– Knowing precisely what is to be done. Standards and guides such as the PMBOK only provide general guidance.
– Defining precisely the inputs, outputs and performance criteria. One example: Qualitative risk analysis (PMBOK® Guide 4th Ed., page 292) identifies relative impacts – but what represents a 0.80 impact (extreme), $5000, $50,000, $500,000 – the methodology has to make these definitions. The ‘impact’ can apply to quality, safety, time, cost – which ones matter and need including in the methodology, which can be left out??
– Defining the people responsible for performing the processes by roles, responsibilities and authority levels.
– Creating or adapting templates and guidance documents to implement the processes consistently.
– Defineing the work flows. The PMBOK® Guide is well laid out in this respect but only deals with a single pass – methodologies need to deal with iterative builds.
-Then you get to the questions of how often the processes are used, how intensely they are applied, who oversees the processes, how performance is measured, how the processes are improved and what happens if there is an identified problem or issue.
The real skill in developing a methodology is to make sure the methodology is as simple, quick and easy to use as possible whilst applying sufficient rigour to optimise project outcomes. Creating a ‘good’ methodology from scratch using a standard such as the PMBOK® Guide, or adapting an existing methodology such as PRINCE2 or Method 123, involves some serious work and the research and development work needs to be properly resourced to ensure the methodology is developed properly and is useful and usable.
For more on this see: http://www.mosaicprojects.com.au/WhitePapers/WP1045_Methodologies.pdf
Pingback: Methodologies | Stakeholder
Pingback: Methodologies « Stakeholder Management's Blog
Pingback: Methodologies « Mosaicproject’s Blog
Pingback: 2010 in review | Mosaicproject’s Blog
Pingback: Thoughts on ISO 21500 | Mosaicproject’s Blog