Why the PMBOK is not a methodology

One of the more common discussions on the web and in other places is focused on arguing the merits of, or comparing, the PRINCE2 methodology with the PMBOK methodology. The problem with the proposition is the basic premise is completely wrong! The Project Management Institute’s (PMI) Project Management Body of Knowledge (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.

PMBOK is an American National Standards Institute (ANSI) standard. To give it its full name, it is A Guide to the Project Management Body of Knowledge. The processes described in the PMBOK are generally accepted good practices that apply to most project most of the time. This may be the foundation for a good project management methodology but of itself, 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 should be done by whom, when 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 organisation structures and governance committees?
• How will the processes 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 three 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, when, how and how much.

The gaps in the PMBOK and consequently the information you need to develop and incorporate in your methodology include:

1. Knowing precisely what is to be done. The PMBOK only provides general guidance and states this specifically.
2. Defining precise input, output and performance criteria. The PMBOK is largely silent on these. For one simple example qualitative risk analysis identifies relative impacts, but what represents a 0.80 impact (extreme)? $5,000, $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? The last major risk assessment I helped run for a US$1 billion tank farm, the team decided anything over US$250,000 would be considered an extreme risk, on other projects $250,000 is more than the total budget.
3. Defining the people responsible for performing the processes by roles. The PMBOK only provides general guidance. A methodology defines roles, responsibilities and authority levels.
4. Developing user-friendly templates and guidance documents to implement the processes consistently. The PMBOK is largely silent on these.
5. Defining the work flows. The PMBOK is well laid out in this respect but only deals with a single pass; methodologies need to deal with iterative builds.
6. 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 above is an elementary description of the contents of any well designed business methodology, is consistent with concepts such as Six Sigma, is well defined in the PRINCE2 methodology and is assessable in part through the PMI’s Organizational Project Management Maturity Model (OPM3) construct.

In short, all the PMBOK guide offers is precisely what it says it offers: “a generally accepted set of good practices that may be used on most projects most of the time.” A methodology expands on this start by defining the, what, how, who, when and how much. Even the PRINCE2 authors expect organisations to constructively adapt the methodology to their needs: one size does not fit all! Real hard work is needed.

The PMBOK is certainly a great starting point (as is PRINCE2), and having a good foundation is crucial, but foundations are only ever the beginning point. Once the foundations are right, the real work of building a useful methodology or adapting a published methodology begins. The real skill is to make sure the methodology is as simple, quick and easy to use as possible while applying sufficient rigour to optimise project outcomes.

Download Pat Weaver’s whitepaper on what’s needed to develop an effective methodology.