If you heard that holding a one hour meeting would increase your project success by 10%, would your team do it? After all, time is precious and meetings can easily turn into a waste of time for everyone. Meetings should have some true value to invest your time… yes?
Lessons Learned
This is a short meeting with only three simple agenda items and is conducted immediately following a project (while the experience is fresh).
- What went right?
- What didn’t go so well?
- Suggestions for improvements?
The Lessons Learned meeting is moderated by one person, often a project manager, and is attended by the full team (whether in person, by phone, or by video).
Careful note taking is highly important. It’s useful to take notes with a projector so attendees can see what is being written and can give the note taker feedback, such as, “that isn’t really what I meant,” or “you’ve got the main idea, but technically it isn’t quite right.” Typing comments on the spot also helps remote attendees who may be screen-sharing to follow along and cuts down on critical post-processing time (more about that later).
Advance preparation for the meeting is also very useful. Appoint someone as the team “reporter” or “spy” (choose any name you like if it adds a little excitement!). As the project unfolds and something notable takes place, the “spy” adds this to a running log. Review the log at the end of the Lessons Learned meeting to ensure the team hasn’t forgotten a key point or event. The log review is best at the end of the meeting. Why? It’s helpful to let the most memorable events come out first. Those events are often the ones with the most impact.
Meetings like this can start a little slow. We’re often already busy thinking about the next project(s). It’s important to get the creative juices flowing. The moderator should prepare a couple of items to post at the very beginning of the meeting to get the group “in the mood.” These can be the moderator’s own thoughts or ideas from a preview of the “log” or even just something funny like “we’re never ordering pizza from THAT place again!” Anything to get the group engaged. Much of the value of this meeting is created by comments heard by team members that spark another, perhaps unrelated, but potentially important thought. One of the key jobs of the moderator is to keep the conversation moving and “lubricate” the discussion.
The selection of the moderator is actually very important. This is a group discussion. Getting the most out of a group discussion is not necessarily so easy! Hopefully, the team’s manager(s) or project manager has gone out of their way already to create an atmosphere of trust and personal safety so everyone feels free to speak. If that hasn’t happened, it might be a good thing to list under “what didn’t go so well.” There may be a member (or more) with “large” personalities that tend to dominate discussions. It’s highly important that we get the ideas from all. Less powerful personalities may need a little encouragement to speak, but their ideas might contain the most important lessons of all!
The idea of “feeling free to speak,” means that not all ideas will come out in the group meeting. It’s best if they do, because engaging the entire groups’ creativity and experience increases the quality of the results (as in so many endeavors). However, some comments may be about management, or a team member may feel they can’t say an important point in a way that won’t destroy the group cohesion, or it may be an embarrassing personal admission (with truly great group dynamics, even these can come out). The moderator should add a point at the very end, “if you have any more thoughts after the meeting, please feel free to contact me.” The moderator may even want to seek out a team member or two if there were signs a member might be “holding back.”
This also isn’t about reaching perfect agreement. An idea you record might be useful for some and not for others in the next project. Don’t lose an opportunity just because not everyone agrees. It might even be useful to add a phrase to the notes like, “only about a third of the team agreed with this point” (and perhaps even, why).
By the way, resist any attempts by upper management to turn these meetings into a “witch hunt” to discover the guilty and punish them! Lessons Learned is all about making our teams stronger. To err is human, but to learn from our mistakes is truly divine!
So far, so good. Your “spy” has kept a log of items as the project unfolded, you reviewed those items at the end, you took great notes, everyone felt free to speak, lots of ideas came out and the moderator lubricated the flow of the groups’ creative juices! You even got a couple more comments a day or so later as people thought of “one last thing.”
All done, right? Nope.
The team invested this one hour to get the ideas out. Now, how will those wonderful “Lessons Learned” become lessons that other projects and future teams will not need to uncover? The whole idea is to keep from “reinventing the wheel” or “encountering the same pitfall that other teams did.”
How do “Lessons Seen” become “Lessons Learned?”
Part of the success of a Lessons Learned meeting is good “post production” by the note taker; reading through the notes one more time to be sure everything is clear (wait 1 day). Pay special attention to how an idea is described. Try not to use “team shorthand” that may be clear today, but won’t make any sense a year from now or to some not on the team. Imagine explaining the information to someone who never heard of this project or even the particulars of the technology being used. Are the ideas described in ways that are easily understood by others?
The notes also need to be concise. Try not to ramble on and make the document any bigger than it needs to be. You’ll see why this is truly important in just a moment.
These Lessons get their greatest value when all teams learn from them, before a project starts!
Wow! How to do that? Two essential pieces are needed.
First essential: Lessons Learned from all teams need to be in a central, known repository.
Lessons Learned shouldn’t be hard to find. Organizations often file the Lessons Learned with the project, which is fine, for a copy. For maximum value, all Lessons Learned need to be documented in a central, known place. Why? To benefit from this hard-won knowledge, people need to read it!
Second essential: A little process. Teams need to review all Lessons Learned before the next project starts.
Now, you see the value of those concise notes! Ideally, Lessons Learned should fit on a single page. Each new project team designates someone to review all the Lessons Learned on file. Often, this will be a project manager. Whoever does this is responsible for noting items that might be relevant to the current project and letting the team know at the beginning.
You might think, “Wow! Read every freakin’ (yeah, that’s a technical term) Lessons Learned from every project we’ve ever done? OMG (Oh My Goodness), we’ll never be able to do that! I’m not even going to start!”
Let that become a problem, if it ever does. Believe me, getting started down the path of adding a highly-effective process at the end of one project and the beginning of the next will take a little time to gather steam. If and when your central, known repository of concise Lessons Learned becomes so big that reading all the (hopefully) one-page summaries of valuable Lessons Learned takes too much time, then you will know it is time to summarize a year’s worth into one, neatly organized, concise document. Use this opportunity to throw a big party, celebrating all the success you are now enjoying because teams don’t keep repeating the mistakes of the past and instead are using the great ideas from teams all over your organization!
How does this work at Go Daddy?
When I came to the company in August, 2011, Lessons Learned was already known and being practiced to some extent. Preparation for our Super Bowl commercials is a big deal at Go Daddy. We spend a lot of time ensuring our systems can handle the influx of traffic. There are design discussions, capacity planning, new infrastructure, new code, and load testing to tune our systems.
2012 was our eighth time airing a Super Bowl commercial. When all was said and done, we did a Lessons Learned and found there was no central repository for documentation of this annual project. I was only able to locate one summary, from 2008. We didn’t make it a priority to review previous documents. However, following this year’s project, we started a “Lessons Learned roundup.” We are trying to find all the documents from past events and get them into a central repository, and as we approach next year’s project, we’ll take some time to read previous Lessons Learned, looking for hard-won, good ideas from the past. So, each time, we will get a little better, a little smarter.
Is this worth it?
I believe so. I’ve been managing projects since 1975. I’ve seen many come and go. If done carefully, there’s no big investment of time; a 1 hour meeting, less than an hour to review and summarize the notes, a central file share, and just a little time reviewing before starting an important project. For professional project managers especially, tuning up their game by periodic review of other teams’ lessons makes a lot of sense. It’s not so bad to prevent ever saying, “Dang! I think we made that same mistake on a previous project!” and instead be saying, “Hey! That’s a pretty smart idea from that other team!”
If you have some good ideas from your own experiences about Lessons Learned, please, please add them as comments to this post! There’s no shame in sharing your pitfalls and the good ideas that have come from them if it means we are all more successful together!
Excellent article Marc!
What would be great is if the central repository for Lessons Learned had 2 parts. Part 1 is for Global Lessons learned – things that apply to the majority of projects. Part 2 would be for project specific lessons learned – these would be the items that would apply to future phases of this project or projects very much like this one.
It would be most beneficial if users could search for the global lessons learned, then also search for lessons learned based on team/project type/project name.
Mr. Franke,
This is an excellent article. I have facilitated many of these meetings in the parallel universe of the nonprofit world. Dynamics are slightly different, however, with board members, sponsors, donors, staff and volunteers at the table. We called it “processing”,” downloading”, or” the wrap up meeting’” after major events ( a major 10k run, a black tie affair, a 24-hour telethon). It is helpful to hear about the event from other perspectives, while it is still fresh, even the surprises (“I didn’t know the Board Vice President lost his wallet in the parking lot after the event !”) Of course, with Twitter, Chatter and FB, I would imagine the communications are much better in real time during events now.
“Lessons Learned” are useful in higher ed, too, but not in the way you would think. I have lead /instructed this type of process at the University level in service-learning for scholar/ honors seminars. In higher education, it is called “Reflection,” and is often a personal, journal-based written document of ones’ internship/research project as it unfolds, and how that project experience meets the student’s expected goals or not. So the good news is, as more universities are encouraging this service-learning- reflection model, the new graduates will already understand the foundational idea behind “Lessons Learned.”
I also think the “Lessons Learned” Process is inherent to –and probably would be applauded by- Tony Schwartz’s Energy Project. Although I am reading his book again and not affiliated with him, I have thought for a long time that the constant, reactive “put the fires out” mentality of the workday is what drives most of us out of the office temporarily…or permanently.
“Lessons Learned” reinforces the GOOD stuff that happened, too, in a proactive way, so there is less to “reinvent” and hopefully, fewer fires to put out during the next project. Quite a beneficial use of time and energy and resources, I think.
I would agree, the facilitator’s role is critical. He or she needs to be aware of the emotions these meetings can stir up, like ego (“wasn’t MY input on the project the best?”), or fear (“who wants to tell the big donor –whose son owns the pizzaria– that we won’t be ordering from THAT place again?”) or dollar driven anxiety (“will MY portion of the project be funded next time?”). The facilitator must encourage a safe, open minded approach for all, be firm but lighthearted, and recognize the ego-fear-anxiety territory, steering the group back to the healthier goal. If we keep the observational, reporter-like quality of conversation, ( i.e., Brian Williams Nightly News, not Meet the Press!) we can gather the facts, sort out the details, and make more effective decisions for next time.
Good enough for HBR. Thanks for sharing this. I will put a link to my weblog and with more thoughts.
Hi, I was wondering if anybody has a good approach to run a LL session over the phone/netmeeting. I need to facilitate a session for a project that has closed done pre-maturily so it’s key to capture those sensative learnings that lead to the project closing. So far I have only done one-one interviews and group sessions.
Hi,
I’m just preparing for a lessons learned session and ran across this article. Great stuff! Love the advice about keeping the notes of all lessons learned in one place. And having a “spy” next time for sure!