Lessons learned to be accessible need to be well structure. Do you have define way to do it (template) or should it be just plain text. Saving Changes...
Normally, Lessons Learned is submitted during every project handover. In our case, lessons learned are collated from weekly and monthly risk and opportunities reports. From this tabled format issues are identified, mitigation required, dates when identified, dates when mitigated, responsible staff (position). Added comments for each item shows each item's impact on time, cost, quality, safety, etc. I like what Rami suggested about adding pictures.
Lesson Learned structure should be in such a way that key stakeholders are represented. Though, may differ from one industry to the other but the idea is the same all through to learn from the past and take notes of preventive or take-forward actions on future projects.
At the beginning of each Lesson Learned session (for a program) high-level project description is necessary because of stakeholders that ore possibly not in the center of execution of the projects
...
1 reply by Vincent Guerard
Oct 12, 2019 8:50 AM
Vincent Guerard
...
Adeola,
Who attends your lessons learned? You say you need to present the project to attendees, so they are not implicated in the project?
Trying to understand who is participating.
Saving Changes...
Maya KalachHead of PMO, IT| Middle East AirlinesBeirut, Lebanon
Lessons learned to include the following:
ID / Logged by/ Category/ Subject/ Corrective Actions taken/ Recommendations & Lessons Learned
Categories could be: Technical, Resource, Planning, Communication, etc.
...
1 reply by Vincent Guerard
Oct 12, 2019 8:46 AM
Vincent Guerard
...
Maya
So you structure it in a spreadsheet or a database. Categories are predefined, are there subcategories?
where can I get a template for a lessons Learned? also, some activities were not included on the schedule plan after the project is completed. can I note this in the lesson learned document? Saving Changes...
Lesson Learned structure should be in such a way that key stakeholders are represented. Though, may differ from one industry to the other but the idea is the same all through to learn from the past and take notes of preventive or take-forward actions on future projects.
At the beginning of each Lesson Learned session (for a program) high-level project description is necessary because of stakeholders that ore possibly not in the center of execution of the projects
Adeola,
Who attends your lessons learned? You say you need to present the project to attendees, so they are not implicated in the project?
Trying to understand who is participating. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
When we are reading a document prepared by someone else we may interpret differently what that person wrote.
How can we overcome this situation, with particular reference to the record of lessons learned?
On the other hand, if the document is too long, there is also a risk that those who should read it may lose part of the information because they have not read the document to the end.
The same applies to complexity in the way the document is structured.
...
1 reply by Vincent Guerard
Oct 16, 2019 10:13 AM
Vincent Guerard
...
Luis,
Very true, Lessons learned need to be accessible and usable
When we are reading a document prepared by someone else we may interpret differently what that person wrote.
How can we overcome this situation, with particular reference to the record of lessons learned?
On the other hand, if the document is too long, there is also a risk that those who should read it may lose part of the information because they have not read the document to the end.
The same applies to complexity in the way the document is structured.
Luis,
Very true, Lessons learned need to be accessible and usable Saving Changes...
When you say that "Lessons learned to be accessible need to be well structure[d]," are you talking about the content AFTER the lessons learned meeting? I hope so, because that is what I am responding to :-).
Asking the right questions and getting honest feedback are both critical to a good lessons learned. Equally important is asking the questions at the right time (I have started holding lessons learned meetings at the end of each phase, instead of the end of the project).
More important than these things, however, is what you do with the information AFTER the meeting.
I will keep the notes from the meeting with the project documentation, but if I were to stop there, the document would be meaningless. I break down the information in the following ways:
- Who needs to be recognized for valuable contributions? I make sure this takes place, to the extent that I am able. This may be an email to the person, recognition from leadership, gift card, etc... - Are there any scope change controls needed for the project? If so, I make sure a change request is submitted. - Was something identified that could affect other active projects? I notify other project managers so that they are aware. - Was something identified that should be considered for every project? I add it to a checklist that I maintain for each project, so that I can determine whether or not it needs to be addressed.
It doesn't matter how you structure your lessons learned if you do not make the information actionable and get the information to the people that need to take action on it. Saving Changes...
Community Champion
