can anyone recommend a template or give me some pointers as to the types of details that should be documented in a post project review.
I'm hoping to start creating these after a release has completed to publish issues and identify how we can try and prevent problems happening again in the next release, but would welcome some info to ensure that they are useful.
Post Project Reviews are also called "Post Mortems" and "Lessons Learned". I'm sure if you did a search for those phrases, you may get some more insight into what you should bring to this meeting.
I'm at a new company now - so what I'm introducing is new. What I'm starting with is:
Test metrics (# of bugs, types)
What went right, why?
What went wrong, why?
The result is a "Lessons Learned" document that is published to the team. That way they can learn from their mistakes and not repeat history. This document is key to a true QA initiative of constantly improving and increasing the effectiveness of the overall process.
Jean's pretty much stated this already but I was pretty impressed at the post-mortem I attended yesterday that we came up with solutions (or beginnings of solutions) for every problem we spoke of. In past post-mortems I've attended, they just ended up being gripe sessions and none of the gripes were ever acted upon. In the session I attended, we only spoke of what went right/what went wrong in the view of individual developers, testers, project manager, tech writer and product manager.