post-project reviews

Upload: fakhro

Post on 31-May-2018

218 views

Category:

Documents


0 download

TRANSCRIPT

  • 8/14/2019 Post-Project Reviews

    1/3

    Post-Project Review

    George SpaffordFebruary 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 isthat reality enters in! In this article, we'll cover two reviews--the Control Gate Review and thePost-Project Review.

    What is a Control Gate?As we plan projects, there are points that are considered milestones. Milestones areimportant 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 anddecisions are made. Whereas a milestone is an indicator of progress, a control gate is asystematic review of the project that determines what should happen next.

    Control Gate ReviewCGRs 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 knowingabout 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 healthof the project will vary. To help demonstrate how a CGR template may be structured. After thedata is collected and analyzed, a decision is made following one of the following generalthemes:

    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 proceedwith 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 themdirectly, share summarized results, or not share the findings at all. My recommendation is thatyou inform your clients that there is a review process in place for control purposes andsummaries of the reviews will be prepared and discussed with them. These CGRs, coupledwith regular status meetings and reports, help to calm fears and demonstrate a professionalapproach to project management. Let's change gears from in-process reviews to the reviewsthat happen at the end of a project.Post-Project ReviewWhereas CGRs happen during a project, PPRs happen at the end. The project may haveended successfully, failed miserably or been cancelled. Regardless, you still need to collectinformation about it. By methodically reviewing a completed project and identifying theperformance of key areas, teams learn what to do and--just as importantly--what not to do inthe next project.For a person or team who needs to continue where this project left off, the PPR serves as akey summarized knowledge repository. Without the PPR, a new person or team will be forcedto sift through all of the status reports, change notices, etc. to surmise how various thingswent.Many of you are probably saying, "He's just calling a post-mortem a PPR." In a sense, I amdoing just that. However, please ponder one small marketing concept--"post-mortem" literally

  • 8/14/2019 Post-Project Reviews

    2/3

    means after death. A failed project is one thing, but to have a post-mortem meeting after agreat project just doesn't sound good.In terms of the PPR itself, I've seen a number of approaches ranging from free-form text tohighly structured documents. I tend to favor checklist approaches that fall in the middle anduse 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, stakeholdersand the sponsor. The core team, stakeholders and sponsor will have different perspectives onthe project, and it is worthwhile to solicit their input. With this in mind, you should structureyour PPR questionnaires to ask the appropriate questions for the audience involved.Core Team PPRAn internally focused PPR is aimed at the core project team. It should be done first to identifypotential issues and resolutions prior to moving outside the core team. To clarify, it is better todiscuss potential issues here than to go straight to the stakeholders and sponsor and be

    surprised.Stakeholder PPRAfter the core team PPR is completed, move on to the stakeholders. As they are very differentfrom the core team, I recommend a different template. Be sure to focus on the project fromtheir 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 readilyunderstandable. The intent is to learn from these people, not confuse them!Sponsor PPROnce the core team and stakeholder PPRs have taken place, then meet with the sponsor(s). Irecommend doing the reviews in this order so the risk of a surprise is lower plus you will havemore information should the sponsor elect to ask questions.

    In terms of recording the answers, you can use the same template as the stakeholders orgenerate your own tailored form. Whether you use the same stakeholder template or create anew one, be consistent so you can compare reviews across projects.Overall Review RecommendationsReviews are positive events and people must realize this. To be viewed as such and notdespised 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. Thepoint 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 bothmethods be effective. I have noticed that there does seem to be a benefit to group reviewsduring tough projects because they draw strength from one another and speak more freelyabout what went wrong. If you use group meetings, use a skilled facilitator and segregate thethree groups. Do the core team review separate from the stakeholders and the sponsor(s).People need to be at ease to answer freely.

  • 8/14/2019 Post-Project Reviews

    3/3

    Periodically analyze the reviews, both CGRs and PPRs and look for trends. If you only look atone and not a series, then you have a point value as opposed to seeing scores--and thuschanges--over time.Consider putting the reviews on a secure intranet and make them full-text searchable soproject managers can read the reviews and learn. Remember the old saying: "Those who fail

    to learn from the past are doomed to repeat it."SummaryControl gate reviews and post-project reviews are excellent methods to learn and evolveproject 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 knowledgecaptured and shared with others through the review process.