Dependency Management

Microsoft is a big place with a huge number of software products in development and a number of those products have dependencies between each other.  We’ve got a pretty rich & consistent process for managing bug across divisions — but managing software product dependencies (e.g. The Office team needs a component from Windows in order to ship) is a different story.  Some teams have built custom tools, some teams use Word documents and yet others use Excel.  The common theme about the process and the tool is that two teams are essentially creating a “contract” between them. It is certainly from the task-level dependencies that you’d often see in a Microsoft Project plan.

We’ve recently started managing dependencies more formally within Team System, so that the different product units (e.g. TFS, Team Test, Team Architect etc.) have a way of creating, managing and tracking the dependencies between each other.  Here’s what a “Dependency” looks like:


Some of the interesting fields:

  • Risk: To indicate a High,Medium,Low risk level for the dependency

  • Short status summary: For a human to take everything the system is saying and boil it down — great for presentation in a table 

  • Iterations and dates: To mark out the delivery data from the producer and the expected use date from the consumer

  • Producers and Consumers links: To have the traceability to what features the dependency is delivered by and what it is consumed by

  • Producer and Consumer section: To have space for both sides to sit down and work out the details of the dependency

 The state flow is pretty simple:

  • The dependency starts off in Proposed and only needs Title to be filled out.  It can go to the Active state from there.

  • When it is in Active state, the producer product unit and description and consumer product unit and descriptions need to be filled out (the assumption is that if the dependency is active, at-least that information should be known)

  • From the Active state, it can to to a Closed state or back to Proposed or get Cut

Please share your feedback and I’d love to hear you are managing your dependencies and what additional support you’d like to see there.




Comments (6)

  1. Siddharth,

    Thanks for sharing – I have loved getting a peek over the last couple of years into how the Visual Studio Team System team manages product development.  Obviously your system is very complex compared to the rest of us out here, but it is very interesting to see how you use TFS to attack some of the management problems around software development.  I loved the blogs earlier about Value Props, Experiences, etc.. as well as the posts/Tech Ed presentations by Brian Harry and Jeff Beehler.  This one continues that streak of good information and will cause me to rethink how I approach dependency management on my projects in the future.

  2. Hi!

    Your comments are very much appreciated and we’ll keep up the trend of giving you a peek into our process!


  3. SivaG says:


    Very interesting feature!!

    How are dependencies defined? Can they be associated to work items and be rolled up to view for an iteration?  

  4. Hi Siva,

    In this case — to manage "contracts" — in some sense, a heavy-weight dependency — we created a work item type called dependency.

    It is possible to link the dependency to other work items and because the dependency has Iteration as a field on it, it is also possible to get a view by Iteration.


  5. rodclaar says:

    Thanks for the overview.  Can I get some more details?  I’m working with a large group at MS to deal with dependency issues.

  6. A good read: Applying Value Up at Microsoft by Sam Guckenheimer (also available as 60-minute-webcast

Skip to main content