AXELOS ProPath, the world's most powerful project, programme and portfolio best practice certifications

Why the PMBOK is not a methodology

Patrick Weaver
August 8, 2012

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.

Patrick Weaver
Patrick Weaver is the managing director of Mosaic Project Services and the business manager of Stakeholder Management Pty Ltd. He has been a member of both PMI and AIPM since 1986 and is a member of the Asia Pacific Forum of the Chartered Institute of Building. In addition to his work on ISO 21500, he has contributed to a range of standards developments with PMI, CIOB and AIPM.
Read more

6 thoughts on “Why the PMBOK is not a methodology

  1. Pat,

    Thanks for a cogent explanation of the gap between PMBOK and it as a methodology. And especially for the need to adapt, depending on the needs of the project.

    I’ve been involved in projects for quite a while and seen slavish adherence to either SDLC and/or PM methodologies, where the net result was an informal observation that there seemed to be a high level of INVERSE correlation between the amount of “shelf-ware” produced (documents that are completed to meet the methodology, but never referenced again) and effective project outcomes.

    A number of your comments also reminded me of aspects of Paul Culmsee & Kailash Awati’s recent book “The Heretic’s Guide to Best Practices” where they seriously question the suitability of shoe-horning someone ELSE’s “Best Practice” into another organisation, when often the “Best Practice” is not necessarily universal best practice. Give me “Horses for Courses” any day, though still doing this in an informed way. It would be pretty daft to pendulum swing and re-invent the wheel each time. The middle ground of working WITH and WITHIN the organisation’s current structures/ethos, working collaboratively with the people and going on the journey with them to improve how things are done seems sensible to me.

    It believe it would enhance our project success track record if it became a regular feature of project planning to actively assess what was required to support delivering effective outcomes. Your article will hopefully catalyse a move in that direction.

    Peter Reefman

    1. I could not agree more!! The application of common sense seems to be overwhelmed in many organisations by the application of process.

      The PMBOK® Guide is clear in section 1.1, para 1 (page 4) that the organisation and/or project manager is responsible for tailoring the ‘guidance’ into a sensible framework.

      Philosophies such has ‘Lean’ advocate focusing on outcomes over process (and minimising process) ideas that go back decades if not centuries…. But the bureaucrats love bureaucracy and think paper forms solve problems……

      It’s a theme I’ve been focused on for a very long time:

  2. Great quote from the article: 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.

  3. Thanks you for providing this detailed of an explanation on what the PMBOK provides and what it does not. I find that many Project Managers use the PMBOK as it was intended, as a guide to developing a great methodology for project delivery.

  4. This is a good article, I would contend that ANSI was wrong to even identify it as a standard. A body of knowledge doesn’t even come close to meeting the definition of a standard. Not one company I have worked with uses the PMBOK consistently; even terminology from the PMBOK is used inconsistently from company to company, department to department, workgroup to workgroup. PMI, is a marketing group, they are not standards group. As an engineer I have worked with many standards, and this is by far a standard.

  5. By reading thing I decide to throw pmbok out of the window coz it largely silent on everything…

Comments are closed.