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:

  1. Total Slack = 0; or
  2. 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:

  1. 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.]
  2. The Start Slack, Finish Slack, and Total Slack of the summary task are computed according to the inherited early and late dates.
  3. 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.
  4. 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.
  5. 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.

2 thoughts on “No Summary Tasks on the Critical Path – Calculating Total Slack for Summary Tasks in Microsoft Project”

  1. Hi Tom…

    I have instituted the following formula in a custom Duration1 field renamed as ‘TS*’. * denotes it is a custom field
    IIf([% Complete]=100,240000,[Total Slack])

    #1 – this coverts all 100% tasks to Total Slack = 100w** – Completed tasks should have no float, not even zero. This simplifies filtering for critical zero float tasks and not having to also filter out completed tasks. It also prevents completed tasks to falsify a summary task total slack from zero (a completed task) to show the proper minimum positive value. I have yet find a schedule that the most critical task was 100w positive.

    #2 – I set roll up minimum as your article suggests. This way the summary displays the most critical task under the summary, preventing hidden critical paths in summary schedules.

    **Note… I usually schedule in weeks. I find weeks is a more universal terminology to communicate schedules with non-schedulers. Everyone can conceptualize weeks much better than any other date element. Days become problematic due calendar vs mfg or working days. The difficulty of individuals (even schedulers) to conceptualize quickly large durations in days (125 mdays = 25 wks = ~6 mo.). Most Mfrs provide lead time in weeks. Weeks also conveniently breaks down into smaller increments: 5d = 1w; 1d = 0.2w; 1/2d = 0.1w; 1/4d = 0.05w. I rarely schedule to the 1/4d. Therefore, one could schedule using one date unit of measure for durations from 1 day (0.2w) to 3 years (156w) and everyone understand quickly and easily without doing mental or physical calculations.

Leave a Reply

Your email address will not be published. Required fields are marked *