"But then England beat Australia 21 - 20 in the game that really matters over the weekend."

Wow! That’s a really low scoring cricket match!

Fraternally in cricket,

Steve the Bajan

Hi, Mike.

I can’t say for certain, because I’m not sure I understand your filtering process -- but I honestly can’t see how what you describe would compute how much time each activity is adding to the duration, even in a short network.

On a small network with only FS relationships, DRAG is pretty easy to compute visually. On a large network with complex dependencies, it’s both difficult and very time-consuming without software help. (As a consultant, I’ve spent much time helping clients identify opportunities to recover schedules by papering my house with network diagrams. Without software, it would sometimes take more than a day to compute the DRAG in a 3000+ activity network.)

Knowing how much time each activity/bottleneck/constraint is adding to the project duration seems like a pretty fundamental metric -- more so than float (total or free), which pretty much every package computes, yet is off the critical path. You can have a thirty-day activity on the CP that’s only adding one day, but an eight-day activity that’s adding eight. But yet the metric, and even the idea of it, is not listed in the PMBOK Guide nor any other PM book I know of, and no software computed it prior to my book. It certainly was new info to both Vladimir Liberzon of Spider Project (you can ask him) and Joel Koppelman (founder and CEO of Primavera), enough so that Vladimir programmed an algorithm to do the computation in Spider.

So if you have a filter and simple algorithm that will compute it, I’d love it if you could send it to me.

"But what is the purpose - the critical tasks will be as tight as they possibly can be to start with."

Clearly, the projects you work on are very different from mine. Maybe what you describe is the norm on the construction projects you work on. I’ve done a little construction and that certainly hasn’t been my experience, but I won’t deny perhaps it’s been yours.

However, I’ve also worked with many other industries, and I can assure you that such is not the case in aerospace/defense, or nuke plant shutdowns, or pharma, or consumer electronics (and I won’t even mention information systems!). Before optimization of the schedule, it’s not unusual to have activities with hundreds of days of float, or four or more weeks of DRAG, on a two year project. Typically, I find that I can compress a schedule anywhere from 10% to 40%, and DRAG computation is what makes it possible.

I’d also add that even if "the critical tasks will be as tight as they possibly can be to start with", that may be how they start -- but it’s not how they’ll be when things start slipping! The the typical scheduler is scrambling to find places to recover, and the DRAG metric points him to productive areas.


Fraternally in project management,

Steve the Bajan