What’s in PMBOK 5?

What’s in PMBOK 5?

PMBOK 4th edition

PMBOK 5th edition

Though I know people are hard at work, deciding what will go into the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK) 5th edition, I can’t help but add my 2 cents.

We’re all armchair quarterbacks at one time or another so I’m rationalizing this post.

What is one of the biggest gaps in the current edition of the PMBOK, in my opinion?  It’s the complete omission of (management) models or approaches.  Agile, Scrum, Kanban, Spiral, Waterfall, and RUP should be defined in the PMBOK.  It would be really nice if the PMBOK added an entire section dedicated to this, complete with diagrams and workflows.  I think there is a problem, if you find yourself sending people to Wikipedia to find a list of the different software development processes.  I completely understand there is more to the world of project management than just software development. But, I’m trying to make a point and provide an available resource for this post.

I’ve had people use the PMBOK as the excuse not to use Agile, saying it wan’t explicitly listed.  I pointed out that neither was Waterfall.  I wrote a post titled “Agile is in the PMBOK so it must be true” to make a point.  If PMI wants the PMBOK to be used as the de facto standard for over 400,000 PMPs, they need to take a more iterative approach in releasing editions.

If anyone at PMI is listening, I would be more than happy to help.

Like the image?  Find it at Pictofigo

22 Replies to “What’s in PMBOK 5?”

    1. Rapsli, the PMBOK is not the end-all-be-all of Project Management knowledge. I know PMI would like it to be. But, it’s a start. If they truly want it to be a body of knowledge, I want everything in there! Let’s start with Agile

      1. I think the PMBOK is a general reference on project management methods. As time moves on, those methods grow and develop and even off-shoot – possibly. I just think the PMBOK has to appeal to the broadest audience possible. I know you’re not a fan of PMI per se, and I think it has its value when used appropriately. I think the PMBOK is just trying to educate as many people as possible because there are so many people out there either called project managers and not using project management at all, or project managers with very little education.

        1. Laura, I’m neither a hater or a fanboy of PMI. I recognize they have a challenge, as the membership grows and grows, and as the industry seems to evolve at a faster and faster pace. My recommendations can most certainly be dismissed but I think we all need to have our voices heard. I think it’s good to question the status quo and to propose new ideas. How else can we expect things to evolve?

          Thank you for posting your feedback. I appreciate reading a different point of view.

        2. Laura,

          We all need to be very careful with words or confusion abounds. PMBOK contains the Knowledge Areas and Process Groups which frame the Guide to the Body of Knowledge. When you insert the word “method” or when others insert “methodology” (the study of methods actually), you’ve made a connection between PMBOK and a method where there is none.

          As suggested in the past, and actually performed,, the METHOD of applying the Knowledge Areas and Process Groups in PMBOK is performed in the PMI Practice Guides.

          To date these are:
          1. Risk Management
          2. Program Management
          3. Portfolio Management
          4. Work Breakdown Structure
          5. Portfolio Management
          6. Configuration Management
          7. Scheduling
          8. Earned Value

          Derek’s suggestion to include Agile Software Development METHOD(s) (Scrum, DSDM, Crystal e.g.) inside of PMBOK is not supported by the organizational structure of PMI’s documents nor PMBOK.

          Value would certainty be produced by having an Agile Software Development PRACTICE GUIDE.

  1. Derek,

    I’d hope that PMBOK is about Project Management, not software development. Here in the “Project Management” world, we bend metal into money, pour concrete, develop drugs and anti-drugs, install data centers, provide services for cost and schedule management to several government agencies, drill for and discover oil, build pipelines and pumping stations, develop alternative fuels and the power plants that burn them, design and build manned and unmanned space craft, major weapons systems and the processes that deploy and maintain them.

    Software, while an important part of all these systems, is just a part. And the software development methods you mention – all wonderful – are implementations of the principles defined in PMBOK.

    So please don’t have PMBOK 5 focus on or even contain a software development method. Put that in an adjunct text on how to development software using Scrum and the 5 Process Groups and 9 Knowledge Areas.

    1. Glen, I think your comment in very well articulated. That first paragraph is like something I would read in the forward of a book, not my blog. I appreciate that extra effort you put into it. As I’m sure you read in my post, I stated “I completely understand there is more to the world of project management than just software development”. That being said, are you saying Agile does not belong in the PMBOK? When I attended the PMI North American Congress, Agile was everywhere. When I went to an Agile EVM session, the PhD presenting, used you as one of his resource for his published paper.

      I then saw the U.S. Chief Information Officer say, during his government keynote address, over and over again how we need to use more Agile methods on Federal Projects.

      Don’t you think it would send a conflicting message from PMI to so prominently support Agile and then ignore it in the PMBOK?

  2. Found the Agile EVM PhD
    Dr. Nikravan, Director
    Microsoft – Naperville, IL

    An IT PM guy. Wonder if he’s gone through a DCMA EVMS validation, JSR, IBR, and made it to CDR with his “agile EVM” concepts?

    1. Yep, that’s the guy.

      When asked curing Q/A, he stated they were using this “agile EVM” method on a DoD contract and that it passed a GAO audit. I don’t have further specifics as to what contract.

  3. Glen,
    You make some very good points.

    When I heard the Federal CIO speak, I heard him mention two of the Agile Manifesto principles. Again, the world is much bigger than just software development. We all recognize that. But, I’m still thinking it would be helpful if all of the methods, approaches, frameworks (insert word here) that have been accepted as a standard ways of doing things, were listed somewhere.

    I’m not recommending a full rewrite of the PMBOK. I’m recommending PMI, at the least, capture terminology being used in all project management areas.

    1. Derek,

      I’d suggest a Practice Guide is in order. Since Agile Software Development using PMBOK would be a PRACTICE not a GUIDE to a Practice.

  4. Sorry mate, can’t quite see your point. With all due respect to software development projects (which is where I come from) they should not be elaborated on in the PMBOK as they represent just one of many disciplines in which project management is used.

    1. Shim, this is just my take on things. I feel the project management community, on a whole, would benefit from this proposed change. Perhaps each of these methods have been mis-categorized? I’ve seen agile used on non-software projects. I’ve also seen waterfall used in non-software projects. I’ve certainly seen kanban used in non-software projects. IF these are terms used in project management vernacular, I still believe they belong in the PMBOK.

      If there is a solid use case demonstrating a method is used in more than one are vertical market, do you think they should be included in the PMBOK?

      1. Derek,

        We’re back to the core issue. PMBOK is not a method, the things you describe are.
        The PMI Practice Guide describe the method of applying PMBOK.

        Tell us why that is not the workable solution?

        1. Glen,
          The PMBOK is not a method, it’s a book of knowledge. Like I wrote to Shim in my last comment, perhaps each of these methods have been mis-categorized? Within the PMBOK, perhaps they should be re-categorized as tools and techniques and they should most certainly be defined. I’m trying to make the PMBOK a more useful document. Just because methods I listed were originally defined for software development, I think “traditional” project managers could benefit from knowing about or using some of the defined tools and techniques.

          If more projects could be defined as “successful” by their sponsors, as a result of more people utilizing some newly defined tools or techniques from the PMBOK, isn’t it worth considering?

          I’m curious, why is your way is the only way?
          I’m curious, why do you think maintaining the status quo is so important?

          I may be wrong, but I get the impression that you find more value in defining process than in delivering the product the project was created for in the first place.

      2. Derek, that’s an interesting point. Could you further elaborate on those ‘not software projects’ using Agile or Waterfall. Are you suggesting that Agile and Waterfall are but generic terms, traditionally associated with Software Development but are not necessarily Software Development, but rather generic methods for implementing ‘things’?

    2. Shim makes a good point. The PMBOK is an overview, not specifically detailed by industry, so to speak. However, I also see Derek’s point in that the PMBOK could acknowledge different processes out there and provide a brief description.

  5. Hi Derek,

    I just picked up this thread. I am an agile proponent who is also in the content creation group for the PMBOK v5 Guide.

    I agree with you that the PMBOK Guide, is a “guide” not a method, and it would not be suitable for many industries if we filled it up with software development related practices, but at the same time I am trying to increase the recognition for the agile, lean and kanban related elements that transcend industry and may be of use to project managers.

    However it is a long and slow process, you can read some reports on my experiences at http://www.leadinganswers.com by browsing through my posts or access them directly here

    PMBOK v5 – Raise a Little Hell http://bit.ly/cwb3Jk
    PMBOK v5 – Rejected http://bit.ly/a24AcX
    PMBOK v5 – Accepted http://bit.ly/di4vnv
    PMBOK v5 – Slow Progress http://bit.ly/9Wa06u
    PMBOK v5 – Who’s Gonna read it? http://bit.ly/9Dogjl

    Time will tell if I am successful in getting agile related content included, but with the PMI acknowledging around 65% of its members working in the IT field, and Gartner predicting 80% of software projects will be using agile methods by 2012, I think they would be well served to investigate its integration into the Guide or creation of a PMBOK Guide Extension for software (my preference).

    Best regards

    1. Mike, I’ve seen agile approaches in both manufacturing and on acquisition projects. That being said, if these approaches were at least listed in the Glossary, I would count it as a small win. The debate for some people continues to be if any of this should even be listed in the PMBOK Guide. I still believe that it does. It’s like PMI knows there is an elephant in the room, they want to admit it to everyone, but they’re not sure how to do it. I think a little transparency would go a long way. Though I don’t want to rush the process, it feels like such a long time coming. I look forward to reading your blog and hearing about the progress. If your team needs any additional bandwidth, sign me up.

  6. I agree completely. The draft for version five has just been released – (2/17/2012) – and they mention Agile methodologies in several places – (which they did not in version four). They have also added “Adaptive Lifecycles” for the Agile/Iterative approach to be contrasted with a Predictive LIfecycle approach. However, they need to go much farther, and – as you recommend – explain advantages/disadvantages of each, and where they best suited. I haven’t read through the draft completely, but some areas I think should be addressed are:
    – Expand on the Adaptive vs. Predictive Lifecycle Models
    – Expand on Stakeholder roles in Agile – (Product Owner, Scrum master, Team Members)
    – Project Management Plan – Do we always need the level of formality currently defined in the PMBOK®  Guide? Do we always need all the subsidiary plans and supporting documents? Does the project management plan always require formal approval? Is this always a single, one-time event? Can we allow for more informal models, and “pull/JIT” models of the Agile approach?
     – Scope Management – Should the Agile approach be included? (An approach that sticks entirely with a customer focused view for defining requirements and features?)
     – Earned Value Methodology – Traditional EVM cannot be done: (no baselines, no BAC, don’t know how many iterations will be included; so, should the new, alternative approaches being created for Agile methodologies be included? (e.g. – velocity of change in Burn Down Charts, Burn Up Charts?) – Human Resource Management – Again, possibly include the different stakeholder roles defined in Agile, and the different approach to team development, and managing the team members.
    As a long-time PMP, and a supporter of PMI and the local Washington DC chapter, I fear that if they do not address making such changes, the PMBOK Guide will become less and less relevant and useful for project managers.

Leave a Reply

Your email address will not be published. Required fields are marked *