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

What is the True Cost of an Activity’s Work? Is It Worth It?

I have been delighted that my recent blogs about aligning the program and the project, the sponsor and the project team, have gotten a very positive response. In particular, the value breakdown structure (VBS), as a tool for accomplishing this, seems to have been very well received. So this article explores the next step, how to combine the VBS with other new investment-based techniques and metrics, to ensure that project effort and money are not being frittered away on low value products and work.

It is no revelation to the business community that projects are being completed every day that fail to generate the intended benefits. Many of these can be categorized, from an investment viewpoint, as “losses” – they cost more than they turn out to be worth.

The same principal that says that such project investments are losses also says to me that, on every calendar day and throughout the world, there will be a substantial number of projects completed that include work that costs significantly more than it is worth. No, I have not conducted a study to see if such is the case (although I think that it would be a very fruitful topic for research!). Rather, I deduce this from the fact that the following important steps in measuring both value and cost on projects are simply not being done:

  • Most projects never bother to create a value breakdown structure (VBS) and so have not even a guesstimate of what the value is of any optional scope;
  • Most projects do not bother to estimate the value/cost of time;
  • Many projects (and programs!) fail to perform even rudimentary critical path schedule analysis; and
  • Even on those projects that do perform critical path analysis, they rarely compute critical path drag and drag cost up front, and almost never re-calculate it during project performance. Such re-calculation is especially crucial when the critical path changes during execution.

If all of the above techniques are not used on a project (or program), then it is very likely that the effort will include products and work that cost more than the value they add.

My recent blog articles have discussed the essence of the first of the above points, the value breakdown structure (VBS). This is a tool for prioritizing project work packages and activities by estimating their relative importance and value. Some project components (like both the left wing AND the right wing on an airplane) are mandatory: the project cannot be completed without both of them. Other components are optional, included not because they are essential but for the value they are expected to add. If you have not yet read this blog article on the VBS, I urge you to do so now and then return to the rest of this article.

The True Cost of Work (TCW)

If would-be project sponsors could simply buy the exact product they want and have it immediately delivered and ready for use, they would elect to do so almost every time. In fact, they would usually even be willing to pay a significant premium for an off-the-shelf product that precisely meets their needs rather than funding a project to create it.

Why? Because (1) there are many more risks in creating the product than in buying something that has already been made and quality-checked, and (2) the time that it takes to create something you want almost always has a cost, and sometimes a great deal of cost!

Time is money, wrote Benjamin Franklin, and it is rarely more definitively so than when the sponsor/customer has to wait for project completion. But how much money is time worth on a given project? How much would the sponsor be willing to pay for each week earlier that they would be able to deploy the desired product?

Occasionally, it’s worth very little. Rarely, it might even be worth less if delivered early because its internal systems will start to run down and/or become obsolete. But such situations are so unusual that, when such is the case, it is crucial that the project manager and team know that this project is one of those “exceptions”! (And, by the way, it is almost always due to the fact that the specific project is part of a program but not on the program’s critical path!)

In the vast majority of cases, the value/cost of time on projects ranges from moderate to, yes, vast!

  • Our intended new product can generate no value until it’s deployed.
  • Our new product is an enabler and other revenue generators need it.
  • Competitors enter the market and make our product a “me-too”.
  • Market windows are missed.
  • Market share is lost.
  • We lose weeks in implementing a tool that will result in weekly cost reduction.
  • And sometimes humans die because of the delay.

Yet, sad to say, projects are initiated with arbitrarily-chosen “deadlines” and without any attempt to quantify the value/cost of being earlier (or, indeed, later!) than that target date.

So if an earlier deployment of a product would be worth $40,000 per week to a potential sponsor/customer, surely we can see that they would be delighted to consider an off-the-shelf product that costs $2M rather than execute a 30-week project with a $1.5M budget to create a similar product. All else being equal, the project approach would have a true cost of work (TCW) of $1.5M + (30 * $40,000) = $2.7M.

The TCW is the overhead-burdened cost of resource usage plus the value/cost of the time we lose in waiting for the work to be completed. If the work is serial in nature (i.e., one activity only, or simply one activity after another), it is easy to measure the time we must wait and “charge” each activity’s duration with the cost of that time.

But what if the work comprises a project that is part of a program that has other projects occurring in parallel? Or, onion-like, if the work is an activity in a project and it has other activities occurring in parallel?

As project managers understand, the determining factor of the duration of every project (and program!) is the work, constraints, re-work, dropped batons, and other delays that comprise the longest path, i.e., the as-built critical path (ABCP)! Activities and other delaying factors that are not on the critical path (even if with only one day of float!) are not delaying completion, and in TPC (i.e., Total Project Control) terms have zero drag – and thus zero drag cost! Therefore the true cost of work that is not on the critical path (either of the program or of the project) is simply the cost of resource usage.

But the TCW for each item of critical path work is the sum of its drag cost plus its resource usage costs. Thus comes the importance of computing these on every project and program, because without that computation, you really don’t know what each item of work is costing! And if the true cost of a work package, activity or project is greater than the value that it is adding (per the value breakdown structure), we should either figure out a way to reduce its true cost (perhaps by electing to use the DRED) or jettison it from the project (or program)!

In my next article, I will talk more about how work with negative value-added (value-subtracted?) often arises. But meanwhile, you might want to take a look at this article on drag (published here in Portuguese by Peter Mello) and perhaps at the drag cost and true cost exercises on the main page. (Or just read my two new books, Managing Projects as Investments: Earned Value to Business Value or the second edition of Total Project Control).

Fraternally in project management,

Steve the Bajan