none
Tasks assigned automatically, in error, to non working days RRS feed

  • Question

  • I use Project Server 2013 and Project Professional 2013.

    I have an issue with tasks being assigned to non working days, i.e. on the weekend.

    All tasks in the project use the same, standard calendar and there are no task-specific calendars on these tasks.

    See screenshot, where Joe's task starts on the weekend. It is a successor to a milestone that is on 4/1/18 and it should start on the next working day which is 7/1/18. Instead it starts at the end of the day of the milestone and continues on the weekend.



    • Edited by HFprojects Sunday, January 7, 2018 3:38 PM
    Sunday, January 7, 2018 10:55 AM

Answers

  • To those who may be following this thread,

    HFprojects sent me the file for analysis. This is what I found and reported back. For reference there were no issues with any calendars and no elapsed durations. The file was not leveled.

    The answer to your current issue is the same as when we communicated previously. The file is corrupt. If this is the same file we discussed previously, it has either become corrupt again or it was never fully “cleaned” from the first fault.

    Specifically, the Duration field for the t1 task (joe assigned) and the t5 task (greg assigned) are both invalid. Tom Boyle noted this in his response but he didn’t have the benefit of actually seeing the file. The invalid duration data shows up when the tasks are saved as XML. I also got an error flagging an invalid fixed cost accrual method on the summary line associated with those tasks when I tried to re-open the XML in Project, so there are obviously other issues with the file. I have no clue what caused the problems but if you are working across versions or across languages, those might be contributing factors. Or it could be some artifacts of improper editing (e.g. calendar manipulation, etc.) that don’t always present themselves immediately but can show up in later iterations.

    Since what you sent me was a snippet of your whole file, one possible solution is to find all tasks with the duration issue and manually re-enter the Duration field value. However, since there are other issues that won’t “fix” the file. I suggest you re-enter affected durations as a first step and then save the whole file as XML. Because of the other issues you may still get failure on re-open so you will have to address those. The whole process to clean the file may take multiple iterations.

    John

    • Marked as answer by HFprojects Tuesday, January 9, 2018 10:46 AM
    Tuesday, January 9, 2018 2:10 AM

All replies

  • HFprojects,

    Unfortunately the screen shot is way to small to be of any use. The obvious question is, is Joe's base calendar the standard calendar or does he have a separate resource calendar?

    Also, maybe it's to early in the day for me but the dates you cite don't appear match up with any dates I can find in 2017 or 2018. For example, assuming a date format of mm/dd/yyyy, 1/4/xx is not a weekend in either 2017 or 2018 and 1/7/xx is not the next working day in either year. It doesn't work for a date format of dd/mm/yyyy either.

    So, if you can provide some clarification, we'll have a better chance of helping.

    John


    Sunday, January 7, 2018 2:38 PM
  • Hi John

    I added a bigger picture.

    The 'weekend' calendar is Friday and Saturday.

    Joe uses the same calendar as everyone else in the project file and doesn't have any calendar or other constraints on his task. I added the time of day in the date to check when the task started. As you will hopefully be able to see, it is exactly after the previous task ends.

    Sunday, January 7, 2018 2:50 PM
  • Is there an elapsed duration (e.g. "32 ehrs") on the subject task (299, t1)?  An elapsed duration essentially imposes a 24-hour calendar on the task.
    Sunday, January 7, 2018 4:15 PM
  • HFprojects,

    I see you corrected the dates to show the correct year and your "weekend" but unfortunately I don't see any change to the readability of the screen shot. I tried two different browsers (firefox and Safari) and they both show a small unreadable screen shot. I'm not sure what you use to grab the screen shot (I use SnagIt) but you'll need to make it larger somehow. Or, if you send me your file, I can analyze and tell you what's happening.

    You say "Joe uses the same calendar as everyone" but that doesn't tell us if the Base Calendar for Joe (and other resources) is the same as the custom Project Calendar. Note, in Project the Standard Calendar has Saturday and Sunday as the weekend, not Friday and Saturday.

    John



    Sunday, January 7, 2018 4:25 PM
  • ditto on comments above.

    There seems to be confusion on what you are stating as a problem.   Hours and duration are two different aspects of the scheduling formula.  The diagram is showing hours on the left but on the right is duration.

    The scheduling formula is  Duration * Units = Work

    For example, 5 days * resource (50%)  = 20 Hrs Work.


    Michael Wharton, MVP, MBA, PMP, MCT, MCTS, MCSD, MCSE+I, MCDBA
    Website http://www.WhartonComputer.com
    Blog http://MyProjectExpert.com contains my field notes and SQL queries

    Sunday, January 7, 2018 11:11 PM
    Moderator
  • Thank you to everyone for your responses. I'll reply to each one:

    Tom - I am not sure where to see if there is 'elapsed duration' .

    John - While we have different calendars in the system, all tasks use the same base calendar. I changed it to have a weekend of Fri/Sat instead of Sat/Sun, so that should be non-working time for all tasks and all resources.

    Michael - the problem is that Joe's task, T1, has been scheduled to happen on Jan 5 2018 - Jan 6 2018, both of which are non working days in the calendar.

    Monday, January 8, 2018 9:29 AM
  • HFprojects,

    Apparently Tom and Michael are able to view screenshot detail whereas I cannot, different viewers I guess. I'll repeat my offer to analyze the file if you are able to send it to me.

    With regard to calendars, if you set the Project calendar to be your custom calendar with Friday and Saturday as non-working days then indeed all resource Base Calendars should also follow the Project calendar, but did you actually check to insure that Joe's Base Calendar has Friday and Saturday as non-working days? There is something causing Joe to work on the weekend and checking working calendars is the first place to look.

    With regard to elapsed duration, it will show up as "ed" or "edays" directly in the Duration field.

    John

    Monday, January 8, 2018 2:40 PM
  • John, I’m seeing HFproject’s screenshot using the Chrome browser and zooming to 300%.  He actually had a larger image yesterday which subsequently disappeared.

    HFprojects,

    In the English-language version of Project, elapsed durations are evident by an “e” prefix on the units in the Duration column.  Other language packs might have a different prefix.  You should always make this column visible.

    Re-inspection of your screenshot reveals that two of your four tasks (t1-Joe and t4-Greg) have work being performed according to 24-hour calendars.  I.e. Joe performs 32 hours of work between 17:00 Thursday and 01:00 Saturday (during 32 hours of elapsed time), and the following weekend Greg performs 81 hours of work between 17:00 Thursday and 02:00 Monday (during 81 hours of elapsed time).  This seems unrealistic if Joe and Greg are human.  The other two tasks (t2-Mark and t3-Susan) have work being performed according to 8-hour calendars during the work week.

    Subject to the logical restraints, Project schedules your four tasks according to the project calendar, the specific calendars of the assigned resources, and applicable task calendars.  The rules of calendar priority can be complex, depending on task settings and assignments, and some results can be overridden by manual editing of the usage tables.  Your use of calendars is not clear, though you’ve implied that any applicable calendars are identical (i.e. Gulf standard 5dx8h Sun-Th.)

    If all calendars (task, resource, project) are in fact identical and no manual edits exist, then the only obvious way to get what you’ve got is through elapsed durations (i.e. implicit 24-hour task calendars) on the two tasks.  It seems more likely that some explicit 24-hour calendars have been allowed to slip into the mix and become active for some tasks but not others.  There are many ways for this to happen.  If I were you, I would accept John’s offer to examine the schedule file directly.

    Monday, January 8, 2018 4:31 PM
  • Tom,

    I have Chrome browser on my virtual PC but never use it as Firefox normally works fine (except in this case). I've never needed to use the zoom function but now when I try it with Firefox, it looks like I could have seen more detail in the screenshot. Old dog, new trick.

    It sounds like you have been able to get more detail on this one, so I'll just bow out and let you handle it.

    Thanks for jumping in.

    John

    Monday, January 8, 2018 4:49 PM
  • John, haha - didn't you see my last sentence?
    Monday, January 8, 2018 4:59 PM
  • Tom,

    Oops, I just gave your response a quick read and didn't catch the last sentence. I read the part where it sounded like you already figured out there were some anomalies in the calendars, so I left it at that. At any rate, the ball is in HFproject's court now.

    John

    Monday, January 8, 2018 6:05 PM
  • To those who may be following this thread,

    HFprojects sent me the file for analysis. This is what I found and reported back. For reference there were no issues with any calendars and no elapsed durations. The file was not leveled.

    The answer to your current issue is the same as when we communicated previously. The file is corrupt. If this is the same file we discussed previously, it has either become corrupt again or it was never fully “cleaned” from the first fault.

    Specifically, the Duration field for the t1 task (joe assigned) and the t5 task (greg assigned) are both invalid. Tom Boyle noted this in his response but he didn’t have the benefit of actually seeing the file. The invalid duration data shows up when the tasks are saved as XML. I also got an error flagging an invalid fixed cost accrual method on the summary line associated with those tasks when I tried to re-open the XML in Project, so there are obviously other issues with the file. I have no clue what caused the problems but if you are working across versions or across languages, those might be contributing factors. Or it could be some artifacts of improper editing (e.g. calendar manipulation, etc.) that don’t always present themselves immediately but can show up in later iterations.

    Since what you sent me was a snippet of your whole file, one possible solution is to find all tasks with the duration issue and manually re-enter the Duration field value. However, since there are other issues that won’t “fix” the file. I suggest you re-enter affected durations as a first step and then save the whole file as XML. Because of the other issues you may still get failure on re-open so you will have to address those. The whole process to clean the file may take multiple iterations.

    John

    • Marked as answer by HFprojects Tuesday, January 9, 2018 10:46 AM
    Tuesday, January 9, 2018 2:10 AM
  • Thank you, once again, to those who contributed very valuable input into the challenge, which turned out to be due to a corrupted file.

    John, your suggestion was spot on. I copied all the values in the duration field to MS Word and saved them as unformatted text. I then re-copied them back to the original project file and the problem then vanished.

    Thanks again!

    Tuesday, January 9, 2018 10:50 AM
  • HFprojects,

    You're welcome and thanks for the feedback.

    John

    Tuesday, January 9, 2018 2:23 PM