Lessons Learned: It's Déjà Vu All Over Again

This forum is for members to share and gain knowledge of Project Management. Got a question about project management? Need help with a problem? Wish to offer tips and advice? Post here.
Post Reply
User avatar
Site Admin
Site Admin
Posts: 495
Joined: Sat 19 Dec 2009 4:39 pm
Location: London

Lessons learned are one of the most powerful and cost-effective project management tools available today. If you consider that many projects make the same mistakes time and again, you soon realise that lightning does strike twice, often more frequently.

It's important to carryout lessons learned in an organised and systematic way. It must be done properly. In lessons learned, we need to bring together experience from past projects and an implementation plan.

Don't just focus on failures, also look at successes. A reluctance to share lessons learned is often caused by fear of the "blame culture". It's difficult to admit mistakes, but it is important to do so for the future.

Lessons learned must be correct, so don't just accept them on face value, ask questions. Check what the person is saying, otherwise you will be doing things that are either wrong or not applicable.

Make lessons learned part of the normal project routine, including using them on your projects. Lessons learned are considered a best practice. Companies that do well use lessons learned.

Companies make important savings by removing redundant work and repetition of mistakes. Create a good process, where lessons learned are planned and implemented in projects. Understand what the benefit of each lesson is and avoid a tick box exercise.

Make lessons learned accessible to others in your organisation. Creating a website for storing and distributing of lessons learned can prove effective. Don't leave others to learn the same lessons you have, with all the cost and time implications of that attitude. Pass lessons on!

Running a Lessons Learned Session

Get the project team together at the start of a project and bring people in (including other PMs) to talk about lessons you can use on your project.

There are two key questions to ask:
  1. How will we use lessons learned on our project?
  2. How will we make our lessons learned available for others to use?

Always estimate how much time or money each lesson will save you. Unless it's significant, don't use it.

Using external facilitators to run lessons learned sessions can be beneficial as they can take an external view. It's difficult to run a session when you are close to the project.

Concentrate on the big, important lessons - the ones that will have a big impact on your project and future projects.

Common Reasons for not Using Lessons Learned

So why aren't lessons being learned?

Arrogance: We think we know all the answers.
Lack of experience: We don't know how to implement and use lessons learned.
Time: It takes too much time and effort to implement lessons learned.
Apathy: Can't be bothered to seek out lessons learned; it's easier to just start work.
Pride: We don't want to seek help from others because we feel it's a sign of weakness.

Senior management can help by insisting lessons learned are used in their departments, and by checking which lessons have been used. This ensures lessons learned are carried out and the team knows something about lessons from the past.

Relying on luck is not a viable project strategy; however, this is what we do when we ignore lessons learned.

Remember, collecting the lessons is just the start of the process; it's how you benefit from them that counts.

When approving a project, senior management should ask what we have learned in the past and how this will impact future projects. Before they agree the spend they must ask, "Can lessons learned save us money on these projects?"

What lessons learned have you applied on your projects and how much did you save?

Expert Member
Expert Member
Posts: 132
Joined: Wed 08 Sep 2010 1:38 pm
Location: Westminster - London

Hi Duncan, you missed out a very important reason why lessons learnt are not factually collected and collated.

Fear: Peoples incompetence’s, secret agendas and politicking collectively combined with the lack of total commitment to the company form the bulk of reasons of why a project fails. It is the project managers fear of repercussions, embarrassment combined with the fear of breaking the unwritten code of ethics especially when it comes to key players or line managers that prevents the recording of the real reasons for project failure.

Even the PMBOK Guide (and in my opinion quite wrongfully) encourages project managers when dealing with the lessons learnt report, not to make direct negative reference to individuals.

I know that this is a very, very serious and somewhat touchy area of project management that can not only lead to considerable resentment but also a whole quagmire of future problems. However, if this particular problem is not adequately addressed then it will manifest itself in to every single project that follows.

I have studied this problem for a long time and there seems to me to be no easy solution especially if the problem exists with a superior such as a line manager, executive or board member let alone if the top person is the owner of the business.

The advantage that Prince2 has over the PMI, APM and AIPM is that under this system the project manager reports directly to a company Executive who in turn reports to the Board Member who is the champion of the project. Under this system a discrete word at the right level can often work wonders.

However, in functional and matrix organisations very often the project manager reports directly to a line manager and the ethics of the reporting structure does not allow him or her to bypass this person when approaches to them through interpersonal skills fail.

All is not lost though; project managers can collate information outside of the normal lessons learned procedures and then make references to them within the lessons learned document.

Project in a Box configuration management software has a very good reporting function just for this purpose. Within the document audit function of the package each time a person accesses the package for information the date and time of the activity is recorded. The package allows the project manager to call up any individual’s activity history details therefore providing maximum transparency.

An example. The project manager has sent an email to say 10 people to view a document prior to a meeting. Two people claim that they never received notification of the meeting and a further three people claim when asked that they had studied the document. Prior to the meeting the project manager had called up each of the attendees activity reports and knows exactly who is being over zealous with the truth.

At the end of the project, the project manager knows who were enthusiastic and responded to request for information or permissions on time and who were half hearted or not committed at all and delayed or obstructed the project.

So in short, to deal with the fear of reporting true and factual personal performance information for the lessons learned report, the project manager must have a robust, efficient and above all else totally transparent configuration management system. Then /she must make sure that everyone knows that is there, that it is functioning, that it is totally transparent and it will date and time record every single document transaction.

This level of transparency is a very good psychological motivator.
Kind regards

Stephan Toth
Post Reply