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
2 responses so far ↓
mikeathome // April 12, 2009 at 10:43 am |
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’?
Pat Weaver // April 12, 2009 at 11:37 am |
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…..