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?
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!