Microsoft Office Online
Sign in to My Office Online (What's this?) | Sign in

 
 
Project Server 2003 IT Documentation
Search
Search
 
Check for updates: (c) Microsoft
Office downloads
 
 
 
Warning: You are viewing this page with an unsupported Web browser. This Web site works best with Microsoft Internet Explorer 6.0 or later, Firefox 1.5, or Netscape Navigator 8.0 or later. Learn more about supported browsers.

Email this linkEmail this link Printer-Friendly VersionPrinter-Friendly Version Bookmark and ShareShare
Optimizing Enterprise Calendars
 

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.

advertisement