07 Dec Understanding Departments in Project Server 2010 (part 2)

<baileys>

Resource Departments

In my last blog I introduced the concept of departments.  Let’s now look at how departments can be used with resources.  When project server is installed an Enterprise Custom Field is created called Resource Department, and this is associated with a lookup table called Department.  This can be a multi level lookup table, so its now really feasible to set up a single project server instance to service multiple business units, each with discrete business processes; this type of configuration is popular in Shared Service environments where a single instance of Project Server is serving multi business units.

Associating a department with an Enterprise Custom Field

Perhaps the 1st place most administrators will come across the Departments field (once they are set up of course) will be when an Enterprise Custom Field (ECF) is set up.  Remember, there are two types of ECFs that can be associated with Departments (resource and project).  In the screen shot below I’ve created an ECF called Access Level, which I’m going to use to hold the employee access level for resources within the HR department.  This access level is just a pure text field in this instance, but could be a number, date or one of the other available types within the Entity Type.

Associating a resource with a department

So looking at resources, a resource can be assigned to zero or one department (note that the MS documentation says that a resource can be assigned to zero or more Departments, which is true, if more = 1!).

The 1st place of impact when we associate a resource with a department is when we create a resource, either within PWA or within Project Professional.  The screen shot below shows the (Resource) Departments field set to blank.  Note below it the only resource custom field available is the Resource Role (another inbuilt field).

As soon as a Resource Departments field is selected, then the Resource custom fields change to now include the ones that have been associated with the selected department (HR) , i.e., the Access Level Resource ECF.

That’s the crux for resource custom fields – they allow additional resource information to be associated and captured for different business units (okay, lets call them departments).  So, within HR, for each resource I might have a business requirement to capture Access Level and Resource Role, whereas within Engineering I might want to capture Health and Safety compliance, and within Marketing I don’t want to capture anything (so I don’t associate Marketing people with any Resource departments).

Why bother with different fields – simple, it’s so that we can use them later for reporting, filter and grouping.

More later, but hope you enjoyed this for now.

Enjoy – Ben.