Project Server Issue and Risk Data

Issues and Risks are kind of an oddball in the Project Server data world. Most Project Server data is handled within the context of the Draft and Published databases. That to a degree is a reflection of the Project client tool making the transition into the server world. 

Issue and Risk data is not tracked directly in the client tool, rather the assumption is made that the PM will use a tool such as SharePoint, spreadsheets, or some other mechanism to track these values. In the Project Server world (since it’s closely integrated with SharePoint) the assumption is that SharePoint Workspaces will be used for team coordination on individual projects, and Issue and Risk data will be stored there.

This causes a disconnect at two levels: not only is the Issue and Risk information not stored with the rest of the working Project Server information, but due to the structure of SharePoint there are potentially many SharePoint lists containing Issue or Risk data with each SharePoint project workspace containing one of each.

This makes accessing the Issue and Risk data directly problematic, especially for a reporting tool like SSRS that likes nice, well defined data connections.

How Project Server Compensates for the Issue and Risk Disconnect

Project Server handles this problem by acquiring a copy of Risk and Issue data from the appropriate workspaces at project Publish time and placing it in the Project Server Reporting database. This very nicely pulls together that information so it can be more easily reported on, but it has some inherent weaknesses.

In order to centralize Issue and Risk data in a single location, that location has to have a consistent data definition, or schema. On the other hand, SharePoint lists by nature are highly modifiable by those with the appropriate rights. While the structure of the Issue and Risk lists in a project workspace is set to mirror that of the tables in the Reporting database via the workspace template, there’s really nothing to stop a SharePoint designer from tweaking that structure after creation, should they want to do things with their Issue or Risk lists that are not supported out of the box.

This can cause problems.

Problems with Issue and Risk Data Synchronization

At the time Project Server is going through its Publish process, it acquires Issue and Risk items from the corresponding project workspace, and attempts to synchronize the items with the centralized tables in the Reporting database. This sync is done down to the field level.

So what happens if the fields are changed?

If it’s a new field that does not exist in the central location, no harm done, Project Server just ignores it. There is no attempt to add that field to the central location; that could get out of control quickly if each PM decided to have their own set of fields per project.

If an “out of the box” field is deleted, then Project Server becomes unhappy because it can’t find the field it wants to sync to. It assumes the list is not really its list, and ignores the items. The problem will show up as an error in the Job queue and the logs, and the synchronization for that list instance will not occur.

What This Means for Issue and Risk lists

So the moral of the story is, you can add fields to Issue and Risk lists, but you can’t delete them.