Critical path drag

Thanks for these responses, Rafael and Vladimir.

Vladimir, please know that any issues I may have with specific Spider computations are minor! Just the fact that Spider (and also now Asta Powerproject) undertakes to provide users with the DRAG metric is of huge benefit, pointing schedulers to those places where they might most effectively compress their schedules.

Ftarternally in project management,

Steve the Bajan

Hi, Steve,

We usually measure project duration in work days using project calendar.

It is natural to measure drags using the same calendar.

In other case 7 days drag means project duration that is only 5 days shorter, but 3 days drag can mean project duration that is 3 days shorter or 1 day shorter depending on the day of the week of the project finish. Activity drags become dependent on the project start date.

So I think that both approaches make sense,

Best Regards,

Vladimir

Steve,

I agree, maybe not the whole story but the first place to look.

Best Regards,

Rafael

Hi, Rafael.

You wrote: "Activity Drag is the amount of time that an activity on the critical path is adding to the project duration."

If we use Vladimir's example below, that's why I'm saying Activity 4 is on the CP and has 7D of DRAG--shorten it (even by just 2D) and the project will be 7D shorter. (Admittedly, due to Activity 3's calendar--but compressing Activity 4 is one way to work around that problem; another would be to change Activity's 3's calendar, because it too has DRAG. But that latter may not be an option.)

let's imagine that the scheduler is told to find a way to finish the project by Apr 19.

Clearly, this can be done by shortening Activity 4 from its current duration (15D) by just 2D, allowing Activity 3 to occur Apr 18 & 19.

Now imagine this is a small portion of a 10,000 activity project:

• If Activity 4 is shown as having DRAG = 7D, I'd immediately be drawn to consider it for the needed compression.
• But if it shows Activity 4's DRAG = 2d, or even 5D, I'd likely consider many other activities before I consider it.
• Perhaps even more important, let us assume there's an early delivery premium of $100K/D (incentive or avoided LDs): On a large and complex project, we might never realize that Activity 4 has a DRAG Cost of $700K UNLESS the software draws our attention to it.

That to me is part (NOT all!) of the huge value to a scheduler of DRAG and DRAG Cost calculation.

You have much more practical knowledge of this than I do. Am I wrong?

Fraternally in project management,

Steve the Bajan

Activity Drag is the amount of time that an activity on the critical path is adding to the project duration. If looking for contract duration a 24hr calendar is what l would use for this purpose.

Alternatively, it is the maximum amount of time that one can shorten the activity duration before it’s no longer on the critical path or before its duration becomes zero. If looking for how much to shorten activity duration activity calendar is what I would use for this purpose.

Another calendar option for DRAG is main project calendar I never considered using.

Best Regards, Rafael

I understand that there are different calendars, Vladimir--but when a project has activities/resources with different calendars, shouldn't the default unit for the project, and its DRAG, be 7-day weeks? Just asking here...

And happy to discuss my way of calculating DRAG whenever you want--but why don't you first check the SS example on the Wikipedia page and see if that method of computing DRAG seems interesting/helpful to you.

Fraternally in project management,

Steve the Bajan

Steve,

as other project time parameters like Activity Duration and Time Lags, Drags have calendars and can be measured in project workdays like was done in my example. With 5 days work week 5 work days is the same as 7 calendar days.

In cost and material constrained schedules the problem with drag calculation does not depend on the algoritms.

Of course it would be interesting to discuss the technique of drag calculation that you propose.

Best Regards,

Vladimir

Hi, Vladimir.

Thanks so much for your explanations. As I thought, the issue is based in the algorithm the software uses to compute drag--reducing each CP activity's duration to zero. It's interesting in that Ben Taunt's Asta Powerproject seems to have a problem in that the drag algorithm apparently consumes a lot of time. i assume it's doing something similar.

I appreciate that the human mind cannot neccessarily be replicated by software. As a consultant helping clients compress schedules, for years I had to compute drag "mentally". I certainly couldn't turn each CP activity's duration to zero, count how much the project duration had changed, set it back the way it was, move to the next CP activity and repeat, all the way through the project! Software can do that, and pretty quickly--but I had to find a quicker way.

Instead, I developed techniques based on the standard forward and backward pass metrics. It's MUCH faster and simpler than changing all the durations. And, interestingly, I think it would be aided by Rafael's concept of FLEX!

Would it work in software? With a resource-leveled schedule? Without changing resources/costs? I don't know for sure--but I think it would. And I'd be happy to discuss if either of you (or Ben!) is interested.

As an example, I'd suggest you check out the method I use for computing drag in the SS + lags example in the diagram at the bottom of the Wikipedia critical path drag page. Which is how I compute drag mentally , and quickly, in SS relationships.

Also, Vladimir, when I looked at the example you posted, I quickly computed the drag of Activity 4 as 7 because the float of the parallel Activity 4 = LF - EF = 19 - 12 = 7D. (7D is also how much the end off the project would come in by if Activity 4's duration = 0, but doing that calculation mentally on a project with even 50 CP activities would be too difficult. And doing it my way doesn't require changing durations--just using the standard metrics that CPM calculates.)

Again, happy to discuss  if anyone is interested.

Fraternally in project management,

Steve the Bajan

I agree with Vladimir, you can get unreliable results, even if consumption is fixed. I got the following in my example by reducing Bricks Installation D duration to 0.

Sometimes we tend to think complex schedules with ancient CPM calculations in our mind.

An activity of Productivity type: Activity duration is calculated during scheduling based on its volume and assignments productivity. You should get more reliable and dynamic model if you use production type activities.

https://www.mediafire.com/file/mkl1merjq6jnqjz/BricksConsumablesProductivity.001.sprj/file

Still it is not a good idea to manage these projects using DRAG values and reduce activity duration to zero by making volume of work zero. Therefore I believe in such models no DRAG should be shown and some warning/reminder should be issued.

Best Regards,

Rafael

Steve,

Project cost and material consumption requirements change when duration of an activity that has costs and consumes materials becomes zero. The schedule that takes into account financial and material supply constraints can become quite different and not feasible when this is done.

It also depends on the way materials and costs are consumed. If activity cost depends on assigned resource costs then it can become zero when activity duration becomes zero. If activity cost is fixed then project cost will not change but project cost distribution will change. The same with materials. In the latter case drag calculation could make sense. In the first case we exclude activity cost and materials and will get project duration if an activity is excluded AND project cost and material requirements were different.

"When required to level cost or materials not doing so most probably will yield wrong schedules. Perhaps when there are costs or materials set for leveling DRAG calculations should not be executed at all and a warning at schedule report and DRAG column be issued for the scheduler to know."

Rafael, I don't understand? Could you (or Vladimir) elaborate on this?

But I was VERY happy to read this, Rafael:

"...DRAG is still very useful in most of my jobs."

Fraternally in project management,

Steve the Bajan

Vladimir,

When required to level cost or materials not doing so most probably will yield wrong schedules. Perhaps when there are costs or materials set for leveling DRAG calculations should not be executed at all and a warning at schedule report and DRAG column be issued for the scheduler to know.

Only few of my schedules require materials or cost leveling therefore DRAG is still very useful in most of my jobs.

Best Regards,

Rafael

Hi, Vladimir.

"I am pleased that Spider Project features were appreciated."

HIGHLY appreciated!! And please know that any quibbles I may have with a specific calculation is VERY minor, considering all that Spider does AND the issue of programming the software to do these computations!

To paraphrase the American poet Joyce Kilmer:

"The drag metric would wither, I fear,

Without Spider and Asta to code the software!"

Asta Powerproject excepted, most other s/w doesn't even try to provide these data to users. And, I swear, PMI and the PMBOK remain oblivious! And from this discussion (and especially Rafael's comments!), I am concluding that Spider's users are finding drag very useful! I think that introducing the functionality to compute a brand new metric in critical path theory, AND TO HAVE USERS ADOPT IT'S USE, is a huge tribute to Spider!

For me, positive drag can only exist on activities, lags, constraints, and other delays  (e.g., calendars) that ARE on the actual critical path. And that's why drag calculation is so... um!.. critical! The world 9(nd PMI!) does not seem to comprehend that ALL projects, whether planned using CPM, resource leveling, agile, or darts at a dartboard, will be ALWAYS precisely as long as their longest path!

And for me, Activity 4 in your example is on the longest path and if it's duration were 0 days, the project would finish 7 days earlier: on April 19 instead of April 26, thus 7 days of drag.

Fraternally in project management,

Steve the Bajan

Rafael.

we do not recommend to calculate drags in schedules with financial and material supply constraints.

Reducing activity duration we also reduce its cost and material consumption, this leads to wrong schedules. 

Vladimir,

Please take a look at the following schedule images.

Initial schedule show no DRAG for Building D Brics installation but if I reduce the duration to 0 schedule duration is reduced.

The file you can download from the following link.

https://www.mediafire.com/file/van56vku8h18tnj/ConsumableBricks.001.spr…

Am I missing something?

 

Rafael,

brute force is realized in activity menu where Calculation/Calculate Drag can be selected.

Best Regards,

Vladimir

Hi, Steve,

I created this example to show that positive drag can exist on activities that are not critical and that drags on some critical activities can be zero even if parallel critical path does not exist.

Activity 4 in my example does not have any calendar exceptions and so no calendar delays and positive total float.

I am pleased that Spider Project features were appreciated.

Best Regards,

Vladimir

Vladimir,

And what about Materials, Financial Resources and DRAG?

Maybe Brute Force, by setting one by one activity duration equal to 0 is the fail safe way.

Best Regards,

Rafael

Hi, Vladimir!

First things first! Did you know there was a Russian-born chess grandmaster named Vladimir Liberzon?

https://en.wikipedia.org/wiki/Vladimir_Liberzon

I am embarrassed to admit I only discovered this a few months ago!

Regarding your diagram, let me say that, unlike many "gotcha" examples I've been shown over the years, this one I find really interesting!

Let me stress:

• The whole purpose to drag computation is to help the scheduler identify where to look first when seeking schedule compression, and how much potential compression can be found in each critical path item.
• Software computation of the critical path AND drag may be (may HAVE to be!) different from how a human would do it. (In MS Project, I've been told, you can't assign drag to lag because it's not an "object"!) But the Perfect must not be allowed to be the enemy of the Good Enough!
• ALL delays on the longest path can have drag, NOT just activities.

i think it's helpful to compute drag as if analyzing the ABCP of a project.

From my viewpoint, I'd say the CP was:

Activity 4 ---> Activity 4's calendar delay ---> Activity 3

That is the path that is determining the project's duration and that must be shortened to compress the schedule.

The drag of Activity 4 is 7. (If its duration were zero, the project would be 7 days shorter.)

The drag of Activity 4's calendar delay is 5. (If its duration were zero, the project would be 5 days shorter.)

The drag of Activity 3 is 2.

It seems to me that THIS is the info that would help the scheduler perform compression.

On an entirely different topic, I recently mentioned Spider to a longtime MIT Business School (Sloan) professor. He looked at it and came back and told me: "That Spider is a very nice product, with some really good features!"

Fraternally in project management,

Steve the Bajan

Vladimir, yesterday I noticed Spider was updated to calculate DRAG on activities with multiple shifts.

  ... took you less than one day! Thank you very much.

A common strategy to reduce project duration is by adding a second shift without changing schedule logic, you want to know if there is still some DRAG. Shift work on same activity is very common, splitting the activity can be dumb. When work to be done by each shift is not fixed but will change as the activity moves manual adjustments to activity splits can easily become impossible, impractical or a nightmare.

Best Regards,

Rafael

Hi, Steve,

Please look at the example that I published in one of my previous posts.

In this project activities 1 and 4 have  5 days work week (Mn to Fr) calendar, activities 2 and 3 have work days on Mondays and Tuesdays only (red on time scale). Activity 2 has an exception in its calendar and cannot be executed on 18 and 19 of April.

Project DRAG is not resource loaded and activity drags calculation is based only on the network logic and activity calendars. You may see that in this project some critical activities do not have drags and an activity 4 with positive total float has positive drag. The reason is different calendars of schedule activities.

SS and FF dependencies are usual in linear projects where different crews perform different types of work one after another. These crews could have different productivity and both SS and FF dependencies between concurrent activities are required to avoid the case when succeeding activity is performed faster than preceding and required distance between the crews is not maintained. To keep the distance the faster succeeding crew must start later or work with lower workload. Negative Drags show those activities that must be executed slower for schedule optimization.

Spider Project seeks such activities and adjusts their duration and assigned crew workloads for schedule optimization. We call this option Schedule adjustment.

Alex,

Flex is certainly not resource drag and can be calculated in the schedules that are not resource loaded.

But both Drags and Flexes can be also calculated in resource constrained schedules and in this case they will depend on project resource availability and applied scheduling algorithms. In particular, activities that were critical in initial schedule can have floats in resource constrained schedules and vice versa.

Remove this duplicate, please?

Alex, a question about your example? If A is NOT on the resource schedule CP, isn't there another predecessor of B? And if not, isn't B on the resource schedule CP?

An activity can be forced onto the CP by any delay: work, constraint, resource bottleneck, dropped baton, etc. And all those can have drag.

Hi, Vladimir and Alex.

First, please believe that I am NOT insistent that MY thoughts about drag have to be correct! If my almost 40 years in project management have convinced me of ANYTHING, it is that:

• We are still in our infancy; and
• There are undoubtedly great new ideas out there that (a) I am ignorant of; and (b) that PM "authorities" are ignoring just as much as they have ignored my ideas!

In addition, Vladimir and Spider are responsible for major steps forward in terms of making new ideas pratical in software. They are owed a great debt, IMO

The current discussion relates to several issues that I have addressed in my books. First, Alex, there is and SHOULD be a significant difference between CPM drag and resource schedule drag.

1. CPM drag is primarily a function of logic. and often based on Newtonian physics.
2. Resource schedule drag is caused primarily by a lack of SPECIFIC resource availability.

In general, resource availability drag (RAD) is much easier to address than CPM drag, especially if the drag cost is computed for each delaying resource and used to justify the expense of the resource needed to remove the drag.

Alex, that's my feeling about your schedule issue: attach the drag to each specific resource lack which is adding time to the resource schedule duration.

Regarding the negative drag in FF or SF relationships, Vladimir, you and I have debated this for over a decade. These are caused by constraints in an algorithm that assumes a successor activity that cannot be interrupted and therefore the activity's are pushed toward their completion dates in SF and FF relationships.

I believe this is a byproduct of the US Navy's discovery and use of CPM during WW2. Their desire to "finish no earlier than" the travel time of the slowest ship caused the critical(!) concept of drag to be completely overlooked, and meant there was really no downside to putting the float [Flex?] at the start of successors of FF or SF relationships. This LinkedIn article explains:

https://www.linkedin.com/pulse/2016-year-drag-stephen-devaux/

I believe that, while changing the CPM algorithms to correct this may be problematic for software, in the vast majority of cases a user who recognizes the issue WILL find a workaround to an "uninterruptible" activity! Rafael's Flex workaround is certainly acceptable--but I have always felt that, since constraints also can have drag, it's the FF or SF constraint (and any lag thereon) that is delaying the project and should have the drag assigned to it.

Using either Flex or assigning drag to the constraint should do what is neccessary: i.e., pointing the user to the cause of the quantification of the delay. How they then resolve it (decrease resources, start the successor earlier, change the constraint or its lag) is then up to the project manager.

Alex, I will respond to your post in LinkedIn with a link to this discussion in PlanningPlanet.

Fraternally in project management,

Steve the Bajan

Regarding the "Anti-Crashing post" please provide the Spider schedule file.

Regarding Non-critical activity drag >0, short examples as this helps you keep focus. Also if we cannot reduce this activity to 5 days but set it to ALAP, the overall duration will be reduced.

Vladimir,

Try the following link to download my file.

https://www.mediafire.com/file/d4guxbdzl53tlrt/AssignmentFloats.001.sprj/file

Your example is very good at showing non-critical activity with DRAG. Thank you.

Best Regards, Rafael

Rafael,

it looks like we missed drag calculation for activities with multiple teams assignment.

We will consider this case in the near future.

Rafael,

please send the file of your project.

In the example below:

Activities 1 and 4 have  5 days work week (Mn to Fr) calendar, activities 2 and 3 have work daya on Mondays and Tuesdays only (red on time scale).

Activity 2 has an exception in its calendar and cannot be executed on 18 and 19 of April.

Project file is here https://dropmefiles.com/5m5XM

Activity 4 has 3 days total and free float and 5 days drag.

Activities 1 and 2 are critical but have zero drags.

Please remove

Vladimir,

You said not only critical activities can have positive drags.

• Can you provide us with an example including its Spider file?
• Are you referring to activitiies with critical resource assignments?
• What is the best way to filter activities with critical resource Assignments while at Activity Gantt?
• Please take a look at the following for your comments.

  Work slab ..., activity shows no DRAG - Activity Drag is the amount of time that an activity on the "critical path" is adding to the project duration.



if activity duration is reduced to 0 project duration is reduced? It is shown as non-critical but impacts "longest path"?

Note Schedule Report do not disclose DRAG settings/calendar.

https://www.mediafire.com/file/d4guxbdzl53tlrt/AssignmentFloats.001.spr…

Best Regards,

Rafael

Steve,

look at slides 7 - 13 of this presentation http://www.spiderproject.com/images/img/pdf/Construction%20CPM%20Confer…

Drags can be negative and, besides, not only critical activities can have positive drags.

Ben, there are ways of writing the drag-computing algorithm that would make it take less computer time to compute. Please email me if you are interested in discussing.

Hi, Alex.

I am willing to be persuaded otherwise--but I can't imagine a situation in which drag is negative. That would imply negative passage of time.

An algorithm which computes negative drag in situations with FF or SF relationships is actually pointing an arrow to the constraint on the activity's finish, which is delaying project completion and therefore has positive drag. (Which is why I always stress that NOT just activities can have drag!)

I have no issue with the negative drag calculation--but I think there should be an explanation that the drag is really on the constraint.

Calculating the drag of critical tasks when rescheduling with Asta.

If you choose to calculate critical path drag, it will take longer to reschedule a project; for this reason, drag is not calculated whenever Risk Analysis or the resource leveller reschedules the project.

  Non leveled schedules are not feasible therefore Drag can be misleading.

  Leveled schedules are feasible; if Drag calculation considers resources as Spider Project can you should get reliable Drag values. And yes, it can take a lot of time. Perhaps it makes sense to apply Drag calculations to a selected group of activities, maybe long duration critical activities. Maybe a dialog box to calculate drag in selected critical activities could make it followed by a simple report.

Hi, Ben! That's a nice explanatory webpage for drag, and I'm glad to see you have support people on staff who can explain it.

Two questions:

1. How have your customers reacted to Powerproject's drag computation function?
2. Are your sales folks showing it in sales demos and explaining that Primavera lacks this critical CPM functionality?

Fraternally in project management,

Steve the Bajan

Hi Alex,

Online help article is here: Calculating the drag of critical tasks when rescheduling (elecosoft.com)

However, if you send me an email, I can set you up a demo with someone here to go into the details: ben.taunt@elecosoft.com.

Thanks,

Ben @ Powerproject