I would like to know about your experiences with Lessons Learned Logs. I personally believe that they are of great use to PM's but would like to know other peoples opinions.
So far in my career I have seen very few companies use them and very few PM's promote the use of them. I feel that it is a shame as they can really assist shaping future projects.
Andrew MakarProgram Manager| AMAKAR LLCOakland Township, Mi, United States
Neal Whitten had a good approach to lessons learned. Stated simply, if the organization isn't mature enough to actually take action on the lessons learned or there isn't a direct link between lessons learned and project start-up, stop doing lessons learned.
Elyse NielsenSenior Project Manager| Ascension Health Information ServicesHaines City, Fl, United States
Sometimes, small steps can help an organization grow. We need to take to the steps to share great practices among other teams, and to earmark those tactics which were not as successful as intended. Others can expand upon the greatness and view the unsuccessful tactics with a fresh pair of eyes. Practicing Lessons Learned assures your organization learns from other teams. A lessons learned practice is simply how to documented knowledge for continuous improvement. However, in order to fully utilize lessons learned, one needs to have key processes in the organization’s project management methodology.
Those key process points are as follows:
1. Implement Lessons Learned Log – While in the execution phase, it is a good idea to have a lessons learned log. This log should comprise a couple of basic fields; the learning opportunity, recommend solutions, responsible party, and who submitted. The purpose of this log is to capture the knowledge throughout the project, not just at the very end. A good practice is to schedule the review as a part of the project status meeting on a monthly or bi-weekly basis. Once you have the project team updating the lessons learned log it is time to disseminate it to the organization. A common approach is to submit all lessons learned logs on the first of the month to the PMO office. The PMO office is then charged with sharing the information and updating other related documentation.
2. Craft Final Project Lessons Learned – During closure, one of the last activities will be to do a final lessons learned document. This document will be the culmination of the lessons learned log, business benefits realization, and post mortem. The entire project team needs to collaborate and create the lessons learned. When completed and signed off by the project team, this document should be submitted to the PMO Office. The PMO Office responsibilities are three-fold. First, the PMO will track when to request the realized business benefits. Additionally this office is accountable for updating the project management quality review check list. Finally, the PMO office should review and add the final project lessons learned document to the shared knowledge base within the organization. This document can then be referred to by anyone initiating a similar project.
3. Develop Quality Review Check List – A Quality Review Check List is a listing of items to consider for all facets and phases of a project. This document should be updated with all of the check up items from the lessons learned log and the final lessons learned. For example, let’s say you are about to complete and receive sign off for the needs analysis and about to engage in System Analysis. The checklist would provide common questions of items to what out for and best practices to follow. Common questions are if backup and recovery issues need to be address? Are the data migration plans completed? Has the education and training needs been reviewed? Once you have a check list in place, the PM and Sponsor should review this document near the end of each SDLC milestone gate.
If your organization isn't practicing lessons learned yet, it is best to start small. Commonly, the best starting place is the lessons learned log review at the project team meetings. This practice will remove the finger pointing mentality and help to advance the team into a performing state. It also has immediate benefits for team members to learn from shared wisdom. After this practice is in place and performing smoothly, it is an easy next step to implement a final project lessons learned. The project team, by this time, will even be receptive to sharing knowledge among the organization – as they have seen the benefits of sharing knowledge among the team.
Peter TaylorVP Global PMO and Keynote Speaker/Author| DayforceNewent, United Kingdom
Either you have been missing something, or nothing has really been going on
‘As we know, there are known knowns
There are things we know we know
We also know there are known unknowns
That is to say we know there are some things we do not know
But there are also unknown unknowns
The ones we don't know we don't know’
Donald Rumsfeld (Feb. 12, 2002, Department of Defense news briefing).
That is one crazy set of words but actually there is a lot of sense in the whole thing. Here you are at the end of the project. It has been a success or, at the very least, is has not been a complete failure, and you are about to head off to the next project. But wait, do you really honestly know everything? Do you know what you don’t know? Well of course you don’t, you can’t possibly. So don’t fool yourself that you do!
So what do you do about it? Well what you do about it is to do something about it – now is the time to conduct a retrospective of your project, a review, a considered and open activity that will allow you the opportunity to learn what it is you don’t yet know.
Just as at the start of the project, remember ‘a brand shiny new project… at a point in time that is full of peace and love and general wellbeing between all parties involved’, well the end of the project is a special time as well. It is a time when project team members are far more likely to talk to you openly, equally and honestly. Therefore it is a time you should really focus some effort on to learn how to be more effective (and even more ‘Productively Lazy’) next time around.
Saving Changes...
In my experience, I worked with the client in documenting the lessons learned. We collected the top 10 things that went well in the project and top 10 things that did not go well in the project.
We also discussed why certain this did'nt go well and what are the corrective actions that needs to be taken. This will ensure that future projects will go fine!!
I personally feel that Lessons Learned Log is very much useful but not only for PMs. This will be useful for any individual. Project Manager's Primary qualification is Leadership, I think a person shall grow as Project Manager from a Leader to Project Manager. The person who learnt from Lessons Learned will be a succsessful PM since he is also a leader by his attitude. Leadership will not come alone with Position and Project Manager will show project management will not able show his project management only in one particular aspect. Project Manager shall demonstrate Project Management in every aspect of PM. It is important to have lessons learned log and really learn from Lessons that are taught. Saving Changes...
Hi Roxane - I definitely support your view that they are of great use, but also find that they are rarely done effectively. The traditional approach tends to be to do them as a tick-box exercise at the end of a project but more often as not, they then just enable the team to let off steam around what went wrong and pat themselves on the back for what went well.
I've recently set up some new processes whereby a standardised log is used throughout the project to capture lessons learnt as the project progresses. This is structured in a format that encourages those completing it to determine appropriate strategies for preventing / mitigation similar issues in future rather than just logging the problem. For example, how many times do you see lessons learnt along the lines of "requirements signed off late; lesson learnt is to sign off on time". Was the issue one of resourcing where the BA was not available when required? Was it due to stakeholder issues? Was it due to scope creep? Without understanding the true root cause of an issue, enabling others to avoid it will never be possible.
These logs are structured in a format whereby they can then be consolidated into an overall log which enables others to search it when setting up similar projects.
Already, this has piloted on a number of projects both to log lessons learnt, but also to inform risk assessment on new projects and is starting to encourage a greater level of focus on effective lessons learnt reviews.
Andrew has an excellent point. If there truly is no appetite to learn from these experiences, then save yourself the time! However, we've had good feedback on the new lessons learnt logs to date so I am hopeful that we have turned a corner and am looking forward to rolling it out more widely. Saving Changes...
Hi Roxane - I definitely support your view that they are of great use, but also find that they are rarely done effectively. The traditional approach tends to be to do them as a tick-box exercise at the end of a project but more often as not, they then just enable the team to let off steam around what went wrong and pat themselves on the back for what went well.
I've recently set up some new processes whereby a standardised log is used throughout the project to capture lessons learnt as the project progresses and a final version produced as part of closure activities. This is structured in a format that encourages those completing it to determine appropriate strategies for preventing / mitigation similar issues in future rather than just logging the problem. For example, how many times do you see lessons learnt along the lines of "requirements signed off late; lesson learnt is to sign off on time". Well obviously!! However, was the issue one of resourcing where the BA was not available when required? Was it due to stakeholder issues? Was it due to scope creep? Without understanding the true root cause of an issue, enabling others to avoid it will never be possible.
These logs are structured in a format whereby they can then be consolidated into an overall log which enables others to search it when setting up similar projects. The PMO takes each project's feedback and then stores it in a central reference database.
Already, this has piloted on a number of projects both to log lessons learnt, but also to inform risk assessment on new projects and is starting to encourage a greater level of focus on effective lessons learnt reviews.
Andrew has an excellent point. If there truly is no appetite to learn from these experiences, then save yourself the time! However, we've had good feedback on the new lessons learnt logs to date so I am hopeful that we have turned a corner and am looking forward to rolling it out more widely so don't give up hope! Saving Changes...
Sylvie EdwardsProfessor/Program coordinator| Durham College (DC)Whitby, Ontario, Canada
I would suggest a couple of things:
1. the term LOG might not be appropriate. I seem to find that people use terminology for Lessons Learned that is most of the time not condusive to it being done, followed or used. Let's just name another: Post Mortem Report.
2. one of the best books that I have read over the years on this topic is by Norman L. Kerth and called: "Project Retrospectives: a handbook for team reviews". Have a look at it, it might help you with your issue.
3. have a look at what the military does for theirs. I found that they have a great process that is really followed and promotes use in the future.
Hope this is helpful. Saving Changes...
Yvonne ParleEast Victoria Park, Western Australia, Australia
Hi,
Great question/topic. The research says only 35% of best practice organisations successfully conduct Lessons Learned.
I've seen it done well in one engineering organisation where the PM wasn't allowed to be assigned to her/his next project until the LL had been done and stored in the LL Database - that worked rather elegantly and mainly because the CEO was inflexible on this rule.
I was wondering if any of you out there have been working on Projects being run with the Agile PM approach and what if any impact/influence the iterative rather than traditional approach was having on capturing Lessons Learned? I would have thought that an Agile project would be capturing lessons learned on the end of each iteration and therefore should improve the statistic mentioned above?
