none
Task Calendar - DO NOT Ignore Resource Calendar

    Question

  • Hi folks

    Can someone help me confirm that this is a bug...

    The problem has to do when a task calendar is applied and the ‘Ignore Resource Calendar’ = No.

    The Task Type is set to ‘Fixed Duration’, and Effort Driven = No.

    This is the Scenario:

    The task Calendar is explicitly set to e.g., Standard (i.e., Mon-Fri, 8am-12pm, and 1pm-5pm).

    Assigning resources whose base calendar does not overlap with the task calendar (e.g., Resource works on weekends only), this yields a warning message that there is “Not enough common working time” which is fine by me.  However, rather than respecting the resource calendar (i.e., which is set to NOT Ignore resource the calendar), MS Project goes ahead and does the opposite of what I asked it to; i.e., it IGNORES the resource calendar!

    When we do not apply a task calendar, and leave the task to its default setting, i.e., Task Calendar = None, this scenario behaves beautifully!  I.e., in trying to assign a weekend resource to a default task Project will not assign any hours from that Weekend resource to such a task.  This is what I want and would expect as well when a task calendar is applied, and the ‘Ignore Resource Calendar’ = No.  Yet this default scenario (Task Calendar = None) does not even yield a warning message when there is “Not enough common working time”.

    Do you see the errors in this behavior or is it just me?


    \Spiro Theopoulos, Montreal, QC (Canada)


    • Edited by Spiro Theopoulos Thursday, December 13, 2018 2:31 AM fixed some typos
    Thursday, December 13, 2018 2:24 AM

Answers

  • Greetings again Spiro,

    I have tried to translate your comments into MS Project:

    As I understand it, you claim that;

    In (B), Project is supposed to alert us with a warning message since there is no intersection between the project calendar and the resource calendar. But the result is OK, the resource with 0 hours allocated. 

    In (E), Project is not supposed to allocate any hours for the resource, since there is no intersection between the task calendar and the resource calendar which is not being ignored. So it is a bug or design error. 

    R1's base calendar: Standard

    Wknd_Rx : resources working only at the weekends. 

    Monday_Rx: resources working only on Mondays.

    I might not consider it as a bug since I am familiar with the behavior, but I understand your point. 


    Ismet Kocaman | eBooks on Formulas

    Thursday, December 13, 2018 8:42 PM
  • Spiro,

    nice puzzle you've got going here.

    OK, I'll stick to a 5 day task, the task is fixed duration and effort driven is off, ignore resource calendar is off.

    The sequence of doing things makes a difference. This has always been true for, for example, type in a duration, type in a start date, type in a finish date, re-type the duration... and around in circles you go. If you don't get what you want in one hit, you have to go back to scratch and start again and take a different route with a different sequence.

    Case 1: Before the resource is assigned, the task is fixed duration and effort driven is off, ignore resource calendar is off, and the task has no task calendar assigned:

    there is no warning about insufficient common time, no work, and no over-allocation

    Case 2: Before the resource is assigned, the task is fixed duration and effort driven is off, ignore resource calendar is off, and the task has the standard calendar assigned:

    there is a warning about insufficient common time, 40 hours of work, and the resource is over-allocated.

    You can't change Case 2 back into Case 1 by just removing the task calendar. If you try it, you get a warning that the resource is assigned outside the original dates and MSP changes the duration to accommodate (but of course it can't accommodate), and the 40 hours of work ends up on the weekends and the resource is over-allocated. True, it makes a change that you don't ask for, or one that you don't expect (depending on what you expect). It tries hard, and comes up with only one "solution" when there may be others that it doesn't suggest.

    It is less of a pain if you put aside your expectations and opinion about what is good or bad design, and accept and understand what "is". I discovered long ago that using MSP gets a lot easier this way. I could blame the SW, but if I set up an extreme or impossible case (M-F task with a weekend resource), it's my fault, and it's gonna do what it does.

    Thursday, December 13, 2018 10:10 PM
  • Spiro,

    This is an interesting question, and I don’t know the answer.  Project generally follows good logical processes, but sometimes a coin has to be flipped at the edges….  I think Ismet's got it right.

    In the case of a task having both a task calendar and a resource (with a conflicting calendar) applied, there are three obvious control methods:

    1. To have work performed only when BOTH the task calendar and resource calendar allow, then “Ignore resource calendars” = NO.
    2. To have work performed according to the task calendar only, forcing resources to work when they are not formally available, then “Ignore resource calendars” = YES.
    3. To have the work performed according to the resource calendar(s) only, allowing resources to work even in violation of the task calendar, then REMOVE THE TASK CALENDAR.

    It seems logical to expect a checkbox or radio buttons to select between the desired outcomes of (2) and (3), but it’s not so simple.  When they exist, Task Calendars over-ride all other calendars when it comes to calculating slack, and they are the default calendars for any of the special project date functions.  If the Task Calendar exists but does not control the scheduled dates, then these calculations could be very wrong.  Removing the calendar assignment seems the cleanest way to minimize confusion.  (Note: in this case, slack calculations will be made using the Project calendar, which may be presumably less wrong.)

    Thanks for the thoughts, tom

    Thursday, December 13, 2018 11:50 PM

All replies

  • We just got through with a conversation about a similar topic:

    https://social.msdn.microsoft.com/Forums/en-US/8a589c69-fb6c-4b47-bbbf-a13ad7a817b3/the-latest-project-20162019online-versions-have-an-assignment-oddity-related-to-the-resources?forum=projectprofessional2010general

    I say it is just you, for now at least. A bug is when it doesn't work as designed. Even if what you get is not what you want or expect, it can still be working as designed, and it is what it is. What you want or expect is irrelevant and best forgotten because it just gets in the way. You may say that it is bad design, but that is just an opinion even if perhaps a valid one. If you think that one scenario is more "beautiful" than others, this is a bias resulting from wanting or expecting.

    Also, I think you suggest a bug without sufficient investigation.

    You cite only the case of the task type being fixed duration and effort driven off/no.

    But there are 5 possible combinations of task type and effort driven so they would all have to be accounted for. It is probably best to start with the default fixed units and effort driven off, and go from there. Not that the default is better or worse than any other combination as a starting point.

    There is also that case that the task has or does not have an explicit task calendar assigned, so that is 5 x 2 = 10 possible scenarios.

    And you have not considered the case of Ignore Resource Calendar = On/Yes, and if that was considered there would be 20 possible scenarios. Maybe one of the other 19 scenarios is as beautiful as the one you like.

    Anyway, what's your beef? You got what you want, Is the complaint that you don't get the "Not enough common working time" warning?

    So I will check those 20 scenarios and get back to you. However, I think you are incorrect where you say that it "IGNORES the resource calendar!". It doesn't, but it does just look like it does.

    Thursday, December 13, 2018 6:57 AM
  • Greetings Spiro,

    I would like to share my opinion on this behavior with you.

    Let us think the other way around, that is, using a task calendar with the weekend working hours, as shown below: 

    Consider the scenario where a project task can only be performed at the weekends in a manufacturing plant.

    For this purpose, I define and apply the task calendar Wknd to those tasks.

    In Scenario 1, despite its calendar, I assume that R1 is flexible enough to work at the weekends. 

    In Scenario 2, the warning dialog box message already displayed and the column Indicators, both tell me that 
    I need to find another resource available to work on that task at the weekends. This is the behavior that I expect from Project, in other words, not ignoring the task calendar in any scenario. 

    Kind Regards.

    PS. Both R1 and R2 have "Standard" as the base calendar.

    • Edited by Ismet Kocaman Thursday, December 13, 2018 8:42 AM Added PS.
    Thursday, December 13, 2018 8:32 AM
  • Hi Ismet and Trevor,

    Thanks for taking the time to reply to my post.

    The following is what I expect the behavior to be.  I want us to focus on the Fixed Duration and Effort driven = off, given this task type's particular behavior and because this is what I am trying to isolate as the issue.  I know there are many other combinations/ permutations, but again it is the Fixed Duration that I want and the Effort Driven "off" that I am interested and focused on.

    There are 2 extremes in my scenario:

    1) the default, i.e., the project calendar drives

    2) the task calendar drives, i.e., task calendar applied and Ignore Resource Calendar = Yes

    And in the middle of these two is where my so called "beef" lies. (Task Calendar, Ignore Resource Calendar = No).

    You see in Scenario 1, where there is no task calendar explicitly set, the task's start and finish establishes the window when the resources are requested to work (if they can).  in this scenario the resources work and respect their respective resource calendars.  Great!  If there is no overlap between the task's start and finish window, then the resource does not perform any work.  One very "minor" beef (and I do not really care regarding this inconsistency in behaviour) which I have here in this scenario "1" which is that you do not get the warning message, i.e., when where there is no overlap (or better yet, where there is no "intersect" between a task start-finish and the resource calendars).  In this case, when there is no "intersect" between task start-finish and resource calendar it sets the resource work to zero.  Great!!! I would say that in this scenario, MSP implicitly does "not" ignore the resource calendar. Perfect!!!!

    BETWEEN scenario "1" at one end, and Scenario "2" at the other end of the spectrum lies my "beef" (scenario "2" being: do what the task calendar asks of you regardless; i.e., ignore your resource calendar).  So, what I would expect in "my" middle-of-the-road scenario, where I have a task calendar specified with Ignore Resource Calendar set to "OFF" (i.e., the do not ignore behavior, that it would act more like in scenario "1" above), that it is it should behave like Scenario "1", i.e., the task's start and finish establish the working window, and if the resource calendar permits, then the resource would be assigned during that intersect between its resource calendar and the task's start-finish.  This would seem rather logical to me.  My "beef" in this middle-of-the-road scenario is it assigns you work when I did not ask it too.  I am using do not ignore.  If I wanted anything else, I would have set it up using Scenario 1 or 2. This, my  middle-of-the-road scenario is a pain that MSP assumes that I must want the resource to do what the task says when there is no overlap, and use the intersect for other resources. Wow!

    Bug, or bad design?  Wrinkle?  For sure it's a "pain"!

    Kind regard,


    \Spiro Theopoulos, Montreal, QC (Canada)






    Thursday, December 13, 2018 2:36 PM
  • Hi Trevor, I replied to you via my reply to Ismet...

    \Spiro Theopoulos, Montreal, QC (Canada)

    Thursday, December 13, 2018 2:37 PM
  • Greetings again Spiro,

    I have tried to translate your comments into MS Project:

    As I understand it, you claim that;

    In (B), Project is supposed to alert us with a warning message since there is no intersection between the project calendar and the resource calendar. But the result is OK, the resource with 0 hours allocated. 

    In (E), Project is not supposed to allocate any hours for the resource, since there is no intersection between the task calendar and the resource calendar which is not being ignored. So it is a bug or design error. 

    R1's base calendar: Standard

    Wknd_Rx : resources working only at the weekends. 

    Monday_Rx: resources working only on Mondays.

    I might not consider it as a bug since I am familiar with the behavior, but I understand your point. 


    Ismet Kocaman | eBooks on Formulas

    Thursday, December 13, 2018 8:42 PM
  • Spiro,

    nice puzzle you've got going here.

    OK, I'll stick to a 5 day task, the task is fixed duration and effort driven is off, ignore resource calendar is off.

    The sequence of doing things makes a difference. This has always been true for, for example, type in a duration, type in a start date, type in a finish date, re-type the duration... and around in circles you go. If you don't get what you want in one hit, you have to go back to scratch and start again and take a different route with a different sequence.

    Case 1: Before the resource is assigned, the task is fixed duration and effort driven is off, ignore resource calendar is off, and the task has no task calendar assigned:

    there is no warning about insufficient common time, no work, and no over-allocation

    Case 2: Before the resource is assigned, the task is fixed duration and effort driven is off, ignore resource calendar is off, and the task has the standard calendar assigned:

    there is a warning about insufficient common time, 40 hours of work, and the resource is over-allocated.

    You can't change Case 2 back into Case 1 by just removing the task calendar. If you try it, you get a warning that the resource is assigned outside the original dates and MSP changes the duration to accommodate (but of course it can't accommodate), and the 40 hours of work ends up on the weekends and the resource is over-allocated. True, it makes a change that you don't ask for, or one that you don't expect (depending on what you expect). It tries hard, and comes up with only one "solution" when there may be others that it doesn't suggest.

    It is less of a pain if you put aside your expectations and opinion about what is good or bad design, and accept and understand what "is". I discovered long ago that using MSP gets a lot easier this way. I could blame the SW, but if I set up an extreme or impossible case (M-F task with a weekend resource), it's my fault, and it's gonna do what it does.

    Thursday, December 13, 2018 10:10 PM
  • LOL.  I do appreciate to a large extent and agree with your comment, "It is less of a pain if you put aside your expectations and opinion about what is good or bad design, and accept and understand what "is".  So, true... I guess I am a hopeless dreamer, i.e., "hoping" perhaps to see or make a difference/ improvement in our beloved software : )

    PS... I was thinking of doing a video on calendars, but the fact that I can not explain this behavior logically has me thinking twice about delving into it.


    \Spiro Theopoulos, Montreal, QC (Canada)




    Thursday, December 13, 2018 10:23 PM
  • Spiro,

    This is an interesting question, and I don’t know the answer.  Project generally follows good logical processes, but sometimes a coin has to be flipped at the edges….  I think Ismet's got it right.

    In the case of a task having both a task calendar and a resource (with a conflicting calendar) applied, there are three obvious control methods:

    1. To have work performed only when BOTH the task calendar and resource calendar allow, then “Ignore resource calendars” = NO.
    2. To have work performed according to the task calendar only, forcing resources to work when they are not formally available, then “Ignore resource calendars” = YES.
    3. To have the work performed according to the resource calendar(s) only, allowing resources to work even in violation of the task calendar, then REMOVE THE TASK CALENDAR.

    It seems logical to expect a checkbox or radio buttons to select between the desired outcomes of (2) and (3), but it’s not so simple.  When they exist, Task Calendars over-ride all other calendars when it comes to calculating slack, and they are the default calendars for any of the special project date functions.  If the Task Calendar exists but does not control the scheduled dates, then these calculations could be very wrong.  Removing the calendar assignment seems the cleanest way to minimize confusion.  (Note: in this case, slack calculations will be made using the Project calendar, which may be presumably less wrong.)

    Thanks for the thoughts, tom

    Thursday, December 13, 2018 11:50 PM