September 2016 – TomsBlog

Inactive Tasks in Microsoft Project

Beware inactive tasks in MSP 2013+, especially if you use non-finish-to-start relationships.

The other day Dominic Moss posted a nice Pulse article over on LinkedIn called Inactive Tasks – more than meets the eye. I liked the article, though I pointed out some fundamental issues with Inactive Tasks that were introduced in MSP 2013. [Note: the link takes you to a new, improved version of Dominic’s article; our original discussion was lost.] Here’s a recap of the lost comments:

“Dominic, this is a nice write-up. I was an early adopter of inactive tasks in MSP 2010 for the reasons you mentioned. With MSP 2013, however, Microsoft introduced a substantial change to schedule calculation around inactive tasks – the program inserts a hidden FS link between inactive task predecessors and successors at run time. I imagine that change persists in 2016. It seems a large number of users complained about the logical consequences of inactivating a task – i.e. its successors lose their driving logical constraints and slide back to the project start date. While the change seems to make life easier for the complainers, users should recognize that inactivating a task does not reliably remove it from the scheduling calculations (except in MSP 2010). That defeats most of their benefits for my purposes…. I stumbled across that ‘feature’ by accident, when a client’s planners (newly upgraded to 2013) started getting different end dates than I was (on 2010) from exactly the same mpp file. We had a number of contingent tasks that were inactivated – some with FF links. MSP 2013 was replacing those FF links with FS links and driving out the project completion!”

So the conclusion is – Beware Inactive Tasks on MSP 2013+.

[Edit: July 2018 – having finally upgraded a dedicated machine to MSP Professional 2016, I can confirm that the program’s updated behavior is a bit more refined than I had experienced with MSP 2013. In the absence of complications caused by lags and multiple calendars, the run-time adjustments generally comply with expectations of a “dissolved” activity. That is, relationships are applied through a zero-duration inactive task – at least on the Forward Pass (the calculations leading to the Early Dates.) This can still extend the scheduled project completion if the inactivated task… 1. was on the driving path to project completion, and 2. possesses reverse logic flow, as in the case of a driven finish and a driving start. Unfortunately, all this sleight of hand seems to wreak havoc on the Backward Pass and the corresponding Late Dates; if the inactive task has a parallel logic path, the late dates (and corresponding Total Slack values) of its predecessors are typically incorrect. Lags and multiple calendars make things even more complex. We’ll have to address all these behaviors in the pending upgrade to BPC Logic Filter, our MSP add-in.]

Musings on Critical Path Drag and Calendars in CPM Schedules

As is the case for Total Float/Slack, introducing variable task calendars can significantly confuse the understanding of Critical Path Drag in Project Schedules.

Video – Compute Critical Path Drag in Microsoft Project]

Critical Path Drag is a useful metric in CPM scheduling that Stephen Devaux introduced in his book Total Project Control, but it is not widely computed or used. Drag represents the individual contribution of any single schedule element (e.g. a task) to the overall duration of a project. By definition, only “Critical Path” tasks have it, and a task’s Drag indicates the total theoretical project acceleration that could be gained if the task’s remaining duration were reduced to zero. Viewed simplistically another way: if Total Float/Slack represents how much a non-critical task may slip before becoming Critical; Critical Path Drag represents how much a Critical task may be compressed* before becoming non-Critical. This can be very useful in focusing a project acceleration (e.g. Crashing) exercise.

It’s clear that theoretically many components in a CPM schedule can possess Drag: activity durations, early constraints, and predecessor lags to start with. Activity calendars can also possess Drag. I originally incorporated Drag analysis into BPC Logic Filter with the aim of correctly analyzing the Drag possessed by each component, but I recently decided to at least temporarily set aside that idea for the following reasons:

Drag seems so rarely used in practice that using even a single number for each activity is a stretch for the typical user; parsing it out to its many components seems unhelpful to most.
Allocating Drag purely by passive network analysis is hard.
Most importantly, other Drag-computing software (namely Spider and Asta) seem to compute only a single figure for each activity. Allocating Drag to different components could conflict with these single-value metrics under some circumstances, leading to confusion and possible loss of confidence in the tool.

Now BPC Logic Filter provides an option to compute a single driving path Drag number for each task included in a logical analysis – using a brute-force, remove-and-recalculate approach. This Drag reflects the maximum acceleration of the project’s completion milestone (or any other selected milestone or task in the project) to be gained by modifying the task’s duration alone. A negative value indicates that the project is shortened by lengthening a particular task – this is reverse logic flow.

As is the case for Float/Slack, introducing variable task calendars can significantly confuse the understanding of Drag. Consider a simple project comprising three 1-day tasks in sequence, beginning on a Friday and with the first two tasks assigned the “Standard” calendar, i.e. 5dx8h. The concluding task “Activity 3” (perhaps a management task) is on a “Monday-Only” calendar.** As shown in the figure below, Activity 3 is scheduled to complete on the second Monday.*** Clearly, removing the duration of Activity 1 (or 2) will accelerate the Completion Task – Activity 3 – by seven calendar days, from the second Monday to the first Monday.

So what is the Drag of Activity 1? As shown by the combined figures below, the answer depends on the calendar used to quantify the acceleration. Measured according to Activity 1’s own calendar, a Monday-to-Monday acceleration is 5 days – indicating 5 days of Drag. That same Monday-to-Monday acceleration is only 1 working day according to the calendar of the Completion Task – resulting in 1 day of Drag. Using the Project’s overall calendar could provide different results altogether. For Activity 3 of this example, the Project Calendar is neither the Local Task Calendar nor the calendar of the Completion Task (also Activity 3); then it becomes like the first two tasks with a Drag of 5 days.

Which is the correct calendar to use? My own preference is to use the calendar of the Completion Task to quantify potential acceleration of the Completion Task (i.e. the middle option above), and this is the default selection in BPC Logic Filter. A detailed logical analysis would assign 1 day of Duration Drag to each of the tasks in the example and a further 4 days of Calendar Drag to Activity 3. There is no logical basis for adding these 4 days of Calendar Drag to any other task, but using a mismatched calendar in a brute-force Drag analysis does exactly that, as shown in the top and bottom options above. Those options remain in BPC Logic Filter to allow consistent comparisons with Drag calculations from other tools.

*In the absence of constraints, variable calendars, and certain relationship lags; the compression of a particular Critical Path task can lead directly to compression of the project. Then the idea that Drag represents the potential productive compression of the task itself (i.e. the mirror image of Total Float/Slack) can appear true. Such a simplified view should not be generalized for complex projects, however.

**Credit and thanks for this example go to Vladimir Liberzon of Spider Project. Spider is one of the few scheduling tools to compute Drag.

***Project correctly computes Total Slack of 4 days for the first two tasks, meaning they could each slip 4 days – according to their own calendars – without delaying the project. MSP marks them non-Critical. They are nonetheless on the driving path to project completion, as shown by BPC Logic Filter, and they possess Drag.

No Summary Tasks on the Critical Path – Calculating Total Slack for Summary Tasks in Microsoft Project

Total Slack as presented in Microsoft Project is not a valid metric for logical analysis of Summary Tasks. Users are advised to ignore it.

Underlying the “automatic” project scheduling in Microsoft Project are some simple mathematical processes that are commonly referred to as the Critical Path Method (CPM). CPM schedule calculation starts with a “Forward-Pass” through the schedule network to identify the earliest POSSIBLE start and finish dates that can be scheduled for each task – subject to its calendars, predecessors, and early constraints. Next – starting from the project completion – comes the “Backward-Pass” to identify the latest ALLOWABLE start and finish dates for each task, subject to its calendars, successors, and late constraints. For each task the difference between the late and early dates is called “Slack”.

“Start Slack” = Late Start – Early Start

“Finish Slack” = Late Finish – Early Finish

“Total Slack” = the lesser of Start Slack or Finish Slack (with some exceptions).

In traditional CPM, the “Critical Path” – i.e. that collection of tasks that controls the completion date of the project – is identified using Total Slack according to one of the following definitions depending on the complexity of the project and other factors:

Total Slack = 0; or
Total Slack = the lowest observed value.

Microsoft Project identifies critical tasks based on Total Slack <=0 (or some other threshold). [As noted in another post, this often leads to an incorrect identification of Critical Path for a project.]

Summary tasks are not anticipated in traditional CPM algorithms, so calculation and interpretation of Slack/Float for summaries can vary significantly between scheduling tools. In some (or most) CPM tools, summaries exist primarily to roll-up cost and schedule data (including slack/float) from the underlying sub-tasks. In Project, however, each summary task exists first as a task in its own right, with corresponding logical and hierarchical relationships to other tasks. This leads to common misunderstandings of exactly what is meant by “Total Slack” of a summary task in Microsoft Project.

In general, the following observations hold true for MSP 2010 Professional:

Each summary task inherits its early and late dates from its sub-tasks according to the following:
1. Early Start = the earliest Early Start of all the sub-tasks;
2. Late Start = the earliest Late Start of all the sub-tasks*;
3. Early Finish = the latest Early Finish of all the sub-tasks;
4. Late Finish = the latest Late Finish of all the sub-tasks*.
  [* Behavior shown is for normal scheduling, i.e. schedule from project start with ASAP constraints.]
The Start Slack, Finish Slack, and Total Slack of the summary task are computed according to the inherited early and late dates.
Since Total Slack of the summary task is derived from up to four different, logically unconnected sub-tasks, it has no significance with respect to the Critical Path or any other logic path in the project schedule. This is illustrated in the figure above: Summary task B inherits its Early Start and Late Finish from task B1 and inherits its Late Start and Early Finish from task B4. The resulting 4 days of Total Slack shown for the summary task reflects the difference between the Late Finish of task B1 and the Early Finish of task B4 – completely meaningless in the absence of any logical connections between the two tasks. The 4 days of Total Slack for the summary task is also unrelated to the Total Slack values of any of its underlying sub-tasks.
If the summary task possesses logical successors – or if its parent or any outline-ancestor summary tasks possess logical successors – then the late dates can be further accelerated through hierarchical inheritance. The result is total slack that is sometimes zero or negative.
If the summary task possesses a manually-scheduled sub-task whose start date precedes that of any other sub-task under the summary, then the manual sub-task’s scheduled start date will be written to both the early and late start of the summary task, resulting in zero start (and total) slack.

Some tools have allowed summaries to display the “most-critical” (or lowest) float of the associated activities – which at least means something. Similar behavior may be obtained in Microsoft Project by inserting a custom duration field – say “Rolled Up Total Slack” – using a simple formula (“=[Total Slack]”) with “Rollup” set to Minimum.

Many modern MSP schedules incorporate variable calendars, deadlines, late constraints, or resource leveling; and the basic CPM assumptions no longer apply. Under such conditions Total Slack for any task – summary or sub-task – becomes unreliable for identifying the Critical Path or any other logical path through the schedule. That’s when a utility like BPC Logic Filter is needed.