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.
Summary
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. reproduced from Tensix
