Network Practice Exercise 2: Computing Critical Path Drag with SS and SS+lag Relationships

Lately there have been a number of very interesting and metrics-focused LinkedIn discussions (many started by Alex Lyaschenko who will be exploring such topics at the Construction CPM Conference Jan 15-18, 2023 in Disney World, FL) including about critical path drag: what is it, how does it help, how to compute it, etc.

Previously, I published a few articles on the topic on LinkedIn:

• “2016: The Year of the Drag” explains what drag is. It also explores why, despite its obvious importance and value, it was never a part of the original CPM metrics.
• “Network Practice Exercise 1: Computing Critical Path Drag, Drag Cost, EMV and the DIPP” walks the reader through the process of “manually” computing drag and drag cost (also expected monetary value and the DIPP) in a network with ONLY finish-to-start (FS) relationships.
• “Exercise on Value Integration in Project Management” combines the use of the value breakdown structure (VBS) with drag and introduces the concept of an activity’s True Cost (TC) and net value-added (NVA). (TC = resource costs + drag cost; NVA = value-added - true cost.)

A big issue with drag calculation is that most software packages don’t compute it. Spider Project and Asta Powerproject do, if in slightly different ways from those that I use, but that's fine—the key is to point the scheduler to those activities and constraints that are adding time to the project duration! However, the two packages with the biggest global market share, MS Project and Primavera, seem blithely unaware that their products omit THE most critical(!) metric in critical path analysis. (Maybe their marketing materials should say they do “only non-critical path analysis”—computing float OFF the CP! But they say "zero" about the critical path! And, if I may say so, the critical path is... critical!)

Of late, a number of people from across the globe have asked me for help in computing drag. I start by suggesting that they speak to their software vendor about it. But since that seems unlikely to have much impact in the near future (because why would a company go to the trouble of writing new code when both PMI and AACE insist on ignoring the whole concept?), I’ve sent them explanations and exercises.

So here is an exercise in computing drag in a network with complex dependencies. The answers, along with an explanation, are below.

I’d also suggest referring to the Wikipedia page for “critical path drag” which has a diagram explaining how to compute it for SS and SS+lag relationships.

I hope this helps.

Notice that in the diagram above, things like float calculations are a bit different from what you might be used to in the software that you use. For example, the start of F has 6d of total float whereas its finish has 4d. Most CPM algorithms use what is called the "continuous activity assumption", where an activity CANNOT be interrupted. This means that if F can't finish till Day 32, it also can't start till Day 21, EVEN THOUGH it actually could start on Day 19! This means that the start and finish are calculated as having the same amount of float, even though they don't! Surely we could think of a way to either increase its duration by 2d OR interrupt it! (The continuous activity assumption makes programming the software easier--but it also can make projects longer by causing the "reverse critical path anomaly" where projects take longer (sometimes resulting in human deaths!) because of a software algorithm!

The continuous activity assumption can also sometimes distort drag calculation, so I've ignored it in this exercise. But if a software package that computes drag wants to include the assumption, that's still MUCH better than simply not computing drag! (And by the way, if you want to eliminate this problem, just add a "finish milestone" to the end of any activity that has an FF or SF predecessor!)

So now for the calculations (and the way I do them "mentally"!):

1. Drag is ONLY on activities and constraints that are ON the critical path!
2. If a critical path activity or FS/FF lag (which is just like an activity!) has anything else "in parallel", its drag = WHICHEVER IS LESS: (a) its own duration OR (b) the total float of the parallel activity with the least total float. (Activities are defined as parallel if they are not on the same path, i.e., neither "ancestors" nor "descendants" of each other.)
3. If a critical path activity has an SS or SS+lag successor, its drag is WHICHEVER IS LESS: (a) its own duration OR (b) the total float of the parallel activity with the least total float OR (c) the lowest "lag to" plus float of any of its SS successors!
4. So let us look at the answers for this exercise:

1. Activity A can be divided into 3 subactivities: The first 3d of A has nothing in parallel (everything is a descendant) and so has drag of 3d. The next 4d is parallel with just K and L (with float of 15d) and so has drag of 4d (because 4 is less than 15). The last 5d of A is parallel with B, K?and L, but is NOT on?the CP and so has drag = 0d! So A's drag = 3d + 4d = 7d. (Alternatively, (lag to + float) of K = 3 + 15 = 18d; (lag to + float) of B = 7 + 0 = 7d; duration of A = 12d. Lowest = 7d and that is Activity A's drag!)
2. B has a duration of 8d. It is a descendant of A (but just its first 7d!), B, and C. It is an ancestor of E, H, G, M and J. It is therefore parallel with C, D, F, I, K and L, and ALSO the last 5d of A. The lowest TF of the parallel activities is C = 2d, which is less than B's duration. So B has drag of 2d. And in this case, the FS lag of 9d from B to F also has drag of 2d.
3. E has a duration of 12d. It is a descendant of A, B, and C; and an ancestor of H, G, M and J. It is therefore parallel with D, F, I, K, and L. The lowest TF is 4d on the finish of L. Therefore E's drag = 4d.
4. H has a duration of 18d. It is a descendant of A, C, D, F, B and E; and an ancestor of J. It is therefore parallel with K, L, I, G, and M. The lowest TF in parallel is M = 3d. Therefore H's drag is 3d.
5. J is a descendant of all the other activities and therefore has nothing in parallel. So its drag is its duration of 12d.

The best way to look at the drag totals, in my experience, is in descending order:

J = 12D

A = 7d

E = 4d

H = 3d

E = 2d

B-E lag = 2d.

In my experience as a consultant, computing critical path drag to compress a project's duration can reduce it by 15% to 40% (depending on the level and skill of previous efforts) with MINIMAL increase in cost. But that process also requires repeated recalculation of drags as the critical path changes. That gets to be a pain! But computers don't feel pain...