How to Run a Lessons Learned Meeting

It should be mandatory at the end of every project – and if possible at the end of every phase –  to run a lessons learned session. And not only run it, but make sure that it’s documented and – unless highly sensitive – available to all future projects. Here’s how to do it:

–Be sure that you have an agenda. People hate to come to meetings and not know what is being discussed or for how long.

–Invite the right people. Do whatever you can to schedule this so that key stakeholders are available. If some are available remotely, or by Skype, fine. Better they attend that way than not at all.

–Meet as soon as possible. Memory is a fleeting thing. People forget. Strike while the iron is hot and meet no later than two weeks after the close of the project.

–Keep it short. In addition to running my own sessions, I have solicited input on this from many students. The great majority advise me they can run a lessons learned session in 1 – 2 hours.  People hate meetings. Keep it short.

–Solicit input prior to the meeting. This can help you weed out what’s important to discuss and look for common themes.

–Provide multiple ways of “attending.” Some people are flat-out just too busy. Can you set up a poll? Or have them email you information? That way their voices are heard and recorded. They feel like part of the process and their thoughts are not excluded.

–Don’t get sidetracked. It is easy for meetings of any sort to get derailed. If, for example, there is a technical issue, some team members will be inclined to want to discuss and solve that problem. You need to remind them that that is not the purpose of the meeting. Have a “parking lot” flip chart for issues such as this that arise. Then these can go on your issue log to be dealt with in a separate session.

–Set the tone. You want to make it clear that this is not a finger-pointing exercise. All you should care about is what didn’t go so well and what can we do better

–Keep good minutes. Team members are going to make observations that are crucial. Keep track of them and make sure that you record – and follow up on – any action items

–If necessary, have a facilitator. Strictly speaking, in most cases there’s no reason this session cannot be run by the project manager. However, sometimes there is bad blood between departments or stakeholders. In that case, bring on a consultant or someone from the PMO to defuse the situation.

–Work the issue, not the person. If it turns out that a lot of problems point back to one department or even one person, make sure to reinforce that this is not a blame game. Any good functional manager will probably long since have recognized the problem she has. If no corrective action is taken post-meeting, meet with the functional manager and/or escalate to the sponsor.

–Acknowledge your own imperfections. You’re not perfect. Acknowledge that you could have, e.g., published the schedule in a timelier fashion. If others see you willing to be self-critical they will be more willing to come forth.

–Document and distribute. I have met far too many people who, after running the meeting, put the document in a drawer, never to be seen again. Circulate it for comment then put it in a centralized repository for consideration by subsequent project teams. Each project has new challenges. But there is no need to reinvent the wheel.

–Write up some questions. You need to ask, at least, these three questions:

1. What went well?
2. What didn’t go well?
3. What might we do differently next time?

Make lessons learned sessions a habit. Otherwise you will continue to treat every project as brand-new and never be able to continuously improve.