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 ...
Forum Discussion
Partially Solved.
This is slightly cumbersome but it does work.
I have created an additional Resource named "Planning". This resource is a modified 24hr Calendar that shows a lunch break per shift.
When the initial schedule is created every task will be assigned to "Planning"
Then, each task will hold its own TASK CALENDAR
Then, using the calculated Start/End times i will assign the correct resources. In the times that there is WORK runover from one shift to the next I assign both day and night resource.... So far there has been no (and I know that this verbiage is wrong) Level Loading.
Each task falls into the anticipated time slot. The only other minor modification that i made was using DURATION instead of WORK..... Understanding that DURATION should be assigned on a day/week level, instead i am using hours. this also correctly changes the total work for the task.
I will update if there are any issues going forward, or if I find a better way to tackle this.
This is slightly cumbersome but it does work.
I have created an additional Resource named "Planning". This resource is a modified 24hr Calendar that shows a lunch break per shift.
When the initial schedule is created every task will be assigned to "Planning"
Then, each task will hold its own TASK CALENDAR
Then, using the calculated Start/End times i will assign the correct resources. In the times that there is WORK runover from one shift to the next I assign both day and night resource.... So far there has been no (and I know that this verbiage is wrong) Level Loading.
Each task falls into the anticipated time slot. The only other minor modification that i made was using DURATION instead of WORK..... Understanding that DURATION should be assigned on a day/week level, instead i am using hours. this also correctly changes the total work for the task.
I will update if there are any issues going forward, or if I find a better way to tackle this.
Chris,
Thanks for the update. A couple of comments.
If you assign your Planning calendar as the Project calendar, all tasks will follow that calendar and there won't be any need for separate Task Calendars, unless specific tasks need to deviate from the Project calendar.
In Project, duration is the time span during which a task is performed. Work is the effort expended to perform the task. Project only has one definition for a "day". With multiple custom calendars you should avoid entering duration in anything other than hours. Hours are hours but days, weeks, and months may vary.
John
Thanks for the update. A couple of comments.
If you assign your Planning calendar as the Project calendar, all tasks will follow that calendar and there won't be any need for separate Task Calendars, unless specific tasks need to deviate from the Project calendar.
In Project, duration is the time span during which a task is performed. Work is the effort expended to perform the task. Project only has one definition for a "day". With multiple custom calendars you should avoid entering duration in anything other than hours. Hours are hours but days, weeks, and months may vary.
John
- 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'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