Problems with Predecessor Tasks in Task Inspector and Task Paths (Microsoft Project 2010-2016)

Neither the Task Inspector nor the “Task Path” bar highlighter is a reliable indicator of task driving logic in Microsoft Project in the presence of mixed-type predecessor relationships. 

At first glance, the Task Inspector pane in Microsoft Project (MSP) seems to be a reasonable tool for revealing the logic that is largely hidden in project schedules.  After all, you just select a task, click “Inspect Task”, and MSP provides a hyperlinked list of “Predecessor Tasks” that are controlling the schedule dates of the selected task.  For simple (i.e. Finish-to-Start) relationships between tasks with no progress, this assumption seems generally correct.

Unfortunately, many times Task Inspector is just plain wrong. (The examples below are taken from a ~1000-task real-world project schedule with actual progress updates.  Task names were obfuscated for confidentiality).  Each example represents many more cases in the schedule.

1. Once an actual start is recorded, logical drivers constraining the finish are ignored.

2. In case of parallel FS and SS driving predecessors, the FS driver is ignored.

Here is the corresponding bar highlighting from Task Path’s Driving Predecessors (MSP 2016).  The noted red bar should be orange like the one below it.

3. In case of parallel FS and FF driving predecessors, the FF driver is ignored.

3. In some (but not all) cases, an FF predecessor with substantial relative float is identified as the driving predecessor, while the true FS driver is ignored.

In general, the issues are present mainly in tasks with multiple predecessors of different types.  They are not found in tasks whose predecessors are all of type Finish-to-Start.

The “Driving Predecessors” bar highlighter of the Task Path tool in Microsoft Project Professional 2016 has the same issues as the Task Inspector results shown here.  They are both consistent with the StartDriver object for each task.  Any driving-logic tracer based on the StartDriver object – including those provided in my blog (Macro for Listing Driving Predecessors and QuickTrace Macros ) – should be expected to have similar issues.

In the examples above, the task predecessors are displayed in Logic Inspector views from BPC Logic Filter (our MSP Add-in).  Predecessors are “driving” if their relative floats are zero; i.e. there is no working time between the corresponding predecessor and successor dates.  The driving predecessors identified in the examples are easily confirmed by examining the dates.  [Though illustrated mostly using Microsoft Project Professional 2010, all examples have been confirmed in Microsoft Project Professional 2016.]

On Manually Scheduled Tasks [Aug’18 Edit]

If a manually scheduled task has predecessors, then MSP will identify one or more of them as the driving predecessor even when the manual scheduling has substantially delayed the task compared to the logic requirements.  This is one of the few factors differentiating a manually scheduled task from a normal (i.e. automatically scheduled) task with a mandatory constraint.  In this case, the Task Path “Driving Predecessors” bar highlighter ignores the delay and continues to trace “driving” logic through the identified start drivers.  (The Task Inspector suggests that the user either accelerate the task to remove the delay or convert the task to automatic scheduling.)  As a consequence, a schedule with manually scheduled tasks can have a driving path to project completion (according to Task Path) that is substantially different from the Critical Path that is based on Total Slack.


Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.