Reviewing the Process

A “lessons learned” review allows you to learn from the process you have been through and helps you find ways to improve your project management. Because the project process should be repeatable, the main purpose of review is to establish what went well, what could have gone better, and what you can do to improve future projects.

Looking back at your project

The review process is your chance to learn from experience. It is not just about spotting errors or identifying parts of the process that did not run as smoothly as they could have—evaluation of what was successful is equally informative. If something worked particularly well (such as a technique or a supplier), it should be noted for future reference.

However, inevitably there will be some things that go wrong in your projects, and these also provide valuable lessons for the future. Although they may have been unforeseeable the first time they occurred, by taking the time to understand what has happened and why, you should be able to gain insights that would otherwise be missed, and take action to prevent their recurrence in future projects.

Planning projects for learning

Table

Fast track	Off track
Establishing quality assurance procedures from the outset	Allowing an experienced project team to perform their roles out of habit
Giving personal learning objectives for the project to all team members	Being cynical about the organization’s ability to do things differently
Including “lessons learned” as a regular agenda item for meetings	Considering change a threat to what has been successful in the past
Having a team culture characterized by high levels of feedback	Allowing a blame culture, in which it is dangerous to admit mistakes
Establishing mechanisms for disseminating new ideas	Holding the project plan centrally and discouraging discussion of its details

Learning from the details

When reviewing the project, consider all aspects of the process in detail. Do not rely on opinions about what went well or make assumptions about what went wrong: talk to those involved and try to discover the facts. When these are in dispute, ask for evidence. Be curious about why things happened, and explore how this could inform future project decisions. When searching for the truth, be sensitive to the feelings of those involved: reviews should never become witch-hunts.

Once you have a good understanding of how everything worked, make sure that you act on your findings. Project learning is done for a purpose—to improve performance on future projects. Don’t keep useful information and ideas to yourself—pass them on to where they can make a difference.

Holding a project review

A “lessons learned” review meeting is your opportunity to get the team together and discuss how the project went. Hold the meeting as soon as implementation is complete—you can always call a second one, if necessary, once the project has been embedded. Far from duplicating effort, you will find that you actually save time using this approach, because memories are clearer and conclusions are reached more quickly.

Involve as many stakeholders as is practical in this meeting. A process review should take account of the views of everyone involved, within the constraints of cost, time, and availability. If possible, include the views of the client and end user, although in commercial projects, you may need to think carefully about how you are going to get these.

Be clear on what you want to achieve and have an agenda for the meeting. A review meeting can become unfocused and descend into generalizations unless there are specific items to discuss. If you have held interim learning reviews, use the notes from these as a structure. If not, then the PID, plan, and risk logbook can be a good basis for discussion.

What can we learn from this project?

• How good was our original scope?

• How accurate were the time and cost estimates?

• Did we have the right mix of people on our team?

• How effectively did the stakeholders work together?

• Where might we have anticipated risks better?

• How effectively did the technology we used perform?

• How well did our project methodology work?

• What project documents were most useful? Which, if any, were missing?

Documenting your review

Brevity is often the key to a successful project review document, so record the recommendations that you generate following the “lessons learned” review meeting succinctly. Aim for three key learning points clearly described so that anyone encountering a similar problem in the future can implement your recommendations. If you have to write more because the project was large and complex, structure the document in a way that enables people to gain an overview quickly and then select only the detail that is relevant to them. It can be useful to generate a main document that you distribute to all stakeholders—containing a limited number of key recommendations for the conduct of future projects—and a number of annexes. These can either cover each recommendation in detail or provide more detailed feedback to specific individuals or departments.

Discuss your recommendations with the sponsor. Even if the sponsor does not want to be fully involved in the review process, at the very least you should discuss the findings with him or her before disseminating them to a wider audience.

Giving personal feedback

The review phase of your project should also look at the performance of individual members of your team. Although you should have been giving regular feedback throughout the project, people appreciate a final review once it is completed, especially when they’ve put a lot of effort into making a project successful. You will find that the best workers use feedback from project reviews as a way to build their resume or gather references. Equally, people will be more likely to make a second effort if they know that failure will be investigated and recorded.