PMBOK® Guide Sixth Edition: What Would You Like to See Added?

Sometime in 2016, the next edition of the PMBOK® Guide should be published by the Project Management Institute. We could wait until too late and then complain about how the hard-working folks who author the “bible” haven’t seen fit to include our pet terms, techniques, metrics and ideas. Or we could start now by developing a list of items that we feel it should include, and perhaps either someone will notice it or we can summarize it and email it to PMI for consideration.

Toward this goal, I am starting a “PMBOK® Guide Sixth Edition Wish List” thread in the Discussion FORUM attached to this blog. I hope that readers will weigh in with their own suggestions/nominations, as well as comment on the suggestions of others. And periodically I will compile a summary of them.

For starters, here are ten items that I personally think should be included in the next edition, listed in descending order of how valuable I feel the inclusion of each would be. I will follow each with a brief explanation or descriptive link and a five-scale rating, running from VL (for Very Likely) to L to M to U to VU (for Very Unlikely), of my estimate of the probability of each being included.

  1. Change in the definition of “project” to eliminate the weasel word ”endeavor” and replace it with “investment in work”. My preferred redefinition would be: “An investment in work to create a unique product, service or result.” (No need for “temporary” either, until someone can show me something that isn’t temporary!) [U, even though this would have great benefit for the project management profession by recognizing our important role in utilizing the resources and funds with which we are entrusted to maximize value and ROI.)
  2. Expand the section on “Business Value” that was introduced in the 5th edition and that currently occupies most of pages 15-16, as well as being mentioned in the Glossary. The current description starts: “Business value is a concept that is unique to each organization.” That is indisputable. But it is also such a crucial concept (the raison d’etre of every project and/or program!) that surely it needs to be expanded to far more than two pages. Deserving of exploration are:
  • What are the commonalities of business value across any and all organizations?
  • How should it be measured? (Value is usually measured in monetary units.)
  • What generates the business value? (Answer: the product scope, with occasional contribution from the project scope if just doing the work adds value {e.g., a more experienced workforce}.)
  • What project documentation/technique should be used to define the business value? (Answer: the value breakdown structure (VBS) – which should definitely be included, and I think will be!)
  • How should business value be used to manage the other aspects of the project? (Through optimizing it in integration with schedule and cost, and using it to justify additional resources where their cost is less than the value they add.)

[VL. Business value is an obvious concept that lots of people have been writing about for a while. Whether any of the information mentioned above is included in the expanded treatment of the topic is much more doubtful. But almost any expansion would be useful.]

  1. Change the EVM term from planned value (PV) to planned cost (PC). It is cost, as the original earned value terms (that are still used in US Department of Defense contracting) BCWS, BCWP and ACWP emphasized: notice the “C” as the second letter in each of those. Yes, using two letters instead of four for each term made the metrics more accessible, and PMI has done a great job in spreading the use of the technique. However, the word “value” instead of “cost” in PV and (and in EV!) confuses people over the concept of business value. (For a great illustration of this, read Mike Hannon’s review of my book Managing Projects as Investment: Earned Value to Business Value.) [U. Okay, maybe I’m too optimistic and it should be VU. But if PMI wants (as it should!) to expand the concept of business value, it has to start clearly distinguishing between cost and value.]
  2. Include critical path drag as a scheduling metric. Wikipedia definition here. Every item on the critical path of a project or program has drag (unless two parallel paths are both critical, in which case neither has either drag or float but both, in combination, have drag compared to the next longest path). Why does the PMBOK® Guide include the non-critical float (slack) metrics but not the always-critical drag that costs the project time and money? Knowledgeable project managers are now computing drag “manually” – but drag analysis would be done so much more routinely if all the software did the calculation. That will happen someday – but much faster if the next PMBOK® Guide recognizes it. Besides, it’ll stimulate a lot of additional opportunity for PMP Exam questions! [L. Again, maybe I’m being overly optimistic — but it’s just hard to see how knowledgeable people could think that drag doesn’t belong in the Time Management section.]
  3. Stress the importance of a clear estimate of the value/cost of time as part of the charter or project business case or other initiation documentation. [U. It’s an obvious idea which would help tie PMBOK® Guide methods to the shutdown and turnaround discipline, where such estimates are standard and hugely important. I think it will happen eventually, but probably not in the 6th Edition]
  4. Include drag cost as either a Time Management or Integration Management metric, or both. Wikipedia definition here. On more than 98% of projects (by my estimation) extra duration (i.e., time on the critical path) reduces the expected value-over-cost (expected project profit (EPP?) of a project. And on those few exceptions, it’s important to know that they are exceptions! If critical path drag is included, it would be hard to understand a rationale for not mentioning drag cost. [M. Less likely to be included than plain naked drag, but still a good chance. If it is included, it would increase the chances for inclusion of #5, stressing the importance of a clear estimate of the value/cost of time.  But #5, recognition and quantification of the value/cost of time, is more important than just the act of tying it to an activity’s drag.]
  5. Mention and discuss the DIPP formula (DIPP = {$EMV of Scope ± $Acceleration or $Delay} ÷ Cost ETC} for planning, optimization and tracking. [VU. A rephrasing of the definition of “project” to include the word “investment” (see #1) would obviously make this more likely. But the “enabler” (see below) has to be recognition of projects as investments. Maybe this important metric will be included in the 7th or 8th]
  6. Recognize and discuss the multiplier effect on the value of “enabler” projects within a program, as well as the multiplier effect on an enabler’s acceleration premium and/or delay cost. The failure to recognize the special nature of enabler projects and to designate them as such leads to many bad decisions in terms of resource targeting. [U. Again, it’s an obvious and important concept. Some of the PMBOK® Guide authors are very smart people, so I hold out some hope.]
  7. Discuss/mention the doubled resource estimated duration (the DRED) as a technique for estimating the resource elasticity of an activity’s duration in response to additional resources. The DRED is an estimate of what an activity’s duration would become (shorter, longer or stay the same) if its assigned resources were doubled. [VU. Too bad, it’s a useful little tool for identifying where additional budget would help the most.]
  8. Discuss/explore the cost of leveling with unresolved bottlenecks (the CLUB). We know that resource insufficiencies cause delays. If we start measuring the value/cost of time, we will be able to quantify that cost and attach it to the specific bottleneck causing the delay. This metric is extremely valuable on a single project basis, and even more when compiled for an entire resource type or functional department across all the projects it supports – in other words, this is a toll that can move us toward right-sized staffing levels. [VU. But the CLUB is SO valuable to project and functional managers! I’m allowed to dream, ain’t I?]

Well, here are ten to start the ball rolling. C’mon, now, you must have some ideas too, don’t you? CCPM folks? Agile expansion suggestions? Add them to the list.

Fraternally in project management,

Steve the Bajan

Project Management and Senior Management: Reconciling Their Needs

I’ve been developing and teaching techniques and metrics for managing the business value of projects for over 20 years. My first major article was “When the DIPP Dips: A P&L Index for Project Decisions”, published in the Sep/Oct 1992 issue of Project Management Journal. And the first edition of my Total Project Control book included techniques such the DIPP Tracking Index, the value breakdown structure (VBS), drag cost and the cost of leveling with unresolved bottlenecks (the CLUB): all techniques for managing and tracking projects for optimum value.

But something was missing. I would explain these techniques to experienced project managers in corporate classes and PMI seminars, and from time to time I’d be hired as a consultant to help plan a big project or pull in a slipped schedule. And then I’d leave and realize that I’d only handed the organization a fish. Despite my efforts, I had failed to teach them how to implement the processes to catch it themselves.

teach a man to fish

About five years ago, during the fourth day of a corporate class on the TPC methodology, an attendee said:

“Steve, these concepts and techniques that you’ve been teaching us are great – but we’re the wrong audience. We’re just the master sergeants. You need to be teaching the colonels and generals in this company. Because they don’t understand any of this!”

I started thinking: what is it that I’m missing? Why is it that senior managers have almost no interest in learning about the techniques of something that so clearly impacts an organization’s bottom line?

And so it finally hit me: the concept that I had been talking all around for two decades, the magic word that would make senior managers sit up and take notice. Investment! The thing that senior managers do understand! Not just understand, but respect and study and believe in planning and tracking and optimizing.

Project managers are subject matter experts. They are engineers and chemists and programmers and biologists and doctors and geologists and… They know a lot! They have not only extensive education, but experience in things that it is very important to know!

Where they often don’t have a great deal of knowledge is in terms of what some would call “business skills”: investment and economics and marketing. And you know what? That’s okay! Knowing how to make sure that the building doesn’t collapse, or the airplane crash, or the software consume the hard drive, or the pharmaceutical compound kill someone, or the ground water get polluted… That’s hard and that’s important! Yes, it would be nice if these smart and conscientious folks also had business knowledge and skills – but if we want those skills, they are going to have to be “add-ons”, because these people have been busy all their lives putting their energy into other very valuable knowledge. And that’s why corporations bring in people like me to teach their SMEs project management.

Executives have learned an awful lot as well: about investment and economics and marketing and taxes and interests rates and corporate bonds and organizational structures and behavior… and that’s all important stuff too. What they don’t know about is project management. And most of the time, they are not willing to attend project management classes.

Now, I’ve met some senior managers who seem to think that project management is somehow “beneath” them. (After all, what’s the big deal about delivering a mall or a jet fighter or an oil well or a cure for depression by an arbitrary deadline for an arbitrary budget, right?) But actually most senior managers I have met are bright and conscientious people, too! It’s just that no one has explained to them why knowledge of project (and program!) management – its techniques, metrics, and governance — is importance to what they do: especially investment!

This is where both sides have to learn! They have to learn a common language. They have to institute and use common metrics that are based in the investment information that senior management respects. But those metrics must then guide the project teams in making the right decisions, and senior management must know that this is occurring.

This is the approach that I took in my book Managing Projects as Investments: Earned Value to Business Value that came out last September. It was intended to provide the “common ground”, the knowledge and understanding that both senior managers and project managers need to share. And that is why it was so rewarding for me when the June issue of PM Network included that very nice review of the book by Gary Heerkens, himself the author of The Business-Savvy Project Manager, which I strongly recommend.

Gary’s review said: “But what about during the project? Luckily, in his book,… Stephen Devaux makes solid points about what can be done to maximize ROI during project execution, and it reveals a large void in my perspective on the business of projects.”

Do not be fooled by Gary’s humility! His own book and his regular writings in his PM Network column have taught me a great deal that I didn’t know. Both of us (and let me emphasize that I have never met Gary!) share a love for project management, a desire to learn and, most important, a willingness to admit when we don’t know something. But what makes me happiest is that he identified, without any assistance from me, the deepest intention of the book: to create, define and explore that crucial nexus between the project management discipline and its techniques and the senior management interest in, and concerns about, business value and investment.

I believe project managers must say that word again and again – investment, investment, INVESTMENT! – to project sponsors and customers and all of senior management (especially, when possible, to the Chief Financial Officer!) to establish that we understand why we are doing these projects. (And then, of course, we must be sure to manage them as investments!)

By the way, I have seen this work in a slightly different arena: job interviewing. I often mentor former students through the interview process, and I always urge them to say, at an appropriate point: “Of course, all projects are investments and really need to be managed as such.” They invariably report back to me that the hiring manager’s face lights up. The next former student that tries this technique and later reports that they didn’t either get the job or at least get another interview will be the first!

This territory is also where this blog will continue to cultivate and nourish the improved status of and respect for project management. I believe it is where project/program management and business management must come together for the sake of organizational progress and efficiency.

Fraternally in project management,

Steve the Bajan

Multiproject Resource Leveling – Some Advanced Considerations

Yesterday I watched this short (2:45) video by Jennifer Bridges on the important topic of multiproject resource scheduling. I absolutely recommend it for an audience learning the basics, as it’s a good primer on the topic, with some important reminders.

However, one can only say so much in any short video. So in keeping with the general approach of this blog, I thought I would add some considerations that more sophisticated project management professionals should keep in mind. All of these (and more) are explored in depth in my book Managing Projects as Investments: Earned Value to Business Value – but I thought a quick thumbnail list might be of interest.

  1. Always optimize CPM schedules (using critical path drag and drag cost) before you plug them into the resource library and start automated resource leveling. Why? Because the software’s resource leveling algorithm resolves bottlenecks by delaying activities, never by pulling them earlier. Take as an example the case where a resource is only available the first week of each month. If your CPM schedule has that activity scheduled for the second week in April, it will slip to the first week in May. However, if your schedule optimization process had pulled it in to the last week in March, the resource-limited leveling algorithm would schedule it for the first week in April, shortening that path by a whole month. If that path is the critical path, how much is gaining a month worth? And all without increasing the budget by even a dollar.

  2. A shorter schedule is not necessarily a better schedule. What is the value/cost of time on your project? If you know that, you can justify the cost of resources when they are profitable and refuse them when they are not.

  3. Just because Project X has a bigger budget, or greater expected value, or even is managed by the CEO’s brother-in-law, does not mean it is the one that should get an over-allocated resource. The determining factors should be:

  • The amount of time that not getting the resource when it’s needed will cost in total across all the competing projects; and
  • The value/cost of that time on each project.

These factors must be quantified (i.e., monetized) and the decisions made on the basis of greatest benefit to the overall organization.

  1. The amount of time that a project is delayed due to resource bottlenecks is, in Total Project Control terms, called resource availability drag (RAD), i.e., the project delay caused by insufficient resources. But the value lost through such delay is called the cost of leveling with unresolved bottlenecks (the CLUB). That dollar value, if known to the project manager, can be used to justify targeting the needed resource to their own project.

  2. The CLUB for a particular resource, on all projects over a period of time (a quarter, a year) can add up pretty quickly. Organizations are not tracking this vital metric for “rightsizing” an organization’s staffing levels. This is a crucial function that a good PMO can serve, greatly justifying its existence for the next time the “costcutters” want to get rid of it.

  3. Finally, remember that the resource-leveling algorithms in project management software packages can vary greatly in terms of functionality and robustness. Some automated resource leveling algorithms are woefully inadequate, adding time needlessly to a project schedule. A good project manager can often improve the post-leveling schedule by eyeballing it and making intelligent decisions.

I explore this subject much more thoroughly in my two books.

Fraternally in project management,

Steve the Bajan