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.


Inspecting Task Links with BPC Logic Filter for Microsoft Project

BPC Logic Filter – an add-in for Microsoft Project (desktop) – includes an advanced Logic Inspector feature to greatly simplify the examination and navigation of logic-driven schedule activities.

When building or managing a complex project schedule, it’s often necessary to examine the logical relationships between tasks for a variety of reasons.  Particular questions for any given task include:

  1. What other tasks must finish (or start) before this task may start (or finish)? (i.e. what are its predecessors and how are they related?)
  2. Of all the task’s predecessors, which ones are actually controlling the scheduled dates for this task? – i.e. what are its driving predecessors?
  3. For the task’s non-driving predecessors, how much may each be allowed to slip before it becomes driving (for this task)? – i.e. what is the relative float?
  4. a)What other tasks must wait for this task to finish (or start) before they can proceed? – i.e. what are its successors?  b)Which successors are driven? c)How much relative float exists?

For users of Microsoft Project (MSP), questions 1 and 4a are most easily answered using the “Predecessors and Successors” view of one of the Task Forms in the lower pane.  For simple schedules, question 2 can be answered by the “Predecessors” list of the Task Inspector pane.  For more complex schedules – and for all other questions – the user must visually cross-reference the scheduled dates of the various linked tasks from several views, estimating relative floats and identifying driving relationships.  This can be time consuming and error prone.  Beginning with the 2013 version, MSP provides “Task Path” bar styles, which visually identify driving and non-driving predecessor and successor paths (i.e. logically connected task chains) of any selected task on the bar chart.  These can be difficult to read, however, when the project logic is complex.

BPC Logic Filter has always answered these questions on the way to visualizing logic flow through a schedule, and several of the tracer analyses can be easily customized to examine only a single task and its links.  Since the tracers generally apply a custom filter to the schedule, however, the time to examine a single task could become unwieldy for a very large project.

The native MSP predecessor and successor tables provide only limited information: ID, Name, Type, and Lag – all sorted according to the order the links were initially created.  Here they are shown as part of the Task Details Form.

Clicking BPC’s Logic Inspector creates two new floating windows listing the predecessors and successors of the selected task.

In contrast to the native forms, Logic Inspector provides a richer table: sorting the links according to relative float, highlighting driving links at the top of the table, and identifying links to inactive tasks at the bottom. Scheduled dates, Percent Complete, Total Slack, Task Calendars, and Resources of the linked tasks are also shown by default for easier confirmation and communication of relative float results.  (If desired, the latter two fields can be replaced by user-selected fields from the current task table.)

Logic-related fields for the selected task – Total Slack, Constraints, Deadlines, Start/Finish dates, Resources, and Calendar – are included for reference above the table.  Colored highlighting is used to emphasize those fields with notable influence on the current schedule.  E.g. effective constraints, violated Deadlines, Actualized dates, leveled resources.

The JUMP button allows logic-based navigation forward and backward through the schedule network one task at a time.  Jumping to another task using the button automatically updates the predecessor and successor forms.  Driving relationships are selected by default, but any relationship can be selected and explored.  To keep things simple, you can’t jump to a task that is hidden (by a filter or outline selection) nor to a task in another project window.

Since implementation, I’ve found Logic Inspector to be an invaluable – and fast – complement to the rest of the features in BPC Logic Filter.  The two new windows are passive readers of existing project data; they are not for adding, removing, or modifying relationships.  MSP already provides a number of different approaches there.

Check out the video here to see the feature in action.

Using Logic Inspector to examine resource drivers is addressed in another post.