I think it depends on the culture, as a Latin American, I have seen people like others to share their lesson learned by telling their experience, and it is almost sure than other project managers are going to ask again when they need the information.
What do you think? Is it useful to write them down? Saving Changes...
Aejaz ShaikhPM I| Alyx Technologies India Pvt LtdPune, Maharshatra, India
I agree with the point highlighted by Mike Fallon's - get an unbiased person to conduct the lessons learned and to collect the feedback to share. Getting an unbiased person will capture the true lessons and will propagate to others.
Documenting and sharing in a collaborative manner will be beneficial not only to current stakeholders but will also be a great fro future references. Any formal way can be adopted for capturing the Lessons learnt viz. reviews, demos, meetings etc. Saving Changes...
Anonymous
Lessons Learned should be recorded and shared. Doesn't mind if is an excel file, word or whatever, and you have SharePoint or portal. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
There is no way to be successful with leassons learned if you do not think it inside a knowledge management environment. For example, it is critical to achieve organizational agility by implementing agile. So, take a look to serious references for knowledge management. I am leading my seventh initiative on that field. Saving Changes...
The stories have to be written down so that details are retained and readily accessible to anyone who wants or needs them.
The flip side is that people frequently don't have or make time to review mundane things like postmortems. Notes may only have relevance to a few people in the organization. I think this is where periodic reviews play a role in making sure "company history" remains fresh in the minds of employees (especially new ones). Institutional memory is valuable but it needs organization and periodic retelling so that people know it exists (even though they may not know the details). Experience counts for a lot in planning and managing projects and its usefulness increases as more people share the experience, even if it isn't first-hand.
Write it down to be sure it persists, talk about it to be sure it is understood. Saving Changes...
Lisa KomidarService Delivery Manager - Sr. Engagement Manager| Optimum Healthcare ITKane, Pa, United States
In our unit, we do lessons learned in our retrospectives. But I don't think that a lot of PMs look at them if they were not involved in the project. This is a shame. We should be reviewing them regularly. An electronic knowledge base would be helpful. We usually put our documents in Box. Maybe if we start tagging better, it would help. Saving Changes...
Nick MiltonKnowledge Management and Lesson Learning consultant| Knoco LtdBath, Somerset, United Kingdom
I heard a great quote recently - "the biggest lie we tell ourselves is 'I don't need to write this down - I will remember it'"
You need to write down the lessons - the human memnory is an unsafe place to store knowledge. I also agree with the need for objective faciltiation, and with Sergio's point that lesson learning should be seen as part of a KM framework.
However just storing lessons is not enough - you should use them to update the company guidelines and best practices. Once these are updated, the lesson can be archived.
Lessons learnt are really useful also to provide feedback to sales and pre-sales folks, who will have the experience from past to be more assertive in the coming proposals. Definitely it needs to be documented. Saving Changes...
If you wait until the end of the project to engage in a lessons learned discussion, you risk missing out on forgotten details or risk that the emphasis will be on emotionally charged issues that should have been dealt with earlier in the project. You should be having these discussions at the end of each stage of the project. It can be a simple as an email, or it can be a formal meeting with a list of questions as discussion points.
When you get feedback, identify if there is anything that needs immediate action.
I'm currently running an SAP project with three test cycles. At the end of the first test cycle, I sent out an email asking for lessons learned. I didn't get a lot of feedback, but some of it will be applied in the test cycle that just started.
...
2 replies by Mayte Mata Sivera and Naomi Caietti
Apr 06, 2017 7:35 PM
Naomi Caietti
...
Retrospectives are good to use. It's like a Deming approach based on the feedback received and allows you to refine processes, tools and techniques as you roll out each build or complete a phase. It's a win, win.
Apr 07, 2017 11:48 AM
Mayte Mata Sivera
...
Aaron, I have +10 SAP implementation experience, usually, people don't like to answer lessons learned mail with an attached excel.
My recommendation is a small 30 minutes gathering meeting, where you can explain the importance of the lessons learned for the next phases.
If you wait until the end of the project to engage in a lessons learned discussion, you risk missing out on forgotten details or risk that the emphasis will be on emotionally charged issues that should have been dealt with earlier in the project. You should be having these discussions at the end of each stage of the project. It can be a simple as an email, or it can be a formal meeting with a list of questions as discussion points.
When you get feedback, identify if there is anything that needs immediate action.
I'm currently running an SAP project with three test cycles. At the end of the first test cycle, I sent out an email asking for lessons learned. I didn't get a lot of feedback, but some of it will be applied in the test cycle that just started.
Retrospectives are good to use. It's like a Deming approach based on the feedback received and allows you to refine processes, tools and techniques as you roll out each build or complete a phase. It's a win, win. Saving Changes...
Marcus ReisFormer President and CEO Razor Engineering Ltd| Project Results Calgary, Alberta, Canada
Very interesting question to the forum. Of course there is no right or wrong way to conduct these meetings as long as the objective is to learn lessons in order to improve performance for the next project.
So below are my on personal guidelines that I follow for these meetings.
To begin if the project had a small team I invite the entire team. On larger projects its the discipline leads that attend. I then distribute a meeting agenda to the team, it lets individuals responsible for any actions, prepare any comments that they may have. It is high level so no real details (intro, PM report, feedback, open forum, close). My focus is not to catch anyone off guard or to finger point directly, believe me if a project had some negatives the individuals know who they are so its a time for them to be able to redeem themselves in a open environment. It is a "lessons learned" so it is not always going to be rosy we need to know who to perform the next similar project.
Now, with the intro: I always congratulate the team for completing the project thanking them for attending and then lay out some ground rules for the meeting (e.g I mention that I will be going through some of the project highlights etc and any questions will be addressed after my little say). Now I get into the meat (PM report). I mention the client, key stakeholders, I review/remind everyone of the scope and deliverables that were required, I then go through the schedule performance and cost data. Basically did we deviate from any of the baselines. Review any comments from clients. I usually say positives then discuss the negatives.
The second part of the meeting (Feedback) is I allow and encourage individuals to discuss why any if any problems occurred (cost over runs, schedule conflicts, inter-discipline interaction etc.) and a very important step is a "remedial action" to prevent and learn for the next project. They also are encouraged to bring up any procedures that were found to be beneficial or a hindrance to project performance and if and how it can be improved. I should mention that when a person is speaking no other questions or comments from the other members are taken. It is like a one on one with me and that person talking. We do this until each person has had his or her say with me only allowed to do any questioning. I note all concerns.
Finally the open forum is where I allow individuals to address other team members. This "clears the air" and I can tell from experience it can get hostile and quickly LOL. So keep control of the meeting remind everyone we are on the same team and our goal is to continue to perform at our best for our customers. If it gets to a blame game intervene and shut that down quickly. Mention that after this meeting we can take it off record and discuss.
Final comments (close), if what I sum up from the meeting. and end POSITIVE and inform all where in our PMIS drive they can find the information gleaned from this meeting. Then I may or may not discuss up and coming projects of similar nature.
Community Champion
