Forum Discussion
Chris_Legereit
Aug 16, 2021Copper Contributor
Ms Project Shift Work
Hello, I am currently changing how I manage our production schedule within MS Project..... Background - I work at an industrial repair facility, durations are roughly estimated, i use "Work" as an ...
Chris_Legereit
Aug 18, 2021Copper Contributor
Thanks John,
I agree that for my specific needs Duration is best suited for hours entry rather than days/weeks
I have been messing with the options for [hours per day] [hours per week] [days per month]
Can you please verify something for me.
During the initial build of a schedule if the base calendar is 2 shifts 8 hours per shift [16 total hours with 15 hours of work available due to lunch breaks]
The option would be [16 hours per day] [80 hours per week] [20 days per month]
This would be scaled to the appropriate initial base schedule.
The reason I ask is that it seems to be just very slightly off.
Again, Thank you for your continued support!
I agree that for my specific needs Duration is best suited for hours entry rather than days/weeks
I have been messing with the options for [hours per day] [hours per week] [days per month]
Can you please verify something for me.
During the initial build of a schedule if the base calendar is 2 shifts 8 hours per shift [16 total hours with 15 hours of work available due to lunch breaks]
The option would be [16 hours per day] [80 hours per week] [20 days per month]
This would be scaled to the appropriate initial base schedule.
The reason I ask is that it seems to be just very slightly off.
Again, Thank you for your continued support!
John-project
Aug 18, 2021Silver Contributor
I'm not sure what you mean by "scaled to the appropriate initial base schedule" but this is what the options mean: The "day", "week" and "month" options describe working time. They define the value in the Duration field. For example, if you use a normal Standard calendar and you enter 5 days in the Duration field, that represents 5 working days of 8 hours each. If however, you elect the 24 Hour Calendar as the project calendar and leave the definition of a "day" at the default 8 hours, then it will take 3 "days" to cover a full 24 hour time period. So if a plan has a mix of project, task and resource calendars, the definition of a "day" (or "week" or "month") can create real headaches. I recommend Excedrin.
Using hours in the Duration field is always a good bet since an hour is an hour (universal).
Attempting to use months for duration is even worse since Project does not provide for more than one definition. The default 20 days is working days and is a compromise that attempts to cover the actual Gregorian calendar. That's why entering months in the Duration field is fraught with frustration. It is sometimes useful to enter duration in "elapsed time". For example, an entry of "7ed" covers a calendar week, Monday through Sunday, whereas an entry of "7d" will cover Monday through Friday, skip the non-working weekend, and continue with Monday and Tuesday of the next week.
When faced with dates that seem "slightly off" it is often useful to set the general option for date format to include the time.
Hope this helps.
John