First, I want to say that, if DRAG is being judged as not relating to relationships, it’s because I haven’t adequately explained it. DRAG is about anything that delays the critical path: activities, relationships, lags, resource bottlenecks, or even just delayed baton-passing. If it has a time impact and is on the CP (or longest path, if you will), then it has DRAG.

Also, I’d like to point out a key difference between float/slack and DRAG. DRAG is always on the CP; float/slack is always off the CP. Thus DRAG delays the end of the project and therefore can result in huge loss of project value, as well as increases in "marching army" overhead costs. Conversely, float is a measure *of the amount of time before an activity (relationship, etc.)becomes critical*! Thus, by definition, DRAG (in planning, but also in ABCP delay analysis) is more *critical* (in the sense of critical = important) than float.

For anyone interested, the fifth article in the TPC series, "DRAG Racing on the Critical Path," is now up at:

http://www.projectsatwork.com/content/articles/234282.cfm

If you read it, please check out the discussion at the end -- I think MikeG’s criticisms/comments help with understanding the concept.

Dear All

This become a very good topic where relationship, activity, slack, float, critical path is discussed in detail.

I guess my view is when I study a schedule I normally look at both the longest path as well as the least total float activity. Doesnt matter you call it critical, one way or the other. At the same time it is very hard in real schedule that dont have any constraint or interrelationship milestone. Thats why critical path is not necessary the longest path, but dont discard the value of study the longest path, becasue it is another key information to the project schedule

Alex

"By definition, an activity can only have one free float value. In the special case where that activity only has one predecessor, then Slack will equal the Free Float. Activities can have more than one predecessor and in these cases, each predecessor relationship will have its own Slack value. Free Float does not lend itself to incorporation into larger concepts."

Wouldn’t each activity also "have its own" Free Float value? Maybe I still don’t understand the idea of slack -- can you demonstrate/draw a network in which an activity’s Slack and free float would be different?

"Slack is the key to turning the binary process of following the driving relationship to determine what activities are on the longest path into computing the Longest Path Value for every activity in the schedule. The fact that this property of a relationship is sometimes equal to the free float of the successor activity is irrelevant."

Actually, the "driving relationship" is also denoted by the DRAG computation. Except that DRAG contiues the process by measuring how much time is being added by the activities, lags and constraints with "driving relationships" (for me, "on the critical path").

Wow, this is developing to be a fascinating discussion! Let me start by saying that I think that much of what we are discussing is a semantic difference. In response to Alex, I basically agree with mktse -- in theory, a project has one critical path at any given moment (omitting the issue of equally long parallel paths), and it’s what Ron is calling the Longest Path. Now, in performing projects on contract, contractual issues can change the way we both focus on and do the work -- but that is just one of the many project distortions that can be caused by a contract. PM software packages allow us to "distort" the schedule (and the meaning of critical path) to match the contractual distortion. But here’s where you and I completely agree, Ron: it is crucial to sill identify and be able to focus on the Longest Path (whether one chooses to call it the critical path or not).

As Ron says, a contract sometimes forces project managers to manage to "mid-term milestones." But he adds: "To model the contract properly, then constraints must be used. This practically guarantees that total float will be unrelated to the longest path." I would argue that one has to be very careful in using date-based constraints -- on the working schedule!

To explain, in performing a contract project, one is always working with at least two schedules -- commitments and actual. The commitments are the baseline schedule, which typically includes schedule reserve (visibly or invisibly!) and the earned value baseline, and against which progress is "taken". Date-based constraints on the baseline schedule are fine.

But since projects never go exactly as expected, there is always another up-to-date schedule reflecting the changes as they occur. Hopefully, this schedule is "earlier" than the baseline schedule (the difference between them being the schedule reserve). But if we don’t keep that working schedule, then we’ll still have a working schedule which is different from the baseline, except the project will have slipped and our working schedule will be later than the baseline! (This, of course, is where so many projects are!)

I am opposed to using date-based constraints on the working schedule because such constraints deprive the project of flexibility and restrict the ability to conduct full-scale schedule analysis and what-ifs. When there is constraint in place, the impact of altering durations and/or logic is likely to be distorted. (If it’s not, it means the constraint is having no effect anyway!)

Let us suppose that 6 months into a three-year project, there is a requirement for a contractual subdeliverable. The fact is that this subdeliverable is really a little internal project, with a logical fragnet of ancestors leading to its completion. Let us further presume that this subdeliverable is NOT on the longest path, and so started with total float of 20D. This is pretty simple, and there is no reason for a NET constraint, because the subdeliverable and most (if not all) of its ancestors will have float.

But now let’s make it more complex -- because of slippage, (or, in a specific case on which I consulted, because the customer decided he had to have the deliverable thirty days earlier!), the total float on this subdeliverable and all of its ancestors suddenly went from 20D to minus 10D. A separate file of the subdelivery and its ancestors should be created, with no date-based constraints, and analyzed in order to pull in the schedule. There is no need here for constraints, as the longest path *to that subdeliverable* is the critical path of this subproject. (NOTE: And this, by the way, is one of the places where knowing the activity DRAG on the critical path is extremely useful.)

I get asked a lot about the question, “Is Longest Path Slack is equal to free float?” Just because they are often the same number, this does not mean that they are even related. Free Float and Total Float are always the same number on the critical path, but this special condition does not mean that they are the same concept.

By definition, an activity can only have one free float value. In the special case where that activity only has one predecessor, then Slack will equal the Free Float. Activities can have more than one predecessor and in these cases, each predecessor relationship will have its own Slack value. Free Float does not lend itself to incorporation into larger concepts.

Slack is the key to turning the binary process of following the driving relationship to determine what activities are on the longest path into computing the Longest Path Value for every activity in the schedule. The fact that this property of a relationship is sometimes equal to the free float of the successor activity is irrelevant.

I have read the little that you have published on the net about Drag. Drag is an interesting concept. So is Scott Hearold’s Multiple Critical Paths concept (that was purchased and implemented by Primavera in their P5 product.) Drag doesn’t appear to be very dynamic, requiring a complete re-computation with the slightest change in the schedule. Still, a very interesting concept.

Subject to one condition "NO constraint throughout the network", longest path is one of the critical path to the project.

Hi, Ron.

I just read your "Longest Path Value" article. Very interesting. I was particularly interested in what you had to say about activities done out of sequence (e.g., successor is finished but the predecessor hasn’t started yet!). A few comments/questions:

1. I’ve always differentiated between a concept/metric and how a given software package might incorporate that concept/metric. For me, the critical path IS the longest path. The fact that a software programmer might find it convenient to identify it with the path with least float is simply a shortcut.

2. How is the metric you define as "slack" different from free float? In the example in the diagram, the free float computations would, I believe, be the same as your slack.

3. I feel that the focus on the second longest path obscures a much more important concept: DRAG. DRAG, which is always on the longest path, is the amount of time an activity is adding to the project duration, i.e., how much longer an activity’s path is than its longest parallel path.

4. When activities on an ongoing project are done out of sequence, as a scheduler (or consultant!), how do you assess the schedule? Isn’t it vital to find out how this could happen and then to re-work the logic before being able to assess the new schedule?

Have you by any chance read my book "Total Project Control: A Manager’s Guide to Project Planning, Measuring and Tracking" (John Wiley & Sons, 1999), where I introduced the concepts of DRAG and DRAG Cost, and showed how to compute them? Also, I think you might be interested in some other articles I’ve already mentioned here at Planning Planet in another thread: "Scheduling is a DRAG" by Bill Duncan and myself at Chief Project Officer on-line magazine:

http://www.chiefprojectofficer.com/article/135

Also, articles 3-5 in the series I’m currently doing for Projects@Work online magazine, "Time is a Crook," "Delay Tactics," and "The Whips and Scorns of Time" (due out on Thursday of this week). They can be found at:

http://www.projectsatwork.com/departments/methods-means/

I’d be very interested in your comments, and how you see those comments fitting in with your Longest Path ideas.

My guess (as this happens to me) is that you’ve got different calendars running through your critical path.
e.g. if you have an activity on a 7 day a week calendar finishing on a Friday and a Finish to Start succeeding activity on a Mon-Fri calendar (i.e. can’t start until Monday), then even if the Mon-Fri calendar activity has zero float, the 7 day a week activity will have 2 days float (Sat and Sun).