I am looking for some experienced help. We are having a debriefing for our fall Internet application. The application takes in a great deal of data and aggregates it and spits out several reports. We had a particularly difficult rollout this season and I want the debriefing to help us for our next rollout. My role is test lead and I feel responsible for pointing out the needs for improvement but want to get some suggestions on what to include in a standard debriefing as this will be my first. We had 4 months of fast testing and were not able to use automated test tools nor extend the release date. We also had requirements from outside that changed during our process (still young). I guess I am looking for an outline or template.
OK - First, I use this type of thing as a "This is what IS." Political posturing and "spin" is kept to a minimum. Call a meeting of the project team to do this. Present facts, not opinion. There should be no "surprises" in a meeting/discussion of this ilk. High level, this is the format I've used.
1. Start with what worked. Something like "These aspects of the project as a whole went well... These features have gotten rave reviews... "
2. Move to what was acceptable. I use this for things that were OK, within tolerances for example, yet could have been better. "Our customers consider these features to be improvements over the old product/release, and are a good step toward their long-term goals..."
3. What did we muddle through? I use this for things that everyone involved in the project knows was a problem and recognizes that they should not have happened.
4. What bullets did we dodge? What items, some of which may be in #3, could have been disaster or totally derailed the project? These are the things that really need to get sorted out - how and why they happened. Then - what can be done to not make the same errors again.
5. These items are open issues that need to be addressed. Pretty straightforward - what problems or concerns are unresolved, and how are we going to resolve them.
Now then, quantify, quantify, quantify. Present #1 and #2 as statements. These things ARE. Have information prepared on #3, 4 and 5 - use them to prime the well if need be. Give other project team members the opportunity to add their perceptions to these issues. Then summarize them.
Don't be afraid of using pointy-haired-boss phrases to your own ends - e.g., "We've had some really good input on this issue. I think the general trend we've all pointed out is..... If we can correct this trend, then I believe we will correct these other issues resulting from that trend." Be cautious of "I told you so." It only aggrivates the people you told. ;-)
That is as close to a single template that I use. Each of the last 5 major projects have been so different that a single template would not work. I have found this general format works pretty well.
Finally. Don't be afraid to back down. There are times when a tactical withdrawl will leave you with enough resources to renew the fight another day. Doing so may also win you more face with others in the room that by slugging it out to an unknown resolution. At the same time, if you have won over the majority of the team, don't be afraid to take the moral high ground.
thank you, I am using what you have written and adding some statistics like how many bugs where they came from, what environment and who found them. Your reply is very useful just the start I needed. [img]images/icons/smile.gif[/img]