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.