Share via

How Microsoft/DevDiv uses TFS-Chapter 7 (Tracking Risk)

  • Article

In the previous post, I talked about tracking progress across multiple projects. Here I'll talk about how we tracked risks across multiple projects.

First, let's look at the Progress tab of the Feature record.

image

You'll see two fields related to risk. Risk Level is the standard traffic light indicator for risk. Green = We will meet the dates, Yellow = We are at risk, Red = We will miss the dates. The second field is descriptive text.

Every week, the project manager was asked to look at the dates published in the feature record, and determine if they felt they would still meet them, then set the Risk Level accordingly. Text was added in Risk Comments as needed.

This yielded this report:

 

image

This report is generated by Excel, which was bound to a query of all features where Risk Level <> Green. The color formatting was added by Excel.

So every week, any project who assessed themselves as non-green in the Risk area, was asked to just explain to the rest of the team why they were at risk and what they were doing (or needed to be done) to get back to green.

If the Risk was just reflecting a slip in the schedule, then the item would be Risk=Red for one week, everyone would understand that the schedule had slipped and why, the end date was updated, and the Risk was set back to Green.

You'll notice that the above risk report mentions "snow/ice storms" as a risk. In Seattle, we don't handle snow very well. You may chuckle about that, but everyone around here understood perfectly :-)

What about gaming the system?

You might ask, why would someone willingly show their project as Yellow or Red? Why wouldn't they just leave it as Green. Less heat, right?

I have two answers to that.

First, eventually, if a project was in trouble, people would have to slip their dates. If they all of sudden slipped their date by 4 weeks with no prior indication of risk, people would rightly ask the question: "Why didn't you know about this sooner?" or "If you did know about this, why didn't you let us know sooner?" That helps keep people honest.

Second, its about culture change. Setting your project Risk Level didn't always mean you were doing something wrong. Many times, the risk was out of your control. What is in your control, however, is communicating the status. People were held accountable for communication, not the project's risk. (Of course, if you were repeatedly slipping your dates, someone would talk to you!)

Next post, I'll talk about how we managed our quality gates using this system.

Comments

  • Anonymous
    May 16, 2008
    PingBack from http://microsoft.wawblog.info/?p=30151

  • Anonymous
    May 19, 2008
    NWCadence Blog on Geek Speak on Team Build. The Teams WIT Tools Blog on How Microsoft/DevDiv uses TFS...

  • Anonymous
    May 23, 2008
    In a previous post , I talked about how we tracked risks across multiple projects. In this post, I'll

  • Anonymous
    June 08, 2008
    Kes veel ei tea, siis Workitem Tracking vahendite meeskond Visual Studio Team System -i arendusmeeskonnas

  • Anonymous
    June 09, 2008
    I apologize for not getting this post out sooner. I was not feeling well most of last week. In a previous

  • Anonymous
    June 16, 2008
    Content Style: Text and screenshot,&#160; Content Type: Translated post&#160;&#160;&#160; 英語原文: http://blogs.msdn.com/teams_wit_tools/archive/2008/05/16/how-microsoft-devdiv-uses-tfs-chapter-7-tracking-risk.aspx

  • Anonymous
    August 17, 2008
    A good read: Applying Value Up at Microsoft by Sam Guckenheimer (also available as 60-minute-webcast