You can optimize the use of Enterprise Calendars in your
organization by doing the following:
- Disallowing local base calendars
- Avoiding duplicate calendar names
- Republishing projects after changing an Enterprise Calendar
- Using resource units to help identify resource availability
- Using a unique naming convention
Disallowing Local Base Calendars
Project Server administrators can allow or deny the use of local
base calendars. Although Enterprise Calendars and local calendars
can coexist in an organization, allowing local base calendars
enables users to create their own calendars and compromises your
ability to maintain a consistent set of calendars across all
projects within your organization. Usually, satisfying requests for
additional Enterprise Calendars is a manageable task even in large
organizations. For this reason, it is recommended that you leave
this option disabled if you want to standardize project management
in your organization.
Avoiding Duplicate Calendar Names
Calendars are identified by name, not by a unique ID in the
Project Server database; therefore, it is possible for duplicate
calendar names to exist. If your organization is allowing local
base calendars, you should ensure that local base calendar names do
not duplicate the names of Enterprise Calendars in projects that
are published to Project Server 2003. One way to do this is by
using a naming convention that is unique to each project manager
(for example, pma_, pmb_, and so on).
If you publish a project that contains a duplicate local base
calendar to Project Server, you will receive an alert message
indicating that the duplicate calendar that you are currently
publishing to Project Server will be overwritten by the Enterprise
Calendar that exists in the Enterprise Global Template. You must
click OK to proceed, because Project Server 2003 does
not allow duplicate calendar names.
Republishing Projects After Changing an Enterprise Calendar
If you make a critical change to an Enterprise Calendar, that
change will not be applied to projects and resources that are
associated with that calendar until those projects and resources
are republished to Project Server. You might notice that project
and resource information is not synchronized with the updated
Enterprise Calendar during the time between when the Enterprise
Calendar is updated and published and the time when a project or
resource is republished to Project Server. This delay can affect
the following areas of Project Server 2003:
- Resource Center
- Project Center
- Portfolio Modeler
- Portfolio Analyzer
- Scheduling at the project level, depending on the change made to the Enterprise Calendar
- Resource availability, at the resource or project level, depending on the change made to the Enterprise Calendar
For this reason, it is recommended that after you make a
critical change to an Enterprise Calendar, you republish all
projects that are associated with that Enterprise Calendar to
Project Server 2003.
Using Resource Units to Help Identify Resource Availability
You can use the Available From and Available To
date fields to help identify resource availability. You can also
use the Units field. For example, when a resource joins your organization, you can set the Units field to 100 percent
based on the Available From date, and when a resource leaves your organization, you can set the Units field to 0 percent
based on the Available To date.
If a resource is moving within the organization and will no
longer be available for projects, consider renaming the Enterprise
Resource with a prefix, for example, z_. This enables
you to identify users who are no longer available as resources but
are still in your organization, and the prefix will ensure that
those resources appear at the bottom of any alphabetically sorted
list. In this way, you can preserve the information for that
resource. Create a new entry for this resource for use within his
or her new department or division.
Note If you are using
Active Directory directory service synchronization with the
Project Server Enterprise Resource Pool, then assigning a prefix is
not an effective way to manage resources that move within the
organization.