Risk mitigation using ‘Lessons Learned’

Whilst, as a Project Manager I prefer to manage a project my own way there is value in visiting the ‘Lessons Learned’ logs of previous projects run within the organisation to see where common problems or risk areas lie.

In the context of IT projects there will be very valuable lessons that will have been learned from other IT projects that have already been carried out by the organisation in areas such as data migration or system configuration, or business engagement, for example..  If this is the case, then doesn’t it make logical sense to tap into that wealth of knowledge and use it to better set up and manage your project?

The ‘Lessons Learned’  or ‘Lessons Learnt’ from a project explain a lot about

  • the gaps,
  • problems,
  • culture, and
  • staff maturity levels

relating to the tasks and outcomes previously carried out on a project. They really do provide insight into what didn’t go well.

Mitigating risks using ‘Lessons Learnt’

Using the ‘Lessons Learnt’  from previous projects you can better assess and manage your own project risks.  How?   Well if, for example, you become aware of gaps in knowledge/skills etc with teams that you are working with, you have a better chance of mitigating the risks involved in needing to work with that team on your project by being forewarned, aware and prepared.  You can mitigate this risk by ensuring that you have other support available – perhaps other team members, outsourced vendors, contract staff with specialist knowledge, or the knowledge that you are going to need to get the job done.

It is also very helpful , to have this visibility, because ultimately with this, you as the Project Manager are more able to mitigate risks up front and having plans in place at the commencement of your project, rather than wait for them to occur.

‘Lessons Learned might also provide visibility of things that you would otherwise not be aware of, for example, that there is no policy in place for a particular process in the business which is critical to your data integrity.

If you disregard the ‘Lessons Learned’ from projects where the same issues keep being listed as ‘we should have done this’ on previous projects, then you are being less than clever about managing the outcome of your project in the best possible way.

Storing and searching ‘Lessons Learned’

I am not saying that you need to trawl through list upon list of ‘Lessons Learnt’ from previous projects, that would take too much time.

If you are lucky and have a centrally managed repository for ‘Lessons Learned’ logs, then hopefully someone can help you to sort and filter the log(s) so that you can take a snap shot of the things that are going to be relevant to your project.  For example, lessons around data transfer issues will be completely irrelevant for an infrastructure build project, but, issues around configuration that are relevant to server set-up may just be relevant to both projects.

Ask the question when your Project Initiation Document (PID) is being produced – “Is there a central repository of Lessons Learnt logs?”  You might just find some really useful lessons that will help you to deliver your project in the best and easiest possible way.


Written by Karen Munro