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:
OK, this report was projected on the screen. Then Jim would just start asking questions like:
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.
"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.