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?