Post-Project Review

George Spafford February 05, 2003

Projects always run smoothly, are under budget, within timelines and meet expectations… right? We all know that is what we wish would happen. The only problem with that scenario is that reality enters in! In this article, we'll cover two reviews--the Control Gate Review and the Post-Project Review. What is a Control Gate? As we plan projects, there are points that are considered milestones. Milestones are important points in the project that are typically associated with certain tasks being completed. When milestones occur, these are also good points to have control gates. Control gates are essentially in-process audits where the health of a project is assessed and decisions are made. Whereas a milestone is an indicator of progress, a control gate is a systematic review of the project that determines what should happen next. Control Gate Review CGRs serve as opportunities to collect data, make decisions and then share information. Without these reviews, it is very easy for a project to be in trouble without anyone knowing about it. The longer a problem continues, the more difficult and costly it will be to correct. Organizations and projects differ and, as a result, the questions needed to assess the health of the project will vary. To help demonstrate how a CGR template may be structured. After the data is collected and analyzed, a decision is made following one of the following general themes: • The project is fine, so proceed as planned. • There is a problem(s), and corrective actions are required prior to proceeding. • There is a problem(s), corrective actions are required, but the project may proceed with another review set at a certain date. • The project is unrecoverable, needs to be terminated and a post-project review performed. Depending on the environment, CGRs can be sensitive documents. You may share them directly, share summarized results, or not share the findings at all. My recommendation is that you inform your clients that there is a review process in place for control purposes and summaries of the reviews will be prepared and discussed with them. These CGRs, coupled with regular status meetings and reports, help to calm fears and demonstrate a professional approach to project management. Let's change gears from in-process reviews to the reviews that happen at the end of a project. Post-Project Review Whereas CGRs happen during a project, PPRs happen at the end. The project may have ended successfully, failed miserably or been cancelled. Regardless, you still need to collect information about it. By methodically reviewing a completed project and identifying the performance of key areas, teams learn what to do and--just as importantly--what not to do in the next project. For a person or team who needs to continue where this project left off, the PPR serves as a key summarized knowledge repository. Without the PPR, a new person or team will be forced to sift through all of the status reports, change notices, etc. to surmise how various things went. Many of you are probably saying, "He's just calling a post-mortem a PPR." In a sense, I am doing just that. However, please ponder one small marketing concept--"post-mortem" literally

means after death. A failed project is one thing, but to have a post-mortem meeting after a great project just doesn't sound good. In terms of the PPR itself, I've seen a number of approaches ranging from free-form text to highly structured documents. I tend to favor checklist approaches that fall in the middle and use a structured series of questions with the capacity for numeric scores as well as free-form text. The intent is to capture both metrics and summarized information. To improve over time, you need both. For the review, I recommend getting input, if possible, both from the core team, stakeholders and the sponsor. The core team, stakeholders and sponsor will have different perspectives on the project, and it is worthwhile to solicit their input. With this in mind, you should structure your PPR questionnaires to ask the appropriate questions for the audience involved. Core Team PPR An internally focused PPR is aimed at the core project team. It should be done first to identify potential issues and resolutions prior to moving outside the core team. To clarify, it is better to discuss potential issues here than to go straight to the stakeholders and sponsor and be surprised. Stakeholder PPR After the core team PPR is completed, move on to the stakeholders. As they are very different from the core team, I recommend a different template. Be sure to focus on the project from their perspective. For example, highly technical language may confuse a person. Instead, ask "Was the project successful from your perspective and if so, why?" It is readily understandable. The intent is to learn from these people, not confuse them! Sponsor PPR Once the core team and stakeholder PPRs have taken place, then meet with the sponsor(s). I recommend doing the reviews in this order so the risk of a surprise is lower plus you will have more information should the sponsor elect to ask questions. In terms of recording the answers, you can use the same template as the stakeholders or generate your own tailored form. Whether you use the same stakeholder template or create a new one, be consistent so you can compare reviews across projects. Overall Review Recommendations Reviews are positive events and people must realize this. To be viewed as such and not despised requires the following: • Objectively review the process and facts. Avoid using leading questions and allowing personal bias to skew both the questions and answers. • Keep the reviews at a high level. They provide summary information, not tons of detail. If people need detail, let them review the project plan, change management tracking system, risk tracking system, etc. • Actively avoid allowing review sessions to regress into a means to lay blame. The point is to learn, not assess fault. There is a big difference. • Consider using an auditor or reviewer that is not from the project. The objectivity will be higher as there will not be personal stakes involved. • Act on the reviews! I cannot stress this enough. If people see that nothing ever comes of the reviews, then they will not put forth an effort either. Some people elect to do reviews as a group, and some do them one-on-one. I've seen both methods be effective. I have noticed that there does seem to be a benefit to group reviews during tough projects because they draw strength from one another and speak more freely about what went wrong. If you use group meetings, use a skilled facilitator and segregate the three groups. Do the core team review separate from the stakeholders and the sponsor(s). People need to be at ease to answer freely.

Periodically analyze the reviews, both CGRs and PPRs and look for trends. If you only look at one and not a series, then you have a point value as opposed to seeing scores--and thus changes--over time. Consider putting the reviews on a secure intranet and make them full-text searchable so project managers can read the reviews and learn. Remember the old saying: "Those who fail to learn from the past are doomed to repeat it." Summary Control gate reviews and post-project reviews are excellent methods to learn and evolve project management practices. The most important thing is to actually use these reviews. Don't just make them steps in the process. There can be a tremendous amount of knowledge captured and shared with others through the review process.