March, 2010

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.

Project Permissions

Project Server 2010 includes the new Project Permission feature so that by-default, Project Managers can directly control who has access to the projects that they own.  For more information about the Project Permissions feature, see the Project Server 2010 – Project Permissions blog posting.

How to Control Access to the Feature

The ability to directly add or remove permissions to a project is controlled by the Manage Basic Project Security category permission. Given that this is a category permission, it means that it is possible to grant this permission for one project yet deny it for another project or more commonly, to grant it for a group of projects yet deny it for a different group of projects.

By default, the following groups have the Manage Basic Project Security permission enabled on the noted category:

How do you enable or disable this permission? The following steps show you how you could, for example, deny Portfolio Managers from creating project permissions. A similar approach is taken to enable or remove the permission for a group or user. 

• Log on to Project Web App as an administrator or as a user who has the Manage Users and Groups permission
• Go to Server Settings – Manage Groups.
• Click on the name of the group that you wish to edit. This action will take you to the Add or Edit Group page.
• In the Categories section of the page, in the “Select Categories” list on the right-hand side, select the category.  In this example, it is the My Organization category. You’ll see a view similar to this:
  
  

• If the group does not have any other categories assigned to it, then you can simply deselect the “Allow” checkbox. Otherwise, you’ll need repeat this for each category. If you always want to disallow members of the Portfolio Managers group from using the project permissions feature not matter whether other categories allow it, then you can click the Deny check box.
• Once your selections are made, click the Save button.

As noted, you can use a similar process to add the Manage Basic Project Security permission to other users or groups. But do note that that though you can control this permission directly on a category on a user account, for easier manageability it is recommended that you control this at the security group level.

Great post from the SharePoint team today on Accessibility and SharePoint 2010, great paragraph on the Project grid accessibility capabilities that will ship with Project Serve 2010. A guess what, it’s also highly extensible (and ActiveX free!).

Key announcement today on the Microsoft Office 2010 Engineering blog: Get Office for Today or Tomorrow

In addition to the Office 2010 Technology Guarantee, were excited to confirm that Office 2010, SharePoint 2010, Visio 2010, Project 2010 and Project Server 2010 are on schedule and will release to manufacturing (RTM) next month.

For businesses, we will launch the 2010 set of products, including Office 2010, SharePoint 2010, Visio 2010, and Project 2010 worldwide on May 12. To find out more about the Worldwide Business Launch, visit http://sharepoint.microsoft.com/businessproductivity/proof/pages/2010-launch-events.aspx.

For consumers, Office 2010 will be available online and on retail shelves this June

Release is just around so start planning and attend the May 12 virtual launch event!

Delegation is a great new feature in Project Server 2010 that allows one user to allow others to act on their behalf.  Very useful when a Project Manager is going to be out of town and doesn’t want to have to re-set the status manager for all her owned tasks just so someone else can action updates – instead she just sets a delegate and they can work as if they were the Project Manager.  Works across all features – so can be used for timesheets, or even administrative functions.  I’m sure there will be plenty of posts going in to the details but wanted to describe how this works for both new instances of Project Server 2010 as well as upgraded 2007 instances

This is pretty powerful and for new Project Server 2010 instances the default behavior is that Administrators can manage resource delegates – so they can set up delegates for any user on the system.  So if they navigate to the Manage Delegates option (under the new Personal Settings on the left navigation – or site map) and click New they will see all the users who can be a delegate if they click the Browse button next to Set Delegate, and they will see ALL users if they click Browse next to the Working on Behalf Of.

However, we have taken the design decision that this is quite a dramatic new feature for existing 2007 users, so the default if you have upgraded a PWA instance from 2007 is that Administrators CANNOT manage resource delegations.  So in this case when clicking Browse next to Working on Behalf Of they would see no one.

So the next question is – how do I change this?  It is one of the tricky category permissions that sometimes catch our customers out – as it is set for the category of My Organization within the Administrators group.  So if you either want to turn this off in your native 2010 instance, or turn it on in your upgraded 2007 instance, go to Manage Groups and select Administrators, then within the Add or Edit Group page scroll down until you see the Categories. 

Now for the tricky bit – click on My Organization and you will then see the set of permissions for My Organization!  I have collapsed the Project permissions to fit the interesting bit in – the Manage Resource Delegates option. 

In 2007 upgraded instances this will look like this and be unchecked – and will need to be checked if you want administrators to be able to set delegates for everyone – in 2010 native instances it will already be checked – so uncheck if you want to turn this off for administrators.  You can of course do this the other way around, and go to Manage Categories and then select Administrators – but the key take-away here is that you need to select the category (or group) to see the applicable permissions – something that isn’t always intuitive.

More 2010 postings to come –many, like this one based on early feedback and experience from our TAP customers and Ignite attendees (thanks Jesse!).

[Cross-posted @ Project Server 2010 - Architecture, Sizing, and Capacity Webcast]

Following this announcement at the beginning of the month: ANNOUNCING Microsoft Project Server 2010 IT Professional TechNet Webcast Series, don’t miss out tomorrow to learn from the very best consultant on the subject:Michael Jordan, How to Architect, Size and Plan your Project Server 2010 Farm. Live at a browser near you starting at 8:30 Pacific Time (Seattle time!): https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032442909&EventCategory=4&culture=en-US&CountryCode=US

If you missed it, check this first webcast on the subject: Microsoft Project 2010: Project Server Stress Testing