Home › Forums › Discussion › Looking for a Clear Definition of MS Project Driving Path › Reply To: Looking for a Clear Definition of MS Project Driving Path
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”.)