01 Nov Understanding Departments in Project Server 2010 (part 1)

<decaf coffee>

Introduction

This is an introduction to Departments, where they are used and how they are set up.  I intend to follow up this post with a drill down into the specific use areas of departments over the next few posts.

Departments are a really useful new feature in Project Server 2010, and they (alas) add another level to your planning.  So before you ask “what exactly is a department”, let’s see what the MS documentation has to say

“Departmental custom fields, or departments, enable you to define, at a resource, task, or project level, which fields are required or not required. This helps to filter information displayed throughout Project Web App, so that information is focused on what is applicable to each department. While this is not a security feature, it can help to simplify the interface for Project Web App users.” 

I’d go a stage further and say that departments are also used to segregate data during Business Analysis, and the reporting of data within the OLAP cubes.

So the 1st question you need to ask yourself is “Do I need to implement departments”.  Whilst this isn’t cut and dried, if you have different business processes and reporting structures within the scope of your EPM solution, then you’ll need to utilise departments.  If you just have lots of the same thing, even on a large scale, within the scope of your EPM solution, then you can leave them well alone.   The good new is of course, that you can change your mind later on, but as most of us know, that’s costly in terms of re-training, re-writing process documentation etc.

Just to be clear, as stated by MS above, departments are NOT a security feature, they hide data (security by obscurity), so you still need to understand the concept of groups and categories.

The table below details where departments have an influence within Project Server 2010.

Setting up Departments

For anyone used to Project Server, this is really easy.  Departments are implemented as Enterprise Custom fields, and the following are already setup when you create your Project Web App instance.

1. A lookup Table with the name Department.  By default this is blank.

2. An Enterprise Custom Field called Project Departments, which uses the lookup table called Departments.  Note that by default we are not allowed to multi select this field

3. An Enterprise Custom Field called Resource Departments, which uses the lookup table called Departments.  Note that by default we are not allowed to multi select this field.  This contradicts the comment above about resources belonging to zero or more departments.

To update the Departments lookup table, within Server Settings select Enterprise Custom Fields and Lookup Tables, click on the Department lookup table and complete it to represent your departments.  Note that I have filled it in using rather unimaginative names here, but your departments really should be boundaries of process or information type.  I’m assuming here that within HR, IT, Legal etc they all use their own processes, and the scope of those processes are defined within the department.

Once that is set up then we can begin using the departments to segregate our data and processes, which we’ll begin in the next blog.

Enjoy,  Ben.