One of the more mysterious Project Server features—mysterious because most folks simply don’t get it from reading the Help files or find the coverage of it on TechNet—is the Resource Breakdown Structure (RBS). I mentioned this in the discussion of custom fields in Chapter 8, and here’s where it comes into play.
The RBS, Enterprise Resource Outline Code 30, identifies reporting structures that enable the resources-I-manage relationships when defining access to projects, resources, and views in categories. The RBS is also a blank slate out of the box, so the onus is on you to design and configure it for your organization. Keep in mind that outline codes can be hierarchical, and that’s what you need for this purpose. The simple rule is that everyone who is a resource manager has access to resources tagged with a value that’s on a subordinate leaf of the hierarchy.
Depending on requirements, an RBS will reflect a reporting structure. If it’s the responsibility of various resource managers within the organization to maintain their own resource data, then a design such as the one shown in Figure 10-11 might fit the requirement. In this structure, the analysis manager will be seen by the system as an analyst’s manager providing that the person who is the analysis manager and the corresponding analyst are attributed correctly in the resource pool. You’ll learn more about this in the next chapter.
Figure 10-11. A sample two-level RBS
The example in Figure 10-11 shows how a two-level structure appears in a drop-down selection list. Though the example structure gives each manager the right to edit reporting resource data, it doesn’t define a relationship above the manager level; therefore, the administrator is the only one who can edit the data for the managers.
The scope of your deployment largely determines the complexity of your RBS. If you’re deploying a single implementation across many departments, and each department distributes resource maintenance to its manager, your RBS structure may have many top-level branches with many descending levels. On the other hand, if your installation is for a single department, and only one person is responsible for handling resource data, then you may not have a need for an RBS at all.
The key is to assess the value of the RBS to your organization. Is the relationship-based security rule, enabled by the RBS, useful to you as it was intended? If you can hijack it to accomplish something entirely different, that’s OK, too. Remember that users granted access to data and views through relationship-based security rules require corresponding permissions.