Jory MacKay on January 29, 2020 What to Do When a Project Fails: How to Document and Share Lessons Learned
Not every project goes as planned. And while it’s great to celebrate your wins, the best teams (and project managers!) know it’s just as important to dig into your failures and capture lessons learned.
Unfortunately, when a project fails, the last thing most people want to do is dig into why it did. Failure sucks. But whether it’s pride or future deadlines that cause you to turn a blind eye, ignoring failed projects as a source of future knowledge is a huge mistake.
Even at a massive company like IBM, only 40% of projects successfully hit all their criteria. But the other 60% is where they learn how to improve and update their processes, communication styles, workflows, and goals.
The issue is that not everyone knows how to properly document lessons learned. Sure, it’s easy enough to write down what you thought went wrong. But without a formalized way to document, analyze, and archive lessons learned, it’s impossible to make use of these insights.
So how do you turn your project failures (and wins!) into tools for future success?
In this guide, we’ll cover a simple process for capturing lessons learned as well as provide a customizable lessons learned template you can use with your own team.
The Lessons Learned Process: 5 steps to making the most from project 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.
As we wrote in our Guide to Knowlede Management, this kind of knowledge is also called tacit knowledge—lessons learned intuitively or from the context of a past project. This means that lessons learned don’t have to just be negative. In fact, it’s just as powerful to solidify positive processes and workflows as it is to talk about what didn’t work.
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.
This is where most companies fail.
It is just as powerful to solidify positive processes and workflows as it is to talk about what didn’t work.
Yes, you understand the importance of documenting lessons learned. But do you have a clear process in place that everyone follows to make the most of that gained knowledge?
Do you have a tool or database where your team knows to look for these lessons or tips?
Do you have a way to turn these lessons learned from tidbits of knowledge into actual workflows that make you more productive, efficient, and effective?
My guess is, probably not.
Luckily, smart companies have been capturing lessons learned for decades and have come up with a simple 5-step way to make the most of your failed projects.
Note: In this post, we’re going to cover a structured lessons learned session that you run with your team. However, there are tons of different ways you can capture and document knowledge from your team from project critiques to storytelling. Learn more about these processes in our Guide to Knowledge Management.
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. But before you bring your team together and open the floor to comments, you need to make sure you’re all on the same page.
There are two parts to this step: Deciding on a process for capturing lessons learned and then preparing for your lessons learned session. Let’s start with the first.
Are you using an integrated or Post-Facto approach to lessons learned?
There are typically two approaches you can take when it comes to your lessons learned process. The first (and simpler of the two) is the integrated approach.
This is where you incorporate lessons learned early, regularly, and consistently throughout your project reporting. With an integrated approach, you set aside time every 3–6 months (or around other reporting requirements) to discuss projects, synthesize lessons, and share them with the rest of the team through an internal newsletter, workshop, or knowledge management tool like Planio Wikis.
The main advantage here is that the lessons learned process is a regular process (meaning it’s less resource-heavy and more a part of your team workflow). However, limiting yourself to just quarterly means you might miss out on key lessons learned from past projects, especially if you work on a faster sprint cycle.
The other approach is called Post-Facto. This is much more complex and resource-heavy as it includes external reviewers and multi-pronged data collection, including interviews, documents, and meeting minutes.
Obviously, this takes more time but can be worth it at larger companies or after completing a project with a serious investment of time and money.
Choosing an approach usually comes down to your team size, project, and specific needs. If you’re a small team using an Agile methodology, an integrated approach probably works better (and can be scheduled around sprints or milestones). Whereas large or more traditional teams may want to invest in a Post-Facto session after especially large projects.
How are you going to identify lessons learned?
Once you know how lessons learned work into your larger product lifecycle, it’s time to figure out how you’re going to actually identify them.
This is where the lessons learned session happens. This is a structured event where you engage with your team and project stakeholders to uncover opportunities for growth and improvement.
A good lessons learned process can expand your perspective and help successfully execute any project.
But as we’ve written before, every meeting benefits from structure and a few rules, especially when there’s potentially negative feedback involved. So to start, you’ll want to get a few things in order:
- Facilitator: Who is going to lead your session? Someone has to take the lead of the lessons learned session. This could be you as the project manager, the scrum master, or someone else. The goal here is to choose someone who will act as a guide and not impose their own bias on the session. The best lessons learned come from a safe space and an environment where people feel like they can speak openly without being punished.
- Project survey: What is the scope of your session? The key to getting the most out of a lessons learned session is to keep it focused and get your team thinking about it beforehand. Put together a short survey that digs into specific areas you’re going to discuss such as project management, communication, resources, technical aspects, testing, and implementation. The most common questions to include in each section are: What went right? What went wrong? And what needs improvement?
- Guidelines for the meeting: How will you discuss lessons learned? Setting guidelines and an agenda for your session helps keep everyone moving forward and not dwelling on issues. For example, let’s say you’re documenting lessons learned during a Sprint retrospective. In this case, you’d make sure everyone knows the time-blocked schedule for the session as well as the specific guidelines (keep things positive, don’t make it personal, focus on actionable insights, etc…)
- Distribution strategy: How will this information become a part of your workflow? Finally, knowing how you’re going to use these lessons learned will help guide how you run the session and engage with your team.
Once you have all these in place, it’s time to set a meeting time, gather your team, and document the lessons learned they bring to the table.
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.
Once you have your team together, the lessons learned facilitator should run through a few steps:
- Revisit the project plan or scope of work and identify any deviations. Go through your project step-by-step and look for places where you moved away from the initial plan. Where did things drag or speed up? What did you set out to achieve and what did you achieve? For each response, ask “why” several times to dig into the root cause of the issue. Often, people don’t fully realize the underlying reason behind failure or success until they dig deeper.
- Ask team members to share “what went well?” With everyone’s memory fresh, go around and ask people to share what they thought went well. The facilitator should write these down either on sticky notes, on a whiteboard, or in a shared doc.
- Ask team members to share “what could have gone better?” Next, move onto places for improvement. It’s important here to identify roadblocks or pitfalls rather than trying to place blame on a specific team member. Again, document these statements.
- Rewrite these statements as 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.
- Collect and document lessons learned in a detailed report. This should include all relevant input from the session as well as suggestions for improvements during future projects. (We cover what this looks like in the example below!)
The goal of documentation is to make actionable changes to your processes and workflows; not just tick boxes.
As we wrote in our guide to creating a successful knowledge base, it’s crucial to offer a standardized process that incorporates the ability to organize, add tags and track changes—and one that’s easily accessible to every stakeholder. A tool like Planio makes it easy to set up and organize all of the information in one place.
It’s also important that leadership is looped in on these findings, including what went right, what went wrong and what can be improved in the future—and how resources can be shifted and maximized to optimize outcomes.
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.
When you first start out, this might just mean sharing your lessons learned with project stakeholders using an internal newsletter or Wiki. However, as your company grows and projects pile up, you’ll want to find other ways to report on lessons learned.
The goal of lessons learned is to make knowledge accessible to everyone at your company. Not just the people on your team.
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.
However you report on your lessons learned, it’s important to make sure everyone understands these are teachable moments, not personal attacks. As Thomas Edison reportedly said,
“I have not failed. I've just found 10,000 ways that won't work."
Step 4: Store
Of course, it’s not just about creating and analyzing lessons learned, but also finding a way to store them so that they’re accessible to the entire team. This is where knowledge management (KM) comes into play.
We wrote an entire guide on how to properly store company knowledge. However, there are a few key takeaways when it comes to creating a repository of lessons learned:
- Make lessons learned easily accessible. If you’re using a shared resource like Planio Wikis, 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.
Here’s an example of how this works in Planio.
In Planio, you can store lessons learned either in a shared Wiki or as issues in your product backlog. Let’s say as part of your lessons learned, you discovered that your team was missing deadlines because your process for writing user stories was resulting in vague or unclear tasks.
You can create a Planio Wiki that addresses all aspects of your sprint planning process and includes articles on user story mapping, sprint planning, and even breaking down tasks.
Each entry can include links to projects (for more context), specific tasks (for actionable next steps) or even repository files, versions, and forum messages.
Now, every member of your team and any relevant stakeholder will have easy access to all of the same files, and the ability to call up all of the information with a moment’s notice.
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 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?
Planio helps you keep everything in one place, easily accessible to every team member, so you can optimize the lessons learned the next time around.
Lessons learned template and example: Capturing knowledge the NASA way
So how does this lessons learned process look in practice?
How do you know what to capture during the session and whether a lesson learned is documented in the right way?
One great example is to look at how NASA handles this scenario.
At NASA, each project has billions of dollars of equipment and potentially human life on the line. So it’s imperative that they document lessons learned and continually grow and learn. As such, they’ve put together an incredibly comprehensive resource of their own lessons learned that is commonly accessed by scientists from all over the world.
So how can you learn to be a little more like NASA? It might be easier than you think. You can bring elements of their comprehensive review system to your own work by creating a lessons learned template.
Here’s what this looks like:
Introduction: This is a quick breakdown of what the project was, who was involved, and any other high-level information.
Project objectives and goals: Here is where you list what the goals and objectives were taken from your SOW or the project proposal.
Lessons learned: For the meat of their lessons learned, NASA uses a simple grid to list out the specific details of their lessons learned. This includes the:
- Category: What is the high-level topic this goes under?
- Issue: What specifically happened?
- Problem/success: This is the answer to “what went well/wrong?”
- Impact: How did this impact the project?
- Recommendation: What will you change to do more/less of this action?
To show how this works, let’s use the same user story example from before as an example.
Let’s say you’re working on an update to your app or site and are pulling in some old tasks from your backlog. However, your team starts missing deadlines.
During the lessons learned session, you discover there was confusion because the tasks hadn’t been updated and they ended up doing work that was already done or didn’t need to be completed.
Here’s how this would look:
- Category: Task management
- Issue: Not grooming and updating user stories before planning sprint
- Problem: User stories were old or outdated when assigned.
- Impact: Missed deadlines and created general confusion and frustration around prioritization.
- Recommendation: Set aside time in the initial sprint planning process to groom the backlog and update any user stories that need it.
Of course NASA’s lessons learned template works great for NASA. But you and your team might find using pen and paper more of a hassle than an effective solution. Also, these lessons learned should be accessible for everyone on your team, whenever they need them. Enter Planio. Using trackers, custom fields and categories in Planio, you can recreate NASA’s lessons learned template as issues in your Planio account, which might look something like this:
It’s also worth noting that the lessons learned template above captures not just problems but also successes. What are you doing right, and how can that success serve as a model for future success? After all, you can learn from your accomplishments in the same way you can learn from the events that don’t hit the mark.
Your learnings are meaningless if you can’t access them
Capturing lessons learned is important—but it’s even more important that you don’t view it as the end of the process.
There’s no point in capturing lessons learned if you never look at them again. A large part of getting better as a team 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.
