Jan 26
Strategy for Determining Resource Roles and Security Groups in PMO

Defining resources roles in a new or existing PMO is a critical aspect of setting up project server.  It can be only a handful of roles as such as those that come from out-of-the-box installation or additional roles can be added to meet your organization's requirements.   Once the roles are defined, then security groups are built to define the permissions for the resource roles.

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

Microsoft did a pretty good job with defining basic roles when they designed project server.  The key roles out-of-the-box are: Administrators, Executives, Portfolio Managers, Project Managers, Resource Managers, Team Leads and Team Members.  With each project server role a security group is defined with basic permissions already associate with the roles.  Pretty much 90% of most PMO can start up right away using these definitions.  In fact, I usually suggest that organization go with the out-of-box roles and security groups, because it makes deployment much easier. Once a customer users the tool for a few months makes is easier for them for refining user roles and security groups.

However, over time I have found other security groups that helps refine the PMO roles by ensuring that the right permissions are provided to the right process and also trimming permission from the out-of-box groups to ensure that the PMO runs smoothly.

During the PMO requirements gathering stage review the current project server security groups and roles that come out-of-box and see how they fit into your PMO.  Look further past the out-of-box and determine if perhaps other roles may be needed. Once you have defined the roles that your PMO will use, then the next step is to determine the permission required for each.  There are a lot of category and global permissions to consider, but once it is done, a big part of your PMO security will be defined.

Below is a quick and general review of general roles in a PMO and their general function.  If you already familiar with these skip this and look at the new roles.

Administrator:  The administrator role is one or two persons who can read all or modify any information in project server.  The key aspect of this role is configuration of the project server, but often is the person that manages resources and projects.   It is the most powerful role and thus only a few people show have this role.  Only one or two people should have this role, however some departments may need limited admin rights for updating enterprise custom tables or managing their side of the RBS and may need a Departmental Administrator.

Executives: The executive role provides the ability to see any data in project server but no permissions to modify data.  It makes sense for upper management should have this role because they me the most interested in seeing 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 may be required.

Portfolio Viewers:  Portfolio viewers is similar to executive role but limited to their programs and projects.  They general do not make major configuration changes and often view the results that come up from the portfolio manager.

Portfolio Managers: Portfolio manager controls the configuration of the portfolio analyzer and requires modifying many different projects to play what-if games. 

Project Managers: Project manager's role is to plan and execute the project schedule.  They are responsible for completing the project in a timely manner and under budget.  The do this monitoring and updating the project schedule weekly and updating the schedule as required.  Often they manage the resources in the project schedule, however some companies use the resource manager to manage the resource loads in a project schedule.

Resource Managers:  The resource manager role is to work with the project manager and allocate resources in a manner as to not overburden the resources.  In an idea world, the project manager request 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 project manager and the resource manager roles are given to the project manager and the project manager is responsible for coordinating the resource load. 

Team Leads: This role allows a team leads with limited control of a project schedule to reallocated resources and reassign team member assignments. 

Team Members:  All new work resources are assigned team member role.  Some of the basic functionality is the ability to logon on PWA and enter timesheets or task sheets.  One aspect from this role is that everyone is assigned this role by default and this may be a good reason to use a different role.

_____________________________________________________________________________________

The resource roles below of for special requirements in a PMO or perhaps to allow for greater control in your PMO.  Implementing this roles are given to a few group of people and at the same time will remove permission from other groups. Review and discuss each of the roles and determine if they make sense in your organization.

Department Admin: The department admin is a stripped down version of the Administrator.  Their role may be to update custom enterprise tables or update RBS and categories.

D2D Manager:  The Day-to-Day manager role is similar to a project manager, but they manage resource schedule for a year.  The purpose of the D2D manager is allocate resource for operational and business as usual activities.

Resource Member (PPM Member, Work Member):  The resource member has the identical permissions as "Team Member".  The reason for this group is that it requires deliberate action to add the role to the work resource.  As mention before, team member is added to the new work resources and at times you may not want this to happen.   When using this role, the team member role is configured without any permissions.

EPM Resource Pool Manager:  The EPM resource pool manager role is to control the management of adding, updating and removing resources in the enterprise pool. 

EPM Resource Manager:  The EPM resource manager role is to control and manage resource allocations for many projects.  They have the ability to edit many projects schedules and level resources. 

Delegation Manager:  The delegation manager role is to setup delegates and working on behalf of resources. This provides control and limits the surface of having others setting up delegation for administrators. 

Delegate Manager (or Timesheet Manager):  The delegate manager may be a person who enters and submits timesheets for a group of resource.  This role could be the same person as the timesheet manager if they are required to get their resources timesheet in.

Comments

There are no comments for this post.

 ‭(Hidden)‬ Blog Tools