What is a post project review?
One of the features of a project is that it has a definite start and a definite end. Sometimes the start and end may not be very clearly defined (!) but one can usually get a rough idea when a project started and when it is over. Something that does not have this sort of finite lifespan is not really a project. However, it is possible to break up any activity such as ongoing software maintenance and support into a series of clear projects - typically ending a project when a software release is put into production and starting a new project for the next release or upgrade.
A post project review is a very useful and powerful way of adding a continuous improvement mechanism. Most activities can be divided into a set of discrete projects as mentioned above. This continuous improvement mechanism helps make each succeeding project more successful (and frequently less stressful to all participants). Post project reviews typically involve the project team and major stakeholders meeting together and reviewing what went well and what went badly during the project. This input can help participants make the right decisions and plans so that the next project runs better. It can also help clear up misunderstandings and other issues.
For example, on a post project review that I once conducted, the Quality Assurance (QA) team was upset as they felt requirements changes had been approved and made without their input during the project. Based on this feedback this was corrected in subsequent projects by ensuring that a representative from the QA team was always present when discussions on requirements needed to be done. This put them in the loop as well as gave them an opportunity to bring up potential impacts on the QA deadlines. It is important to ensure that all participants in the post project review understand that it is not a time for assigning blame or making personal attacks. The idea is to praise each other on jobs well done as well as find ways to do things even better. One must be careful that a post project review does not degenerate into a finger pointing exercise or shouting match.
The elements of a good review
As mentioned previously a post project review's primary purpose is not to apportion blame but to identify areas for improvements and ways to improve them. Before you plan a post project review identify your primary goals and what you want to take away.
- Identify items that were done well: For example maybe time estimates were very good, developers and quality assurance teams worked well together and so on.
- Identify items that could improve: Maybe system documentation was not ready on time; developers had disputes with analysts, etc Basically these are items that need some improvement that can be realistically achieved with some degree of effort.
- Identify items that are broken: These are quite serious and may require a complete rethinking on how they are done. Possibly some processes may need to be dropped or changed. Maybe continually changing requirements requires the team to change to a more agile development methodology. Two people who get on each other's nerves may need to be reassigned so that they do not have to work together.
- Decide action plans: Get input & agreement on action plans to improve items that need improvement and ways to fix items that are broken. This will make it much easier to implement long-term changes as well as help build a strong sense of commitment and team spirit in the team.
Try to get as many of the stakeholders and team members together for the meeting. While it may seem like a recipe for chaos (!), if planned well it can be a great experience for all. Make sure everyone understands the action plan and goals. Stakeholders and team members are likely to be enthused if they see it as a chance to work on getting problems resolved. In my experience the first time these reviews are done are usually the hardest since people are not sure what is allowed and what is not. Some members may also take criticism badly. It may make sense to have an idea of potentially explosive issues and how to defuse them before going into the meeting. Meeting in private with the affected participants before the meeting to ensure ground rules are understood and get commitment that they will be followed can be very helpful.
A good technique that I have found to help identify major issues is to do something like voting. Each participant puts up items that can fall into one of the categories well done, some tweaking needed and needs to be fixed. This makes everyone feel that his or her opinions are being counted. Plus it can help provide a complete view of many problems. Frequently one will find a pattern in many issues. Offer praise on items that people feel are well done. The issues mentioned most frequently are the ones that need attention. At this point it can help to have people provide ideas on how to improve items that need improvement and how to fix items that are broken. You may even have an informal vote on which ideas seem the best.
Once the meeting is over, collect all the information and record it down. Make sure to detail what is going well, what needs improvement and what needs to be fixed. Identify the techniques everyone agreed would work on making the improvement and fixing the problems. It is a good idea to present this to senior management especially if some fixes need approval or resources. These reports provide them a way to review the team and will build their confidence that the team is trying to attack and fix problems on it's own. It is much better to find ways to fix problems yourself rather than have senior management getting involved in finding the fixes. People typically resent executive orders but will willingly work on changes they themselves proposed.
Post project reviews are a valuable way for teams to improve their performance and skills. They offer a mechanism to help fuel continuous improvement as well as improve team morale. It is important to get as many stakeholders as possible in the review since it is helps to review all parts of the project as well as provides a mechanism to clear up misunderstandings and other issues. Good planning and post meeting follow-up is crucial to make these reviews a success.
Copyright © 2002 Sanjay Murthi
Sanjay Murthi is President of SMGlobal Inc. He has over fourteen years of experience in the software industry in a variety of roles and responsibilities. He now helps companies to review and improve their software definition, development and delivery process. He can be contacted at firstname.lastname@example.org.