Looking for a Clear Definition of MS Project Driving Path

[Ed Knox]

Can someone please provide an explanation of how MS Project calculates the “Driving Path”? I currently us Project 2010 and know that when I use VBA, there are references to driving path. I think 2013 has a trace tool that openly shows the driving path as part of the application.

However, while I have seen some research, I have only been able to find answers similar to “driving predecessor is one which will potentially cause a change to the scheduling of the selected task if its schedule changes…” However, I am extremely interested in the math behind the curtain. Is is a combination of Free float and logic?

Any help is greatly appreciated – I know there is someone in this forum who can answer this. Thanks!

[Tom Boyle]

Hi Ed,
Based on my own research trying to answer these same questions a few years ago, I would submit the following:
1. The Task Path functionality in MSP 2013+ is based on the PredecessorDrivers collection in each task’s StartDriver object. These are also present in MSP 2010 (and I would assume 2007, though I skipped that version.) StartDriver members are displayed in the Task Inspector pane, where the hyperlinked “Predecessor Tasks” are developed from the PredecessorDrivers collection.
2. The task dependencies in the PredecessorDrivers collection are added to the collection – very efficiently and without reference to any float calculations – during the forward pass through the schedule logic network. E.g. as each predecessor relationship is considered for scheduling a task, if the relationship changes the task’s early start then it is added to the collection and all previous entries are removed. Free Slack/float is also computed during the forward pass – as a property of the task, not the relationships. For tasks with zero Free Slack and multiple successors, the driving successor relationships are identified only by their membership in the successors’ PredecessorDrivers collections.
3. It’s pretty straightforward to write a recursive macro for tracing driving paths based on PredecessorDrivers; it took me just an hour or two to develop and test the one on my blog. (I wrote it because Mike Dahlgren’s Trace macro seems no longer available.) As long as your project has only FS relationships, then it’s pretty reliable.
4. Unfortunately, PredecessorDrivers in MSP 2010 fails to catch some non-FS driving relationships – I don’t know if this was fixed in MSP2013+ with Task Paths. I no longer use it since I developed a separate procedure to trace driving and near-driving paths using something I called “relative float.” (Primavera calls it “Relationship Free Float”.)

[Author]

Posts