How Microsoft/DevDiv uses TFS-Chapter 7 (Tracking Risk)
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.
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:
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.