Why Nobody Really Learns from ‘Lessons Learned’ in Projects
By: Marcus Glowasz
Tags: Project Analytics, Software Development, Data Analytics, Lessons Learned, Project Management

In times where the Project Management industry is continuously confronted with low project performance rates, one process which aims to contribute to the improvements of project performance is to gather lessons and resulting learnings from a conducted project, commonly known as “Lessons Learned”.

This is an activity that usually is being executed as part of the project closure process, with the goal to feed its learnings into future projects and to avoid mistakes that have been made before.

The reality however is that Lessons Learned meetings are usually just conducted as part of some project protocol, just to get something off the chest and to move on. Often, such sessions are not being conducted at all because of time pressures to get going with the next project.

What often remains forgotten is what the whole purpose and goal of Lessons Learned supposed to be. The key goals should be:

Recap on mistakes made in a project, and take measures to avoid those in future projects

Identify what went well in a project and take measures to promote it towards “best practices”

Improve performance of future projects in the organization

Especially the last item needs to be emphasized because the output from “Lessons Learned” is an artefact that should flow into any future project in the company, so that all project teams in an organization can benefit from it and project performance generally can improve. Especially in larger organizations we are facing the issue that such learnings are not shared appropriately or not at all.

In fact, what usually happens as part of a Lessons Learned meeting is that team members gather in a room, collect their lessons, discuss what needs to improve, and in best case, such learnings make it to some document which ends up in some folder or archive.

Item checked off. Move on to the next project. Nothing really learned.

The deliverables of a project should provide added value, otherwise what is the point in executing a project. Lessons learned may not be the project’s main deliverable but it as still a project deliverable with a lasting and significant organizational value if done right.

How can we make those lessons lasting then? The below practices should get you started for a proper value delivery of decent lessons learned:

Make Lessons Learned meetings mandatory in your organization

If it is not mandated, nobody will really do it. In fact, some teams run into some issues in a project, resolve it somehow and refer to a Lessons Learned session for a wash-up of what happened. Problem only is that such Lessons Learned session actually should be conducted — i.e. many just talk about it but are only doing it whenever they have time.

If it is not mandatory, it always will be down prioritized. Do not rush through a Lessons Learned meeting — Reserve sufficient time

Teams often just reserve 1 hour for a Lessons Learned session, and depending on the items that actually come up, this might not be enough — I always would reserve 2–3 hours at a minimum. At the end you want to make sure that you make a complete recap on anything good and bad that happened in a project and the resulting lessons. Define and follow one method to collect lessons learned

There are various ways to run Lessons learned meetings and I don’t think there is one right way of doing it. But I think it is important to follow one method across teams, departments, etc. — in short the entire organization should follow one defined method.

The entire organization ultimately should benefit from your team’s lessons but if those are not captured in a consistent way, it could be hard for other teams to make use of them. Store all lessons in a central digital repository

Often, the learned lessons do not make their way into a digital project management information system (PMIS) for further use. The offline handling of Lessons Learned might work immediately for a team but there would be no lasting effect of such lessons. Especially in companies where teams possibly will not stay together for years or maybe not even for months (e.g. teams that are composed of contractors and/or consultants with only temporary assignments), such lessons obviously would vanish quickly — the Lessons Learned session practically would be a total waste. The lessons need to be made accessible for an entire organization, so that other teams can learn from made mistakes and do not run into same problems in their future projects. Review Lessons Learned repository when new projects are initiated

Collecting and storing learned lessons is obviously useless if such information is not being consumed by anyone. I don’t know of any project where a proper review of documented lessons learned from past projects has been made in order to find some patterns and information that could be useful for the performance and effectiveness of a starting project. At best, there are some informal discussions of a type “I remember, back then we had a particular problem….” which maybe happens only by coincidence because someone knows someone who had such experience to share. To scan the Lessons Learned repository therefore should be one critical step as part of a project initiation phase.

The value of lessons from past projects cannot be emphasized enough. One thing to remember is that project success rates continue being low and improvement is not really in sight with the traditional way of running projects. Consequently, projects rely on learnings from past projects, to ensure that future projects can do better.

And as we are entering an era where project management will be very much data and analytics driven, it becomes more and more critical to collect historical data from projects.