The nice thing about rolling out a new product line every couple of years is that I get to take all of my old blog posts written for previous versions of Project Server, and refresh them. In this case, I am redoing a post from over a year ago on how to deploy risks as centrally controlled content types. I’ll probably end up doing this every couple of years I suppose – kind of like the Project Server equivalent of the Charlie Brown Christmas special.
For those of you not familiar with content types, the basic concept is that I can define a content type for every site within a SharePoint farm, and then control the content type metadata from a centralized interface. In this case, I can define a risk as a content type, and then control the specific fields associated with the content type from the Site Collection. Any change trickles down to existing sites as well as being inherited on any newly created sites. I can even create a Risk content type, then inherit all of those settings to two slightly differently configured Schedule and Cost Risk content types.
In the past, I’ve seen a lot of organizations implement manual changes to risk metadata whenever their risk management methodology changes. This typically requires the poor System Administrator to click through every site in existence to manually make these changes. Using content types, a lot of that work can be avoided.
The same technique may also be applied to any of the custom elements instantiated as part of the Project Collaboration Feature on a site: Issues, Risks, Deliverables, and Project Documents – although there may be some caveats around Deliverables which tend to be a bit quirky in my experience.
The trick to getting content types to work with Project Server is to understand that Project Server needs to see certain specific fields attached to the risk whenever the project is published. If these fields are not there, then the publish activity may throw an error, which then freaks out your end users and clutters up the queue.
The challenge is that these fields cannot be easily recreated. You can’t simply create a bunch of fields with the same name, and hope that Project Server sees them. It just doesn’t work like that. These fields are instantiated as part of the project collaboration lists when the collaboration feature is activated. Thus, unless you have some SharePoint developers handy, the easiest way to tackle this is to deploy the content type to the list, instantiate the core Project Server columns, and then save the workspace as a template.
To accommodate future changes, you simply need to add centrally managed fields, which are then inherited by the content types instantiated in the list. Your users get the use of the centrally managed fields. Project Server gets the local fields. Everyone wins.
Creating the Content Type
The first step is to navigate to Site Settings for the top level site in your site collection. In this case, that site is my main PWA site.
Select the option to manage content types for the list.
Select the Create button.
I set the content type as a Project Risk and the parameters as displayed:
This drops you into the configuration screen for our new content type. Here is where I can add all sorts of organizational metadata – or even tie specific fields back to the Project Server database.
For demonstration purposes, I’ll add one column. Note that there’s not necessarily a limit to how many content types you can create. For instance you can create a Risk content type, and then inherit the shared columns into two sub-content types such as Schedule Risk and Cost Risk.
Your content type is now created. Should you wish to add or remove a field in the future, simply do so from the same interface on the site collection level. Now let’s talk about how to get this content type on your project workspaces.
Instantiating at the Site Level
The easiest way is to incorporate the content type into your workspace template. In this case, I am just going to show you how to add it to an existing site properly – not how to create the site template which is a whole topic into and of itself.
Now, I navigate to my site, and specifically, to the Risks list.
Click on the List option in the Ribbon, then select List Settings.
From there, select Advanced Settings.
Set the list to allow the management of content types.
This drops you back into the List Settings page where you now see the option to manage content types. In fact, the Project Site Risk content type is already deployed.
From there, add our new content type.
Set the new content type as the default option. This is also where you can configure the tool to include multiple risk types depending on your organizational methodology.
One more step remaining. I have to add my local list columns back to the new content type. To do this, I navigate back to List Settings and click on the new content type.
…and add the list columns.
This gives me a list of all of the list columns – of which I add all of them to my content type. If I don’t, Project Server may throw errors on the publish event.
…and that’s pretty much it. I click back to my Risks list.
Now, when I add a new Risk, it picks up my Followed Up column – and any column I add in the future to my centrally managed content type.
…But Wait There’s More
So not only do I now have a centrally managed content type, but I can also use that to hide some of the out of the box columns. For instance, Category is still a list column that is not centrally controlled. If I want, I can simply hide that column, and replace it with a new centrally managed field called Risk Category or something like that.
In this case, I go back to List Settings, and click on the content type.
I click on the Category column.
…and set it to Hidden.
And now it’s like that column doesn’t even exist – except to Project Server, which sees it during the Publish event.