Written by Colleen Berish
Call it what you want – look back, reflection, retrospective or post-mortem – but an effective lessons learned session is sometimes harder to come by than most people realize.
During most projects, best case is that people are able to identify problems or roadblocks and fix them quickly; worst case is most people are heads down in the actual work and don’t stop to think about what might be going wrong or what might work better. Or somewhere in between. For longer projects or multi-phased projects, lessons learned sessions can make the difference between future success or status quo.
Holding a Lessons Learned session has many challenges. There is always the danger that it will deteriorate into a complaint session or that people only remember what happened in the last week or two of the project. Successful lessons learned sessions are held with some degree of frequency throughout the project, include all working members of the team, even if individuals have moved on to other projects and be an organized part of the overall project plan.
1. Capture in the moment
Use google docs, company wiki, outlook task or note, email to yourself, running list in a spreadsheet or even writing in a special notebook for those of you still like pen and paper. It’s important to capture the details of what happened, why it was good or bad, the impact of the event and how to avoid it or promote it for the future. Otherwise, you might end up forgetting, exaggerating or blaming.
2. Encourage openness
The only way the feedback is valuable is if people are encouraged to be honest and open about how something went. If someone really feels like they can’t speak up, you probably have a bigger problem.
3. Plan ahead
Outline the lessons learned process at the beginning of the project so the entire team understands how the information will be used. Define the timeframe (every three months we will have a lessons learned), the structure (identify an event and the impact) and how team members should capture the information (see #1).
For the actual meeting, provide a summary of common comments, solutions or tasks that should be entered as future best practices. Don’t call out any one individual’s comments. Center the discussion around the summary points.
Have the team figure out solutions and how to best implement, then assign tasks. Get buy-in and commitment from group to do what will make the project better. Lessons learned only work if you actually use what you learned (duh!).
It’s also important to communicate best practices to a larger group or team. Depending on the size of the organization, many lessons learned can be packaged for other teams. Try to keep tools and summaries in a central place for future reference.
My own personal experience with lessons learned came from working on several high-profile corporate initiatives in a busy IT department. As a participant, I witnessed several sessions degrade into angry finger-pointing sessions. As a first time Quality Assurance (QA) lead on a highly visible project, I set the expectation at the beginning of the project in order to get quality feedback. The first time one of the QA’s came to me with a complaint about something, my response was, “please write this down on a document or as a task so that we can make sure it doesn’t happen again.” After addressing whatever issue was causing the complaint, I moved on.
For each iteration (usually monthly), our team got together and discussed issues and what we might change in the future. Then we assigned actions items to those things we knew we could fix, brainstormed mitigations for risks we couldn’t fix and documented everything for future iterations of the project.
In order to solicit feedback that is constructive in nature, I also kept my own list of issues. Sometimes, the items on my list were the result of an emotionally charged confrontation or failure in one part of the project – either a team member or a business partner who wasn’t fulfilling their role responsibilities, personality conflict or an area where I failed to recognize an issue, which then escalated. When I reviewed the list before holding the meeting, several topics usually fell off the list because my temper had cooled down a bit and I recognized that it would not be a productive topic for the look back. However, many of the items on my list also made it onto everyone else’s list which provided the starting point for conversations during the session.
Lessons learned provide a huge opportunity to improve individual projects and institutionalize best practices uncovered during the process. Harnessing the best ideas and suggestions from the team is the easiest way to get good results for the future.
Colleen Berish is a former IT Business Analyst and a content contributor to the BABOK 3.0 effort. She currently uses her analysis and technical writing skills in the world of corporate learning and development. Learn more about Colleen from her blog or website: https://cllnberish.wordpress.com or berishbusinesswriting.com.
Powered by Facebook Comments