A Poor ‘Lessons Learned’ Approach Can Impact Actual Learning

Once a project is completed, it can be tempting to simply wash your hands and move on. Looking forward to the next thing down the line is usually much more exciting than reviewing what’s in the past. Sure, basking in the glow of a job well done feels good. But scrutinizing the things that didn’t go so well isn’t enjoyable. Nevertheless, documenting lessons learned and implementing them is a critical part of project management. How can you ensure that this task is done in a way that promotes learning rather than discouraging your team?

Build Good Capturing Habits

If your team hasn’t been collecting data throughout the project, you won’t have much to put in your lessons learned knowledge base at the end. By that time, much of the wisdom that was actually gained about successful and unsuccessful strategies has been lost. Trying to recapture all this information at the end of the project is a time consuming and flawed approach. It will make everyone feel overwhelmed and exhausted.

The initial project management planning stage is when a process for gathering lessons learned along the way should be determined. For simple projects, this may be as straightforward as instructing each team member to keep a journal documenting insights throughout the life cycle of the project. For more complex projects, this documentation responsibility may be bundled into another process such as Quality Management.

Be Careful With Phrasing

Remember that the next team you work with will be reviewing the lessons learned by the previous group. Plus, the current team will also need to go over these materials. This means the documentation should be carefully written to avoid placing blame on specific people if things went wrong during the project. That way, the process of review is less intimidating and uncomfortable for everyone. Any necessary discussions about individual errors should be done in private rather than being made a permanent record in the lessons learned database.

Here’s an example of the wrong way to write a lessons learned report:

“Project management assistant Gary Ross failed to coordinate with HR on a simple scheduling task. This created a serious delay of 2 weeks and probably cost the company a lot of money. This employee has been reprimanded and received remedial training on how to do his job properly next time.”

Here’s an example of a much better approach:

“An initial decision was reached regarding scheduling based on partial information that resulted in a delay of 10 working days. Further investigation revealed that pertinent information readily available from Human Resources was unintentionally overlooked in the decision making process. Future schedule planning will include a consultation with HR to ensure more accurate results.”

As you can see, using a passive voice in writing makes it easier to achieve the objective of teaching in this situation. It is possible to outline the known facts about a mistake and how it will be avoided in the future – which is really the important information – without publicly shaming anyone. This is key if you want your team to be forthcoming about their mistakes in the future.

On the other hand, you can mention specific team members who contributed lessons learned about highly successful strategies. It’s a great way to recognize individuals who have done an outstanding job. Team members are more likely to participate eagerly in the review process when they know that this is where their achievements will be recorded for the purpose of improving future projects. In effect, they get to be the teachers!