November 5, 2020, 8:30 a.m. to 6 p.m. EDT | November 6, 2020 – February 7, 2021, On-Demand | Online Conference
Please login or join to subscribe to this thread
I am not familiar with 4L method at least by name. Just google-d it and see that it is nothing extraordinary..
I defined some years ago Lessons learned process, basically applying similar questions.
For me lessons learned have value when there is a clear, simple and transparent action plan, what precisely have to be changed to improve not so good experiences. This is something I could not see in your method, of course I may be wrong, as I quickly went through description.
As for templates, you can search in Templates section here. They may give you an idea, but you still may need to adapt them to your needs. OR, you just create your own template, based on your needs. This for me always worked the best.
I'm not a fan of traditional lessons learned practices (I did a webinar about that which is available here https://www.projectmanagement.com/videos/4...essons-Learned) but if you have to stick with that approach then:
1. Define categories of lessons beforehand and either have the group go category by category in identifying lessons OR break the group up into smaller groups and assign categories
2. If there is likely to be some tension between participants or some of them may be unwilling to share openly, you might want to harvest the lessons in advance and use the meeting to review what was submitted making sure to not indicate who submitted what
3. Focus on coming up with a short list of improvement ideas for the next stage
Once lessons learned are documented, I look for what is actionable:
- What do we need to start/stop/try on the current project? (assuming phase gates and we're not closing the project)
- Is there anything that affects other active projects?
- Is there anything that needs to be considered on future projects?
- Is there anything that needs addressed by operations/the business, outside of a project?
- Has anything been identified that represents a new project?
I keep this in a spreadsheet, like an action item list. For anything outside of the current project, the appropriate people are notified so that they can determine what action is needed. Any lessons learned that have the potential to affect future projects go on a checklist used by PMs, maintained by the PMO.
We also use the LL meeting to recognize outstanding achievements on the project.
I started doing this because not everything that comes up in a LL meeting is actionable, and nobody wants to review pages of old LL documents hoping to find that one piece of information that might make a difference.
4L is a good method to extract LL in a meeting. Similarily I use SWOT quite often for this purpose. Both serve as methods to shift perspectives in people's minds and make them look at the project from different angles.
There are more ways to find LL, e.g. looking at your issues and risks, solutions and root causes. This can be / should be done at any time, when the mind is focused on this solution and it can be easily documented. A LL is similar to an invention, it is something new (at least for the people involved), and it is deemed worthwhile to remember.
The value of a LL is increased if it is used or remembered in another situation or project. At IBM, we used to measure the reuse of LL (e.g. hours saved by using an asset) and could look at the accumulated value. For the one finding the LL, compare them to an inventor, a scientist - publishing (making available the LL) and being mentioned is key to their progress. Many great inventions improve your career.
Regarding LL, even simple tips are helpful, the expert may gain no benefits from them, but you also have rookies who can improve their understanding.
LL go beyond a project, they build a knowledge base for the organization, if shared openly and across all people. Knowledge is a key asset of any organization, most of it is called tacit knowledge, and is in the heads of staff and not codified. It is transferred by workshops, shadowing, mentoring and similar people to people events (in contrast to codified knowledge which can be read, like a method, a technique, a process). The problem is when staff leaves or if knowledge is in the heads of consultants only - it is probably lost to the organization.
If you are further interested, I wrote an article about LL in LinkedIn.
I have not used the 4L method myself. Instead I have managed the LL according to the client and project I am working on.
One project where we did a monthly retrospective (rather than stage or milestone based review) worked well - each member of the core team, client and partner, named one thing that worked for them and one thing that did not - on the things that did not work we had to come up with an actionable plan for how to change it - then checked in on the next review as to whether that had helped.
- Doing it monthly gave people the frequency to call out things that weren't working for them and enough time to address before reviewing
- Each person only having one good and one bad thing meant we rarely ended up with pages of issues, there were definite themes that became clear during certain stages
- The actionable part was key, we had to agree a plan to address. Last year I did a LL with a client for Phase 1, we came up with key areas where things had to change for Phase 2. I had an opportunity to revisit with the client mid way through Phase 2 (where I was not the PM) and sp many of these actions had not been followed up.
I see lessons learned as a two-edged sword. First, it allows us to apply both personal and corporate experience to future initiatives, and second, it can stifle innovation and bog us down with dated processes - this is what we did and learned from the last project and is to be applied on this project. A lot of the convoluted contract language and corporate processes are the result of adjustments from earlier less than perfect documents without due consideration as to what is best for the project at hand.
Lessons learned is documented experience both good and bad and is very useful as a reference however the specific situation of the lesson learned needs to be documented as well. What may be applicable to Project A may not suit Project B. The people that developed Project A lessons learned were close to Project A but may be totally unfamiliar with Project B.
Please login or join to reply