MSDN recently pointed to an article on the approach being taken in the Team system to software project management. What I found to be the best "take away" from this was "Getting crucial metrics about the project is important to track status, and to make decisions."
Status is important but so is severity and lifespan. The warning posted in the article is that "Often, the project lead becomes lost in the details of tracking and is not analyzing project risk or making course corrections on the project."
Well another big problem is making sure the leads stay AWARE of the issues going out. Whenever you distribute metrics, be aware that too many numbers simply make people ignore them. Of course, if you've already flipped the bozo bit on the person who gathers them, you're only setting yourself up for failure.
But seriously, just because a project may have 1500 open "bugs" doesn't mean it's impossible to figure out what to look at. Break them into quantifiable categories: reproducible, enhancements (like it or not, customers will likely see many ERs as "bugs"), critical, by design and others.
Our development team at one client has a rule: no critical bugs over 24 hours, no serious bugs over a week. Well, the problem with those rules is that how do you get rid of critical bugs? No - You don't re-categorize them to a lower level with a work-around.
Regardless of the tools people use to track bugs, the only way not to get lost in the metrics is to have some discipline about going through them. Maybe Visual Studio's Team System will help this (I'm still in the process of installing it as it requires a separate DB server).
I don't find the discipline that hard to work with: Critical within 24 hours, Serious within a week. After that, duplicated non-fatal bugs are looked at. Even if you only look at 5 a day, you're still chipping away at something and getting out of the death march.
But sharing the metrics are critical. We send out a daily status report on support calls and issues, followed by a weekly one with a larger breakdown and then a monthly summary. All of these are done through email. Sure, we could ask people to look at them on a web site but guess what? That makes it "someone else's responsibility". Put it in their face (although not as a pop-up ad) and then be brutal. There's no reason for people to say "I didn't know" if you have at least given them every opportunity to see what's going on.
And if your project lead becomes lost in the details, then someone needs to be trained better and soon.
Visual Studio 2005 Team System: Software Project Management
Status is important but so is severity and lifespan. The warning posted in the article is that "Often, the project lead becomes lost in the details of tracking and is not analyzing project risk or making course corrections on the project."
Well another big problem is making sure the leads stay AWARE of the issues going out. Whenever you distribute metrics, be aware that too many numbers simply make people ignore them. Of course, if you've already flipped the bozo bit on the person who gathers them, you're only setting yourself up for failure.
But seriously, just because a project may have 1500 open "bugs" doesn't mean it's impossible to figure out what to look at. Break them into quantifiable categories: reproducible, enhancements (like it or not, customers will likely see many ERs as "bugs"), critical, by design and others.
Our development team at one client has a rule: no critical bugs over 24 hours, no serious bugs over a week. Well, the problem with those rules is that how do you get rid of critical bugs? No - You don't re-categorize them to a lower level with a work-around.
Regardless of the tools people use to track bugs, the only way not to get lost in the metrics is to have some discipline about going through them. Maybe Visual Studio's Team System will help this (I'm still in the process of installing it as it requires a separate DB server).
I don't find the discipline that hard to work with: Critical within 24 hours, Serious within a week. After that, duplicated non-fatal bugs are looked at. Even if you only look at 5 a day, you're still chipping away at something and getting out of the death march.
But sharing the metrics are critical. We send out a daily status report on support calls and issues, followed by a weekly one with a larger breakdown and then a monthly summary. All of these are done through email. Sure, we could ask people to look at them on a web site but guess what? That makes it "someone else's responsibility". Put it in their face (although not as a pop-up ad) and then be brutal. There's no reason for people to say "I didn't know" if you have at least given them every opportunity to see what's going on.
And if your project lead becomes lost in the details, then someone needs to be trained better and soon.
Visual Studio 2005 Team System: Software Project Management
Comments