(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?
(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.
I believe it's now 10 years since Spider Project started computing critical path drag in CPM schedules and 5 years since it introduced the computation functionality on its resource critical path schedules.
It's also approaching 3 years since Asta Powerproject started computing CPM drag.
So why does Primavera still not compute this literally critical metric which tells planners how much time each activity or constraint on the critical path is adding to the project duration? And how are Primavera planners expected to do an adequate job of compressing schedules without the metric? I mean, it's possible to compute it "manually", but it's quite time-consuming. And every change requires new computations. Is it possible that Primavera planners are simply not bothering to compress/recover schedules and so are getting worse results than users of Spider and Powerproject?
In case some Primavera users still aren't aware of drag, here are a couple of articles that explain what it is, why it's so valuable, and suggest the reason for such a simple and obvious metric being omitted from scheduling theory for so many decades:
The Drag Efficient: The Missing Quantification of Time on the Critical Path
I feel sure Primavera planners are as conscientious as users of other software. They should push Oracle to modernize the software, or switch to a software package that does comprehensive critical path analysis.
Fraternally in project management,
Steve the Bajan
Printer-friendly version
Send to friend
Hi, Kannan.
The reason that the drag of an activity is the lowest total float of the parallel activity with the lowest total float is that, as one removes days from the duration of the critical path activity, the project duration is reduced UNTIL the float of a parallel activity becomes zero. Thereafter, shortening the CP activity will NOT reduce the project duration because that parallel activity with the least float will have become part of a new critical path (and will therefore have drag!).
One issue is how to define "parallel". Two activities are parallel NOT because they are scheduled to occur simultaneously, but because they are not on the same path. In other words, neither is an ancestor nor descendant of the other.
The Wikipedia page for "critical path drag" and the diagrams on it may help:
In the diagram:
1. B is parallel with F and H, but NOT with G, which is a descendant of B. Therefore if we start taking days out of B, after we have shortened it from 20D to 5D, the project duration will have come in from 65D to 50D. But now, although H will STILL have 5D left of its 20D of float, all 15 days of F's float will have disappeared and it will be on a parallel critical path. Taking more days out of B will not shorten the project further, but just create float on the original critical path.
2. C is parallel to exactly the same activities as B (F and H) and so WOULD have drag of 5D -- except C's duration is just 5D and so is adding only 5D to the project duration.
3. D is NOT an ancestor or descendant of G, and so is parallel with all of F, H AND G. Therefore D's drag is constrained by G's TF of 5D, as reducing D's duration by just 5D uses up G's float and puts it on a parallel CP even while F and H still have float.
I hope this helps, Kannan.
I still would like to know why Oracle Primavera ignores this fundamental and critical scheduling metric.
Fraternally in project management,
Steve the Bajan
Hi Stephen,
Can you please explain the concept that the drag days shall be the lowest total float of parallel activities. If possible with a clear example.
Best Regards
Kannan
Email: PPadmin@planningplanet.com
Replies