No one likes to feel like they’ve screwed up. And when we do fail–whether at work, in a relationship, or on a personal goal–our gut reaction is to shut down, push it aside, and forget it ever happened.
But this is the worst thing you can do.
Failure sucks. But ignoring a failed project as a source of future knowledge is a huge mistake.
As Thomas Edison reportedly said,
“I have not failed. I’ve just found 10,000 ways that won’t work.”
In project management, there’s a term called lessons learned, which relates to the formal process of documenting, analyzing, and archiving your failures to turn them into insights.
Lessons learned are a way of ensuring not only that you never make the same mistake twice, but that even when things go wrong, you’re setting yourself up for success.
The Lessons Learned Process: 5 steps to making the most from your failures
In project management, a lesson learned is knowledge gained from the experience of performing a project. In other words, they’re tips, guides, rules, and workflows you learn from experience (or the experiences of others) that help make sure you’re not falling into the same traps over and over.
The problem is that because these kinds of lessons are from an individual’s perspective (rather than hard data), they can be difficult to share in a way that’s easy for everyone to access.
We all don’t have the same context or experience, and sharing that knowledge in an actionable way means having a process and system in place to clarify and provide all the information you’ll need.
Let’s look at a simple 5-step process you can use to capture your own lessons learned.
Step 1: Identify
The goal of any lessons learned process is to identify, document, and prioritize opportunities for growth based on the experiences of previous projects.
Most commonly, this starts with a lessons learned session—a structured event with your team (or on your own) where you go through what happened and look for opportunities to document.
Put together a short survey that digs into specific areas you’re going to discuss and asks three questions for each one:
- What went right?
- What went wrong?
- What needs improvement?
Step 2: Document
Now that you know how you’re going to identify and capture lessons learned, it’s time to document them in a way that’s clear and actionable.
This means doing more than simply typing them up in a file and hiding them away. Remember, the goal is to make actionable changes to your processes and workflows, not just tick another box.
Start by asking what went right with your project. Write these down on sticky notes and put them up on the wall where you can see them.
Next, move onto what went wrong. Don’t get too negative, but be honest about where you messed up.
Next, rewrite these statements as future advice or guidelines.
For both what went well and what went wrong, make sure they’re expressed as advice for future projects rather than passive or past-tense statements. This might mean asking “why” again to dig into the actual process rather than just what happened during that project.
Step 3: Analyze
Now that you’ve collected your lessons learned, you need to determine what you’re going to do with them. This part of the process involves analyzing, organizing, and determining how you’re going to disseminate lessons learned with the rest of your team (or store them for future use).
Here are a few of the most common options you can choose from:
- Detailed report: This is a “project case study” that goes in-depth on your findings and presents responses gathered during your session organized by key fields.
- Summary: For shorter or more focused sessions, you might use a one-page brief summarizing the findings and providing recommendations for correcting the findings.
- Findings: Even more succinct is to simply summarize the issues found during the review process.
- Recommendations: Finally, you can translate lessons learned to recommendations. These could become issues in your product backlog or suggestions on ways to change your current processes and workflows.
Step 4: Store
There’s no point in going through this process if you’re just going to hide these lessons away and forget about them. Instead, you need to store them in a way that’s accessible to you and anyone else who could learn from them.
Here are a few examples:
- Make lessons learned easily accessible. If you’re using a shared resource, make sure you have a clear structure in place and rules about what needs to be included in each lesson for it to be actionable.
- Create actionable next steps or suggestions. Speaking of actionable, lessons learned are more about moving forward than reflection. A good bet is to turn each lesson or statement into an issue that you can add to your product backlog or future sprint.
- Revisit regularly to make sure these changes have been made. Lastly, assigning issues to specific people and setting deadlines means your lessons learned get followed up.
Step 5: Retrieve
Lastly, your lessons learned process needs to include a process for recalling and retrieving this data.
This probably won’t be the last time you work on a project or goal that has overlapping requirements with the one you just reviewed.
The next time you’re working on a similar product, or with an identical workflow, or with the exact same team, you might want to stop and ask yourself: What happened last time and how can we do it better?
Don’t waste the lessons that a failure can teach you
Capturing lessons learned is important—but it’s even more important that you don’t view it as the end of the process.
A large part of getting better is having the ability to go back, again and again, and think about how your successes and failures can help you make every project your greatest hit.
So take the time to formalize the process for capturing your lessons learned instead of waking up in the middle of the night wishing things had gone differently. Treat your losses as an opportunity to improve your chances of winning in the future.
With the right lessons learned process you can expand your perspective on how to successfully execute any project.