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:
| Field | Scope | Department | Required? |
| ProjectCustomText1 | Global | - | No |
| ProjectCustomText2 | Global | - | Yes |
| ProjectCustomText3 | Department | Marketing | No |
| ProjectCustomText4 | Department | Marketing | Yes |
| ProjectCustomText5 | Department | Development | Yes |
| ProjectCustomText6 | Department | Development | No |
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:
-
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.
-
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:
-
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.
-
Departments are not meant to act as a security measure. Remember, it’s about Structure and NOT Security.
-
Examples in both Project Professional and PWA where departments are used.
