Refining Resource Roles and Security Groups in Your PMO

Defining resource roles in a new or existing project management office (PMO) is a critical aspect of setting up Microsoft Project Server. That might be just a handful of roles, such as those that come from out-of-the-box installation; or you can add additional roles to meet your organization’s requirements. Once the roles are defined, then security groups define the permissions for each.

Here are the general steps for defining PMO roles and security groups for resources:

1.  Determine the resource roles in PMO.
2. Define security groups for each resource role.
3. Define permission for each security group with both global permissions and category permissions.
4. Configure and test your security group and verify that the security groups meet your PMO requirements.

Default Resource Roles in Project Server

Microsoft did a pretty good job with defining basic roles when it designed Project Server. The default basic roles encompass these:

Administrators: Given to one or two people who can read all or modify any information in Project Server. The main aspect of this role is configuration of Project Server; but often it’s the person who manages resources and projects. It’s the most powerful role, and thus only a few people should have it. However some departments may need limited administrative rights for updating enterprise custom tables or managing their side of the resource breakdown structure (RBS) and may need a Departmental Administrator (covered below).

Executives: Provides the ability to see any data in Project Server but has no permissions to modify data. It makes sense for upper management to have this role to enable them to see the full scope of their investment and benefits of using Project Server. However, some managers may be sensitive to what others are seeing, and a Departmental Executive group (covered below) may be required.

Portfolio Managers: Controls the configuration of the portfolio analyzer and requires modifying many different projects to model “what-if” scenarios.

Portfolio Viewers: Similar to the executive role but limited to specific programs and projects. They generally don’t make major configuration changes and often view the results that come up from the portfolio manager.

Project Managers: The PM role is to plan and execute the project schedule. They’re responsible for completing the project in a timely manner and under budget and update the project schedule weekly or as it requires. Often they also manage the resources in the project schedule. Other times, an organization assigns a resource manager to manage the resource loads in a project schedule.

Resource Managers: This role works with the PM and allocates resources in a manner as to not overburden them. In an ideal world, the PM requests resources from the resource manager and the resource manager allocates the resources to the project schedule. This takes quite a bit of maturity and coordination within the PMO. Often the PM and resource manager roles are both given to the PM, and he or she is responsible for both sets of duties.

Team Leads: Grants a team lead limited control of a project schedule to reallocate resources and reassign team member assignments.

Team Members: All new work resources are assigned a team member role. Some of the basic functionality is the ability to sign into Project Web App to enter timesheets or task sheets. Everyone in the project is assigned this role by default.

With each Project Server role a security group is defined with basic permissions already associated with the role. In my experience, 9 in 10 PMOs will be happy with this set from the start. In fact, I usually suggest that organizations go with the out-of-box roles and security groups because it makes deployment so much easier.

New Resource Roles to Consider

After a customer has used the tool for a few months, however, he or she may decide to refine the user roles and security groups. When new roles are needed, the next step is to determine the permissions required for each. There are a lot of category and global permissions to consider, but once it’s done, a big part of your PMO security will be defined.

Here are few roles that may come up on your list:

Departmental Administrator: A stripped down version of the Administrator that allows the person to update custom enterprise tables or update RBS and categories.

Departmental Executive: The same as the executive role but with permissions to see data within a given department.

Day to Day (D2D) Manager: Similar to a project manager with this difference: He or she allocates resources for operational and business-as-usual activities.

Resource Member (PPM Member, Work Member): The resource member has the identical permissions as a team member. The reason to create this role is so that it requires deliberate action to add the role to the work resource. Sometimes you don’t want a team member added to the new work resources by default; this role stops that from happening. When using this role, the team member role is configured without any permissions.

EPM Resource Pool Manager: Controls the management of adding, updating and removing resources in the enterprise pool.

EPM Resource Manager: Controls and manages resource allocations and schedules for many projects and can also level resources.

Delegation Manager: Sets up delegation and works on behalf of resources. This provides a measure of control and limits the “surface” of having others setting up delegation for administrators.

Timesheet Manager: The person who enters and submits timesheets for a group of resources.

The resource roles I’ve covered here address special requirements within the PMO, providing a more nuanced way to control resources. You should note that implementing new roles removes permissions from other groups. So be sure to review and discuss each role to make sure it makes sense for your organization.

Does your PMO use roles not covered here? Let me know in the comments below.

A version of this article first appeared on Michael Wharton’s blog, MyProjectExpert.

Image Source