Lessons learned workshops aren’t fun. Because you always make mistakes in projects. And during a review you often think “We could have done this better”.
But taking a critical review of your project is actually a good thing. Because if you take the feedback to heart you become a better project leader.
In this article you’ll find everything you need to know about lessons learned. What they are good for and how to conduct an actual workshop.
Table of contents
- What are lessons learned?
- Why do a lessons learned workshop
- How to conduct a lessons learned workshop
- Workshop rules
- Building a lessons learned database
- Why you should continuously ask for feedback
What are Lessons Learned in Project Management
Lessons learned are an informal conversation where you look at a project in retrospect. It is done after project completion, usually conducted as a meeting involving the project manager and key representatives from customer and contractor side.
I have also done lessons learned with the entire project team. This is even more insightful but it requires more organization (How organized are you?).
During the lessons learned meeting everyone shares their perspective on what they thought about the project, what they would have changed, what they learned and what could have been done better.
That leads us to the next question:
Why you should have lessons learned workshops
Lessons learned workshops are performed for three reasons: The first is to learn from mistakes and to avoid these mistakes in future projects. The second is to gather best practices — that is smart ways of doing something — and to pass on this knowledge to other project leaders.
The third reason is for trust building with your stakeholders and team members. Involving people in the process and giving them the opportunity to share their perspective will make them more supportive towards project management as well as future projects.
That being said it should be clear that lessons learned workshops are not (just) a forum for people to vent their anger. Sometimes you might get this impression when people are being very negative. But a project review should always be about sharing helpful and constructive feedback and ideas to become better.
How to conduct a lessons learned meeting
Let’s look at the typical process for a lessons learned workshop. The process differs depending on the number of attendees:
- When you run the workshop with your entire team, you have team members gather ideas in small groups and then present the findings at the end of the workshop.
- In a lessons learned with only a few attendants though, you will just discuss everybody’s conclusions without any presentation.
The challenge in such workshops is that people will be relatively reserved to give candid feedback. They are afraid of coming across too harsh or to hurt anybody’s feelings, or even to be disadvantaged in the future. What usually breaks the ice is when one person steps up. Then others will follow and share their criticism openly. That’s the kind of atmosphere you should encourage (even if it’s painful).
If you believe it will be hard to get the attendees to open up, consider planning some discussion points in advance. Like, putting in a few self jabs to show humility and humor. And to show others that being self-critical of both themselves and their team is accepted. Also, if you have the relationships in place to do it, consider having a few “plants” in the audience who will chime in with pre-rehearsed lessons learned or comments. This will help to get the ball rolling for the shy people.
STEP 1: WELCOME THE TEAM
Start off by welcoming the team. Then move on to explaining the purpose of a lessons learned workshop. You should have gotten enough ideas from this article.
STEP 2: EXPLAIN THE RULES
Next, explain the meeting rules. You’ll find them further below. Attendees should understand they are supposed to be constructive, whether they liked the project or not. Everybody is asked to give their feedback on the following questions:
Lessons learned key questions:
- What was done well?
- What didn’t go that well?
- What did you learn?
You have to decide how to record the results. In a small group you would just enter the feedback in an Excel sheet. With a larger audience, you would normally use flip charts or white boards where team members record their thoughts. Irrespective of the tool you always use a 3 column structure: column 1 = what went well, column 2 = what didn’t go well and column 3 = learnings.
Something like this:
STEP 3: GATHER FEEDBACK
Now that everybody knows the process, they can get to work and write down whatever is on their mind. Of course, you as the project manager are not excluded from the process. You should also take the opportunity to reflect on what went well and what didn’t and document your thoughts.
STEP 4: PRESENT FINDINGS (LARGE GROUPS ONLY)
If you are doing the lessons learned with the entire project team, have one or two team representatives present the results in a summarized form. They will briefly go through all notes and talk about the most frequently mentioned points: Many team members said they were unhappy with the way the product training was done. The 1-day training apparently was not enough, so people mentioned they didn’t feel well prepared for the project. OK, hopefully you will also get positive feedback.
STEP 5: CLOSE MEETING
After everyone was able to share their feedback and you’re done recording it in an Excel sheet, it’s time to close the meeting. Say a few kind words and thank the attendees for their participation. You should also point at how the feedback is going to be used: ‘We will take your feedback into consideration for improving our future projects, especially when it comes to <specific criticism>’.
Rules for a lessons learned meeting
- Don’t constrain people on the questions. Let them tell you what they want to tell you.
- Everybody can share their views openly.
- There is no good or bad feedback. Any feedback is appreciated.
- Avoid personal attacks or naming names. If somebody wants to complain about a specific individual, they can use the title instead, e.g. saying ‘the head of logistics’ instead of Brian Johnson.
Going into the meeting with the right attitude
I want to help you with your mindset for a project review. Suppose you are the project leader and you are going to have your first lessons learned workshop. Then there are a couple of things you should keep in mind.
Don’t dwell on past mistakes: You may be thinking a lot about problems that have happened in your project. A conflict with a stakeholder or a critical step you forgot to take care of. Although this is understandable, it is also not very helpful. I suggest you accept whatever bad things have happened and focus instead on things you have learned (and the things that went well).
There will always be people criticizing: Even the best and most respected project managers face criticism. That’s because projects always trigger controversy and resistance from people in the organization. Therefore, it is natural for people to tell you what you should have done differently. Dogs will always be barking 🙂
Be open to learn: Accept you may not now the best approach for everything. There may be better ways to plan or to conduct certain project tasks. If you’re will to learn, you will become better. And that’s the key. Lack of willingness to introspect is a clear signal project failure is ahead. Read about all the 7 signs why your project might fail because of you.
Lessons Learned Examples (and what to do with the results)
The whole point of a lessons learned workshop is to learn. To become better. As a project manager and as a team but also as an organization. This learning effect only materializes when action is taken in response to the lessons learned. The type of action depends on whether it concerns only you, your team or the entire company.
Lessons learned for you (project manager):
- lack of PM support during client negotiations: If your team feels you could be more supportive in situations involving the client, you need to be more available and take over leadership in such situations.
- team praises your motivational skills: great job, keep going. Nothing to change here.
- functional expert complains about having been informed too late: True, you could have reached out to the guy 1-2 days earlier. But you were so busy with another issue so you totally forgot about that guys task.
Lessons learned on team level:
- lack of team spirit: This is a criticism that’s often raised in newly formed teams. One way to approach this problem is by organizing a team event where team members get to know each other.
- knowledge sharing: A problem when junior team members don’t get enough support from senior experts. The issue can be overcome by defining senior experts as mentors of the junior workers.
- lack of a specific expertise: Assume you are going into an IT project in the oil and gas industry, but you don’t have anybody on your team with oil and gas industry knowledge. That’s bad, and it will lead to all sorts of awkward situations which in the end the team will complain about.
Lessons learned on company level:
Some of the lessons learned may even require action on company level:
- no organizational alignment: Each department has its own set of objectives and priorities, but the leadership of the different departments often don’t seem to be aligned with one another and/or the upper leadership – leaving a messy situation at the project team level due to the conflicting priorities. This lack of alignment is something to be taken up on management or even CEO level.
- poor corporate culture: Project issues caused by a poor company culture, e.g. one that relies on blaming and imposing fear on employees always have to be solved at the root. Corporate management or the owner of the company have to initiate a cultural change that creates the kind of environment where people are willing to take over responsibility without fear.
- corporate travel policy: A company’s travel policy could be too restrictive, for example requiring employees to stay within a $70 per night limit for accommodation. Such restrictions can make a business trip even more challenging and unpleasant as it already is. Maybe the company should revise its travel policy?
Taking it a step further: A lessons learned database
It’s ok to make mistakes. But you shouldn’t make the same mistake twice. This common sense rule is also the idea behind a lessons learned database. In such a database organizations record all their insights and best practices taken from past projects. This way, the information is accessible to everybody in the organization, and project leaders can use it to avoid pitfalls in their projects and apply methods that have worked well in the past.
How do you create a lessons learned database? It can be as simple as having project reports created as Word file and storing them in a (searchable) shared drive. A more advanced solution would be using a dedicated system like Sharepoint or MS Access to store project details. The users could query the system using keywords and the database would return relevant search results.
For ease of use, the database should support full text search instead of relying only on pre-defined keywords or title descriptions, which may not be as meaningful and clear.
The project reports in a lessons learned database don’t need to be too elaborate. A half-page project management summary and a writeup of the challenges (what didn’t go well), best practices (what went well) and learnings are enough to give project managers an idea of what a past project was like.
Useful tools for building a lessons learned database:
- Atlassian Confluence: A commercial Wiki solution for small and larger teams
- Mediawiki: A free open source Wiki solution
- Microsoft Sharepoint: document management solution
My advice to you: Always ask for feedback
One important advice I want to give you is to solicit feedback throughout the project, and not just to wait til the end. In project management, you have to respond quickly to issues, and you always want to improve your process so you get optimum results.
The way I collect feedback is to continuously talk to my team: How is this thing going? Are there any issues? Anything we should be doing differently next time? This way I instantly know what areas we have to improve upon and I can take immediate action and course-correct.