Customizing Enterprise Global Custom Outline Codes

When designing the custom outline codes and fields, a number of questions must be answered to produce a meaningful structure that in turn results in useful reports.

Some of these questions are

• What is the appropriate level of detail needed?

• How many sublevels will be used, and what is the level of detail required?

• How often are the project and resource outline codes values expected to change over time?

• Are there outline codes that can be shared by projects and resources?

When developing these custom codes and fields it is important to remember a few basic rules:

• The enterprise system is meant to standardize collection, management, and reporting of data, and, therefore, anyone who has a stake in the system must participate in the development of these codes and fields. Customizing the views in PWA involves the delicate act of balancing the needs of the individual user with the requirements at a corporate level.

• Clearly define the grouping element. It should not include more than one type of project or resource for any code or field defined. For example, do not mix Project Life cycle values with Project Status values.

• Have clear, objective criteria for assigning an outline code value to a project or a resource. The object of the exercise here is to eliminate ambiguity in reporting, not to create it.

In designing custom outline codes and fields it is recommended that whenever possible you use shared outline codes for projects and resources that can be assigned the same value.

For example, Resource Location and Project Location may share the same value. For example, consider a healthcare management organization that operates in two states: Colorado and Washington. This fictitious organization would have offices in Denver, Vail, Colorado Springs, Seattle, Tacoma, and Redmond.

In this case the deploying organization may choose to organize its projects by location.

As such, the Project Location custom outline code may have the following structure:

• Colorado

  • Colorado Springs

  • Denver

  • Vail

• Washington

  • Redmond

  • Seattle

  • Tacoma

Following the same structure, the deploying organization may choose to create another outline code, named Resource Location. In this case, the values would be identical for both the project and resource location.

Therefore, the deploying organization needs to maintain only a single list of values for project location because the Resource Location value list would be shared with the project location.

The advantage of sharing the value list for two or more outline codes is that it ensures consistency and avoids duplication and redundant work.

Also, for deploying organizations that do business worldwide, it is recommended to group different locations by state, province, or county, and then by country and/or continent. This grouping facilitates the search for a specific location when assigning a value to projects or resources, or when reporting project or resource distribution by location.

In this case, the four recommended levels for project and/or resource location are as follows:

• Level 1: Continent

• Level 2: Country

• Level 3: State/Province/County/Prefectures

• Level 4: City

It is worth mentioning here that a project can be assigned a location based on five different principles:

• Location of the performing organization where the project is budgeted

• Location of the sponsoring organization

• Location of the paying client

• Location of the project manager

• Location of the project management team

Regardless of which method is employed, it is essential to apply the same principle to all projects to generate proper reports.