Is the PMBOK Guide a standard if it is always changing?

That’s the question posed by James Brown (here). He points out that the PMBOK Guide 4th Edition no longer discusses the Triple Constraint — yes, I was shocked it was missing too!  He wonders if the PMBOK Guide:

…is not a standard if it is always changing!… PMI is at risk of devaluing the PMP certification because now you have project managers certified on different sets of terms. When an organization hires a newly certified PMP based on the fourth edition of the PMBOK. they may not know the term triple constraint. A standard doesn’t have to be perfect, but a standard must be a standard to effectively serve its purpose!

In this case, I agree that the loss of the term “triple constraint” is pointless.  It is a powerful way to highlight the choices that one needs to make among competing priorities.  Why not elaborate the concept or point out its limitations instead of dropping it?

However, I challenge the idea that a standard cannot be “always changing.”  For example, should there only be one edition of the Merck Manual or various ANSI standards?

While we should avoid change for change’s sake, project management is still trying to codify the common sense Dr. Brown mentions. We’re a long way from having a stable project management standard, IMO.

PMI and Agilests?

Cats and dogs, living together...

Greg Balestrero — CEO of the Project Management Institute — recently posted (here) on his experiences at the Scrum Gathering in Orlando.  In my experience, Greg and the PMI staff have been very eager to foster a better relationship among the various methodology camps.  Per Greg’s post,

[t]he intent of the visit was to bridge the gap between the Scrum Alliance and PMI. But I guess the real reason we attended was to dispel the myths that surround the PMBOK® Guide and Agile practice. There is a widely held opinion that the PMBOK® Guide and Agile don’t mix… they can’t be “shaken, nor stirred” together. 

Please read the post…it gives an interesting perspective on how to build alliances among disparate points of view and how to overcome misconceptions.

PMBOK Guide 4th Edition — Pet peeve in glossary

There have always been a few in-apt or questionable glossary terms included in the PMBOK Guide‘s glossary.  But in particular, the persistence of the Delphi technique puzzles me.  I mean, how many people actually use it?  Have any of you all seen this technique used recently? 

A lot of such techniques are around and all have their place.  And it isn’t that I have desire to see Delphi stamped out.  It just seems so out of place as something that should be codified in the PMBOK Guide. 

The bottom line is that Delphi just doesn’t belong; here are four reasons off the top of my head:

PMBOK 4th Edition Features — Data models per process

Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)

When I saw the pre-release PMBOK Guide 4th edition draft, the new data models attached to each process caught my eye. 

I liked the 3rd edition’s attempt to capture data and process flow.  However, the approach was a bit clumsy, largely because it was done by knowledge area.  To be fair, the 3rd does have a set of process group diagrams in Chapter 3 with a decent overview of the flow.

Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)

While the big picture view those diagrams provided was nice — versions of them exist in the 4th edition — mapping the data inputs/outputs by process is more rigorous and intuitive IMHO.  I was OK with  the boxes listing the data I/O, but the models are much more effective visual representations of the individual processes.

I’ve provided a couple of examples of the different approaches FYI.