Selecting Time Tracking Options for TFS Integration

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).

image

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.

image

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

image

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).

image

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.

image

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.

image

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

image

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.

image

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.

image

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).

image

I can also update the Remaining Work on the task.

image

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.

image

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.

image

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.

image

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

image

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

image

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.

image

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

image

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.

image

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.

Advertisements
Selecting Time Tracking Options for TFS Integration

13 thoughts on “Selecting Time Tracking Options for TFS Integration

  1. Really interesting thoughts here Andrew. I confess I’ve not got knee deep in this area yet!

    I think there’s a trick missing in the TFS integration and that is where you are working in a timesheet-focused organisation (time by day). What would be ideal is a “by day” component to the TFS data entry to fully integrate into a time by day tracking method, otherwise your driving the dev team to fill in time/est in TFS and then submit a timesheet – dual entry. Something like the old pop-up for by day data entry in the PWA My Tasks view.

    Following your guide the points below may be an option but I am not sure how usable this would be:
    – EPM for statusing: Actual Work entered in Timesheet in single entry mode daily, and submitted to PM’s. Lock down estimate to complete entry in PWA
    – TFS for forecasting: estimate to complete maintained in TFS and updated to EPM Tasks, lock down Actual Work entry.

    This still doesn’t feel ideal as it’s two tools for one purpose.

    One other point: If you only enter time in EPM as per your example, I’d be interested to now if this would then cascade through to Burn down reports?

    I feel some research coming on 🙂

    1. True. Unfortunately, my understanding is that TFS doesn’t have a timephased time entry system built into the database schema. If I had my druthers, I would like to see a separate timesheet application that sits on SharePoint and that would have some sort of standard hooks into any of the Microsoft suite of work management applications: Project, TFS, a Help Desk tool….there’s third party tools like that right now, but I’d definitely like to see a native product.
      On the other hand, just out of curiousity, I don’t think it would be too hard to lock down the Remaining Work in Project Server (pending research to confirm.) More importantly there however, you lose the ability to farm out complexity from Project Server into TFS – which as I see it is one of the main benefits of this tool.

  2. Andrew, thanks for this blog. I really needed these insights and could have spent a morning figuring it out 🙂

    As to your comment
    “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.”
    you may want to look into the Project Professional advanced options called “Move actuals before status date”. I will shortly, but this probably mitigates that issue.

    Cheers,
    Bram

    1. Unfortunately, the TFS import mechanism bypasses the Project Pro “Move Status” function. Some VBA would probably do the trick in Project Pro to move future completed tasks back to the status date though.

      1. Indeed, I saw that when I tried it this morning. Thanks for checking/confirming. And indeed, a macro moving completed parts before the status date is not hard. It’s just something my current client wouldn’t want me to do because they want to avoid any custom code…

  3. Erik says:

    Hi Andrew, thanks for a great blog.
    My organization wants to use timesheets for entry of actual hours spent in the ProjectServer TFS integration. I tried out many different scenarios and I thought Everything was ok. Then I realized something quite severe. I hade synched backlog items, with several tasks that was not synched linked to them. Time reporting and updating, publishing in Project went fine. But then when the developer is ready with a task, and Changes the state to Done, it whipes all work data in Project. Remaining work is set to 0, fine, but also completed work! This update is then sent to Project, and when accepted and published it is also sent full circle back to TFS.
    We are suposed to use Project to track our actuals, and this behaviour is not particulary helpful.

    Could it be fixed by looking on how remining work and completed work is mapped? I suspect that it set on TFS wins, but why would you want that?

    We are using Project2013 and TFS2012

    Regards
    Erik

    1. Good question. So it seems as if the developer is marking the item as complete, and leaving the actual work / completed work column in TFS as 0. In theory, I suppose you could map Actual Work to push to TFS Completed Work, with Project Server winning. Have you tried that?

      1. Erik says:

        Hi Andrew,
        To begin with I set the targetToTFS tag in the field mapping xml to PSwins for actualwork in Project to completed work in TFS. This only helped a little, as the synch triggered in TFS from completed work in TFS to actual work in Project, was still going on and erasing my actuals.

        Solution: I simply removed the TFSToTarget synch from completed work to actual work, and I chose to hide the completed work mirror field. In this way Actuals are reported in Timesheets and submitted to the project plan. Then they are published in Project, which triggeres the one way synch to TFS. So actuals are safe in project, which is coherent with the single entry mode for timereporting we are using.

        My users can still change and synch remaining work from TFS to Project, which is ok as long as actuals are not affected.

  4. Erik says:

    Hi again, I figured out a soloution to the problem. TFS set completed work to 0 when a task was set to done. This value was then synched to Project. In the TFS to project synch you cant use the projectwins-tag. That is only possible when synching from project to TFS. So what I did was simply to remove the synch of actual work from TFS to project. This makes sense as the master data of actual work is entered in timesheets in project.

  5. Erik says:

    However I stumbled into another issue. We are also using material resources. I thought it would be pointless to add these resources to the TFS site so I didn’t. When I synch from projcet to TFS no error is given. And in TFS it is indicated that the work item is linked and successfully submitted. But when I update the workitem in TFS later on, it starts complaining about the material resources, that they are not proper resources, not present on the site etc.

    I would like the sync to simply ignore material resources, would this be possible?

  6. Vasudeva Rao says:

    I am facing issues in following scenarios, request forum users to help me out with the solutions.

    Please find the queries here

    1) As a project manager, I planned a task start from 15-Jun-2014 (in mpp) and assigned a resource (and published to TFS). Due to various reasons, instead of starting on 15-Jun-2014, resource started working on the task from 05-Jun-2014. Then resource entered “8 Hrs” as completed hours in TFS and saved. When project manager refreshed the TFS data in MPP, it showing 8 hrs in actual effort however, it is considering actual effort on 15-Jun-2014 instead of 05-Jun-2014. How this can be resolved?

    2) For a given task, if resource enters more than 8 hrs in TFS as completed hrs per day, after refreshing MPP for tasks details, it shows only 8 hrs on specific day as actual and remaining hours are moved to following working day. Eg, if I spent 14 hrs in office to-day and entered the same in TFS as completed hrs. After refreshing the task details in MPP, it shows only 8 hrs as actuals for to-day and remaining 6 hrs are moved to next day’s actual hrs. Is there a way to control this?

    3) I planned a task for resource 3 days (24 Hrs), Start Date: 05-May-2014 and End Date: 07-May-2014. Resource started working on 05-May-2014 and due to some reason resource is on leave on 06-May-2014 and resumed the work on 07-May-2014. But when resource enters completed hours on 7-May-2014, these will be updated on 06-May-2014 in MPP when it is refreshed for tasks updated. Is there a way we can restrict this in TFS?

    Appreciate your earliest response and support on above queries.

    1. 1) You may look at settings in the MPP file which only allow time to be booked prior to the status date. I can’t remember if the TFS integration short circuits that, but if the status date is set before importing the data, it probably should import the data to the correct date (i.e. before the status date). You’d have to confirm that scenario. The other option is to just have good communication between the developer and the PM.

      Alternately, have the resources enter their time in timesheets – which would solve the issue.

      2) TFS doesn’t timephase data. It just accepts the total number of hours and lets Project figure it out. The only solution is to use Project Server timesheets to enter time, so the resource can indicate how many hours were worked on each day.

      3) See the answer to #2. The other option is to have the PM update the schedule each day or week and move all unfinished work out past the status date (or current date). I wouldn’t recommend doing that by day though – only by week.

      Sounds to me like you should be asking your developers to enter time in timesheets – and not in TFS – for specifically the issues you mentioned.

      1. Vasudeva Rao says:

        HI Andrew Lavinsky,
        Thanks for your quick response. We are planned to follow the agile approach in TFS. All work items (tasks) will be created by developer/tester in TFS and expected to enter daily effort spent/timesheet in TFS it-self instead of using other tools by developer/tester. We are planned to use EPM/MPP to extract/synch the data from TFS to view summary (Iteration wise, release wise etc…) at higher level.
        From your response, my understanding is, TFS will not support timesheet entry. In that case we need to use another tool like EPM for timesheet entry separately for billing and tracking purpose.
        Do you have any other suggetions? Please suggest.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s