In a previous post, I talked about the electronic status report. Basically, our status report was filling a number of fields on a work item.
Today, I’m going to show how our Program Manager in charge of managing all the projects for TFS used the information to track the progress of several projects at a time, using a series of reports.
But first, let me tell you about our process a bit. Every week we have a manager’s meeting. That meeting’s purpose is to track the health of the various projects that are going on.
The meeting is run by Jim Boyle, who is the Program Manager for our group. He is a superb Project Manager who has a lot of experience at holding people accountable.
Every week, Jim would display a report that looked like this. It showed all the in-flight projects (Feature Crews) going on.
Here’s a bit of a description:
- Green – The percentage of work completed, in compared to the entire project
- Yellow – The percentage of work completed in the last reporting period, typically 1 week.
- Red – The number of hours of work remaining.
- You’ll also note that the date the feature crew is scheduled to complete is included with the name of the feature crew.
OK, this report was projected on the screen. Then Jim would just start asking questions like:
- Why did you not have any progress last week?
- Why did you so little progress?
- I noticed you have 1457 hours left, but your scheduled date is Jan 3, do you still feel like you can make that date?
Now Jim wasn’t pounding his fist on the table and saying: "Why in the h*** are you not making more progress!". He just asked the question. The data presented showed a conflict and he just called it out.
Here were some of the answers given:
"I didn’t get the data updated" – This became an unacceptable answer. There was a bit of a verbal spanking that happened, along with the reminder of how important it was to have visibility to this data. By the way, this accosting was done not by Jim, but by our Product Unit Manager (read: Brian Harry)
"We got pulled of on other emergencies last week" – This was a very acceptable answer. Although, in the meeting there was sometimes a redirection of priorities. In other words, management clarified that the emergency is not as important as the project. Either way, management had a much better idea of the status of the project.
"If everything goes well, and there are no complications or problems, we hope to get it done one time" – OK, this is obviously someone trying really hard to believe they can meet the original date. They are reluctant to slip the date because it makes them look bad. Basically the message to them was: We need a date that you have a high confidence of meeting. If you need to slip the date, its better for us to know now, rather than slipping it late.
You might have picked up that a culture change had to happen within our group. Transparency will force that upon you. In this culture of openness, management had to let go of "holding people to their original dates, no matter way" and those on the feature crew had to let go of "presenting the project status in the best possible light" or "hiding bad news". It was a learning process on both sides.
This post has gotten a little longer than I expected, so I’m going to stop this one. In future posts, I’ll talk about how we tracked risk and quality gate status.