Well, it’s been an interesting couple of weeks professionally and on this blog.  During that time, I’ve set my sights on Microsoft Project Professional, SharePoint 2010, Visio Professional, and taken a brief excursion into the world of Ideation.  Spinning the Wheel of Required EPM Consultant Skills this week, I land on the popular TFS-Project Server integration package.

If you’re not familiar with the integration package, it’s an add in that comes as part of MSDN Ultimate that may be installed on your Project Server farm.  Once installed, the integration package essentially marries Project Server to your TFS 2010 SP1 installation – thus allowing bidirectional transfer of tasks and task updates from one to another.

I took a brief look look at the package here and here.  Since then however, I’ve had a number of discussions with clients both during demonstrations and as part of production installations.  This specific post is written to touch on one of those discussions that seems to invariably happen as part of the education process….a review the options available for time tracking.  To date, that discussion usually has revolved around whether the organization would like to track time within TFS or within the Project Server My Tasks/Timesheet interface.

Let’s take a look at the available options…after doing that, let’s take a look at the relevant decision factors.

Default Package Behavior

First off, let’s examine the default behavior of the package.  I am using the demo TFS image downloaded from Microsoft, but have created a new Team Collection and PWA instance to review what happens out of the box and to ensure that everything is set to the default options.

To start out, I create two new tasks, Task 1 and Task 2, then assign those task to the Contoso Administrator.  Each task is 5 days long, which translates into 40 hours (5d X 8h = 40h).

I navigate to the Resource Usage View within Microsoft Project Professional to see how those hours are distributed.  See how 8 hours are planned per day, starting on Thursday.  This is important to note because when the time is updated from TFS, the hours simply get booked from the first day on which Planned Work exceeds Actual Work, and then fill in the gaps until the task has been marked completed.  Here, those hours will begin being booked on Thursday and then proceed through the week.

We look at Visual Studio to confirm those tasks have successfully transferred from Project Server.

Clicking on Task 1, we navigate to the Project Server  tab to see the hours.  In this case, the hours have been pulled correctly from Microsoft Project and populated both in the Project Plan (Project Server) field and in the Work Item field (TFS).

I change the hours within TFS to indicate that I have worked 16 hours and have 24 remaining.  Note that I cannot edit the Project Server fields as they are greyed out.  These fields serve as a reference for what is actually in the project schedule.

Going back into Project Server, I look at the Approval Center page and the hours have been booked to the earliest dates available for the task.

After approving the changes, I look at the schedule in Microsoft Project Professional.  Everything looks good.  The task has been updated correctly.

Again, I review the task in the Resource Usage View to confirm that everything has updated correctly.  See how the hours are allocated against the first couple days of the task?

Picture the task as a series of glasses being filled with water, each glass representing one of the days of the task.  Once the first glass is filled, I move on to the second, then the third, and so on.

The moral of the story is that hours may be updated against the item in TFS, and those hours then get booked against the default hours for the task.  If the task was scheduled to start on Monday, then those hours are booked on Monday….and then any succeeding day on which the task is scheduled.

Note that this could create a potential issue where a task scheduled in the future is completed ahead of schedule.  If the data was updated within TFS, the task will be marked as complete in the future – generally a bad practice in the scheduling world.

Using Project Server My Tasks

So what happens if instead of simply booking time against a task, I desire to track when the work actually happened?  Instead of simply assuming that 8 hours were booked each day, I want the developer to book 4 hours on Monday, 2 hours on Tuesday, and 10 hours on Wednesday. 

Let’s look at the mechanics of this process first, then let’s back up and look at the implications.

Project Server allows the administrator to either set a standard project update mechanism or for each project manager to define the mechanism for their own projects.  In the following screenshot, I am setting the project to allow users to submit Actual Work per Day and then publishing the project.  If that option is greyed out, you will want to discuss with your server administrator.

I publish the project and navigate to the My Tasks screen using my browser.  Within this interface, I can update the actual hours worked per day (or per week).

I can also update the Remaining Work on the task.

Accepting those updates in Microsoft Project yields the following view.  Note that instead of simply booking a default 8 hours to the first two days of the task, I have booked 4 hours to each of the first two days.

Publishing the schedule pushes those task updates into TFS.  Here things start to look a bit strange.  I see that the Project Plan hours have updated correctly, but the TFS fields have not been updated, and still read Actual Work = 0 and Remaining Work = 40.

This gets a bit confusing admittedly.  What appears to be happening is that changes to the hour estimates in Project Server are communicated into TFS, but not transferred into the Work Item fields.  Fair enough.  I can see where that would make sense, i.e. I want to communicate to the developer what the schedule says, but I also want the developer to be able to make his own estimates – in the Work Item fields.

So I go ahead and make those changes in the Work Item fields.  I update TFS to read Actual Work = 10 and Remaining Work = 10.  I save the item.

The change in the TFS record then forces the change in Project Server.  Below, that change is visible in the PWA Approval Center.

…which then updates the project schedule.  My task in Project has now been overwritten by the TFS data.

If I want my users to update their hours in Project Server, this could be troublesome behavior – i.e. that the user can always update the hours within TFS and override the PWA timesheet interface.

Modifying the Default Behavior

But what if I want to change the default behavior?  What happens if I decide to make a commitment to put all of my TFS tasks into Project Server for tracking, and more importantly for my developers to track their time in a full featured timephased timesheet?

Well, after playing with the settings it would seem that this may be resolved with some minor changes to how the mapped fields are configured.

Take a look at the default field mapping.  When downloaded and opened as an Excel file, it appears as follows.  Note the DisplayTFSField and DisplayTFSMirror properties for the Completed Work and Remaining Work fields.

I set those two properties to “False” in the XML source file and re-upload the mapping.

Navigate to the Project Server tab for a TFS item.  See how the TFS values are not even displayed.  Two sets of books are no longer displayed.  More importantly, developers are forced to navigate to the PWA timesheet interface to update their tasks.

Note that since this is a hypothetical scenario, I admit that I haven’t worked through all of the implications of hiding the TFS fields for the Project Server fields, but I’d be curious if anyone has any feedback.

Decision Factors

For the most part, my conclusion is that the default behavior is structured to support an organization where tasks are updated primarily through TFS and then passed back into Microsoft Project.  Changes to TFS override Project Server.  Changes to Project Server get passed into TFS for reference.

Based on my discussions with clients to date, I would agree with this bias in the configuration of the default options.  Most of the groups I’ve discussed this functionality with have definitely leaned in that direction – especially as using TFS to update tasks means that they could leverage TFS to manage much of the detailed complexity of individual project schedules.

That being said, the discussion usually touches on a number of factors:

1. Does the organization desire to keep a daily/weekly view of actual work performed?
2. Is TFS being used to keep extraneous details about tasks out of project schedules, thereby allowing the project manager to focus on the high level details?
3. Are developers expected to use any tool other than TFS to track their own hours?

Pending the resolution of any of those questions, the administrator may wish to look at the specific configuration of the integration package.