Here’s what’s evolved into my own personal method of documenting security for a MOPS implementation.  Figured that I would throw this out and welcome any and all suggestions on how to improve this. 

MOPS 2007 security can be broken out into two major chunks: functional requirements and configuration specifications:


Functional Security Requirements


Functional MOPS 2007 requirements must be broken out into language that the Business users (and approvers) will understand.  Typically, what that means to me is a simple matrix with the resource roles on the left, and then the key elements of the MOPS/MOSS interface along the top.



Project Center

Resource Center

Personal Settings

Server Settings

Project Workspace

Executive Read Only Access Read all projects across the enterprise. No access No access No access No access
Project Director Read Only Access Read permissions to all projects across the enterprise. View all resources within department.  No edit permissions. Full access No access Contributor access to all project workspaces in the organization.
Project Manager Read Only Access Read all projects within region.
Write access to own schedules.
View all resources within department.  No edit permissions. Full access No access Read access to all projects within the organization.  Contributor access to their own projects.
Team Member Read Only Access Can see only projects to which they have been assigned. View their own assignments.  No access to other resources.  No edit permissions. Full access No access Contributor access to their own projects.  No access to other projects.
Functional Manager Read Only Access Read all projects within region.  No write access. View their own reporting resources.  No edit permissions. Full access No access Read access to all projects within the department.  No access to other projects.
Administrator Full edit permissions Full read/write permissions to all projects Full edit permissions for all resources. Full access Full access Read/write access to all projects.

Additional detail and elements can be added as needed, but generally speaking this may be sufficient to provide adequate documentation of the functional requirements in a single, easy to review format.

Configuration Specifications

Configuration specifications require a lot more time and forethought to develop.  Typically, I build a virtual environment in a VPC, develop a Security Workbook, then use the Playbooks tool to transfer the settings over to the target environment.  Generally, this works pretty well, and I haven’t had too much difficulty transferring the security settings over from one environment to another – with a couple of caveats around custom fields, views, and Enterprise Global.

Here’re a couple of key principles.

1) Start with the overall PWA Settings.  To create a workbook for future use, either download the example I have posted, or simply go into the PWA Permissions and right click on the permission list.  You should get an “Export to Excel” option which will allow you to pull all of the security settings into a single Excel worksheet.  Make this your first worksheet in the Security Workbook, and configure appropriately.

2) Next, develop your security templates.  Each Group:Category correlation may have its own security settings, which can make documentation a nightmare.  By using only security templates as the basis of your security planning, you can avoid much of the difficulty of documenting the Group:Category security settings.  Typically, I will create a number of security templates, document those in a single worksheet, and then create another worksheet to map the Group:Category correlations, and to identify which security template I use to apply security to that correlation.

Here’s an example:





RBS Bounded?

Schedulers My Projects Team Members Read own project. No
Schedulers My Personal Projects Project Manager Read/write own project No
Schedulers My Organization Executive Read all projects No


3) List all of your MOPS User Groups in a worksheet.  As a general rule, I like to create new groups, and not use any of the default groups – which seems to work better, especially when using the Playbooks tool.  If you’re using the RBS, identify to which level each of the groups needs to be set:



Permission Template

RBS Level


Scheduler Yes Project Manager 3 Project Schedulers
Team Member Yes Team Member 4 Team members for all projects.


4) Then, if the implementation is using an RBS, I will go ahead and document that in my next worksheet.  Depending on how ambitious I am feeling, when I create the Resource Worksheet, I map it back to this worksheet and create a formulaic check to make sure that each resource, when assigned to a security group, is also assigned to the right RBS level.  This is done by looking up the security group they’re in, and then counting the number of periods in their associated RBS field, to ensure they all match up.  Note that one of the design principles I typically follow is to put each resource into a single security group (if possible).  That may not happen in every implementation, but it makes the administrative burden a lot easier.

5) Make a list of all of your Security Categories, and include enough description of all of them. (Worksheet #5)

6) Make a table of all of your Category configurations (Worksheet #6)

7) Group:Category mapping with the applied Security Template (see the example in item #1)

8) PWA Security settings.  Typically the default PWA security settings are way to open for most companies.  I like to ratchet them down. 

And that’s about it.  As I develop the security model, I may identify a selection of Administrative Security Procedures which may eventually be required: Phase Gate Review and Baseline Save, Creating New User, Transferring Project Ownership.  Typically, I may drop those into a final worksheet called Administrative Procedures.

So, in the end, at a minimum, to fully capture the configuration of MOPS 07 security settings, I have a total of 8-9 worksheets in a single workbook that should include all required data to recreate the security configuration in a brand new environment:

  1. PWA Settings
  2. Security Templates
  3. Security Groups
  4. RBS (if used)
  5. Security Categories
  6. Security Category Settings
  7. Group:Category Correlations
  8. PWA Security Settings
  9. Administrative Procedures (if required)

Note that this doesn’t include the security configurations on the Project Workspaces, but that may be a topic for another post.

Sample security planning/documentation workbook posted here.  The document is provided “as is” with no guarantees, warranty, etc.