How to Make Critical Path Drag a Standard Scheduling Metric?

Okay, so I’m asking.

And this question and article are timed to inaugurate the new discussion forum part of this site, where readers can now go to:

  • Respond to discussion topics like this one and others I will be launching, and
  • Start their own threads to discuss Total Project Control techniques and/or other project management (or other!) topics that are of interest.

Just click on the FORUM tab, and please keep all discussions respectful and courteous. Now back to the point of this blog, to which you can then post your reactions in the Discussion Forum.

****

Critical path drag is not, in my opinion, the most valuable innovation that I have included in my books Managing Projects as Investments and Total Project Control. I think the focus in those books on defining and planning projects as investments and then tracking them in scope/cost/schedule integrated fashion through the DIPP and the DPI indexes is what can take project management, and the project manager role, to the next level of professionalism. But critical path drag is the metric and technique whose value is the most obvious and whose omission from critical path analysis is the most glaring! Why no one previously “discovered” it and its implications, or figured out how to calculate it, is a complete mystery to me. (A student of mine once remarked that I see things that are glaringly obvious!) Yet, 16 years after the first edition of Total Project Control was published, the metric is still not in the PMBOK Guide ® and only one PM software package (Spider Project) currently computes it. In the past two or three weeks, I have published a number of articles on drag and drag cost. Here are a bunch of them if you want to read them again, all gathered together under the “drag” tag. If you haven’t read them yet, you might want to go from bottom to top, in the order in which I wrote them. I honestly believe that anyone who understands critical path analysis will immediately appreciate the value of this new metric:

  1. Unlike the non-critical metrics total float and free float (which every PM software package computes and which are undoubtedly a part of every PMP exam), drag is critical! Why on earth do we quantify the non-critical stuff but not the critical?
  2. Unlike float, drag is always costing our project time and almost always costing it money, in both the form of reduced expected value and in the form of increased overhead through indirect costs. Why wouldn’t we want to compute these costs so that perhaps we can reduce them?
  3. Drag cost is a crucial metric for justifying resources. The true cost of a critical path activity is the sum of its resource costs plus its drag cost. Shouldn’t we want to measure this so that we might be able to lower the true cost by increasing resource costs but thus reducing drag costs by even more?
  4. As every project is an investment, all project work should be adding more value than it costs. We should therefore want to ensure (by combining the value breakdown structure with true cost) that no optional work is included on the critical path whose value-added is less than its true cost. (Here are some blog articles with VBS tags.)
  5. Project managers often have trouble generating an initial schedule that will meet the date target the sponsor/customer has specified. On a large project, drag computation is a crucial metric for seeing opportunities for schedule compression.
  6. Even if we start the project with enough time, what happens when the schedule slips? Every experienced project manager knows that feeling of searching for opportunities for schedule recovery. Again, critical path drag is the crucial metric for seeing the opportunities to iteratively pull in one critical path, then another, and yet another until an acceptable schedule has been achieved.

So I ask the readers of this blog: having published lots of books and articles about drag, having presented many PMI webinars and chapter dinner presentations, what should I do to get this information out into the wider PM world and to spur software companies to start measuring this critical metric that’s always there and costing time and money (and maybe human lives!) whether their software deigns to measure it or not? Fraternally in project management, Steve the Bajan

Answers to the May 22 Weekend Puzzler on Drag Cost

My recent Weekend Puzzler blog, to calculate drag and drag cost (in human lives) attracted quite a bit of attention. A total of 241 different readers viewed it over the weekend, generating a total of 288 views and pushing the total for the blog thus far this year to just over 6,900. This is sufficient encouragement to make me believe that there is a readership for relatively complex project management information, and therefore to keep doing this. This is despite the fact that only 5 people entered a total of 16 answers in the “poll” multiple choice selection format. Oh, well, perhaps many other people figured out their answers but just didn’t enter them into the poll. Of the 16 answers entered into the poll, 10 were correct (and I have a sneaking feeling that one person got them ALL correct, in which case congratulations to that person!). First, from the last article, the final network diagram schedule with all the schedule computations on which the drag cost questions were based: Fig 4 All FS network lives for blog Now here are the answers and explanations. *****

  1. If Activity B takes 10D longer than planned, how many more lives will it cost? A= 7 B= 10 C=26 D=40 E=50 (4 correct answers out of 5)

If Activity B takes 10D longer than planned, it will take 15D, use up all 8D of its float, and migrate to the critical path with 2D of drag. Those 2D will push the project duration to 69D and cost 2 * 5 lives, or 10 more lives lost.

  1. If we can shorten Activity D to 3D instead of 7D, how many more lives would that save? A= 0 B= 7 C=10 D=14 E=20 (1 correct answer out of 3)

If Activity D is shortened to 3D instead of 7D, the first 2D will be its drag and the next 2D will increase its float to 2D. Those first 2D will pull the project duration in to 65D and save 2 * 5 lives, or 10 more lives saved.

  1. If we take resources away from Activity P so that it takes 30D instead of 15D, how many more lives will it cost? A= 0 B= 5 C=10 D=12 E=75 (2 correct answers out of 3)

If Activity P’s duration is increased to 30D instead of 15D, that will be an increase of 15D. But P had float of 17D. Therefore the increase in P’s duration will only reduce its float to 2D and will not impact the critical path and the project duration. There will be no change in the number of lives saved/lost.

  1. If Activity P is now scheduled to take those 30D, AND we also shorten Activity K to 12D, how many more lives would it save OR cost? A= 0 B= 7 more lost C=10 more lost D=10 more saved E=50 more saved (2 correct answers out of 3)

With Activity P now having just 2D of float, it means that K’s drag has been reduced to 2D. Now if K is shortened by 10D, the first 2D will be drag and the next 8D will be float. Those first 2D will pull the project duration in to 65D and save 2 * 5 lives, or 10 more lives saved.

  1. With Activity K now planned to take 12D, if we now decide to give some resources back to Activity P so that it only takes 20D, how many more lives would be saved than in Question 4? A= 0 B=10 C=16 D=22 E=40 (1 correct answer out of 2)

With K now having 8D of float, Activity P is on the critical path with 8D of drag. If P is now reduced by 10D, the first 8D will be its drag and the next 2D will increase its float to 2D. The critical path will have changed and now will again go through Activities K and Q. This will also pull the project duration in by 8D, from 65D to 57D, and save 2 lives for each day or a total of 8 * 2 lives, or 16 more lives saved. ****** If you understand this whole process but find drag and drag cost difficult to compute, then please push the powers that be (i.e., PMI, IPMA, APM and all the software companies) to start incorporating these data in their critical path analysis computations. Because the calculations are dead easy for a computer, and this information is critical! 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

New MIT Paper: Using Critical Path Drag to Optimize Manufacturing Throughput

Eureka! Through the wonders of Google, I have just discovered a new paper describing the practical application of the critical path drag metric to optimize a manufacturing process. The paper is by Blake Sedore and the paper was his thesis for his Master’s of Engineering degree in Manufacturing. It’s titled: “Assembly lead time reduction in a semiconductor capital equipment plant through constraint based scheduling.” You can find the abstract through the Massachusetts Institute of Technology website at the URL below. You can download the complete PDF file by clicking on the download link at the end of the abstract.

http://dspace.mit.edu/handle/1721.1/93851

Manufacturing semiconductors

As far as I know, this is the first time that someone other than yours truly has analyzed a manufacturing process using this metric, and certainly the first time someone has written a paper about it. The paper is 83 pages long and, by my count, mentions drag about 37 times.

From the abstract:

“A preliminary build schedule was developed that prioritized critical path procedures. A trial of this build schedule achieved an assembly lead time of 39 hours, resulting in a 70% reduction from the current average of 5.5 days. This trial was also accomplished with 76% of the average labor hours for assembly. A production build schedule with a lead time of 43 hours was developed based on the trial results. This schedule allows for production rates of up to 5 machines per week to be achieved with the current shift structure of the company, without the incurrence of overtime. A critical path drag analysis identified critical procedures with the highest potential for lead time reduction. The highest drag of a critical path item was 260 minutes, accounting for 10% of the assembly lead time.”

In the paper, Mr. Sedore then goes on to describe how he analyzed the possible ways of reducing the drag and made recommendations based on considerations of greatest drag reduction, lowest cost of additional resources, and shortest disruption of the manufacturing process. This last item seems to me to be a new enhancement in the application of critical path drag analysis specific to the manufacturing industry, and I am very excited about it!

I contacted Mr. Sedore and asked him about his experience calculating drag “manually”, as the critical path software he was using (MS Project), like most, doesn’t perform the calculation. He said that it gave him some trouble until he laid it out in Gantt chart form, when the drags on the critical path became more obvious. He also agreed that it would be so much easier if only the software would compute it!

A Gantt chart is usable on a manufacturing project which is likely to consist of no more than a couple hundred steps. But for a project with over a thousand activities, I have found network logic diagrams (aka PERT charts) to be necessary (provided I am not using Spider Project which computes drag automatically). But it’s certainly high time that MSP, Primavera, MicroPlanner, Asta, Safron and all the others started including this functionality. (They will eventually – but when?)

Seeing drag analysis being used by engineers at the most prestigious engineering university in North America is extremely exciting to me! Yes, it should be used by all project and program managers – but it also should be standard usage for analyzing and optimizing circuit board design, software algorithm optimization, disaster emergency response: any procedure with integral steps. Maybe Mr. Sedore’s article will kickstart its usage in manufacturing.

I have invited Mr. Sedore to write a short guest blog for this website about his experiences in using drag analysis. I hope he will do so some time in the next few weeks.

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

Excellent article on avoiding the use of negative lags

Emily Foster of Ten Six Consulting often writes excellent project management articles. The new one is titled The Negatives of Negative Lag. It explores the risks involved in using negative lags (aka “leads”).

One little addition is to note that in positive lags on SS (and SF) relationships, the lag almost always represents what Spider Project would refer to as a “volume” lag, which represents work/time that is already modeled in the predecessor, i.e., digging the first 25m. of trench. If it is on the CP, the drag and drag cost would then be in the predecessor activity, pointing the scheduler to the fact that to shorten the project, we need to get that first section of trench dug faster. (BTW, a lead, being negative time, has no drag.)

There are often good articles at the Ten Six Consulting site. I find it a useful bookmark.

Fraternally in project management,

Steve the Bajan

Stormy Weather

I’m teaching this week in UMass/Lowell’s Executive Education Project Management Certificate Program. Great students, very bright and motivated, but the result is that I probably won’t have time for a full blog article this weekend.

However, I had decided to write a brief article at the formal start of the Atlantic hurricane season (June 1) referencing the fact that it is likely that some city or country will be devastated in the coming months and that, unfortunately, emergency response that specifically uses PM techniques such as critical path analysis and drag, drag cost in human lives saved, and resource leveling will not have been planned and optimized in advance by the relevant governments and organizations.

Hurricane damage

This morning I read that the first named storm of the season, Ana, has formed off the Carolina coast, three weeks before the formal start of the season. I hope that this is not a sign of a coming season of extensive lethality. But meanwhile, I would urge all readers interested in either critical path analysis and/or emergency response to read this chapter linked on my webpage “Time Is a Murderer: The Cost of Critical Path Drag in Emergency Response” that  I wrote for the CRC Press’s 2013 Emergency Response Handbook. The article is written with a Bay Area earthquake response in mind, but the planning process should be little different for a hurricane, tsunami, volcano, epidemic or any other catastrophe. And it demonstrates the practical use of the critical path drag metric in optimizing any project schedule.

And alas, these techniques are substantially unknown in emergency response planning.

Fraternally in project management,

Steve the Bajan

Disable de Sirens — But Put Out de Critical Path Fires, Too!

I share, with many others of the anglophone Caribbean culture, a propensity for exaggerated over-the-top hyperbole. And no, I’m not being redundant – any one, or even two, of those three terms would often be insufficient to describe the extended lengths to which we will sometimes go to draw attention to the point we’re trying to make.

As an illustration, there is the old story of the Bajan visiting London who is trying to describe the wonders of his home isle.

“In Barbados, we have mountains of sugar, rivers of rum, and fish that fly!”

To which, of course, the Englishman replies: “I might believe in the mountains of sugar and the rivers of rum, but I’m damned if I’ll believe in fish that fly!”

Slide1

So in my previous article, “Whaddya Do When the Critical Path Changes?”, I resorted to a little (for a Bajan!) hyperbole. I wrote that when the critical path changes, “sirens should wail.” And I was, quite properly, taken to task by a couple of people, including Shelley Horowitz in the Comments following that article, for suggesting the need for a state of alarm or danger due to such a change. And the criticism is quite correct. A half century spent in US cities, where sirens are an everyday occurrence, has perhaps combined with my West Indian exaggerations to dull me to the fact that, for many people in the world, sirens really do represent danger and appropriate panic: fire, tornadoes, tsunamis…

So I am taking this opportunity first to apologize, and then to explain in greater depth exactly what I meant.

The exact sentence in that previous article was:

“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.”

So let’s eliminate the need for sirens. What I was suggesting is that a change in critical path during project execution can have a major impact on the future project plan. Work that made sense to perform in a certain way may now be a significant drag (!) on our project investment, requiring new analysis.

Figure 4 full network diagram after slippage

Notice, the key event as described in the quoted sentence above is NOT that the critical path changed — it is that this change caused specific activities to now have a negative impact on the project’s expected value! The project would now be better off without the optional Activity H, because its true cost is now greater than its value-added. And this is a potential hazard any time that the critical path changes.

But the problem is that such an event, as described in the linked article, would most probably not even be recognized. Or if it were, it would only be after a great deal of “manual” analysis. Even on a schedule of 100 activities (never mind a medium-sized project of 2000+ activities!), the chance of the scheduler or project manager noticing that one or more activities are suddenly costing more than they are worth is vanishingly small. Why? Because few of the techniques that would allow such a negative anomaly to be noticed are being used:

  1. Projects are not being defined as investments, so that expected monetary value (EMV, or NPV or ROI or any other investment value term you like) and its changes are not being incorporated into the PM software and tracked and optimized either upfront or during performance. The vast majority of commercial software packages do not provide a project-level field for attaching quantified investment value to a project, nor the functionality to manage and track changes that might affect it.
  2. The value-added of specific work packages is not being estimated and assembled into a value breakdown structure (VBS), so that in the diagram from the previous article the value-added of Activity H would be unknown.
  3. The value/cost of time, which usually has significant impact on project EMV, is not being estimated or tracked on most projects, and certainly not in the software. This in turn makes it impossible to compute either the drag cost or the true cost of an activity.
  4. Even on that small minority of projects where the value/cost of time is estimated, critical path drag and drag cost are not being computed. This means that the true cost of Activity H, and the fact that the slippage it is now making the net value-added (NVA) of Activity H negative, is therefore completely unknowable!

Notwithstanding my previous remark, what should happen when such an event occurs is not wailing sirens. Rather, the user’s PM software (MS Project, Primavera, or whatever) should take the info that was entered up front regarding the VBS and the value/cost of time, compute the new drag, drag cost and true cost totals for each new activity on the new CP and kick out an exception report, calling attention to Activity H, perhaps by highlighting it in red (preferably, fire engine red!). And now the team/PM can reassess and amend the plan.

But first, the team has to recognize the issue. And currently, none of that can happen because with the exception of one software package (Spider Project), none of the others (not MS Project, not Primavera, not Asta, not PlanView, not Safron, NONE!) is even computing critical path drag, far less supporting a VBS or drag cost, true cost, and net value-added computation! (And they should, because every project has a critical path, and critical path items have drag and drag cost!)

And that’s why projects are being performed all the time that generate less expected project profit (EPP) than they might because they include work whose true cost after a critical path change outweighs the value that it adds.

If you want to learn more about assembling a VBS and the other techniques mentioned above, they are explored in much greater detail in the new (2015) edition of my first book, Total Project Control: A Practitioner’s Guide to Managing Projects as Investments.

Again, thank so much to those who criticized my “siren” hyperbole and for making it clear that I need to post another article pointing out the implications (and cures!) listed above.

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