Given the importance of RBS in Project Server application security and resource management, properly defining an RBS code for your organization is a very important part of configuring Project Server 2003 for your organization. The following three factors affect the RBS that you define for your organization:

• The process that you use for resource assignment in your organization. Are project managers or resource managers responsible for staffing projects? If project managers staff projects in your organization, you are probably using a matrix style of resource management. If resource managers staff projects, you are probably using a hierarchical style.
• The goals of your organization for securing the project management environment.
• The method that you use in your organization to determine whether a resource is appropriate for an assignment

To plan an effective RBS, first determine the process that you use for resource assignment in your organization. For example:

• Does the resource manager assign resources?
• Does a project manager select a team and then assign resources to tasks?
• Do both occur?
• Is this process collaborative?
• Does an organization or group make staffing decisions?

RBS has the greatest impact on the resource assignment process when a resource manager is responsible for assigning resources. RBS is less important when the assignment process is collaborative or is the responsibility of a group within your organization. RBS has a small to minimal affect on the resource assignment process when project managers are responsible for resource management.

Next, determine what your organization’s goals are for securing your project management environment. For example:

• Is minimal administration a goal for your organization?
• Does your organization generally allow people to view and edit all project and resource data or does your organization prefer to limit access and editing privileges?
• If you want to limit access to data, do users within the same group or division of the organization need to be able to view each other’s data?

If your organization wants a secure system that is also easy to administer, then RBS will play an integral role. If your organization’s project management style is generally less defined or is decentralized, then RBS might play a less important role in your organization’s security model.

Finally, identify the method that your organization uses to determine whether a resource is appropriate for a project. For example:

• Does the departmental or organizational structure matter?
• Does the geographic location of a resource matter?
• Are the skills of a resource an important factor in determining resource assignments?
• How are the above three items prioritized?

The answers to these questions can help you to determine the appropriate structure for your organization’s RBS code. Most organizations can use one of the following three options:

• An organization-based RBS
• A geographic-based RBS
• A modified organization-based RBS

Because you can only implement one RBS code, it is important to identify the structure that is most appropriate for your organization. You can modify your RBS over time, but implementing a new RBS after you are already using Project Server 2003 to manage projects is a major adjustment.

Using RBS Effectively

It is important to note that RBS is not intended to be a comprehensive resource management code. RBS is one important outline code that is used to define the resource hierarchy for your organization. For example, if location or skill is a factor in determining whether a resource is appropriate for an assignment, that resource can be assigned another location or skill Enterprise Resource Outline Code. If you are not going to use an organization-based RBS, then you should not use a factor that is related to the structure of your organization as the primary factor for staffing projects.

When you are defining RBS, be sure that you include a level for the entire organization as well as for the resources. Many organizations make the mistake of omitting a level for the entire organization and putting the high-level departments at the root level, as shown in the following example.

1.          Sales and Marketing
   1.1          Sales
      1.1.1          Domestic Sales
      1.1.2          International Sales
   1.2          Marketing
2.          Manufacturing
   2.1          Tape Products
   2.2          Drive Products

This approach causes problems when you are using security rules to manage view permissions in Project Server 2003. This approach can also create problems when you are performing resource substitution or modeling throughout the organization. To make the RBS easier to understand and visualize, as well as to make category security easier to manage, consider adding the company and resource levels to the RBS, as shown in the following example.

1.          COMPANY
   1.1          Sales and Marketing
      1.1.1          Sales
         1.1.1.1          Domestic Sales
            1.1.1.1.1          Domestic Sales Resources   
         1.1.1.2          International Sales
            1.1.1.2.1          International Sales Resources
      1.1.2          Marketing
         1.1.2.1          Marketing Resources
   1.2          Manufacturing
      1.2.1          Tape Products
         1.2.1.1          Tape Products Resources
      1.2.2          Drive Products
         1.2.2.1          Drive Products Resources

Although this is not a requirement and it does create some additional work initially, this approach to RBS has generally proven to be the easiest for most project and resource managers to use and for Project Server administrators to understand and manage.

One key to understanding how RBS works is to understand how to use root nodes and leaf nodes. A root node has subordinate nodes and a leaf node does not. Create your RBS so that resources—especially resources in the Enterprise Resource Pool, if your organization is using the Enterprise Resource Pool—are only contained in leaf nodes. In the previous example, Drive Products (1.2.2) is a root node while Drive Products Resources (1.2.2.1) is a leaf node. The resources that can be assigned to projects created by the Drive Products team should be in the leaf node. The project managers should be in the root node.

This is because all resources within a team (or leaf node) should have the same RBS value. Resources that have the same RBS value will appear together after filtering is applied. For example, Steve Masters and Eva Corets are both members of the Marketing Resources leaf node. Therefore, both Steve Masters and Eva Corets share the 1.1.2.1 RBS outline code. This is true of all members of the Marketing Resources leaf node. If Peter J. Krebs is the manager of all resources in the Marketing Resources leaf node, then his position in the RBS code structure is 1.1.2. When the security rule Allow users in this category to view all projects assigned to resources that they manage is applied to a security category that Peter J. Krebs belongs to, he will be able to view the projects that both Steve Masters and Eva Corets are assigned to.

If you use RBS, make it a required outline code. This way, you cannot check a resource in to the Enterprise Resource Pool unless the resource has an associated RBS code. Note that when RBS is a required code, you also need to apply RBS codes to generic resources. However, the benefits of ensuring that everyone in the Enterprise Resource Pool has an associated RBS code outweigh the disadvantage of having to identify generic resources in the RBS.

Using an Organization-Based RBS

An organization-based RBS is appropriate for most organizations. Most Project Server users want to be able to view the projects and the resources that are specific to their workgroup. Resources are typically qualified to work on projects based on the functions for which their department is responsible.

In an organization-based RBS, resources are associated with a particular resource level, and managers are associated with the workgroup, department, division, or company level, depending on their level. Organizations that have the following characteristics typically benefit from an organization-based RBS:

• Departmental or functional resource managers determine staffing for projects.
• Resource managers require access to information about resources in their departmental or functional roles and require access to the projects to which these resources are assigned.
• Preserving the organizational structure is a primary concern when determining which resources are appropriate for particular assignments.

To build an organization-based RBS, structure your RBS so that it closely mirrors the structure of your organization. For example, use company levels, divisions, departments, workgroups, and resource levels to build your RBS. You might require one or more resource levels, depending on the size and complexity of the structure of your organization.

For example, A. Datum Corporation provides storage products for large customers. A. Datum Corporation product engineers are highly skilled individuals who focus on developing new optical, solid state, and magnetic storage drives. A. Datum Corporation’s primary concern is time to market. Regardless of where the product engineers are located, they are selected for projects based on their area of expertise. A. Datum Corporation is organized according to the products that each division creates. Product engineers are concerned with the products that they help to develop. Resource managers are responsible for assigning engineers to product development projects. A. Datum Corporation project managers use resources from product engineering, manufacturing, testing, and quality assurance, as well as other groups, to create cohesive project teams.

A. Datum Corporation selected an organization-based RBS for their Project Server implementation because the primary concerns for resource allocation and project visibility are that these be available to the groups in which people work.

A. Datum Corporation created an organizational-based RBS as shown in the following example.

1.          COMPANY
   1.1          Services
      1.1.1          ...
   1.2          Engineering
      1.2.1          Plant Engineering
      1.2.2          ...
      1.2.3          Product Development
         1.2.3.1          Optical Products
            1.2.3.1.1          Optical Products Resources
         1.2.3.2          Solid State Products
            1.2.3.2.1          Solid State Products Resources
         1.2.3.3          Magnetic Products
            1.2.3.3.1          Magnetic Products Resources
   1.3          Quality Assurance
      1.3.1          ...
   1.4          Manufacturing
      1.4.1          ...

This RBS provides A. Datum Corporation the following advantages:

• Security category rules enable resource managers to access information about their resources easily.
• Because resource managers are responsible for making resource substitutions, the Resource Substitution Wizard works appropriately as a resource optimization tool.
• Managers that are assigned to the A. Datum Corporation organizational (top) level are able to view all resources and projects within the organization.
• Managers within each level or at the company level can perform what-if analyses for resources within a model.
• At each level within the RBS, managers can view all of the resources that are assigned to subordinate levels in the RBS.
• It is easy to model RBS on the reporting structure. Team members are at the resource level, and managers are at the level for their departments.

Using a Geographic-Based RBS

Use a geographic-based RBS code if the primary concern for assigning resources to projects is the location of the resource, and Project Server users need to be able to view the resources who are working on projects in their geographic areas. Typically, organizations for which resource allocation is affected by the cost of travel use a geographic-based RBS.

Consider using a geographic-based RBS rather than an organization-based RBS if your organization meets the following criteria:

• Regional or sub-regional managers are responsible for staffing projects.
• Resource managers primarily need to be able to view projects and resources by location.
• Location is the primary consideration for determining which resources are appropriate for a particular assignment.

To create a geographic-based RBS, build a hierarchy of the locations that your organization includes. For example, you can use continents, countries, regions, sub-regions, cities, counties, and actual office locations to define the RBS. Assign each resource within your organization to a location, and assign managers to higher levels in the RBS.

For example, A. Datum Corporation does business providing break-fix services and hardware deployment services to customers around the world. A. Datum Corporation rarely allows resources to travel to remote offices because the fees that A. Datum Corporation charges customers do not cover travel expenses. Resource managers and project managers that manage various break-fix services are all local and manage only projects and resources within their geographic areas. A. Datum Corporation prefers that resource and project managers only have access to these local projects and resources.

A. Datum Corporation chose a geographic-based RBS because location is the primary consideration in A. Datum Corporation’s resource allocation process and for determining project and resource visibility within Project Server 2003.

A. Datum Corporation created a geographic-based RBS as shown in the following example.

1.          COMPANY
   1.1          Asia
      1.1.1          Malaysia
         1.1.1.1          Kuala Lumpur
            1.1.1.1.1          Kuala Lumpur Resources
         1.1.1.2          Ipoh
            1.1.1.2.1          Ipoh Resources
   1.2          Europe
      1.2.1          Germany
         1.2.1.1          Frankfurt
            1.2.1.1.1          Frankfurt Resources 
         1.2.1.2          Hamburg
            1.2.1.2.1          Hamburg Resources
   1.3          United States
      1.3.1          West
         1.3.1.1          San Jose
            1.3.1.1.1          San Jose Resources
         1.3.1.2          Seattle
            1.3.1.2.1          Seattle Resources
      1.3.2          Central
         1.3.2.1          Minneapolis
            1.3.2.1.1          Minneapolis Resources
         1.3.2.2          Kansas City
            1.3.2.2.1          Kansas City Resources

A geographic-based RBS provides A. Datum Corporation the following advantages:

• Managers at the local, regional, national, and global levels are able to use category rules in Project Server 2003 when accessing project and resource information.
• Resource substitution within a single geographic area is easy to determine by using RBS.
• Managers assigned at the organization level are able to view project and resource data around the world.
• What-if analysis can easily be performed at the local level.
• Managers can easily determine the location to which a resource belongs.

Using a Modified Organization-Based RBS

A modified organization-based RBS is generally appropriate for organizations in which managers and resources require a higher level of access than their organizational structure might otherwise allow. For example, many IT departments include separate divisions for development, system integration, and support. A modified organization-based RBS would define detail only to the IT department level, so that all resources within the IT department can view, access, and assign any resource in the IT department, instead of only resources in one division of the IT department. A modified organization-based RBS is also useful if a team of people strategically determines long-term staffing for projects.

If you use a modified organization-based RBS, consider using an additional Enterprise Resource Outline Code to create the organizational structure for reporting purposes. Although this results in the creation of duplicate entries, it provides a number of advantages, including accurate Portfolio Analyzer reporting.