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

Weekend Puzzler: Computing Critical Path Drag on a Project to Save Lives

There has been a lot of discussion of critical path drag and drag cost recently, both in this blog and elsewhere. Most salient was Blake Sedore’s MIT paper about using critical path drag to optimize manufacturing throughput, but there was also this very nice out-of-the-blue comment on LinkedIn, and a number of email conversations. Maybe the importance of these concepts is finally trickling into general awareness.

So with the weekend here (a long one in the US!), I decided it was time to provide another “Weekend Puzzler” of practice in computing drag and drag cost. So I’ve drawn a network diagram below, with all the dependencies finish-to-start (FS), just to make sure it isn’t too complicated. And if there is any step you feel is too complicated or tedious (perhaps like the forward and backward passes), just jump over it to the next diagram, which will have the answers.

To emphasize the importance of these computations, I’ve chosen a project that is intended to save lives: an immunization program, hospital construction, or medical device development, perhaps. But the calculations would be the same if the only benefits were monetary.

After the fourth diagram, there are some additional questions, with the “poll” function making it a multiple choice quiz. I’ll provide the answers and explain them on Tuesday.

And by the way, next week should be interesting in any case. I am hoping to launch a discussion forum, where readers can raise topics they want to discuss, or make general comments. Additionally, I believe the June issue of PMI’s PM Network magazine will become available on-line, and I have reason to believe there may be a very interesting article in this issue.

Have a great weekend, and the Puzzler is directly below.

Fraternally in project management,

Steve the Bajan

Weekend Puzzler

A.  Compute the forward and backward passes for early and late dates, identify the critical path and compute total float.

Fig 1 All FS network lives for blog

B.  These are the answers to A. Now compute the drags of the critical path activities.

Fig 2 All FS network lives for blog

C.  These are the answers to B. Now compute the drag cost in lives not saved for each of the critical path activities.

Fig 3 All FS network lives for blog

D.  These are the answers to C. Use them to answer the multiple choice questions in the “poll”.

Fig 4 All FS network lives for blog

What’s Costing Time? CPM vs. Critical Path Analysis

The most recent article on this blog, regarding the MIT paper about using critical path drag to optimize manufacturing throughput, generated a number of interesting reactions. First, it has been very popular, attracting well over 100 views per day and several “Likes” in the LinkedIn discussion forums where I mentioned it. However, some people seem to have negative views about the value of such a process. All these people seem to be conflating critical path analysis and CPM and they specifically reject CPM as a worthwhile scheduling technique, expressing a preference for critical chain scheduling or one of the flavors of agile methodologies.

So let me try to improve my communication technique: there is an important difference between CPM and critical path analysis!

  • The former is a technique for developing a schedule for a project, and is almost always performed upfront.
  • The latter is a technique to analyze the detailed aspects of any process (like manufacturing), project or program, upfront, during progress, or after completion, with the purpose of identifying, measuring and perhaps reducing the total duration of execution.

Why should we want to reduce the duration of a process or project? Because, to paraphrase what a really smart guy wrote over 260 years ago: “Time is a whole lot of benjamins!” If we start recognizing that all projects and programs are, as my book emphasizes, investments, then we will quickly conclude that two major factors that impact project investment value are:

  • Scope; and
  • Total duration.

Along with that important but often over-emphasized third constraint of cost, these are the parameters over which project teams have some control, and that project and program managers are paid to manage. And we control completion date through the critical path – of any process, project or program!

Whether a project is scheduled using “naked” CPM or resource leveling or critical chain or agile or darts at a dartboard, at the end it still will have an “as-built” longest path (comprised of activities, constraints, sprints, stumbles, dropped batons, feeding buffers, schedule reserve, hesitations, and any other delays) that always determines its total length. Surely if time has value (as it does on 99% or more of projects!), then it must be worthwhile analyzing:

  1. What items are extending the duration (i.e., have critical path drag)?

  2. By how much?

  3. How much is that extension reducing investment value?

  4. What might we be able to do to reduce that negative impact?

traffic jam

It doesn’t matter what method of scheduling we used! Even a serial string of sprints, if analyzed, will usually reveal a place where we can shorten the critical path by adding a resource, or dividing the process into parallel streams, or deciding not to include functionality whose value-added is worth less than the time it consumes (i.e., its drag cost). And if someone says that doesn’t happen, how do they know unless they do the analysis and determine which sprints/activities/resources/rework have how much critical path drag?

If some item that you need to perform your project is really expensive, wouldn’t you try to see if you could get it for less? Well, how is that any different from using critical path analysis to identify the big drag cost items and seeing if you can perform them for less?

That is part of the beauty of Blake Sedore’s analysis for his MIT Master’s thesis. It’s entirely possible that the manufacturing organization was comfortable with their process, and felt that it was optimized. Then he performed the critical path analysis, identified where the drag was, figured out how to reduce it, and voila! – throughput and value were increased!

Whatever the scheduling method, critical path analysis has always had value. I remember reading an article over 20 years ago about how Motorola used it to increase throughput on the shop floor of their pager division. But the enhancement of critical path drag computation puts the emphasis where it belongs: not on what can take longer without causing delays (i.e., float), but on what’s causing how much delay. The technique for computing it is straightforward, if somewhat brain-intensive in a complex process or project.

A process that is both brain-intensive and can add a lot of value – gee, that sounds like just the sort of thing software packages should compute!

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

“Whaddya do when the critical path changes?”

The title of this blog post may, alas, be a surprise to some less experienced project managers. “What – you mean the critical path might change?” Not only might it change, but if you did a good job of schedule optimization during your upfront planning, it very likely will change!

That’s because time is money and project value is usually increased by a shorter project schedule. The optimization process is usually one of iteratively squeezing critical path drag out of the longest path through fast tracking and added resources, thereby reducing float on the other paths. With less float, it often doesn’t take much delay for a secondary path to become critical, even though the entire project duration is still a lot shorter than it would have been without optimization, and the project will be more profitable.

But when a secondary path becomes critical, lots of important things change. Not only do activities that had drag now have float, but activities that had float now have drag! And drag cost! The basis for our critical path analysis is altered, and should require examination and re-evaluation of all our critical path activities, constraints and resources.

Let’s start by looking at a simple project network diagram as shown in Figure 1:

Figure 1 The VBS with Network

This diagram may contain info which some readers are not familiar with seeing in a project schedule. First, it includes the output of our value breakdown structure (VBS). As you can see, each box contains a letter, either M or O.

  • M stands for Mandatory and means that the activity must be performed as part of the project or the project will have no value. The value-added of all mandatory activities is equal to the project’s expected monetary value (EMV). Since the information at the top of the figure says that the project will have an expected value of $400K if completed on Day 55, and since the current schedule is 55 days, all mandatory activities have a value-added of $400K.
  • O stands for optional. These are activities that add value, but the project would have value even if they were excluded. All projects have such activities, and it is important both to recognize them and to estimate the value they are adding to the project. In Figure 1, Activities C, D, E and H are all optional, with value-addeds estimated to be 50%, 40%, 80% and 20%, respectively, of the project’s value.

In Figure 2 below, I have computed the drag, drag cost and true cost (TC) (TC = drag cost plus budget) for all the activities. If you want, do those calculations for practice before you look at Figure 2.

Figure 2 The VBS with drag drag cost and true cost

Notice that the planned true cost of activities that are not on the critical path is equal to their budgets, as they have no drag and thus zero drag cost.

With both the value-added and the true cost of each activity computed in Figure 2, we can now compute the net value-added (NVA) (NVA = value-added minus true cost) of each activity and ensure that each is worth performing. This is displayed in Figure 3.

Figure 3 Full network diagram including value addeds

As shown in Figure 3, all the activities have a positive NVA. The lowest NVA is Activity H, which has a value-added of only 20% of the project’s EMV, or $80K, but a TC equal to its budget of only $30K, for a net value-added of $50K.

Okay, so all is hunky-dory and we start the project with this plan. And then things start to happen. To be precise, Activity C, planned to take 13 days and finish at the end of Day 23, takes an extra 7 days and does not finish until the end of Day 30. As shown in Figure 4, this can change everything that’s important!

Figure 4 full network diagram after slippage

Suddenly, the critical path has changed and now goes through Activities F, H and I. Additionally, the project’s planned duration has slipped by two days, with a delay cost of $50K per day. As a result, the project’s EMV has slipped to $350K and the value of each activity, both mandatory and optional, has slipped accordingly.

What should happen immediately is that sirens should wail, warning the project manager that Activity H, with a value-added of just 20% of $350K, or $70K, now has a negative NVA due to the fact that it now also has drag of 2 days and thus drag cost of $50K. Its true cost is $80K, $10K less than the value it is adding. Either figure out a way to change the schedule (adding resources or changing the network logic) or jettison Activity I – the project will generate $10K more expected profit without it!

Two final points:

  1. $10,000 may not seem like much – but this is just an example. Projects are being performed every week that include work which, for the same reason as shown here, costs millions of dollars more than its worth.
  2. The only way to identify when this is happening is to have all the Total Project Control (TPC) data for both activity value-added and drag cost estimated and computed.

Fraternally in project management,

Steve the Bajan

The Benefits of Recognizing Projects as Investments: “And yet, it moves!”

One of the great afflictions of mankind throughout history has been the stubborn refusal of certain figures who see themselves as ”authorities” to alter their views in light of new ideas and evidence.

In the 17th and18th centuries, combustion was explained as the escape of a substance called phlogiston from a material. This theory was staunchly defended even after it was shown that magnesium gained mass when it burned. Finally, Antoine-Laurent Lavoisier proved conclusively that combustion was the combining of a material with oxygen. This new explanation led to giant steps forward in both physics and chemistry.

Galileo

Some of the most stubborn ideas are those that come with the imprimatur of sacred scripture. Thus the heliocentrism ideas of Copernicus, Kepler and Galileo were banned by the Vatican as conflicting with the Bible and the teachings of the Council of Trent. Galileo was threatened with burning as a heretic, placed under house arrest, and left only able to mutter about our planet: “Eppur si muove.”

Yesterday I had a discussion on a LinkedIn group in which I tried to explain that, in fact, all projects are investments and that recognizing them as such could have great benefit both for the development of better management techniques and metrics and for the greater esteem for our discipline. Alas, I ran into an individual who refused to accept any definitions or techniques beyond the pages of the Fifth Edition of the PMBOK® Guide.

Make no mistake – I regard the Guide as a very valuable book. But both I and PMI also regard it as a guide, and not as the entire body of knowledge of project management! It is also an evolving document, or there would be no need for new editions.

There are techniques and tools and metrics and, yes, definitions that are being used within our discipline that have not yet made it into the PMBOK® Guide. Undoubtedly many will some year. Critical path drag is an example – every project, however scheduled, has a longest path of activities and other delaying factors, and the amount that each item on that path delays completion is its drag. And drag is always there, and has been since the pharaohs’ projects, whether we and our software compute it or not! And this metric is enormously helpful whenever we are seeking places to compress our schedule! (Many clients have employed me over the years to use this technique to recover schedule.)

So what about the definition of a project that I use in my books?

“A project is an investment in work to create a product, service or result.”

First, is there anyone (apart from the gentleman from the LinkedIn group) who would argue that projects are not investments?

  • Investment: “1 The action or process of investing money for profit or material result;.. 1.2 An act of devoting time, effort, or energy to a particular undertaking with the expectation of a worthwhile result.”

http://www.oxforddictionaries.com/us/definition/american_english/investment

I believe we would all agree that every project is undertaken only if its probability-weighted value is expected to be greater than the cost (i.e., the invested amount). If we need a definition for value, the very first definition from the same source seems applicable:

Value: “1 The regard that something is held to deserve; the importance, worth, or usefulness of something”

http://www.oxforddictionaries.com/us/definition/american_english/value

A project’s value may be:

  • Revenues from a new product or service;
  • Future cost savings;
  • The opportunity to keep a plant open instead of being forced by the government to close it;
  • Avoiding fines;
  • Garnering votes;
  • Prosecuting criminals;
  • Saving lives; or
  • Any other of dozens of efforts intended to create a valuable result.

So every project is definitely an investment. But what might be the benefits of staring to recognize them as such?

  1. Project management would start to focus on the quantified aspects of those things that impact the value of the investment: the Golden Triangle of the integrated value/cost of scope, time and resource usage.
  2. Project managers would work harder to align the scope of the project with the benefits wanted by the sponsor/customer through the collaborative development and implementation of a value breakdown structure (VBS) and other techniques. (The failure to actually deliver the benefits for which a project is undertaken is a big issue in many circles, and this would help to solve the problem.)
  3. The value/cost of time on a project, which is currently almost always left as an unquantified externality and therefore rarely managed in terms of its actual impact on the investment, would suddenly be recognized for its importance. Many scheduling techniques that experienced PMs have mastered, like critical path analysis and resource leveling, would therefore suddenly be fully appreciated.
  4. Both drag cost and the true cost of work could be easily computed, meaning that activities on the critical path would be evaluated not only on the basis of their resource costs, but also their drag costs in terms of how much their drags are reducing the value of the investment. (True cost = resource costs plus drag cost.)
  5. Decisions across the Golden Triangle would be quantified in terms of investment value. Should we employ an additional resource costing $10,000 on a critical path activity? Well, will it reduce the drag cost by more than $10,000? Or would we be better off jettisoning that activity because its true cost will be greater than its value-added?
  6. We will be able to track each project during performance not just on the basis of earned value cost and schedule metrics, but on the basis of investment metrics: the expected project profit (EPP) of the project as tracked through the DIPP and the DIPP Progress Index.

All of these are just a sample of the benefits that would accrue if we start dealing with projects as investments. I believe that practitioners would rapidly develop new metrics and techniques to do an even better job of measuring and ensuring greater project investment value.

But perhaps the most important benefit would be for our profession: the value of project managers and project management techniques and contributions would become clearly measurable in value/cost terms. Instead of being looked upon as “overhead on cost centers” project managers would become valuable contributors to the organization’s bottom line.

Surely this would only help PMI to market its ideas and techniques to senior managers who know little about projects, but who care a great deal about investments!

Fraternally in project management,

Steve the Bajan

What is the most important metric of critical path analysis?

For starters, let’s make an important distinction: there is a difference between CPM scheduling and critical path analysis.

  • CPM is a technique for developing a project schedule by estimating the duration of each activity and then sequencing them in the logical order in which they can occur.
  • Critical path analysis is the process of analyzing any schedule, no matter how it was originally developed – traditional CPM, resource-leveled critical path, CCPM, agile, or darts at a dartboard – in order to make improvements.

If the duration of the project is significant, then it is always important to perform critical path analysis, because every project’s duration will be exactly equal to its actual longest path, or what in the construction industry is referred to as its as-built critical path (ABCP). That path may include activities, constraints, resource bottlenecks, sprints, stumbles, dropped batons, rework, or any other type of delay. But the analysis of those delaying factors should always be a prime concern of the scheduler and project team.

And although there is certainly value to be gained through a post mortem process, mightn’t there be even more value in doing it while the patient is still alive?

Why is critical path analysis so important? Because:

  1. On the vast majority of project investments, expected value/ROI is impacted by completion date. Earlier completion usually leads to:
  • Greater total value;
  • Faster generation of that value; and
  • Elimination of the risk of later completion!
  1. If there is value in shortening the project duration, that can only be accomplished by reducing the length of the longest path.

So what is the most important metric of critical path analysis? It’s certainly not float, either total or free. Float is a measure of the extra time you’ve got, and is (almost always!) on activities that are, specifically, off the critical path.

If critical path analysis is intended to increase the value of the project investment by shortening the schedule (perhaps up front, perhaps after slippage), then the most important metric is surely one that applies to the longest path! It’s the one that will help the project team to identify how much time each critical path activity, constraint, resource bottleneck, sprint, stumble, dropped baton, rework, or other delaying factor is currently adding to the remaining project duration! It’s the one that, when changes are made to pull in the longest path thus making another path longest, will identify how much time each item on the new CP is delaying completion! And when you make changes on that new CP and are now constrained by yet another longest path, will quantify the delays that its items are causing!

That metric is critical path drag, and I maintain that it is, by far, the second most important (critical?) metric in critical path analysis. Why only the second most important? Because the most important is drag cost, i.e., by how much is the drag of a critical path item reducing your project’s expected value. That is the most important metric because that’s the one that will allow the project team to optimize the project investment (the ultimate goal of every project!) by justifying the cost of resources by $X to reduce the drag cost by $2X! But of course you can’t get drag cost until you’ve first computed drag.

Let me make one point clear: Steve Devaux did not invent drag! Drag is always there, and has always been there – on the items (activities, etc.) on the longest path of every project, going back to the building of the pyramids and before! We can compute it or we can ignore it – but it’s still there! All that I did is figure out the rules for computing it as I helped my consulting clients compress their schedules. How did I figure it out when others hadn’t? Because as an engineer in one of my corporate classes said to me about five years ago: “Y’know, Steve, you have an amazing grasp of the glaringly obvious.” And critical path drag and its value as a metric is glaringly obvious!

So why is critical path analysis, for the most part, not being performed? Because the project management community, more than half a century after the initial principles of CPM were published, 16 years after the first edition of my Total Project Control book came out, six years after Bill Duncan’s article “Scheduling Is a Drag” appeared at ProjectsatWork.com, three years after Defense AT&L Magazine published “The Drag Efficient: The Missing Quantification of Time on the Critical Path”, five years after Spider Project released a software version that computes critical path drag, and two years after I presented this webinar for PMI’s Scheduling Community of Practice, remains blissfully unaware of the key enabling metrics.

So I conclude with four questions:

  1. Despite the fact that so many people pay lip service to critical path analysis, why would anyone perform it on a network of 1000+ activities when their software does not support the metrics that make it valuable and simple?
  2. Why would project management professionals perform such analysis when the supporting metrics are not in PMI’s PMBOK® Guide, nor in its Scheduling Standard, nor in any of IPMA’s published methodologies?
  3. Why do software companies and project management professional organizations not support/publicize the metrics that enable this analytical tool that is fundamental to the discipline of project management?
  4. Why do slipping project schedules so seldom recover?

If you want to learn how to compute drag and drag cost manually, check out the exercises (with answers) on under the EXERCISE tab at the top of the page.

Fraternally in project management,

Steve the Bajan

Weekend Puzzler: Computing the Value/Cost of Time on an Enabler Project

The past several blog articles have been discussing the value breakdown structure (VBS). We still have a bit more to cover on that topic, and I’ll get to that next week.

However, the weekend is upon us, and several readers emailed me that they really enjoy the Weekend Puzzler exercises. So I have put together one on a topic that we will get to soon: the value, and the value/cost of time, of enabler projects.

Identifying enabler projects and computing their true value is extremely important for any organization, and especially for a project manager who is trying to justify the resources that they know they will need. We will explore the important topic of projects in the coming weeks – but for now, and for your weekend puzzling, here is an exercise, with answers below, that should get across some important concepts.

If you want to learn more about managing enabler projects (and indeed, about pretty much everything in my blog!), try my two new books, Managing Projects as Investments: Earned Value to Business Value and Total Project Control: A Practitioner’s Guide to Managing Projects as Investments.

Two Projects in a Program: The Values of Project Steel Donkey and Project Rock Stone

(Among the questions below, the most important information for a project team to understand is in Question #7: the value/cost of time on an enabler project! It is crucial that business analysts provide this analysis for project teams!)

NOTE: For this exercise, all dollars are in current dollars.

You have been put in charge of Project Steel Donkey, a 12-month-long effort to develop and implement the Steel Donkey enterprise-wide system, which is expected to improve efficiency and reduce our organization’s overhead costs by $200,000 per month over the next three years. The budget for the project is $5 million.

One of the advantages of the Steel Donkey system is that, once implemented in its basic form, it can be extended.

The key planned extension is a real-time data communication system for our field personnel that should accelerate decision-making. Such an extension is expected to increase annual revenues. Our business analysts have estimated the probabilities of increase to be as follows:

  • 50% chance of $1 million/month for two years after the extension is put in place.
  • 25% chance of increase of $500,000/month.
  • 25% chance of no change.

The enhancement project, named Project Rock Stone, is expected to take 12 months, and will have a budget of $6 million.

But such an enhancement project cannot start until immediately after Project Steel Donkey is over and the overall system is operating.

  1. What is the total savings, just in overhead costs, expected for the three years after Project Steel Donkey is completed? A. $200,000   B. $720,000   C. $7.2M   D. $36.0M   E. None of the above
  1. What is the average monthly increase in expected revenue for the two years after Project Rock Stone (i.e., three years after Project Steel Donkey) is completed, if Project Rock Stone is completed on schedule? A. $13.5M   B. $15.0M   C. $24.0M   D. $27.0M   E. None of the above
  1. What would be the two-year expected project profit (EPP) of Project Rock Stone if completed on budget in 12 months? A. $4.5M   B. $10.0M   C. $18.0M   D. $21.0M   E. None of the above
  1. What is the three-year expected monetary value (EMV) of Project Steel Donkey if completed in 12 months? A. $7.0M   B. $12.2M   C. $16.2M   D. $22.2M   E. None of the above
  1. What would be the three-year expected project profit (EPP) of Project Steel Donkey if completed on budget in 12 months? A. $2.2M   B. $7.2M   C. $10.2M   D. $11.2M   E. None of the above
  1. What would be the impact on two-year revenues of finishing Project Rock Stone one month earlier or later? A. $625,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above
  1. What would be the acceleration premium or delay cost (i.e., change in EMV) for finishing Project Steel Donkey one month earlier or later? A. $200,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above
  1. What would be the DIPP at the start of Project Rock Stone, with a budget of $6 million and a schedule of 12 months? A. 1.50   B. 2.00   C. 2.50   D. 3.70   E. None of the above
  1. What would be the DIPP at the start of Project Steel Donkey, with a budget of $5 million and a schedule of 12 months? A. 1.50   B. 2.44   C. 3.05   D. 3.24   E. None of the above
  1. What would be the expected project profit (EPP) and DIPP be for the entire program? A. $0.2M & 1.01   B. $11.2M & 2.02   C. $22.2M & 2.02   D. $33.2M & 3.01   E. None of the above

Written down your answers? Now scroll down for the answers and explanations.

Answers to the Weekend Puzzler: Value/Cost of Time on an Enabler Project

  1. What is the total savings, just in overhead costs, expected for the three years after Project Steel Donkey is completed? A. $200,000   B. $720,000   C. $7.2M   D. $36.0M   E. None of the above

Answer: C. $7.2M.

Explanation: 36 months * $200,000 = $7.2M

  1. What is the average monthly increase in expected revenue for the two years after Project Rock Stone (i.e., three years after Project Steel Donkey) is completed, if Project Rock Stone is completed on schedule? A. $13.5M   B. $15.0M   C. $24.0M   D. $27.0M   E. None of the above

Answer: B. $15.0M.

Explanation: The expected monetary value (EMV) of potential revenues = the probability of them occurring times the value of the revenues.

The probability of generating revenues of $1M/month = 50%.

EMV = 50% * (24 months * $1M) = 50% * $24M = $12M.

The probability of generating revenues of $0.5M/month = 25%.

EMV = 25% * (24 months * $500,000) = 25% * $12M = $3M.

Total EMV of Project Rock Stone over two years = $12M + $3M = $15M.

  1. What would be the two-year expected project profit (EPP) of Project Rock Stone if completed on budget in 12 months? A.$4.5M   B. $10.0M   C. $18.0M   D. $21.0M   E. None of the above

Answer: E. None of the above.

Explanation: EPP = EMV – expected project cost

= $15M – $6M = $9M

  1. What is the three-year expected monetary value (EMV) of Project Steel Donkey if completed in 12 months? A. $7.0M   B. $12.2M   C. $16.2M   D. $22.2M   E. None of the above

Answer: C. $16.2M.

Explanation: EMV of an enabler project = the EMV of the project itself plus the EPP of all projects it enables.

Therefore the EMV of Project Steel Donkey = its own EMV + the EPP of Project Rock Stone

= $7.2M + $9M = $16.2M

  1. What would be the three-year expected project profit (EPP) of Project Steel Donkey if completed on budget in 12 months? A. $2.2M   B. $7.2M   C. $10.2M   D. $11.2M   E. None of the above

Answer: D. $11.2M.

Explanation: EPP = EMV – expected cost of Project Steel Donkey =

$16.2M – $5.0M = $11.2M

  1. What would be the impact on two-year revenues of finishing Project Rock Stone one month earlier or later? A. $625,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above

Answer: A. $625,000.

Explanation: Impact = the gain or loss of expected monthly revenues for one month = $15M / 24 months = $625,000/month.

  1. What would be the acceleration premium or delay cost (i.e., change in EMV) for finishing Project Steel Donkey one month earlier or later? A. $200,000   B. $825,000   C. $7.2M   D. $11.2M   E. None of the above

Answer: B. $825,000.

Explanation: Impact = the gain or loss in expected monthly savings + revenues for one month on both Project Steel Donkey AND on the enabled Project Rock Stone = $200,000 + $625,000 = $825,000.

  1. What would be the DIPP at the start of Project Rock Stone, with a budget of $6 million and a schedule of 12 months? A. 1.50   B. 2.00   C. 2.50   D. 3.70   E. None of the above

Answer: C. 2.50.

Explanation: EMV = $15.0M. Budget = $6.0M.

Starting DIPP = $15.0M / $6M = 2.50

  1. What would be the DIPP at the start of Project Steel Donkey, with a budget of $5 million and a schedule of 12 months? A. 1.50   B. 2.44   C. 3.05   D. 3.24   E. None of the above

Answer: D. 3.24

Explanation: EMV = $16.2M. Budget = $5.0M.

Starting DIPP = $16.2M / $5.0M = 3.24

  1. What would be the expected project profit (EPP) and DIPP be for the entire program? A. $0.2M & 1.01   B. $11.2M & 2.02   C. $22.2M & 2.02   D. $33.2M & 3.01   E. None of the above

Answer: B. $11.2M & 2.02

Explanation: For Project Steel Donkey, the DIPP acts as a tracking mechanism for project performance. Project Steel Donkey’s the EPP (and thus the numerator of the DIPP) include all of its equity: its expected savings AND the probability-weighted increase in revenues from Project Rock Stone. However, the cost responsibilities and authority of Project Steel Donkey are limited to the costs of that project only, or $5M. That determines its value/cost of time, and those are the metrics against which it should be measured and tracked.

However, the program as a whole includes the EMVs and budgets of BOTH projects. Thus the program EPP would be:

($7.2M + $15.0M) – ($5.0M + $6.0M) = $22.2M – $11.0M = $11.2M

The Starting DIPP would be EMV divided by program budget, $22.2M / $11.0M

= $22.2M / $11.0M = 2.02

So how many did you get correct?

Fraternally in project management,

Steve the Bajan

How to Use the VBS and Critical Path Drag to Ensure Maximum Project/Program Benefits

In recent articles, I have written about the value breakdown structure (VBS) and tried to show the benefits it offers to both program and project. One of the most important of these is the ability to align the business benefits that the sponsor/customer/program manager wants to the products and work that will create those benefits.

The VBS may be created for projects within a program or for work packages and/or activities within a project. Once the upper levels of the plan (i.e., the major summary elements of the work breakdown structure) have been conceived, communication between the sponsor/customer/program manager and the project manager/team should start, ensuring that the planned elements will in fact create the desired benefits as well as prioritizing the elements.

The initial stage of prioritization is between mandatory and optional work.

  • Mandatory work is that which must be performed or else the project/program will have no value. The value-added of mandatory work is therefore equal to the expected monetary value (EMV) of the entire project/program.
  • Optional work will add value to the project/program, sometimes great value – but the rest of the work would have value even without this particular item. The value-added of optional work is therefore equal to the difference in EMV of the entire project/program with and without this particular product or work item.

Ultimately, it is the optional work that can provide “wriggle room” when the project is being performed – but also can cause lots of mischief, either by being omitted when it shouldn’t be or included when it should be omitted. In other words, optional work often requires decision-making. This is one reason why the MoSCoW method, which simply separates optional work into Should, Could, and Won’t categories, is insufficiently granular. If we are deciding whether or not to invest in a specific element of work, we need a monetary estimate of both its value and its cost.

In the last article, we defined the concept of the true cost of work (TCW) in a program or project:

  • If a work item is on the critical path, its true cost is the sum of its resource costs and its drag cost, the latter being the value/cost of the time that the work item’s duration is adding to the critical path.
  • If an activity is off the critical path, its drag and drag cost are both zero, so that its TCW is only the cost of its resources.

This important distinction means that one can have a situation where a valuable (“Should”) work item ought to be omitted in favor of a low value-added (“Could”) work item, if:

  • The Could item is off the critical path with a value-added of $40,000 and a resource budget of $20,000; and
  • The Should item is on the critical path with a value added of $200,000, but with a resource budget of $30,000 and drag of three weeks at a drag cost of $60,000 per week.

Remember: chances are that the sponsor/customer/program manager will not know the details of the work, in terms of schedule and cost, two levels down from them. That is why this example is crucial in demonstrating how important it is that the project manager/team, who should know such details:

  1. Understand the desired benefits of the work;
  2. Understand how the components/work items are aligned with those benefits;
  3. Understand the relative priorities of those components/work items in monetized value-added terms (i.e., the VBS);
  4. Understand the monetized value/cost of time on the project/program;
  5. Perform critical path analysis up front and periodically during execution, including
  6. Computation of critical path drag and drag cost; and
  7. Ensure that no work is costing more than the value it is adding.

The sponsor/customer/program manager will not have this information; only the project manager and team will. Therefore it is of utmost importance that the sponsor/customer/program manager ensures that the project manager and team have the information, knowledge and skills (each as enumerated above) to ensure that the desired benefits are generated without wasted effort and money.

Unfortunately, what percentage of sponsors/customers/program managers know how to do this?

In my next blog article, I plan to show how to use the VBS information in combination with schedule data in a network diagram that includes critical path drag, drag cost, and true cost to determine when an optional activity goes from value-added to value-subtracted.

Fraternally in project management,

Steve the Bajan

Ten Amendments to the Current Practice of Project Management

I believe that project management is, in many ways, failing in what should be its purpose: to provide a valuable return to the investor(s) who provide the resources/money for the project effort and who hope to reap the benefits. But I don’t happen to feel that we need a whole new methodology. The basic tools in our toolbox (WBS, critical path analysis, resource leveling, activity-based resource assignments, earned value tracking) are wonderful techniques, and are being efficiently applied by many project managers.But in many other cases, projects are generating much less value than they should.

I do believe that some of the tools, as valuable as they are, need what I’d call “amendments”: sharpening, enhancing or re-shaping for wider utilization – such as the routine incorporation of the drag metric as a standard part of critical path analysis. But the major flaws, I believe, are not so much in the tools as in how they are being misunderstood and misapplied.

I‘ve been thinking for some time about preparing a list of “Amendments to Current Project Management Methods”. Below is a pretty barebones outline, without getting into a huge amount of explanation (because I just wrote a 255-page book that pretty much provides that!), which lays out some of the techniques and modifications that I feel would significantly improve the way we do projects.

This list will probably evolve over the months ahead (and I’m certainly willing to entertain other suggestions), but the Ten Amendments below ain’t bad for a start:

  1. Get agreement from everyone (team members to senior management and customers) that projects are investments.
  2. Get them to agree that investments should be undertaken for the value they are expected to generate.
  3. Get them to understand that the value/benefit they expect from the project will be based on its scope (mostly product scope) and that therefore the specifics of the product scope should designed with those benefits in mind. [This should lead to the creation of a value breakdown structure (VBS)].
  4. Get them to agree that the results of all investments are not guaranteed, but rather involve estimates, uncertainty and risk. Explain that “deadlines” and fixed cost caps (“budgets”) are arbitrary strictures that are far more likely to cause negative behaviors (e.g., Parkinson’s Law, or secretively cutting quality to meet deadline/budget, or simply taking unwarranted risks when pushed for time/cost adherence) than to have magically made an accurate prediction of what the project would really require. Suggest instead getting the organization used to the terms “target date” and “target cost”.
  5. Get everyone to agree that, the vast majority of the time, project delivery date has a big impact, positive or negative, on the expected value of that scope. This should lead NOT to a deadline, but to an estimate of the value/cost of each unit of time earlier OR later than the target date. And this quantified estimate should be a part of the initiation documentation of every project! And any contract for a project should include clauses establishing incentives (positive and negative) for schedule performance, aligning as much as possible the potential benefits to customer and contractor.
  6. Show everyone how, with the expected value of scope, the value/cost of time, and resource usage all quantified in monetary terms, the three sides of the “Iron Triangle” are now all integrated and monetized so that it has become the Golden Triangle. Any variance in any side will have a quantified impact on the integrated value of the project as measured by expected project profit (EPP) and the DIPP. Show how this now provides a single metric against which project performance can be tracked, with better performance being measured not just in schedule or cost terms, but in what should matter to everyone and particularly to those funding the project: investment value, or ROI, or expected project profit!
  7. Ensure that everyone understands that every project, no matter how it is scheduled, will be precisely as long as its longest path of activities, logical constraints, resource constraints, delays, rework, sprints, and stumbles! And therefore no matter how it has been scheduled, critical path analysis that includes drag, drag cost, and true cost (TC = drag cost plus resource costs) computation must be performed, seeking opportunities to reduce drag costs and thus accelerating the schedule where greater project profit can be generated. Everyone should also understand that the value/cost of time on enabler projects (i.e., those that enable other projects to generate value) go through a multiplier effect, and thus identify such enabler projects and their elevated value/cost of time.
  8. Ensure that both time-limited and resource-limited resource leveling is performed on each project, and on all projects (and especially prospective new projects!), within the portfolio of a multiproject organization. The data regarding the cost of delays caused by insufficient availability of each specific type of resource should be analyzed on an organizational basis at least quarterly, with Pareto charts assembled to identify and quantify the project delay costs to the organization of resource insufficiencies on the critical paths, and to improve efficient levels of staffing for each resource type and functional department.
  9. Ensure that everyone understands that earned value is not about project value, but about project cost, i.e., resource usage! The term has been the source of persistent confusion. Even to a contractor, project value almost always includes value drivers that are not part of the price/budget. On a medium sized project in an organization without robust financial tools, earned value planning and tracking can be performed adequately on the basis of planned and actual labor hours. (Indeed, CPI-Labor should be an important metric in any EVM system.) Everyone also should know that earned value is inadequate for schedule tracking, at least in the way it is customarily applied, and can lead to incentives for out-of-sequence and noncritical work. Schedule must be tracked through critical path tracking and/or by developing a separate earned value baseline for schedule tracking that takes into account the critical path by being scheduled on the late dates.
  10. Ensure that project postmortems are performed on all significant projects (not just on those that went badly!) and that the as-built critical path (ABCP) is presented as one of the key artifacts for lessons learned, particularly in identifying causes of project delay with their quantified costs. And that every postmortem sets a future date on which the data on the mature final product can be analyzed with greater knowledge and objectivity so that current assessments of quality, durability, and value (including revenues/savings) can be updated.

Okay, so at least that’s a start. And I think implementing these would make a huge difference. So anyone have additional suggestions?

Fraternally in project management,

Steve the Bajan