The Status Quo
It is quite obvious the importance of documenting the experiences throughout a project, but in reality, we still constantly fail extracting valuable information from past events and carry on repeating the same mistakes over and over. This is specially relevant in large infrastructure projects, where staff changes continuously during the cycle of delivery and new teams have to face similar situations as the ones overcome by their predecessors, and where information is often captured in meetings and not communicated systemwide through the appropriate channels.
On a project level, the main problem is that there is no defined process in place to capture these lessons. Implementing good practice happens through iterations and depend on accumulated experience gained by each individual. If the team changes, we are back to square one.
On an organisational level, there is usually a system in place to capture lessons learned from the different projects. This register is normally updated at the end of each project or phase although we are finally adopting the culture of updating this register “at the moment”. Information exists. The problem comes when we need to obtain valuable intelligence that can be extrapolated to different projects which, although can appear similar, will be part of a different and complex environment.
In the emerging Data Analysis revolution we are facing, we are gradually becoming experts in extracting and correlating clinical data, but analysing subjective information becomes a complete different task as we can’t measure its outcomes objectively.
What have we learned? What can we do?
1. The Lessons Learned Register
Creating a Lessons Learned Register needs to be done in the early stages of a project, and it is crucial that every team member is fully involved in its development. At the same time, Project Managers are in charge of creating specific repositories for each project (where there will be people from multiple organisations).
2. Make it specific
In order to be able to do a practical use of this register, lessons need to clearly focus on a specific Project Management Area (e.g. Quality Management, Risk Management etc.). Therefore, when extracting information to face new situations we will know where to find it. It is completely true that Project Management Areas are interconnected, and the same lesson could be applicable to more than one field. However, by creating “too generic” lessons we will have the risk of falling into “too general solutions” that don’t add any value on the resolution of future specific problems.
3. Keep it live
Keep it live, keep people engaged, make it useful, make it fun! Regular meetings are required on both project and organisational levels to review lessons learned. Having a register is worth nothing if the team doesn’t use it. Solutions to experienced problems are usually creative, imaginative and have a story to tell of how we came out with the best (or the worst) result. But we have all experienced unstructured meetings lasting for hours without achieving valuable outcomes. Don’t waste your and your team’s time in worthless meetings.
4. Assign Ownership
Project Managers have the duty of aligning efforts in a clear direction. Prepare an agenda, set up clear goals and drive the team towards them. Goals can be from a general overview of experiences used to train and expand the team’s knowledge to the specific resolution of a recurrent problem. Report, communicate and share the outcomes of these sessions as they will be the real tools for a successful delivery of our future projects.
5. Make lessons learned part of the risk review
If you think about it, lessons learned are actually risks because they are things that have happened before and need to be monitored and mitigated against.
