What are Microsoft Project workdays? What can you change, what should you change and where do you change it? This article covers what you can expect with certain changes in the workdays settings, as well as some advice on what to do and what to leave alone. Granted, some advice might not apply to your specific situation.
A Normal Workday in Project
A normal workday is eight hours, from Monday through Friday. It starts at 8 a.m. (0800 hours) and ends at 5 p.m. (1700 hours). It includes a one-hour break starting at noon. This is the set-up when you use Project right after installing it and before you make any changes to the items mentioned in the next paragraphs.
To give a task a duration of one workday, you enter the value, “1 day”, (or “1d” or “1day”) in the Duration column. Project is a work application and therefore won’t place tasks on the weekends by default (more on that later).
Microsoft doesn’t include country-bound or specific holidays in the product out of the box. Your country might have very specific days that you would like to consider. That’s why you need to create your own calendar for your projects.
Workdays Affected by the Calendar
A Project calendar provides information on what is and isn’t a workday, such as company-specific holidays. By default, Project comes with three calendars:
- Standard, as I describe above;
- 24-hour, in which all hours are working hours for 7/24 environments; and
- “Night shift,” a calendar reflecting a schedule that runs from Monday night between 11 p.m. and midnight and goes until between Friday at midnight and Saturday at 8 a.m. with a one-hour break throw in besides.
The 24-hour calendar is the ideal solution when it is set as the resource calendar for machines in a factory. The idea is that those operations will keep on chugging non-stop if you want them to.
The night shift calendar isn’t particularly useful in my opinion. Most times when a client has a specific crew working night shifts, the hours covered by the calendar won’t really represent a 40-hour work week. And they wouldn’t include a break for an hour either.
To change a calendar, you select it in the “Change Working Time” menu, which you’ll find in the Project tab of the ribbon:
Note that the menu isn’t called “Change calendar.” There’s a reason for that: The menu also includes the option to change the hours within workdays as well.
I would advise creating a new calendar rather than overwriting or using one of the defaults (you never know when you’ll need them again). To create a new calendar, click on “Create new Calendar…” in the top right of the menu. Then choose to create a base calendar anew or create a copy of one of the three defaults (my recommendation).
Exceptions and Work Weeks
“Exceptions” is a unique moment in time that will represent nonworking time, such as Labor Day or New Year’s.
“Work Weeks” give you the option to change the default work week, to shift it, for example, from Monday through Friday to Tuesday through Saturday. Changing the workdays in Project is useful when there’s a period where a person works fewer hours and returns to a normal work schedule after that time. To accomplish this, you create two work week schedules and save the values.
Workdays Affected by the Options | Schedule Menu
If you choose Options | Schedule menu, you can make changes on a more detailed level.
A few words of caution: Changing these values will affect schedules only if you match it with the calendar (as stated in the warning text next to it). It will also affect the “golden formula” in Project for calculating assignment actions. If you change the normal work week or month, it might affect your tasks duration substantially.
Do some testing with this on a small project before rolling out changes to production!
Although I live in the Netherlands, I have created a “U.S. Holidays Calendar,” which will work until 2030 that you can download by signing up for my personal newsletter.
Have your own Microsoft Project calendar tips? Share them with the community in the comments below!
A version of this article originally appeared on Erik van Hurck’s blog, “The Project Corner,” here.