Critical Path RRS feed

  • Question

  • I have a task that is clearly in the critial path when I schedule by work and resource availability, but when I change it to scheduling by duration it changes back to blue even though tasks on either side are red.  The reason I want to schedule this task as such is because it is a fixed time and runs by calendar days so I want to schedule by using the 'edays' command.  I have product that must sit on the shelf for X days (calendar) before I can test it.  It is this long time that is driving my project and so by definition it is a critical path.  What gives?

    Wednesday, January 27, 2016 3:28 PM

All replies

  • MedDevice Engr,

    Yes that's right. Think about it this way, a normal working day task has 8 hours working time and 16 hours non-working time. On the other hand a task that is scheduled in edays doesn't have any non-working time, therefore it is very likely that when an eday task finishes, there will be slack time before the next working day task starts. That creates positive total slack for the eday task and therefore it drops out of the critical path, which by default is defined as zero or less total slack. I suppose you could adjust your critical path threshold (File/Options/Advanced group), but that might have other undesired results.

    Hope this helps.


    Wednesday, January 27, 2016 3:58 PM
  • Tasks with duration in edays are never on the critical path if critical is defined as zero total slack, even if they are sandwiched between two tasks which are on the critical path. When you say that the task is "driving" your project, that's your expression but not an accurate one. Critical tasks don't "drive" anything, they just are critical because they have less than some defined amount of total float (slack), where the float is the difference between the late start and early start. The definition of critical is normally zero total slack, but that definition can be adjusted upwards in file, options, advanced. Also, free slack and total slack for tasks with duration in edays are both measured in edays. It is easily tested and best illustrated with an example as in this screenshot which shows the schedule table which has the early and late dates. Note the difference between the finish times. Try this example with the definition of critical adjusted upwards. Try it with the duration of task 1 = 3.5 days. Try it with the duration of task 2 = 1.7 edays. Try it with duration of task 2 = 24h and the 24 hour calendar. Subtle, isn't it? Any help?

    Wednesday, January 27, 2016 8:35 PM
  • MedDevice Engineer,

    To amplify John and Trevor, Total Slack and Project’s definition of “Critical” do not always indicate the logical driving path(s) to project completion.  The situation arises whenever you introduce multiple calendars or multiple deadlines into a project schedule.  (Specifying a duration in elapsed days is essentially the same as imposing a 24h x 7d calendar on the task.) 

    Yes, you can increase your “critical” slack threshold to include higher values, though of course that increases the chance of incorrectly marking non-driving paths as critical.  If you are using Project 2013+, then you have access to the “task path” menu.  There, you can graphically identify the driving logical path to whatever task you choose – including a project completion milestone.

    Ultimately, if you want Total Slack to accurately and consistently represent the driving path to project completion, then you’ll need to abandon variable calendars (including combined working-time and elapsed-time durations) – as well as deadlines and “no later than” constraints.  I wrote an entry on another example some time ago:

    Thursday, January 28, 2016 5:00 PM