Critical Path Quiz

STEVE COMMENT #17

Okay, you are beginning to convince me that Mike Testro is correct: all projects should be scheduled using only FS relationships!  Certainly the continuous PDM algorithm, in specific (and, fortunately, contrived!) cases, not only can make the project longer but also  gives answers that are unhelpful to the point of absurdity. This may be the reason that the computation of drag (i.e., telling the scheduler how much time a critical path activity is adding to the project duration so that the scheduler can figure out how to optiize the schedule) has never previously been defined or used.

Nevertheless, I will try to see if I can "salvage" the drag computation in the continuous algorithm. First, though, some points, and then some questions:

1. The drag of an activity cannot be negative.  Drag is the amount of time that having to do specific work is adding to the project duration.  So giving an activity negative lag is tantamount to saying that doing the work faster will slow down the schedule while doing it slower will shorten the schedule.  This result is not only absurd but also completely unhelpful to the scheduler (and providing information that is helpful to the scheduler is the whole point, not only of drag computation, but of critical path scheduling!).
2. So any time we have a negative drag computation, that is telling us that THE PROJECT IS BEING DELAYED, NOT BY THE ACTIVITY'S DURATION, BUT BY THE (DIABOLICAL?) INTERACTION BETWEEN THE CONTINUOUS ACTIVITY ALGORITHM AND THE CONSTRAINT ON THE FINISH OF THE SPECIFIC ACTIVITY WITH NEGATIVE DRAG! In other words, the drag is on the finish-to-finish (or start-to-finish) relationship. We know (from ABCP analysis) that constraints can have drag. Here is another place where a logical constraint has drag.   
3. In such cases, at the very least, the software should tell us that we are getting an absurd result (much as it would tell us if we had a loop in the logic: just because we can do something in the software, and perform a computation, it doesn't mean that the result is in anyway meaningful).

As I say, let me somehow try to resolve this issue (which is not a problem either in pure CPM nor in non-continuous PDM) for continuous activity PDM.  But first, let me ask:

Earlier, Miklos, you listed the drags as:

Drags for A,B,C

 But in the most recent post, you say:

"Miklós and Rafael have the following solutions

When B is 10:   A = 0,  B= -10,   C = 0
When B is   9:     A = 1,  B = -1,    C = 0
When B is 11:     A = 0,  B = -9,    C = 0"

So what IS your calculation for the drag of B when it has a duration of 9? Is it -9 or -1? Needless to say, it makes a huge difference. I think the continuous activty algorithm would say -9, yes?

Second: Miklos, did you look at the network when I decomposed it into all-FS+0 relationships in my COMMENT #13? If not, would you do so and see if you agree that mine are the correct answers (in fact, those that someone like Mike Testro, doing the schedule in all FS+0 relationships) would get?

Fraternally in project management,

Steve the Bajan

Miklos, are you still here?? I'm sort of waiting for you to confirm which drag totals you feel are correct, because, depending on which ones, I think I can provide a way to make the right drag computations even in a continuous activity CPM algorithm.

Steve

Steve from Barbados,

 "Drag is the amount of time that having to do specific work is adding to the project duration".

May I ask the following: 

1. How do you define an activity duration? 

2. Why bother with "Drag" when an activity duration cannot even be estimated or predicted accurately?

3. And how do you estimate an activity duration?

Thank you.

Hi, Anoon.

I'll answer the first question: an activity duration is how long an activity took.  An estimate of activity duration is an estimate of how long an activity is likely to take.  Some estimates are more reliable than others.

Your question really goes to the heart of planning, not just for projects, but for all human existence.  To paraphrase a famous quote: "It is the job of the future to be unpredictable, and the one thing you can count on is that the future will do its job." Why plan anything, when we don't know what's going to happen? Why play poker when we (almost) never know what the next card is going to be? But Dan Harrington has made many millions of dollars playing poker by estimating the unknowns better than most people. Even in chess, we don't know what the opponent's next move will be -- but clearly some chessplayers are better than others. So too with planners, estimators and project managers.

There's an old question and answer about planning:

Question: Why plan when we KNOW the plan will be wrong?

Answer: Because once we have spent several weeks putting together a detailed plan consisting of thousands of activities and hundreds of resources, we have ELIMINATED ONE of the infinite number of ways the project could actually go!

So critical path drag, like project duration, like budget, like float, like early and late starts and finishes, like resource requirements, like everything else in the planning process, like the stock market, like the weather tomorrow, is uncertain and changeable. But some people will check the weather forecast and, even when it called for fair weather, will take an umbrella if dark clouds suddenly blow in. Others will regularly be caught in a downpour without an umbrella. Just like a project, where one of the big advantages of NOT planning is that the disasters will all come as complete surprises rather than the project manager having to worry about them beforehand.

Drag, like all planning tools, will be more useful on some occasions than on others. When someone's schedule starts slipping, every scheduler starts trying to figure out where the critical path drag is, whether they know what it is and how to do it or not. 

Perhaps a more meaningful question is why would someone who doesn't believe in the value of estimating, scheduling and planning belong to a group called Planning Planet?

Fraternally in project management,

Steve the Bajan 

1. Max TF = 40 on Act J.
2. Only activity A
3. 20 + 30 + 30 + 25 + 30 +  25

I've never encoutered this thing called DRAG so I am guessing on number 3.

Hi, Jorge.  I had actually posted the answers in a separate thread.  But now I'll post them here.

First, you're right on question 1.

1. Which activity or activities has/have the most total float, and how much? J has TF = 40

On Question 2 you are incorrect. Free float is the amount of time an activity can be delayed without delaying the EARLY dates of another activity. In order to have free float, an activity must first have total float.  A is on the critical path and has no total float. So:  

 2. Which activity or activities has/have EXACTLY fifteen units of free float? Activities D & L have exactly 15 units of free float.  More than 15 days of delay and D will delay the early start of H, and L would delay the early starts of all three of its successors.

You were also correct on two of the answers in 3, and incorrect on the other four:

3. How many units of time is each critical path activity ADDING to the total project duration of 160 units (i.e., what is the drag of each activity)?

The answers you gave were the durations of each of the critical path activities -- but, depending on the parallel paths, a critical path activity with duration of 40D might only add 1 day to the project duration, whereas a 5D activity may add 5 days to the project duration.

Drag is ONLY on critical path activities, and in a network with ONLY FS relationships, it can easily be computed as follows:

1. If  critical path activity has NOTHING ELSE IN PARALLEL (i.e., has NO other activity that's NOT either an "ancestor" nor a "descendant"), an activity's drag is equal to its duration.
2. If an activity has other things in parallel (i.e., other activities that do NOT share at least one path with the critical path activity), the drag of the critical path activity will be whichever is LESS: its duration or the total float of the parallel activity that has the LEAST total float (where the CP will go to next if the original CP activity is shortened).

To show the answers to the exercise, and how to determine them, in diagram form:

Two activities are, by definition, parallel if they are not on the same logical path. So A and S are on every path (everything is a descendant of A and an ancestor of S) and thus have nothing in parallel, so their durations are their drags.

The activity with the least total float that's parallel with E is C (TF=20). E has a duration of 20, so its drag is the LOWER of 20 and 30, or 20. Similarly, I has drag of 10 (H's TF), M has drag of 15 (L's TF) and R has drag of 5 (Q's TF).

Jorge, if you have any questions about the answers, let me know.  And if you'd like another exercise, let me know that, too, and I'll post one. (I have lots of them from my graduate classes.)

Fraternally in project management,

Steve the Bajan

Stephen,

I'm curious why by defining an activity duration (your answer), you haven't used the term "by having to do specific work"?

Isn't that in your Plan (or estimates) you will always be needing specifics in order to reach your desired target? So it can be predictable if you have defined your "specifics" in the first place.

"  Some estimates are reliable than others" - Does this statement applies to Plans or Schedules as well? If so, then "Drag" is dependent on the reliability of the plan or schedule that has been made.

Thus, can I say that an "activity duration" and "drag" are the same thing?

Thank you.

Hi, Anoon.

"I'm curious why by defining an activity duration (your answer), you haven't used the term "by having to do specific work"?

Isn't that in your Plan (or estimates) you will always be needing specifics in order to reach your desired target? So it can be predictable if you have defined your "specifics" in the first place."

I guess I thought this was understood. But it's a valid point -- an estimate of an activity's duration should be based on meeting its completion criteria.

""  Some estimates are reliable than others" - Does this statement applies to Plans or Schedules as well? If so, then "Drag" is dependent on the reliability of the plan or schedule that has been made."

Absolutely. And not just on the reliability of the original plan, but also, during project performance, on how well it has been maintained and updated.  I'd say that's true for any schedule data and decisions (one reason why out-of-sequence work is so damaging to good schedule management).

"Thus, can I say that an "activity duration" and "drag" are the same thing?"

Nope, that you can't say.  Activity duration and drag are only the same thing in the case of a critical path activity that has nothing in parallel.  Duration is the amount of time an activity takes -- drag is the amount of time by which the activity's duration delays project completion. An activity that is not on the critical path adds no time to the project duration, and a 30D activity ON the critical path may add anywhere from 0D to 30D.

The answer I posted below, to Jorge, is the clearest explanation (with the specific examples) I can give for computing the drag of an activity in an all-FS network. Of course, PDM dependencies and lags make the computations much more problematic (though no less important).  And finally, it should be noted that lags, constraints, resource unavailability, and delayed "hand-offs" can also have drag, especially in ABCP analysis.

Fraternally in project management,

Steve the Bajan