none
FNET Constraint & Non-Working Days RRS feed

  • Question

  • I ran into an unexpected result using the Finish No Earlier Than constraint with non-working days.  The following tasks were created with a revised standard calendar that has 7/4 & 7/5 set to non-working days.  The first task has a Start No Earlier Than constraint set to 7/4.  As I expected, the constraint respected the non-working days and adjusted to the start date to the first working day after the constraint date (7/6).  The FNET constraint was also set to 7/4, but the finish date was set to 7/4 even though it is a non-working day.

    Task Mode Task Name Duration Start Finish
    Auto Scheduled Sample Task SNET 7/4 1 day? Wed 7/6/16 Thu 7/7/16
    Auto Scheduled Sample Task FNET 7/4 1 day? Thu 6/30/16 Mon 7/4/16

    I expected the finish date to be pushed out to 7/6 due to the non-work days.  I am not understanding something about the FNET constraint functionality or is there something else that needs to change on the task to get result I was expecting?  Any help is greatly appreciated.

    Friday, July 1, 2016 5:32 PM

Answers

  • Dan,

    There's a couple of things missing from your scenario.

    First, for the first task the dates don't quite add up. For a 1 day task, it will start on 7/6/16 8:00 AM and finish on 7/6/16 5:00 PM but your picture shows it finishing on 7/716, time unknown.

    Second, a similar issue with the second task. If it starts on 6/30/16 then as a one day task it would ordinarily finish on that same day, but it is constrained to finish no earlier than 7/4/16 so it inexplicably stretches to two full working days.

    I think what you are seeing is understandable because in the first case the task indeed is started no earlier than the constraint. The modified calendar sets the start date and the constraint is fulfilled (i.e. 7/6/16 is after 7/4/16). In the second case the constraint is also fulfilled in that the task finishes no earlier than 7/4/16. Perhaps it is a little easier to visualize if a resource is assigned to the second task as in the screen shot below. Note that no work is performed during non-working time but to honor the constraint, the duration is actually shown through 7/4/16. Also note in my example that the start date of the second task is 7/1/16, (instead of 6/30/16), which keeps it a one day task.

    Yeah, it is a little bit confusing, but hope this helps.

    John

    • Marked as answer by Dan Smith PMP Sunday, July 10, 2016 2:47 PM
    Friday, July 1, 2016 8:16 PM

All replies

  • Dan,

    There's a couple of things missing from your scenario.

    First, for the first task the dates don't quite add up. For a 1 day task, it will start on 7/6/16 8:00 AM and finish on 7/6/16 5:00 PM but your picture shows it finishing on 7/716, time unknown.

    Second, a similar issue with the second task. If it starts on 6/30/16 then as a one day task it would ordinarily finish on that same day, but it is constrained to finish no earlier than 7/4/16 so it inexplicably stretches to two full working days.

    I think what you are seeing is understandable because in the first case the task indeed is started no earlier than the constraint. The modified calendar sets the start date and the constraint is fulfilled (i.e. 7/6/16 is after 7/4/16). In the second case the constraint is also fulfilled in that the task finishes no earlier than 7/4/16. Perhaps it is a little easier to visualize if a resource is assigned to the second task as in the screen shot below. Note that no work is performed during non-working time but to honor the constraint, the duration is actually shown through 7/4/16. Also note in my example that the start date of the second task is 7/1/16, (instead of 6/30/16), which keeps it a one day task.

    Yeah, it is a little bit confusing, but hope this helps.

    John

    • Marked as answer by Dan Smith PMP Sunday, July 10, 2016 2:47 PM
    Friday, July 1, 2016 8:16 PM
  • And why all the constraints? Best practice is to link tasks and use only the minimum constraints required to map what will most likely happen.

    Rod Gill
    Author of the one and only Project VBA Book
    www.project-systems.co.nz

    Saturday, July 2, 2016 3:52 AM
    Moderator
  • Hi John,

    Thanks for the response to my question.  While I follow the logic of your explanation, I think the FNET constraint would be easier to use if reacted to non-working days in the same as the SNET constraint. In the end, this is a pretty rare circumstance and the impact to the project plan is minimal.  I was really just trying to improve my understanding of the way Project enforces the constraint.  Thanks for your help with this issue.

    -Dan

    Sunday, July 10, 2016 2:47 PM
  • Hi Rod,

    Thanks for the feedback on my question about the FNET constraint.  I agree that pure task dependencies are the best way to manage the WBS.  When I set up tasks initially, that is very much the convention that I follow.  I should have mentioned as part of my original post, that in this case we are in the execution phase and I am adjusting tasks to reflect the actual status of work that has either not started or not finished as originally scheduled.

    You might be interested to know that the constraint maintenance process I use is an Excel VBA module that I created based on examples from your book.  As an inexperienced VBA developer, the examples you include in the book have been a huge help to me. 

    -Dan

    Sunday, July 10, 2016 2:56 PM
  • Dan,

    You're welcome and thanks for the feedback.

    John

    Sunday, July 10, 2016 6:47 PM