The importance of documenting the experiences throughout a project is obvious. However in reality, we consistently fail at extracting valuable information from past events and carry on repeating the same mistakes over and over. This is especially relevant in large projects, where staff change continuously during the delivery cycle and new teams face similar challenges to those previously overcome by their predecessors.
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.
At the organisational level, there is usually a system in place to capture lessons learned from various projects. This register, in the best-case scenario, is updated at the end of each project or phase. Once that register is updated, we rarely come back and look at it again. A key reason for this is the lack of visibility or ease of access for relevant team members. Furthermore, these lessons are often specific to a project and it is hard to extrapolate some conclusions to new complex environments. While the information exists, it’s challenging to find, digest and use.
In the emerging Data Analysis revolution, we are gradually becoming experts in extracting and correlating clinical data, but analysing subjective information becomes a difficult task as its outcomes can’t be measured objectively.
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. Ensuring there is a structured template in place is key to ensure that data can be analysed. Adopting the same strategy as a Risk Management approach is advisable as lessons from today are risk mitigations for tomorrow.
To effectively use this register, it’s crucial to group the lessons by any relevant criteria (type of project, project size, discipline etc) so relevant information can be easily located when confronting new situations. However, creating overly generic lessons risks providing solutions that are too general and may not add value to resolving specific future problems.
Be active, keep people engaged, make it useful! Regular meetings are required on both project and organisational levels to review lessons learned. The process shouldn’t include just the creation and the update of the register, but also the structure and frequency of meetings and the relevant RACI. Remember that implementation is usually 80% of the work in any process. Having a register that teams use would be invaluable.
As explained above, follow a Risk Management approach. A lesson will trigger an action, and each action needs to have an owner. We’ve all seen lessons and risks that were known by the team, but since there was no one assigned to them, they haven’t been controlled or actioned and ended up having the same result.
A data strategy needs to be in place to take lessons learned to the next level and have a scalable process for your entire organisation where analysing and using this knowledge becomes the norm. The approach should optimise how data is captured, aggregated, presented and distributed efficiently. It’s simple; ensure you involve the experts!
So, to avoid repeating history and costly disputes, you need a proactive approach. By following these strategies of adopting a Risk Management approach, categorising lessons learned, maintaining active engagement, assigning ownership, and involving the Data Analytics team, organisations can establish a better process for leveraging knowledge from past projects to improve decision-making on future projects. These strategies will enhance company efficiency and create a culture of continuous improvement.
