none
SCHEDULE VISIBILITY TASKS (SVT)

    Frage

  • During my review of an IMS I found that the Critical Path appears to be broken.  Therefore the IMS cannot be trusted to accurately reflect the impact to the project “Finish” date if duration or logic of any tasks are changed.  I discovered that Total Slack of 8 days is introduced into the schedule via an alternate calendar being used “Test Calendar” which broke the critical path.  The "Test Calendar" had exception days (non-working days) which means that this particular task could not start immediately after the predecessor task.  Therefore the Total Slack of the predecessor changed from 0 days to 8 days, breaking the critical path.  I believe this is called a "Resource Critical Path".  My question is whether or not it is appropriate to use Schedule Visibility Tasks (SVT) to reflect the non-working days and thereby fix the broken critical path.  I've heard the SVTs can be used to reflect Schedule Margin.  Wouldn't it be appropriate to use to fix a resource critical path as well?  Thanks in advance for your assistance on this.

    Freitag, 29. Juni 2018 15:14

Antworten

  • Hi Mike,

    First, regardless of whether the alternate calendar is a Resource Calendar or a Task Calendar, IMO the situation you describe has nothing to do with a Resource Critical Path (an animal that, like a unicorn, is often referenced but rarely seen.) 

    You are describing the natural consequence of introducing multiple calendars into the schedule calculation: i.e. if the interval between two sequential tasks on the Critical Path contains working time according to the predecessor's calendar but not the successor's, then the predecessor quite rightly possesses Float/Slack.  (It could slip some time, according to its own calendar, without delaying its sole successor or the project.)  The problem is not that the Critical Path is "broken."  It's still present as the "longest path"; the driving logic path to project completion; the path that MUST be shortened if the project is to be accelerated/recovered.  Unfortunately, certain complicating factors that are common in complex projects (including multiple calendars) make Total Slack unreliable for identifying it.

    Your suggestion to use an SVT to represent a specific calendar exception seems attractive to remove the float from the predecessor and thereby "un-break" the Critical Path.  I suppose I might be tempted to use it as a one-off approach if better methods weren't available.  Nevertheless, I believe that it - by conflating schedule logic with working time definition - represents a poor practice that in the long run will raise more questions and cause more problems than it solves.  

    There are commercial Add-ins that address these issues.  Look for OPDEC, PathsPro, and Driving Path Widget.  The first seems well established in the defense industry (where the term "SVT" seems to have originated.) I use a different add-in (BPC Logic Filter) that my company developed for internal use, though we do share it.

    Good luck, tom


     


    Freitag, 29. Juni 2018 18:39
  • Mike, I couldn't have said it better than Tom myself. Frankly, I don't see what you are worried about. It is a natural and entirely anticipated outcome and obvious that if you introduce task or resource calendars into the critical path you will introduce float and interrupt (I won't say break) the critical path. Of course, in the Defense world everything has to be over-complicated and three letter acronyms for everything are essential. "SVT"? That's just padding and a device to cover up a problem which is not really a problem at all. Is it "appropriate"? I don't think so. Just let the chips fall where they fall and explain it away. You are perhaps worried about having to explain the gap in the CP to someone who thinks it is somehow "wrong" because they read that somewhere.

    By the way, you can get this interruption just by mixing task calendars, without any resources assigned to anything. So it is not called a "resource critical path" (or RCP), which, by the way, is a unicorn, or rather just another made up expression to make things more complicated than they really are.

    Where this stuff comes from, the DCMA 14 point test, the PASEG etc, are useful and perhaps well intentioned, but they are not the absolute last word on everything.

    Samstag, 30. Juni 2018 01:25
  • Mike, everything to the left of the status date should be actual, and everything to the right should be planned/scheduled. It helps if you make the status date gridline a solid red vertical line on the chart. If a task has not actually started where it was scheduled to start in the past, relative to the status date, then it should be re-scheduled to start asap after the status date. This is easy with the move button on the task ribbon. Move incomplete parts (all of it) to the status date. Note that it picks up a SNET constraint. Progress shown in the future is just plain wrong. The DCMA (I use Barbecana Schedule Inspector) test picks up Tasks scheduled in the past and tasks with progress in the future, but you can just as easily make a filter to find them.

    A much bigger issue. Get this 100% right at every weekly status date or the whole plan falls apart.

    One way to light up the CP where it disappears before the interruption is to make a milestone which is a FS0 successor to the task just before the interruption, and with no successor. In file, options, advanced check calculate multiple critical paths. (but I guess this would be no better than a SVT)

    Montag, 2. Juli 2018 07:31
  • Mike,

    Since you've mentioned several times that you are "reviewing" a schedule [someone else's], I won't repeat Trevor's excellent advice about proper updating procedures.  Your instincts about the "progress bar" and the Status Date are correct.  The schedule you describe seems to have a number of "invalid dates" (DCMA Metric #9), i.e. incomplete work in the past and/or completed work in the future.  The presence of even one of these (particularly incomplete work in the past) means the schedule forecast is not accurate - with or without the calendar-related issues.  As a reviewer, the response is "Rejected. Learn how to update a schedule correctly, then revise and resubmit.)

    Unlike other scheduling tools, Project does not enforce rigorous progress updating.  Rather, the default behavior seems to presume simple updating of task %Complete on a static schedule, and the Status Date does not participate in schedule calculations.  (The latter fact dictates the proliferation of SNET constraints - normally taboo in a logic-driven schedule - as the sole method for delaying un-started tasks during an otherwise valid progress update.)  Thus, while Project remains somewhat intuitive for the casual users that dominate the user base - and whose idea of an "updated schedule" is essentially a paper Gantt chart hanging on the wall with hand-drawn progress bars and maybe the zig-zagging progress line - progress updating in accordance with the accepted industry practice requires jumping through a few extra hoops.  

     

    Montag, 2. Juli 2018 13:15
  • Mike, 

    By the "latter fact," I was referring to the fact that the Status Date is not directly incorporated into any schedule calculations, i.e. the forward and backward passes.  As a result, there are only two direct methods for enforcing the requirement that all incomplete work is later than (i.e. to the right of) the Status Date.  These two methods are 1) SNET constraints set to the Status Date on un-started tasks, and 2) Resume dates set to the Status Date on in-progress tasks.  These methods are typically implemented through one of the "Move" buttons (as Trevor noted) or using the lower part of the Update Project Dialog - i.e. "Reschedule uncompleted work to start after."  In addition, the "calculation options" checkboxes at the bottom of the Advanced Project Options can automatically move actual dates and/or Resume dates (to the Status Date) in response to %Complete or actual duration entries.  Need to be careful with those.

    Finally, since Project only allows a single task constraint, any un-started task with an existing non-SNET constraint can't be updated/delayed using the standard tools.  The existing constraint and/or logic will need to be revised. (And no, a %Complete entry never generates a SNET constraint - that would be kind of pointless.)

         


    Montag, 2. Juli 2018 23:21
  • Mike,

    if you do as many people do, and just input a % complete on a task which doesn't have an actual start date, you will force MSP to take the scheduled start date as the actual start date. It needs a date and that's the only one it's got. Of course, the correct thing to do is to then correct the actual start to be whatever it really was, but many people don't bother to do this. In no time at all, the whole plan unravels and all of the work that has gone into it up to that point is wasted.

    It is better, more disciplined, to forbid % complete input, and focus instead on the facts, the actual start, actual duration and actual finish. You can't go wrong if you stick to facts.

    Dienstag, 3. Juli 2018 09:44

Alle Antworten

  • Hi Mike,

    First, regardless of whether the alternate calendar is a Resource Calendar or a Task Calendar, IMO the situation you describe has nothing to do with a Resource Critical Path (an animal that, like a unicorn, is often referenced but rarely seen.) 

    You are describing the natural consequence of introducing multiple calendars into the schedule calculation: i.e. if the interval between two sequential tasks on the Critical Path contains working time according to the predecessor's calendar but not the successor's, then the predecessor quite rightly possesses Float/Slack.  (It could slip some time, according to its own calendar, without delaying its sole successor or the project.)  The problem is not that the Critical Path is "broken."  It's still present as the "longest path"; the driving logic path to project completion; the path that MUST be shortened if the project is to be accelerated/recovered.  Unfortunately, certain complicating factors that are common in complex projects (including multiple calendars) make Total Slack unreliable for identifying it.

    Your suggestion to use an SVT to represent a specific calendar exception seems attractive to remove the float from the predecessor and thereby "un-break" the Critical Path.  I suppose I might be tempted to use it as a one-off approach if better methods weren't available.  Nevertheless, I believe that it - by conflating schedule logic with working time definition - represents a poor practice that in the long run will raise more questions and cause more problems than it solves.  

    There are commercial Add-ins that address these issues.  Look for OPDEC, PathsPro, and Driving Path Widget.  The first seems well established in the defense industry (where the term "SVT" seems to have originated.) I use a different add-in (BPC Logic Filter) that my company developed for internal use, though we do share it.

    Good luck, tom


     


    Freitag, 29. Juni 2018 18:39
  • Mike, I couldn't have said it better than Tom myself. Frankly, I don't see what you are worried about. It is a natural and entirely anticipated outcome and obvious that if you introduce task or resource calendars into the critical path you will introduce float and interrupt (I won't say break) the critical path. Of course, in the Defense world everything has to be over-complicated and three letter acronyms for everything are essential. "SVT"? That's just padding and a device to cover up a problem which is not really a problem at all. Is it "appropriate"? I don't think so. Just let the chips fall where they fall and explain it away. You are perhaps worried about having to explain the gap in the CP to someone who thinks it is somehow "wrong" because they read that somewhere.

    By the way, you can get this interruption just by mixing task calendars, without any resources assigned to anything. So it is not called a "resource critical path" (or RCP), which, by the way, is a unicorn, or rather just another made up expression to make things more complicated than they really are.

    Where this stuff comes from, the DCMA 14 point test, the PASEG etc, are useful and perhaps well intentioned, but they are not the absolute last word on everything.

    Samstag, 30. Juni 2018 01:25
  • Trevor,

    Thanks for the confirmation.  I'd not want to lump PASEG (nor even GAO) together with the DCMA 14-point assessment.  The first two are actually pretty good documents in my opinion (with a few caveats) that highlight the hazards of relying on float/slack in complex schedules - but without recommending alternative methods.  The DCMA assessment, on the other hand has caused more harm than good in the long run.  This is mainly because the trigger values on the metrics lend themselves to dashboard-gaming behavior rather than good scheduling practices, IMO.  

    Samstag, 30. Juni 2018 14:58
  • Tom / Trevor,

    Thank you both for your response.  I really appreciate your help in enabling me to understand this topic, and whether or not there is an issue to be concerned with.  Based on your responses, I realize the Total Slack of 8 days is due to use of a separate calendar, so it's not a resource issue, and thanks for correcting me that its not a resource critical path.  It sounds as if you're saying that it's normal to have the slack (due to use of different calendars), and that its nothing to worry about.  Is that correct?  Since we have a positive Total Slack of 8 days, any delays in tasks that occur earlier may not be reflected in the final task Finish date, unless the delay in an earlier task exceeds the 8 days of Total Slack caused by the non-working days in the "Test Site" calendar.  So if an earlier scheduled task slips 5 days, we won't see an impact on the final task because we still have not exceeded the 8 days of Total Slack.  Is that why it's not an issue?  If an earlier task slips by 5 days, there was 8 days of Total Slack (now probably changes to 3 days Total Slack), so in fact we have not moved the final task because we still have balance of 3 days of Total Slack.  Is that why we don't worry that the IMS shows 8 days of Total Slack on the critical path?  If a prior task slips by 12 working days, then we would expect the final task to slip by 4 working days (12 days slip - 8 days Total Slack = 4 days of slip to the final task).

    Thanks for taking the time to respond!

    I hope my response here shows up.  The web-site wouldn't just let me "reply".  I had to use a different name.  Strange! 

    Samstag, 30. Juni 2018 17:48
  • Tom / Trevor,

    Thank you both for your response.  I really appreciate your help in enabling me to understand this topic, and whether or not there is an issue to be concerned with.  Based on your responses, I realize the Total Slack of 8 days is due to use of a separate calendar, so it's not a resource issue, and thanks for correcting me that its not a resource critical path.  It sounds as if you're saying that it's normal to have the slack (due to use of different calendars), and that its nothing to worry about.  Is that correct?  Since we have a positive Total Slack of 8 days, any delays in tasks that occur earlier may not be reflected in the final task Finish date, unless the delay in an earlier task exceeds the 8 days of Total Slack caused by the non-working days in the "Test Site" calendar.  So if an earlier scheduled task slips 5 days, we won't see an impact on the final task because we still have not exceeded the 8 days of Total Slack.  Is that why it's not an issue?  If an earlier task slips by 5 days, there was 8 days of Total Slack (now probably changes to 3 days Total Slack), so in fact we have not moved the final task because we still have balance of 3 days of Total Slack.  Is that why we don't worry that the IMS shows 8 days of Total Slack on the critical path?  If a prior task slips by 12 working days, then we would expect the final task to slip by 4 working days (12 days slip - 8 days Total Slack = 4 days of slip to the final task).

    Thanks for taking the time to respond!

    I hope my response here shows up.  The web-site wouldn't just let me "reply".  I had to use a different name.  Strange! 

    Samstag, 30. Juni 2018 17:49
  • Mike,

    you have the advantage of actually being able to see the plan that you are talking about. I think you may be worrying about problems that might occur later or may not arise at all. It is a good idea to look ahead and consider what might happen "if", but you will have to deal with those if and when they happen. You seem to be very concerned that as progress is recorded and logged, and the tasks' scheduled start and finish dates are progressively replaced by the actual start and actual finish dates, that the overall finish date will be forecast/scheduled/planned to be later than you want it to be, or later than your customer expects it to be. Unrealistic expectations are always the source of disappointment. Face it, it is going to happen. That's what the critical path method is for. As tasks slip from their earliest scheduled dates early in the project, as they always do, some of them may be on the critical path or may push other tasks onto the critical path. That might be thought to be bad news, but at least you are getting advance early warning so that you can do something about it, maybe. Everything not yet done is subject to re-planning, re-scheduling etc. That's the reality of management. Anyone who imagines that the plan is fixed at the start and will run like clockwork without any amendment along the way is simply in denial and does not have a clear understanding of what the critical path method is or what it is for. If I were you or your client, I would be much more concerned with rigorous, disciplined, timely progress tracking and updating and a lot less worried about reality occurring and the possibility that the plan may show the final finish date moving a bit to the right. Having someone nit picking about a little gap in the CP which is readily explainable doesn't help. You cannot even begin to plan what remains until you know for sure where you are at the most current status date.

    Sonntag, 1. Juli 2018 04:24
  • Mike,

    Like Trevor, I'm not going to venture into the mathematical realities of the schedule you are reviewing.  But basically, calendars warp some "fundamental" notions about the meaning of "Critical," such that substantial portions of a project's "longest path" actually possess float.  Some accepted definitions of "Critical Path", especially those based on Total Float, can no longer be strictly applied.  Here's an article I wrote about the issue a couple months ago: The Difference Between Critical Tasks and Critical Paths in Project Schedules.

    Good luck, tom

    Sonntag, 1. Juli 2018 15:38
  • Tom/Trevor,

    Thank you for taking the time to read my post and providing your thoughts/expertise.  I really appreciate your responses!  Until talking to both of you, I was under the impression that all tasks along a critical path had the same Total Slack.  It seems so obvious to me now that a calendar (or multiple calendars) that have non-working days can add Total Slack to a critical path.  It's the same as a soft constraint SNET.  After talking to both of you, I'm under the impression that it doesn't break the critical path.  It's still there, but now there is a positive Total Slack along the way, at least until that Total Slack gets consumed by some earlier task that is delayed or takes longer than planned.  Not sure how to proceed now to find the remainder of the critical path.  I think I'll choose the task with the 8 days of Total Slack and make that my "end task" and repeat the DCMA "Constraint Method" and see how far back that takes me.  I may have to repeat this process several times.  I am going to read Tom's article now because that title really perks my interest.

    Trevor talks about being more concerned with the disciplined approach of progress tracking and updating.  The schedule I reviewed had several tasks to the left of the status date, some tasks with a "progress bar" shown and some tasks with no "progress bar" shown.  To properly status a schedule shouldn't all tasks that have started (prior to the status date) show a "progress bar" up to the Status Date?  The Remaining Duration of that task bar would then be shown to the right of the Status Date.  Also if a task has not started yet, shouldn't that task bar be completely moved to the right of the Status Date?  Leaving tasks to the left of the Status Date means the rest of the schedule does not reflect the reality of these tasks behind schedule, correct?  If my thinking is correct, then perhaps this is a bigger issue than the critical path with 8 days of float. 

    Thanks so much for your help!

    Sonntag, 1. Juli 2018 20:53
  • Mike, everything to the left of the status date should be actual, and everything to the right should be planned/scheduled. It helps if you make the status date gridline a solid red vertical line on the chart. If a task has not actually started where it was scheduled to start in the past, relative to the status date, then it should be re-scheduled to start asap after the status date. This is easy with the move button on the task ribbon. Move incomplete parts (all of it) to the status date. Note that it picks up a SNET constraint. Progress shown in the future is just plain wrong. The DCMA (I use Barbecana Schedule Inspector) test picks up Tasks scheduled in the past and tasks with progress in the future, but you can just as easily make a filter to find them.

    A much bigger issue. Get this 100% right at every weekly status date or the whole plan falls apart.

    One way to light up the CP where it disappears before the interruption is to make a milestone which is a FS0 successor to the task just before the interruption, and with no successor. In file, options, advanced check calculate multiple critical paths. (but I guess this would be no better than a SVT)

    Montag, 2. Juli 2018 07:31
  • Mike,

    Since you've mentioned several times that you are "reviewing" a schedule [someone else's], I won't repeat Trevor's excellent advice about proper updating procedures.  Your instincts about the "progress bar" and the Status Date are correct.  The schedule you describe seems to have a number of "invalid dates" (DCMA Metric #9), i.e. incomplete work in the past and/or completed work in the future.  The presence of even one of these (particularly incomplete work in the past) means the schedule forecast is not accurate - with or without the calendar-related issues.  As a reviewer, the response is "Rejected. Learn how to update a schedule correctly, then revise and resubmit.)

    Unlike other scheduling tools, Project does not enforce rigorous progress updating.  Rather, the default behavior seems to presume simple updating of task %Complete on a static schedule, and the Status Date does not participate in schedule calculations.  (The latter fact dictates the proliferation of SNET constraints - normally taboo in a logic-driven schedule - as the sole method for delaying un-started tasks during an otherwise valid progress update.)  Thus, while Project remains somewhat intuitive for the casual users that dominate the user base - and whose idea of an "updated schedule" is essentially a paper Gantt chart hanging on the wall with hand-drawn progress bars and maybe the zig-zagging progress line - progress updating in accordance with the accepted industry practice requires jumping through a few extra hoops.  

     

    Montag, 2. Juli 2018 13:15
  • Tom,

    Thank you for conforming my thoughts that the schedule I'm reviewing does not seem to be statused correctly.  I'm not sure I understand your statement in the 2nd paragraph where you say "(The latter fact dictates the proliferation of SNET constraints...)".  Did you mean that updating the %Complete creates SNET constraints? 

    Thank you again for all the assistance you've provided!

    Mike Oberneder

     

    Montag, 2. Juli 2018 18:16
  • Trevor,

    Thank you for explaining what should happen to the left and right of the Status Date.  I did not know that pressing the Move button to move all the incomplete parts to the Status Date created a SNET constraint, but that makes sense.  Ok on the milestone creation and that it is similar to a SVT.

    Thank you again for all the assistance you've provided!

    Mike Oberneder

    Montag, 2. Juli 2018 18:22
  • Mike, 

    By the "latter fact," I was referring to the fact that the Status Date is not directly incorporated into any schedule calculations, i.e. the forward and backward passes.  As a result, there are only two direct methods for enforcing the requirement that all incomplete work is later than (i.e. to the right of) the Status Date.  These two methods are 1) SNET constraints set to the Status Date on un-started tasks, and 2) Resume dates set to the Status Date on in-progress tasks.  These methods are typically implemented through one of the "Move" buttons (as Trevor noted) or using the lower part of the Update Project Dialog - i.e. "Reschedule uncompleted work to start after."  In addition, the "calculation options" checkboxes at the bottom of the Advanced Project Options can automatically move actual dates and/or Resume dates (to the Status Date) in response to %Complete or actual duration entries.  Need to be careful with those.

    Finally, since Project only allows a single task constraint, any un-started task with an existing non-SNET constraint can't be updated/delayed using the standard tools.  The existing constraint and/or logic will need to be revised. (And no, a %Complete entry never generates a SNET constraint - that would be kind of pointless.)

         


    Montag, 2. Juli 2018 23:21
  • Mike,

    if you do as many people do, and just input a % complete on a task which doesn't have an actual start date, you will force MSP to take the scheduled start date as the actual start date. It needs a date and that's the only one it's got. Of course, the correct thing to do is to then correct the actual start to be whatever it really was, but many people don't bother to do this. In no time at all, the whole plan unravels and all of the work that has gone into it up to that point is wasted.

    It is better, more disciplined, to forbid % complete input, and focus instead on the facts, the actual start, actual duration and actual finish. You can't go wrong if you stick to facts.

    Dienstag, 3. Juli 2018 09:44
  • Message to Mike,

    As a third part observer I think it would be very appropriate for you to select a response from Trevor and  a response from Tom and mark them as the answer to your post. Both guys have given a considerable amount of their time helping you and I feel it is appropriate for you to formally recognize thier efforts. Note that marking a response (or responses) as an answer does not prevent further discussion.

    My opinion.

    John

    Dienstag, 3. Juli 2018 14:35
  • John,

    Thank you for your post.  I am new to this web-site, so I was not aware to select a "Mark as Answer".  I have now done what you suggested.  I also realize that both Tom and Trevor have taken considerable time to answer my questions, and I very much appreciate their assistance, and have mentioned that in my past responses to them.

    Thank you.

    Mike Oberneder

    Dienstag, 10. Juli 2018 02:09
  • Tom,

    Thanks again for your response and additional clarification.  I understand now, that the SNET constraint is set for un-started tasks, not for tasks that are in-progress and updated by the % Complete.  So using the "Move" button will create a SNET constraint but only for tasks that have not yet started. 

    I appreciate the time you have taken to help me understand.

    Thank you!

    Mike Oberneder

    Dienstag, 10. Juli 2018 02:56
  • Trevor,

    Thank you for your explanation.  I understand what you are saying, if someone enters a % Complete with no Actual Start date, then MS Project has to assume that the forecast "Start" date was met.  I like your approach to update the Actual Start, Actual Duration, and then the Remaining Duration.  In that manner then the actual start is recorded, and the Actual Duration plus Remaining Duration would force Project to recalculate the "Duration", and then the Percent Complete is correctly calculated by the "Act Dur"/"Duration".  I think I've heard that some people just "Mark on Track" and then adjust the Remaining Duration.  Is that okay as long as the Actual Start date is not of concern?  The check boxes that Tom wrote about would also have to be checked correct?  To move non-started tasks to the right of the status bar, and remaining duration of in-progress also to the right of the Status Bar. 

    Thanks again for your time in answering my questions and helping me understand.

    Mike Oberneder 

    Dienstag, 10. Juli 2018 03:18