Lessons learned or how to improve your inner manager

Like any self-respecting and forward-looking organisation that encounters project management on a daily basis, we want to improve our practices and learn from our mistakes. Therefore we gladly embrace the concept of capturing lessons-learned during and after each project. We try to keep it simple in a basic form of a list of insights, remarks, failings as well as ideas on how we could perhaps do things better.

Capturing lessons-learned, however, is just a part of the task on hand. How do we make sure we don’t just leave the valuable lessons… well, unlearned? The insights are usually captured in separate documents for each project, and then they are placed somewhere. And then the next project comes, and you don’t really have time and desire to look through each of them hoping that maybe you will find something useful there.

Our first idea was that we need a central master list of lessons-learned. Yes, some solution where lessons can be organised and categorised, ideally even tagged, and easily searchable. That way, if one wanted to see what we have done wrong with, say, estimation in our previous projects, one could easily find a list of our past stumbles on that topic.

The first step in everything we do nowadays is, of course, to google it. We tried looking for some software that manages our challenge nicely, or perhaps some tips on how to do it ourselves utilising Google Docs or any other popular collaborative cloud tools. However, we were surprised to find very little information on this topic, most of it being very hazy, with generic advice on building your own database that supports tagging, search, etc. No samples, no demos.

OK, so there’s no quick fix for this. And when you have to build your own software, you think twice. Which we did. We started at the basics and looked at what the solution has to do for us. Here are the criteria we came up with:

• Lessons-learned should be located on the project’s ‘critical path’, i.e. a project manager should have to naturally come to learn from past experiences, as opposed to pausing just to step sideways to look at past lessons, if one remembers to do that in the first place.
• They must be easily accessible and searchable, i.e. you should be able to quickly find relevant insights.
• Ideally, they should be processed, which means that it shouldn’t just say that we did something wrong, but rather suggest an alternative approach or a solution so one doesn’t spend time trying to come up with one.

Having considered these criteria, we decided that the best lessons’ log to have is… none at all. What we do instead is after each project we process each lesson-captured, with only two possible outcomes for each:

1. Discard, which means that there’s nothing you can do about a particular insight. Perhaps it was very specific to a project situation, perhaps something highly unlikely happened, or maybe it’s a kind of risk you simply cannot ensure against.
2. Action, and then discard. To action a lesson-learned means to update our processes and practices in a way that would ensure we don’t repeat those mistakes again.

It’s a simple and great solution that satisfies all the criteria we’ve raised earlier. Since learning is weaved into our core processes, they are on a project’s ‘critical path’. Also, by updating respective parts of the process, we make learnings relevant to whatever stage of the project we are in (say, altered estimation practices at the beginning of the project). And finally, since we turn each captured lesson into a solution, they are processed and actionable when one encounters them.

So, instead of maintaining a log of captured lessons, we process and then discard each one of them. It’s similar to a to-do list – once you have completed a task, you don’t retain it, do you? (Do you?) Done is done.

Plus, this is a great way to naturally keep our processes updated, which on its own is hardly ever a fun and inspiring endeavour.

This is not to say that our project management approach is process-heavy. On the contrary, it’s rather lightweight and efficient. However, we still have light process descriptions or useful checklists for different stages of a project. For instance, one lesson that was captured in a project of ours was a slower-than-expected start in team communication dynamics, as we had a couple of new freelancers join the team. Having processed this insight we decided that it would be a good idea to organise a team social (translate – drinks) at the project outset. So we added an item to cover this to a project initiation checklist. It is not a prescriptive task, but rather one that urges the project manager to think about this, gauge the necessity for such an event and organise one if seen as needed.

So, if you are thinking about a lessons-learned log, don’t. If you have one, we suggest you have a few sessions to go through it, process each lesson with the goal of emptying the list, and then discard the log and never look back.