One criteria on the scheduling review checklist used by a government naval command agency looks to confirm that calendars are defined at the project level. Why? Let’s explore this issue.
The Naval Facilities Engineering Command (NAVFAC) scheduling review checklist specifies that schedule calendars should be project-specific data and not global. Obviously, if you are submitting your schedule to NAVFAC then you have a compelling reason to use project calendars instead of global calendars. There are other sound reasons, however, that make project calendars preferable to global calendars. And these reasons may be the driving force behind the NAVFAC project level calendar criteria.
This article explores the reasons that Primavera P6 Professional project calendars are preferable to P6 global calendars.
The great thing about global calendars is that they are available to all users in the Primavera P6 Professional database, so all users have access to your defined global calendar. This is a double edged sword, however. Other users may not only use your global calendar; they may have the ability to actually change your global calendar. The implications are that their calendar changes are applied to any project schedule using that global calendar. Not good!
Another reason not to use global calendars is that exported global calendars clutter the recipient’s database. When you export a schedule assigned global calendars, those global calendars wind up in the global calendars list of the recipient importing your project. It’s amazing how quickly ones database becomes cluttered with rarely used global calendar definitions.
There is another reason not to export global calendars. Imported global calendars having the same name as global calendars already in the system are not renamed. They, however, inherit the properties of the global calendar currently in the system. So your global calendars of the same name, but in two different databases may not have the same global calendar definition.
Yes, it’s nice for your calendar to be available to all your projects and all your database users. Global calendars appear to be the way to go when creating a new calendar definition. But there are sound reasons for defining a calendar limited or restricted to a specific project.
Global calendars do not have the same security that project calendars have: other users can change your global calendar, and the respective schedules it’s assigned to. This alone compels schedulers to define project specific calendars. You may also clutter yours or your recipient’s global calendar list with rarely used calendars. There are also some export/import issues that may result in two global calendars of the same name, but with different date properties.
Primavera P6 Professional seems to favor global calendars as it makes it easy to convert project specific calendars into global calendars, but not vice versa. Despite this it is best practice to define calendars as project specific. Again, you may also have to define calendars at the project level to meet your customer’s scheduling guidelines, which removes all doubt that project specific calendars are the preferred way to go.