Is the PMBOK Guide really the “Perfect World”?

In my comment I wrote “it’s funny,” but it’s actually sad that Carl Pritchard has to defend the PMBOK Guide when he conducts PMP prep classes (post here). 

What good is a certification that says that every process needs to be followed every time in a consistent fashion?  It sounds very good to me. And it also provides a jumping-off point to take steps toward that perfect world.

Of course I agree.  But IMO, Carl is softening the blow when he accepts his students’ assertion that PMBOK practices represent the “perfect” world.  Of course, not every process is executed perfectly in the “real” world, but as Carl says, don’t we want to insist on these basics?

Senior management writes and signs chartering documents; Procurement departments deliver what we ask for …; Human Resources departments provide skilled resources…; Management understands that range estimates are more honest and realistic than single-data-point estimates.

Aren’t our projects are more successful and our lives easier when we insist on such fundamentals of project management?  We need to ask ourselves if we have a problem with the practices, or a reluctance to deal with the conflict and effort required to insist upon them.

The latter is the real issue.  I doubt that folks still really believe that an industry standard that comes out every five years represents best practices or the “perfect world”.  If they so, they’ll be in for a rude surprise w/r/t customer and employer expectations.  For our organization, PMBOK-based practices are simply the foundation for our minimum standards.  The minimum

4 Responses

  1. The PMBOK is most helpful when seen as a “correct principles” process and not a “recipe for success”. I have seen too many PM’s expect a recipe, which prompts the need to defend the PMBOK.

    To be a successful PM, problem-solving skills are more valuable than process-keeping (illustrated very well here: Process-keeper PM’s find the PMBOK lacks the detail they want to slavishly follow and either “fails” them or only provides guidelines that requires *them* to solve the project’s significant problems themselves.

  2. It is important to note that we are dealing with a standard (PMBok) for a process (project management). The standard is what guides our organizational process implementation (the foundation). In real world, processes have to be scalable. We do not enforce the same minimum standard on a small project as on a multi-year project. At the same time PMBok is not a step by step guide down to Standard operating procedures either. Thus, an organization will have a choice in the complexity of the process that gets implemented for every size/type of project.

    Process maturity is the degree to which we implement and follow the process that we have implemented based on the standard. Not all processes in an organization are core process and need to be at level 4 or 5 maturity. To the same extend, not all elements of PMBok need to be enforced at the same level of complexity on all size/type projects. We need to focus our attention on the items that will make the real difference.

  3. A quiet, but simple, Amen to the comments above. Great points one and all. Here’s a toast to the JOURNEY toward a perfect world.

  4. […] you’re a regular reader, you’ll know I’m wary of the term best practices.  Stephen is as well, and here’s his […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: