MS Project Server 2010 – Resource Breakdown Structure (RBS)

Resource Breakdown Structure (RBS)

You use the RBS field to control Project Server security by defining a pseudo-org chart for your organization. At this point in the system configuration process, you must populate your RBS lookup table so that when you import your resources, you can select an appropriate value in the RBS field for each resource in the Enterprise Resource Pool. Assigning each resource a place in the org chart shows Project Server 2010 “who reports to whom.” You can control a manager’s ability to see project and resource data through subordination in the RBS field. These resource reporting constructs drive very powerful Project Server 2010 relationship-based security features.

The RBS lookup table is a blank slate by default, so it is your responsibility to design and configure it specifically for your organization. Keep in mind that lookup table values can be hierarchical, which is exactly what you need for this purpose. The simple rule for using the RBS is this: Every manager has access to only those resources below the manager’s level in the lookup table. This means that if you place several managers at the same node of the RBS lookup table, the managers can see all resources below them.

Based on your requirements, you should create an RBS lookup table that reflects your organization’s management reporting structure. For example, our organization uses Project Server 2010 only in our IS department and we have a very simple reporting structure within IS. Based on that reporting structure, I created the RBS lookup table shown in

Figure 2-7.

 

The Resource Breakdown Structure (RBS) is a hierarchical security structure typically based on the management reporting structure of your organization, although it can also be structured in other ways. The RBS can be an important element in your Project Server security model when it is used to define the reporting relationships among users and projects in your organization. When you specify an RBS value for each Project Server user, you can take advantage of the dynamic security options that can be defined for each security category.

The RBS structure is defined by adding values to the RBS custom lookup table that is built in to Project Server 2010. Once you define the structure, you can assign RBS values to individual users by setting the RBS property in the user’s account settings page.

Once the RBS is configured, Categories can use RBS codes to dynamically determine which projects and resources particular users can view or access. The following tables list the security options that use RBS that are available in each Category.

Project options

Option Description
The user is the Project Owner or the User is the Status Manager on assignments within that project Users with permissions in the category where this option is selected can see projects on which they are a Project Owner or a Status Manager
The user is on that project’s Project Team Users with permissions in the category where this option is selected can see projects on which they are a resource
The Project Owner is a descendant of the User via RBS Users with permissions in the category where this option is selected can see projects owned by their descendants in the RBS
A resource on the project’s Project Team is a descendant of the User via RBS Users with permissions in the category where this option is selected can see projects on which their descendants in the RBS are a resource
The Project Owner has the same RBS value as the User Users with permissions in the category where this option is selected can see projects owned by other users with the same RBS value

 

Note: The first two options (The user is the Project Owner or the User is the Status Manager on assignments within that project and The User is on that project’s Project Team) are not related to the RBS, but they do offer a similar method of filtering which projects are visible to a user.

Resource options

Option Description
The User is the resource Users with permissions in the category where this option is selected can see themselves as a resource
They are members of a Project Team on a project owned by the User Users with permissions in the category where this option is selected can see resources assigned to projects that they own
They are descendants of the User via RBS Users with permissions in the category where this option is selected can see their descendants in the RBS
They are direct descendants of the User via RBS Users with permissions in the category where this option is selected can see their direct descendants in the RBS
They have the same RBS value as the user Users with permissions in the category where this option is selected can see other users with the same RBS value

 

Note: The first two options (The User is the resource and They are members of a Project Team on a project owned by the User) are not related to the RBS, but they do offer a similar method of filtering which resources are visible to a user.

 

For more information you can also watch this informative video http://go.microsoft.com/fwlink/?LinkID=168589

Creating the Team Name Lookup Table

You can use the Team Name field to allow project managers to assign a team or resources to tasks in a project. Before you can use this field, you must create a Team Name (or similarly named) lookup table and populate the lookup table with names of the various teams in your organization.

Our organization has six standard teams used on projects, plus any number of “ad hoc” teams created according to the skills required for each project. We have two standard Database teams, two standard Network Operations team, and two Software Development teams. Each team includes the appropriate project manager and team members with the necessary skills.

I therefore must create the Team Name lookup table with the names of the six standard teams in our organization. Figure 2-8 shows the structure of the Team Name lookup table.

Figure 2-8


 

After creating and saving the Team Name lookup table, I edit the Team Name field and select the new Team Name lookup table, as shown in Figure 2-9.

Figure 2-9

 

Planning for Matching Generic Resources

Consider the following scenario in my fictitious organization to understand the need for using matching with Generic resources:

  • Project managers in our organization routinely plan projects that do not start until three months or more in the future.
  • During the initial planning for a new project, project managers add Generic resources to their project team and then assign the Generic resources to the tasks.
  • The Generic resources are skill-based or placeholder resources that indicate the IT skills needed to perform each task.
  • As the project Start date approaches, project managers need to match Generic resources with human resources who possess the same IT skills.

The preceding scenario is very common across the EPM community. Most organizations find Generic Resources a useful planning tool and need to do some form of matching between Generic resources and human resources as they move project into execution. The most common need, as presented above, is to match skills between Generic and human resources. Other common needs involve matching resources by availability, position in the RBS structure, by region or location, and by language proficiency.

Scale is everything when you plan for matching Generic resources with human resources. Project Server 2010 provides tools that instantly sift through hundreds or thousands of resources to locate one that has the preferred attributes for the job. If your organization does not have a large number of resources, then you may take a very light-handed approach to this capability or choose to ignore it completely.

Project Server 2010 provides project managers and planners two tools for skill matching Generic to human or human to human resources: the Build Team from Enterprise tool and the Resource Substitution Wizard. Using either tool, the system matches skills and other resource attributes by comparing enterprise resource fields that contain Lookup Tables and other criteria that the individual user can apply through the interface. Skill matching uses “contains” logic as it compares a Generic resource with possible matching human resources, and does not require an exact match between the resources.

Your challenge as the Project Server business analyst or administrator is to provide thoughtful attribution values to enhance Project Server’s team-building tools. If you are working with a large Enterprise Resource Pool, it is possible to build a significant matrix of attributes for team building. Distributed organizations may want location codes, while larger organizations may want seniority codes and secondary skill identifiers. Remember that once you create a new attribute, you obligate yourself to provide a value for it for each resource in your Enterprise Resource Pool.

My organization’s primary need is to match Generic resources with human resources using IT skills. Using a skills assessment provided by our human resources staff, we categorized six types of IT skills with specific IT skills as follows:

  • Database – DB2, Oracle, SQL Server
  • Network – Microsoft OS, Novell, Sun Solaris
  • Project Management – Database, Network Infrastructure
  • Quality Assurance – Software Development, Hardware/Network Testing, Process Analysis, Software Testing
  • Software Development – C Sharp, VB.NET, Visual Studio
  • Web Development – ASP, HTML, Java

Based on the above information, I can use a single enterprise field containing a Lookup Table to represent the available skills across the IT department. Because Project Server 2010 allows the use of multiple values in the Lookup Table, I can select multiple skills for each resource. To enable skill matching in my organization, I first created the IT Skills lookup table shown in Figure 2-10.

Figure 2-10

 

After creating the IT Skills lookup table, I created a custom resource field called IT Skills using the IT Skills lookup table. In setting up the IT Skills field, I mandated the following:

  • The Enterprise Resource Pool administrator must select specific IT skills for each resource and cannot select one of the six categories only.
  • The field must allow the selection of multiple values.
  • The field must be used for matching Generic resources with human resources.
  • The field is a required field indicating that the Enterprise Resource Pool administrator must select at least one IT Skill for every resource in the pool.

 

Figure 2-11 shows the IT Skills field configuration to meet the above criteria. Notice that I selected three options in the Custom Attributes section to meet the first three criteria, and selected the Yes option in the required section to meet the last requirement.

Figure 2-11

This entry was posted in Reference. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>