While termination activities may seem like a low priority when developing a project workplan, they should be viewed as vital components of a project, not as an afterthought as the team disbands.

Some of the activities to consider at the end of a project include:

  • Declaring success or failure
  • Transitioning the solution to support
  • Archiving the project files
  • Conducting performance reviews
  • Reassigning the remaining project team members
  • Holding a project conclusion meeting

A project conclusion meeting is an opportunity to reflect on the project and examine what can be learned that will help the team members and other project teams in the future. Here’s how you might structure one.

The project conclusion meeting
Just as you would begin your project with a formal kickoff meeting to signify that the initiative has officially started, the project should officially end with a project conclusion meeting. If the project had major problems, or if the project was cancelled, sometimes these are called project post-mortems. There is value to be gained from this meeting, whether the project was a success, a failure, or something in between.

You can plan the meeting in a number of ways so that it is as effective as possible. To make for a better meeting, you may choose to:

  • Use an outside facilitator. Many times, the group is more comfortable if there is a meeting facilitator from outside the team. This is especially true if the project experienced problems. You can get a more truthful discussion if the facilitator doesn’t have a stake in the outcome.
  • Make sure everyone knows the purpose of the meeting. This can be communicated clearly ahead of time to all of the participants.
  • Send out an agenda ahead of time. Your time will be better spent if everyone is prepared ahead of time and knows the discussion topics.

Everyone needs to understand that team members are there to learn both individually and collectively. Don’t treat this meeting like a performance review. All participants need to feel safe to expose what they did and thought so that they can learn how to be more effective.

Focus on what happened vs. what was expected
You won’t discover what to improve unless you know what you achieved vs. what you originally wanted. First, have a frank discussion to list the things that should have happened on the project. For each goal, add a corresponding statement regarding what actually happened. You’re not only looking for problems. If important events actually happened as planned, note them as well.

If the project had problems, it’s easy for the discussion to turn negative. Try to keep the discussion positive. If different people have differing views of what happened on the project, try to find common ground for consensus. Remember that there is not necessarily a right or wrong. You’re trying to gather perceptions. It will help if people focus on the activities they actually participated in, rather than guessing about those in which they were not involved.

Ask why
After you list what actually happened on the project, prioritize a smaller number of important areas to focus on. For each of the remaining items, start asking why things turned out as they did. Again, in some cases, you may be focusing on areas that didn’t turn out as you expected.

I remember applying this process on a project in which the major deliverable was supposed to be completed in four months but it took nine. That was obviously not what was expected. After a series of “why” questions, numerous lessons were learned, including these:

  1. The programmer didn’t do a good job of capturing requirements, so there was a lot of rework once the initial deliverables were shown to the client.
  2. The client sponsor insisted that the deliverables be close to “perfect” before being released. The team agreed afterward that the better approach would have been to implement the solution much earlier with 80 percent of the required features rather than waiting for nine months before the “perfect” solution was ready.
  3. The client had a hard time focusing on the work, and could only spend time on testing every three or four weeks. If changes were required after one set of tests, it might take three weeks for the client to retest.
  4. The programmers did a poor job estimating the work. Whenever the client wanted a change, the programmers would say “no problem” and then it would take them a long time to implement the changes.

This was not the first time these problems occurred on a project. However, it seems sometimes you need to experience them for yourself before the lessons really sink in.

Lessons learned for future projects
To be effective, the discussion next needs to be translated into general observations and key lessons that the group can use as guidelines for the future. Although the unique set of circumstances that caused events to happen as they did on your project may not occur again on any particular problem, the team should be able to generalize what happened on this project into a set of lessons that can be applied to many projects in the future. These lessons learned should be documented formally and distributed to all team members. If you have a group (such as a PMO) that keeps a repository of project lessons learned, these insights should be forwarded there as well.

As “lessons learned,” the insights are of most interest to the project participants and to others who embark on similar projects in the future. As the PMO receives many sets of “lessons learned,” the PMO may also be able to come up with a smaller list of organizational “best practices” that will be of help to all projects in the future.

The end-of-project meeting is a great opportunity to formally wrap up a project. In addition to signaling that the project is completed, it’s also a time to see what lessons can be learned for the future. You don’t want to discuss lessons learned right away. Instead, describe what you wanted to happen, what actually happened, and why. Then you’ll have the context to start talking about what lessons you can take forward.

The project team can internalize the lessons learned and apply them to future projects. The lessons learned from all projects can also be consolidated on an organization level to develop a smaller number of best practices that can be applied to all projects. This allows the entire organization to take advantage of these common lessons.