Using MS Project with TFS

My current customer uses Project Server to track software development projects. One of the considerations for a TFS roll-out is how the two server technologies interact. Yes, there is a degree of integration with MS Project, but what has to be done for this to be useful?


My customer faces two “in your face” issues:

  1. The active directory lists users as “LASTNAME,FirstName” e.g. LYNES,Andrew. This is an issue since by default (for Australians anyway), the comma (,) character is the Windows list separator and MS Project will assume two resources are allocated to each imported work item.

  2. TFS work items can only have one owner. This means MS Project tasks that have more than one resource allocated to them cannot be uploaded into TFS.

The first issue has caused some debate as to whether it is a bug or a feature. Regardless of the answer to this question, there are 1.5 solutions (you choose which one is half a solution):

  1. Change the Windows “List separator” via “Regional and Language Options” in the Control Panel to something else. Yuk!

  2. Wait for a fix. It’s on the way, but not publicly available yet (KB919232). Those of you with support arrangements with Microsoft may be able to access it earlier (as my customer did). As of this moment, the “fix” simply converts all commas (,) into semi-colons (;) as work items are imported into MS Project. It reverses the process when going the other direction. It’s not pretty, but it does the trick.

The second issue boils down to how organisations break work down into smaller tasks. Rather than being a blocker for project managers making use of TFS, I see this as an opportunity to “out-source” planning activities to the people that actually need to do the work. This is one of the features of MSF, so it’s no accident that TFS works this way. One possible solution to the 1:1 issue is:

  1. You can still create the “big-ticket” tasks as you may have done before, but mark these as “Exit Criteria” tasks and allocate them to a lead developer (or the PM).

  2. The first sub-task, which must be allocated to a lead developer, is to create a detailed collection of work items which can be allocated to individuals.

  3. At this point, the tasks can be published to TFS so the team can get cracking. Even though the lead developer may own the “create detailed work items” task, the whole team should work on this.

  4. Any resulting work items can be imported back into MS Project and collected under the original “big-ticket” task. This will allow delivery dates to be estimated and resource availability to be assessed (assuming the team also estimated the work required for each work item).

  5. When all the sub-tasks are complete, the lead developer or PM can close the “big-ticket” task.

Yes, it was “easier” to create one Über task and allocate the entire team to it. However, getting the team to come up with a set of smaller work items that can be assigned to individuals can only improve project estimation. Surely this is a good thing?

Comments (4)

  1. Renil Abdulkader says:

    You said "Any resulting work items can be imported back into MS Project and collected under the original “big-ticket” task". But how it is possible to group work items under a main Task? Could you please explain this?

  2. Andrew Lynes says:

    You’ve honed in the weakness of the "solution" I’ve offered. Out of the box, you’ll need to come up with a way of identifying the imported tasks. My team initially tag the title with some identifying text, so that when the work items are imported into MS Project, it’s clear where they belong. I simply drag imported items into position, remove the tags with a global search and replace in MS Project and republish.

    For MSF Agile projects, this seems to work OK, but you definitely don’t want the "importing" to get on top of you. For a Mission to Mars project with a cast of thousands, this probably ain’t going to work.

    Another alternative is to allow the Dev. Lead to create a new Area in the project, and have them categorise the new work items that way. If you’re in the fortunate position of having one team working in one team project, this can work. You’ll still need to move things around in MS Project though.

    As an aside, you can find the MS Project hierarchy for a work item in the "Task Context" field on the Details tab of a Task work item. This is the source of the "tag" I was talking about.

  3. Eric Jarvi on VSTS Tip: teamprise interview

    Marcus on MSSCCI Provider update available.

    Brian Harry…

  4. David Wolf says:

    Thanks for the post.  FYI, you can run into this issue with old TFS projects that were created on TFS 2005 servers even if you have upgraded all the way up to TFS 2010. We ran into this recently.  The TFS updates don't fix existing projects.  There are some notes in the KB919232 article that put you on the right path to fixing existing projects. They don't work exactly, but they put me on the right path.  In the end I just directly downloaded the TFSFieldMapping file for the project that wasn’t working correctly and compared it to another project that was working correctly to fix the issue.  Hope this helps someone.

Skip to main content