Resource Breakdown Structure

The Resource Breakdown Structure (RBS) is a hierarchical structure representing your enterprise resources that enables you to create project plans with detailed resource assignments and compare this workload with detailed resource availabilities. The RBS also enables roll-up of both resource assignments and availabilities data to a higher level.

Planning and Defining RBS Hierarchy

One specific reserved Enterprise Resource Outline Code is called RBS. RBS is represented by Enterprise Resource Outline Code 30, and its design can have a significant effect on the EPM solution security, views, reports, processes used for project team building, and resource assignments, as well as how you report on resource commitments. It is recommended that you organize your EPM solution security model around RBS by defining it in such a way that it reflects the hierarchical relationships of all your enterprise resources in your organization rather than your organizational structure itself.

Proper definition of RBS is important to the success of your EPM solution deployment. RBS impacts the way your organization manages EPM solution security, access to project and resource views, resource assignments, and other EPM solution features.

You can use the hierarchical relationships defined as part of RBS to simplify data access for your users and user groups. Use RBS to define five security rules when you later create the security categories in the PWA client.

RBS code functionality is also used in the following areas of the EPM solution:

• Resource Substitution Wizard

• Portfolio Modeler

• Portfolio Analyzer

• Build Team

• Two default security categoriesMy Direct Reports and My Resources

RBS code is a hierarchical structure. For executives to see information about the projects and resources they manage, they must be placed appropriately in the RBS hierarchy. If you are using an organizational RBS, make sure that you place your executives above the people they manage. If your executives want to see resource information for projects in their organization, make sure to place them in the RBS hierarchy above anyone who works on projects in their organization. Without that, they may not be able to see all the information about projects they "own."

Three primary factors to consider when you define the RBS code layout for your organization are as follows:

• Your process for assigning resources to projects and tasks

• Your organizational security design goals

• The method your organization uses to determine whether a particular resource is appropriate for a particular task assignment

Proper definition of RBS code is very important. RBS code plays the largest role in resource assignments when your resource managers make the staffing decisions. RBS code plays a lesser role when resource assignments are done in a more collaborative manner by a group of managers in your organization. RBS may play a relatively small role when your project managers make resource assignment decisions.

The next consideration is to determine what your organizational goals are for securing your Enterprise Project Management environment.

The questions you should be able to answer are the following:

• Do you want to minimize the EPM solution's administrative burden for your organization?

• Does your organization generally allow everybody to see and edit all enterprise project and resource data, or does your organization need to limit data access and system permissions?

• If you limit data access, should your users be able to view each other's project and resource data, provided that they are from the same area or department of your organization?

If your organization wants to implement a secure, easily administered EPM solution, RBS will play an integral role in the security design. If your organization's project management processes are generally less defined, RBS may play a less important role in your organization's security design.

Finally, review the processes that your organization uses to determine whether a resource is a good fit for a project:

• Do you assign resources to your projects and tasks based on departmental or organizational structure?

• When assigning resources to your projects, does the geographic location of a resource matter?

• Do you perform skill-based resource planning and scheduling?

• Which of the above three criteria is most important?

The answers to all these questions help you determine the most appropriate RBS structure for your organization.

Most organizations use one of the following:

• An organizational RBS

• A modified organizational RBS

• A geographic RBS

You can define only one RBS code for your organization. You can modify your RBS code structure over time. If you decide to make significant changes to your RBS code structure, be aware that implementing a new RBS code or significantly modifying your existing RBS code structure after you have been using your EPM solution for a few months may be a time-consuming and complex task requiring careful analysis of the impacts of all RBS changes.

NOTE

Use group names rather than individual names when you define your RBS structure entries. Group names change generally less often than individual names. This trick can help you minimize future changes to the RBS hierarchy.

You can choose from three methods when creating RBS:

• Manually define the lookup table hierarchical structure.

• Define RBS structure as part of the process of importing resources using the Import Resources Wizard. This method may be time consuming and prone to errors and omissions.

• Use the PDS to create RBS structure.

Organizational RBS Code

An organizational RBS is usually appropriate for most organizations. Resources perform roles based on the functions of their departments. Figure 9.12 shows an example of organizational RBS code.

Figure 9.12. Use the organizational RBS code structure to associate your resources with their departments and groups.

The organizational RBS code structure closely mirrors the structure of your organization. You build the RBS code hierarchy that reflects all company levels, such as divisions, departments, groups, and resource levels. Resources are then tied to a particular resource level, and managers are tied to the workgroup, department, division, or company level based on their level of responsibility and influence. Most organizations find that an organizational RBS meets their overall needs best.

Modified Organizational RBS Code

A modified organizational RBS is generally appropriate when managers and resources require a higher and wider level of data access than their position in the organizational hierarchy might otherwise suggest. For example, many IT departments are organized into additional groups such as development, network administration, and technical support. A modified organizational RBS would stop at the IT department level so that all IT departmental resources would be able to view and access all project data related to the IT department.

Another example of when a modified organizational RBS might be required is when a strategic long-term resource allocation is determined by a team of people from various departments. Figure 9.13 shows an example of a modified organizational RBS hierarchy.

Figure 9.13. Use a modified organizational RBS code structure to widen the data access in your organization.

Geographical RBS Code

You use a geographical RBS code when the primary concern in defining your project team is where your resources are located. Your EPM solution users will also be able to use RBS code to see only the resources and projects in their geographic location.

To create a geographical RBS code, build a hierarchy of the geographical locations for your organization's offices. You can use continents, countries, regions, cities, and actual office locations to define the RBS code hierarchy. Each resource in your organization is assigned an RBS code identifying the resource location and hierarchical position. Figure 9.14 shows an example of a geographical RBS code.

Figure 9.14. Use a geographical RBS code structure to assemble your geographically dispersed virtual project teams.

NOTE

For additional details on RBS definition and design, review the Microsoft Office Project Server 2003 Application Configuration Guide, Chapter 6, "Working with Resource Breakdown Structure," available from http://www.microsoft.com/technet/prodtechnol/office/proj2003/reskit/default.mspx.

Also review the Microsoft knowledge base article "Description of the Resource Breakdown Structure and How to Use It in Microsoft Project Server 2002" at http://support.microsoft.com/default.aspx?scid=kb;en-us;831611. Although this article was written for Project Server 2002, most of the information applies to Project Server 2003 as well.

Using RBS

The RBS code features include dynamic security features based on the Category security object. You can control which projects and resources any given group of users can see and access.

The Project Server 2003 security model uses RBS to determine enterprise resource hierarchy. This hierarchy is used by the category security settings that allow members of a category to view resources that they manage or to view projects managed by resources they manage. The managing versus managed relationship is based on relative position in the RBS hierarchy. Because this hierarchical relationship tends to follow an organizational structure, you can use your company organizational structure as a starting point when developing your RBS code structure. You can then modify the RBS structure, if needed, to accommodate your unique reporting and security needs.

RBS and Project Server Security

The RBS code structure is used to determine the enterprise resource hierarchy.

The standard security settings available after the initial setup and configuration of Project Server 2003 are the recommended starting point for using the five RBS-based dynamic security rules.

To understand the long-term effects of the RBS code structure on your EPM solution security, you should review two of the default security categories, My Resources and My Direct Reports.

The My Resources category determines which people a resource manager is allowed to view. It does make sense for resource managers to be able to see all the resources that they manage. You can configure this relationship using the Allow Users in This Category to View Information for All Resources That They Manage automatic security rule. Project Server uses the RBS code structure to find all resources with RBS code subordinate to the RBS code of the resource manager. A resource manager can be considered anybody in the RBS hierarchy that has at least one subordinate position defined.

The My Direct Reports category uses the Allow Users in This Category to View Information for All Resources That They Manage Directly automatic security rule to allow resource managers to view resource data for resources immediately subordinate (one level below) to them in the RBS hierarchy.

The common element in each of the five rules is the "resources that they manage" phrase. Figure 9.15 shows five RBS-based dynamic security rules that can be enabled in the Admin module of the PWA client.

Figure 9.15. Five dynamic RBS code-based security rules can be used to streamline your Project Server data security management.

RBS can be an important element of your overall Project Server data security strategy, but it is not the only element you should focus on.

PAGE 143.