none
Tasks wrongly included in the critical path/ wrong calculations

    Question

  • As shown in the example below tasks "e", "f" and "g" should not be highlighted as part of the critical path and their "Start slack" should be 10 days and not 0 as calculated by Project. Free slack calculations for tasks "a" and "b" are also wrong.

    Friday, April 19, 2019 7:50 PM

All replies

  • Ed10001,

    1. Your expectations seem to be based on the original CPM algorithms, where only finish-to-start relationships were allowed, and durations were elastic.
    2. Like the other dominant, modern project scheduling tools, MS Project requires and presumes an inelastic, contiguous task duration in the scheduling calculations.  Consequently, the Early Start of tasks e, f, and g are pulled out (delayed) by their early finishes.  That's just the way it works.  Primavera P3 used to allow interruptible (elastic) durations, which would perhaps give you what you expected.  I haven't used that tool since 2010, and even then it was ~15 years old.  Apparently, interruptible durations were more trouble than they were worth.
    3. What are Free-slack for a and b supposed to be, if not 0? 
    Friday, April 19, 2019 10:01 PM
  • Thanks for your response. My expectations are based on the definition of the terms.

    1) Project defines "Start slack" as follows (https://support.office.com/en-ie/article/start-slack-task-field-3f163fb6-41d6-4571-a1ff-ac821b7e2f77)

    Description    The Start Slack field contains the duration between the Early Start and Late Start dates. The smaller of the start slack and finish slack amounts determines the amount of free slack available, that is, the amount of time a task can be delayed without affecting the start date of a successor task or the project finish date.

    How Calculated    Start slack is the duration that represents the difference between the early start and late start dates. The early start is the earliest date that a task could possibly start. Likewise, the Late Start field contains the latest date that a task can start without delaying the finish of the project. Microsoft Office Project calculates the start slack as follows:

    Start Slack = Late Start - Early Start

    2) In consequence the Start Slack for tasks "e', "f" and "g" must be ten days

    3) If the constraint type is "Start as soon as possible", why are task "e", "f" and "g" scheduled as late as possible?

    4) Project defines "Free Slack" as (https://support.office.com/en-us/article/free-slack-task-field-87145b2b-8d50-45a1-b89b-89aa73015d17)

    Description    The Free Slack field contains the amount of time that a task can be delayed without delaying any successor tasks. If the task has no successors, free slack is the amount of time that a task can be delayed without delaying the entire project's finish date.

    5) The start of tasks "a" and "b" can be delayed for ten days without affecting any successor task nor the duration of the project in consequence the value of "free slack" for those tasks should be 10 and not zero.

    Regards,

    Saturday, April 20, 2019 3:03 AM
  • Ed10001,

    Thanks for clarifying.

    1. From my perspective, the second sentence of the Start Slack reference is just incorrect – a sloppy technical writer conflating aspects of Free Slack with aspects of Total Slack.  (The smaller of Start Slack and Finish Slack typically determines TOTAL Slack, not Free Slack.)  Yes… Start Slack=Late Start – Early Start.
    2. Start Slack for e, f, and g is zero, not ten days, because Early Start = Late Start.  As a consequence of the inelastic task duration requirement mentioned in my earlier response, the Early Start of all three tasks is Fri 5/3/19, NOT Fri 4/19/19 as you seem to expect.
    3. Tasks e, f, and g are indeed scheduled as soon as possible.  Task d prevents e from finishing (and hence, starting) any sooner than shown.  A similar finish-restraint cascades through tasks f and g.
    4. There’s no problem with the Free Slack description in the references.  In practice, however, it’s never been all that helpful and hardly ever gets included in standard schedule reports.
    5. Nope.  Any delay of a or b will directly delay c (through the FF relationships).  Free Slack is zero. 

    When the observed program functionality doesn’t match the user documents, then in all likelihood the documents are wrong.  In this case, they seem to have led you astray.

    Good luck, tom

    Saturday, April 20, 2019 11:53 PM