Departmental Custom Fields

Introduction

Project Server 2007 allows you to creating literally hundreds of custom fields.  This is great, but a huge downside is that all of these fields are not typically needed by every user and therefore, they may add clutter and confusion.  In 2007, it is also not possible to create different custom field rules for one project vs. another user.  For instance, you cannot make a field required for one project yet optional for another.

With Project Server 2010, departmental custom fields help to relieve the problems of too much information and too many choices. As an example, departments help you to manage the UI clutter, and help you to define, at a resource, at a task, or at a project level, which fields are required or not required.  Let’s walk through this new feature and show you how you can use departments to manage your enterprise custom fields.

Scope

To begin with, we need a brief conversation about scope.  In Project Server 2007, all custom fields are globally scoped which means the fields are available to all users.  In Project Server 2010, fields can be globally scoped, but they can also be departmentally scoped as well.  Consider this list of custom fields:

If a project belongs to the Development department, then when viewing areas of the product that enabled departmental fields, you will see:

• ProjectCustomText1
• ProjectCustomText2
• ProjectCustomText5
• ProjectCustomText6

Let’s say we have a user named Bob. Departments filter the list of custom fields Bob sees by-default.  This does not mean, however, that he won’t be able to view custom fields assigned to the marketing department.  When Bob saves a project, which fields will he be required to enter values for?  Remember, in Project 2007, Bob would need to input data for all required fields. In Project 2010 since a project, for example, can be associated with a department, Bob may be required to enter a value for the ProjectCustomText5 field AND will always be required to enter a value in the ProjectCustomText2 field since has global scope.

A quick summary of scope shows that departmental fields enable two primary functions:

1. Filtering custom fields so that a user sees by default, only those fields that are either global to the system or those that are in a given department.
2. Controlling which fields require input.

It needs to be stressed the departmental fields are not tied into security.  That is, you cannot use them with security categories and groups to enable or disable fields and their functions.  Instead, their primary purpose is to filter out fields you don’t need to deal with.  There are places in Project Web App (PWA) where you may not be able to see filtered fields and so it may seem like security has been applied, but you’ll find that in places like Project Professional, you can re-filter to show all fields.

Remember this:  it’s about Structure and NOT Security.

Now, let’s look at what it takes to setup and use departmental fields.

Setup

By default, Project Server 2010 has a new lookup table named Department.  Similar to the 2007 State and RBS lookup tables, this is a permanent lookup table (you can’t delete it) that is blank by-default.

Like any other lookup table, you can define the code mask and create a lookup table that’s flat or hierarchical. In addition to the Departments lookup table, by default there’s also the “Project Departments” and “Resource Departments” fields, predefined with the Department lookup table selected (you can’t change this).

These two new fields control a number of aspects within Project Professional and PWA. As with other custom fields associated with lookup tables, you can choose whether or not multiple values can be selected. But, just as with other such fields, once you’ve chosen to allow multiple values, you cannot revert back to single selection.  So be careful in your selection!

You can create other custom enterprise fields and also choose to associate them with departments as shown below.

To help administrators easily determine which fields have been associated with a department, as you can see in the next picture the new Department field has been added to the Enterprise Custom Fields and Lookup Tables page.

In addition to setting up custom fields and associating them with departments, you can also associate users with departments.  Let’s suppose user Bob needs to be a part of the Development and Testing departments.  While editing his user account, you set the departments as seen the next picture.

Remember, setting the user’s department(s) helps to control how custom fields are filtered to them and helps to control which whether some items are seen or not seen in PWA. 

Using Departmental fields

Now that you’ve had a brief overview of creating departments, and associating departments with fields and with users, how do you use them in normal every day usage and what should you expect?   There are a number of Places in Project Professional and PWA where departmental custom fields can be used to your advantage so let’s take a brief look at these.

Project Professional

To understand how departmental custom fields are used in Project Professional, let’s look back to the first example given earlier where there are the two globally scoped project level fields plus two each for the marketing and development departments.  Our user Bob is working in Project Professional and is saving a project.  By default, Bob will see only the globally scoped enterprise project fields similar to the below picture:

Bob sees the two global fields because this project has not been associated with a department. Therefore, when Bob attempts to save the project (and without entering text into the ProjectCustomText2 field), he sees the following message:

Bob then enters a value into the ProjectCustomText2 field and is able to save the project. Bob then goes to the Project Information dialog box and associates the project with the Development department. Now he sees not only the global custom fields, but also two additional fields associated with the Development department.

Take notice that the required fields always appear at the top of the list.

Here you see the addition of both the ProjectCustomText5 and the ProjectCustomText6 fields.  Bob forgets to fill in the required ProjectCustomText5 field and is reminded of this when saving similarly to when he neglected to enter required text into the ProjectCustomText2 field.

Finally, Bob fills in the required field and is able to successfully save his project.  The same concepts can be applied to task level custom fields as well.  For instance, you can assign a department to a task-level custom field and if the project belongs to the department and a field is required, you’ll need to fill in a value for all tasks in the project before you can save it.

Project Web App

There are a few places in PWA where departments affect your experience and an example is when creating new projects based on an enterprise project types (EPT). The administrator who creates the EPTs can specify that they belong to a department.  Therefore, when creating new projects from within the Project Center view, the list of EPTs you see is filtered based on your department.  Likewise, when editing the properties of a project, you will see similar behaviors.  In the following picture, suppose you you are a project manager and you are a member of the marketing department.

Here, you see the “EPT for Marketing Projects” EPT because you are a member of the marketing department. If there are EPTs that have no department association, then they appear in the list as well. However, EPTs associated with other departments do not appear and unlike in Project Professional where you can set the department filter within the Save dialog box, there’s no provision to do so in the Project Center.

Reporting

Project Server 2010 allows you to create multiple OLAP databases for reporting purposes.  When configuring a cube, you can specify both the project and source departments so that the cube is “filtered” on these criteria.  Here is a look at the OLAP Database Build Settings page:

Within the cube configuration, you can add the Project department field as a dimension to the Project and Tasks cubes and you can add the Resource department field as a dimension to the Resource cube. Like any other custom field, if the Project or Resource departments fields are defined for multiple values, then they can be used for filtering, but the field itself does not make it into the cube.

Portfolio Analysis

Departmental custom fields are used heavily in Project Server 2010’s portfolio analysis features.  When creating your driver library, you can associate a business driver with a single or multiple departments as shown in the following picture:

In this example, Driver2 has been associated with both the Development and Testing departments.

Similarly, after your business driver library has been established and you want to create the driver prioritizations, when establishing the properties for the prioritization set, you can associate it with a department.

A department on the driver prioritization filters which business drivers are available. In the previous picture, you can see that Driver2 is available because this driver belongs to both the Development and Testing departments.  Obviously, having just one business driver will not produce a good portfolio analysis, but the example suffices.

Summary

This brief overview of departmental custom fields has been given to help you understand the following:

1. Departmental custom fields’ primary function is to trim or filter the list of what a user may see within given areas of Project Professional and PWA.
2. Departments are not meant to act as a security measure. Remember, it’s about Structure and NOT Security.
3. Examples in both Project Professional and PWA where departments are used.

Technorati Tags: Microsoft Project Server 2010,Departments,New Features

Comments

• Anonymous
  January 01, 2003
  Hi Valerie, Multi value fields will certain,y not be available.  Other fields that are based on lookup tables will be available in the non-timephased data tables.  It will not be related to the compexity of the hierarchy. Best regards, Brian.

• Anonymous
  August 25, 2010
  Dear Sr., Please, we would like some comments about the departmental custom fields on Project Server 2010. Would you mind to answer these for us? Sincerely yours, Roberto Gattoni. ===================================================================== Question #1> Is it possible to create: A> Departmental custom field name: "Phase"   Field Type: "Task"   Department: "IT"   Lookup-Table: "IT_Phase" AND B> Departmental custom field name: "Phase" (also)   Field Type: "Task"   Department: "Mkt"   Lookup-Table: "Mkt_Phase" The aim of this is to use the same project pro and pwa views, that will be used according the project department; If it´s not possible, what would be the solution for using the same "Phase" name on reports, in the way that the reports wouldn´t need to be customized for attending both the cases? The general idea is the portability warranty of reports on reporting services. Please, send your comments to the roberto.gattoni@fiat.com.br and rgattoni@inet.com.br e-Mails addresses. Regards, rga. ============================== Question #2> Is it possible to assign project pro views to departments. For example, if I have the following situation: A> Departmental custom field name: "IT_Phase"   Field Type: "Task"   Department: "IT"   Lookup-Table: "IT_Phase" AND B> Departmental custom field name: "Mkt_Phase"   Field Type: "Task"   Department: "Mkt"   Lookup-Table: "Mkt_Phase" C> Consider that I have a project pro (or a pwa) view, that contains the following fields: ID Phase Task name Duration Start Finish The "Phase" field will be used accordingly the project department. Or, in other words, the view will show the contents of "IT_Phase" for project where IT is its department and "Mkt_Phase" where Mkt is the project department. If it´s not possible, what would be the solution for using the same "Phase" name on views, in the way that the views wouldn´t need to be customized for attending both of the cases? The general idea is the portability warranty of views on project pro and pwa, specially on corporate global model. Please, send your comments to the roberto.gattoni@fiat.com.br and rgattoni@inet.com.br e-Mails addresses. Out best regards, Roberto Gattoni.

• Anonymous
  April 12, 2011
  Hi Treb, Are there differences in using the Department functionality while in Backward Compatibility mode? For instance, will the department field behavior (from the "Project Professional" section above) be the same in Project Pro 2007? Thanks.

• Anonymous
  May 18, 2011
  Dear Sr. I assigned a custom field to the department A. My User is assigned to the department B. When I fill the custom fields in project professional, I choose department A or B but nothing changes, This is a Project Server error or I am doind something wrong? saulsm17@yahoo.com Thanks an regards!

• Anonymous
  August 22, 2011
  Dear Mr. Gatte, Thanks for a very clear article. I am working with Business Intelligence and adding custom fields to various databases. I also watched one of your Deep Dive tuturials about BI. Can you please clarify the rules that determine whether a custom field will be usable as a dimension. It seems to me that custom fields that have multiple choices available or that have complex hierarchical lookup tables can't be imported and used as dimensions. Thanks very much Valerie Farber vfarber@nds.com

• Anonymous
  June 28, 2012
  Hey Treb, hope you are well; I am working on an installation of Project Server 2010. The person who previously set this environment up went haywire with departments and it is a cluster mess. I need to ready the environment for a global deployment and need to back out the department assignments. For example, several fields that should be for global use are assigned to a department limiting access. Best regards, Linda