One of the new features in Project Server 2013 was to do with Timesheet Managers – i.e. those that approve timesheets. In previous versions of Project Server, this was controlled via the “Accept Timesheets” permission, but the functionality has now been split out into a new section under Server Settings (PWA Settings if you haven’t added Server Settings to the Quick Launch).
Here’s the old 2010 group permissions:
And the new 2013 group permissions:
There are a couple of other permissions missing from the group permissions in 2013, but I won’t cover those in this post.
The Technet article about permissions for 2013 appears to be out of date (still listing the ‘Accept Timesheets’ permission), but it works as a good overview of the permissions required:
There are two methods for timesheet approval within Project Server 2013 – fixed approval, which will turn timesheets in to the resource’s designated timesheet manager, or non-fixed approval, which allows the resource to choose the next approver for the timesheet. This method allows for the approval chains that were available in Project Server 2010.
To set up fixed approval routing – navigate to Server Settings > Timesheet Settings and Defaults and make sure you have checked the ‘Fixed Approval Routing’ option:
When submitting a timesheet with this mode on, the submission screen will look like this:
Disabling fixed approval routing will cause the timesheet submission screen to prompt for the next approver for the timesheet:
OK, so how do people appear in the list of approvers for timesheets? Well, there’s a new menu option in Project Server 2013 under Server Settings > Timesheet Managers:
Simply add users to this list by clicking “Add Manager:
Setting up Multiple Approvers
If you wanted to set up an approval chain so that you have, in effect, timesheet reviewers who then forward the timesheet on for approval, this is done via permissions. Because this is a category permission, you could control which groups of users’ timesheets can be approved or not. This might be useful if you wanted only a subset of resources to review timesheets for another set of resources. This could be useful for reviewing contractor timesheets, for example.
Against the group that you want to have as timesheet reviewers, make sure that the ‘Approve Timesheets’ permission is NOT set for the relevant category. In my example below, this group could approve timesheets for all current and future resources (from the My Organization category).
The above settings would make this group of users able to review all timesheets in Project Server, assuming they have been selected as the approver if you have not turned on fixed approval routing.
Note: There does appear to be a small bug with the label when using multiple timesheet approvers at the minute. This will manifest as the following:
The text says <% <%$Resources:PWA,ADMIN_ADDMODIFYUSER_BROWSE%>>
Nothing to worry about, just a label bug
I came across a little possible pitfall while generating some reporting for a client, which I thought I should share with the community.
In Microsoft Project, the Start Date in Project Information defaults to the Start Date of the first task in the plan.
Obviously this can be changed in the Project Information so that the Start Date of the Project does not necessarily reflect the Start of the first task in the plan, or the Project Summary task.
So which date does appears in the reporting database? Well, here are the results:
From the MSP_EpmProject_UserView view in the reporting database
As you can see, the date from the MSP_EpmProject_UserView displays whatever is set in the Project Information. This might cause some unexpected information in reports, so we need to expand our query to include the date from the Project Summary task:
So, when writing the specifications for your reports, make sure you’re clear which date the client wants – it’s not unheard of having a plan created a few months in advance of the work being realistically scheduled which might cause this confusion!
Obviously the clear process-driven workaround is to have your Project Managers ensure that the Start Date in Project Information is updated when scheduling the project!
Just a quick note to let you know about an error I came across today.
In Project Server 2010, I had a field called “Objective”. This was associated with a lookup table of the same name, which was single-value select. This field was added to the Project OLAP cube, which built successfully. So far so good!
I then changed the field type to multi-select, and left the cube to build overnight. Came back the next day to a failed OLAP build. The exact error I got in the queue was this:
- CBS message processor failed:
- CBSMetadataProcessingFailure (17005) – InitCustomFieldDimensions cannot process the Project custom field ‘Objective’. Details: id=’17005′ name=’CBSMetadataProcessingFailure’ uid=’c69b0459-5d1f-4d78-a410-f56cd32eca97′ QueueMessageBody=’Setting UID=00007829-4392-48b3-b533-5a5a4797e3c9 ASServerName=<SQLServer> ASDBName=OLAPCube ASExtraNetAddress= RangeChoice=0 PastNum=1 PastUnit=0 NextNum=1 NextUnit=0 FromDate=10/30/2012 00:00:00 ToDate=10/30/2012 00:00:00 HighPriority=True’ Error=’InitCustomFieldDimensions cannot process the Project custom field ‘Objective”.
Hmmm…OK, must be the change I made to the field. I need this field to be multi-value, but I don’t necessarily need it in the cube for reporting. So, I went to remove the field from the cube but it wasn’t listed. Weird. I thought re-saving the OLAP configuration and re-building it would just flush out the field since it was no longer listed in the cube configuration. I got the same error in the queue again.
The only fix I found for this was to re-create the OLAP cube with all of the same settings as previously, minus the “Objective” field, which I couldn’t add anyway as multi-value fields aren’t available to add to the cube.
Hope this helps you out if you come across this error in the future.
Edit: it seems that this was a known issue back in 2011, which hasn’t yet been fixed. More info on Brian Smith’s blog here: http://blogs.msdn.com/b/brismith/archive/2011/02/04/project-server-2010-take-care-changing-custom-fields-to-allow-multiple-values.aspx
Have you ever wanted to hide tasks from the Gantt Chart? The following technique is useful for tidying up a schedule – for example, if you want to show only pertinent Gantt information for a presentation, or take a screenshot of a plan for a client that contains some internal tasks.
To hide individual bars in the Gantt display, simply insert the “Hide Bar” field and set it to “Yes” for the requisite tasks:
You’ll notice that all incoming dependencies for the hidden bar are also hidden, so take care when looking at your predecessor/successor logic!
A useful little nugget about Microsoft Project that came in handy the other day is showing or hiding items from your Gantt chart. It’s as simple as this:
In Microsoft Project right-click in the Gantt Chart and select “Gridlines”:
To show, for example the Current Date on your Gantt, select “Current Date” and change the line type from blank to any other line style. Change the colour if required, then click “OK”.
My example here is showing the Status Date as a red line, and the Current Date as a blue line:
One query that we receive a lot from our clients is about setting up automatic traffic light (or RAG) indicators for their project schedule. This is a very well documented request, but a recent client wanted a slight variation – the project schedule indicator to have its tolerance based on a percentage, instead of a hard-coded value. The following formula solves this issue:
IIf([Baseline Duration]=0,"No Baseline",
Switch([Baseline Start]=ProjDateValue(‘NA’) Or [Baseline Finish]=ProjDateValue(‘NA’),"No baseline",
[Duration Variance]<=0,"On schedule",
[Duration]/[Minutes per day]>([Tolerance for schedule in percent]/100)+([Baseline Duration]/[Minutes Per Day]),"Outside tolerance",
[Duration]/[Minutes per day]<=([Tolerance for schedule in percent]/100)+([Baseline Duration]/[Minutes Per Day]),"Within tolerance"
This is for the task schedule RAG, and will return values based on a number field called “Tolerance for schedule in Percent” to indicate whether the task duration has increased beyond its allowed tolerance.
You will also need to set up RAG graphical indicators for this field as well, with the following values, as per the screenshot below:
No baseline = Question Mark
On schedule = Green
Within tolerance = Amber
Outside tolerance = Red
Of course, your indicators could be different to those that I have chosen, as well as the text. Just make sure to update the formula if you want to change the returned text.
Hopefully this will shorten your chin-scratching time when attempting to do something similar!
Inactivate task is a new feature for EPM2010; this feature enables the project manager to set certain tasks to inactive rather than deleting the tasks. This functionality is also useful for performing what-if analysis.
The following paragraph from Microsoft explains that intended usage of the inactivate task functionality:
“Microsoft Project Professional 2010 enables you to cancel a task but keep a record of the task in the project plan. This is called inactivating the task. The task remains in the project plan, but does not affect resource availability, the schedule or how other tasks are scheduled. Note: Inactivating a task is a feature available only with Project Professional.
Why would you want to inactivate a task? For one thing, it can help you model the effects of schedule or resource constraints on the project without deleting tasks permanently. Also, inactive tasks remain in the project plan, providing a record of cancelled tasks and enabling you to reactivate them if circumstances change.
Note: Inactivation is nor a good way to archive complete tasks, because it could have unanticipated effects on the remaining schedule. Instead, mark the tasks as completed.”
Please see the following best practise guidelines for using inactive tasks:
- When in the planning phase, if you decide that a task or tasks are not required, at this stage use the inactivate task feature to set tasks to inactive rather than deleting the tasks. this will give you the option to quickly make these tasks active at a later date if there is a requirement for these tasks.
- Inactive tasks do not affect resource availability. Baseline values that have already been taken are retained, but any new baselines taken will not include data for inactive tasks.
- Tasks that have actual work cannot be made inactive.
- Inactive tasks are not published, so inactive task assignments will not appear on a team member’s task list.
- Inactive tasks are available to report on via the Project Server OLAP cube, so care should be taken when reporting that these tasks are/aren’t included depending on the figures required. The “Task is Active” field can be used to include or exclude inactive tasks. If you do not see this field in your OLAP cube, it may be that the EPM administrator has not enabled inactive tasks in the cube.