Topics

Lessons Learned Storage & Access #lessons-learned


David Graffagna
 

Hello all,

 

As I have mentioned in previous messages, my KM Team has a number of work-in-progress efforts aimed at enhancing our overall knowledge sharing environment. One of our targets for this year is a focus on a more standard approach to soliciting, gathering, capturing and providing access to key lessons learned from variety of projects and initiatives.

 

My question to this group regards your knowledge and insight around the storage of those lessons learned and providing access to lessons learned/insights for a broad audience to tap into and consume. Let me set the context so you have a sense of where our challenges lie.

 

Our primary source for lessons learned typically comes from significant, cross-function, multi-year projects … so numerous people involved, a wide variety of functional areas participating, and broad range of potential knowledge areas for learning. Over the past months we have worked with a handful of project managers in soliciting lessons from their project team members as part of the project wrap-up/closeout; helping us get a sense of the breadth and depth of what those teams learned during their initiative.

 

Frankly, the volume and value of what we have received back is beyond our initial expectations. The team members, individually or in small functional groups, have been great in answering the standard set of questions we have crafted and capturing replies in the format we have provided (Excel for now). One team, for example, consisting of 15 individuals provided us with more than 70 individual “line items” of lessons learned on anything from budget/finance, communications, design & development, marketing/commercialization, production planning, risk mitigation … and on and on across a long list of knowledge areas and activities. Currently, from six projects we’ve ‘tested’ we have over 500 lessons learned, but grouped (and captured) specific to each particular project.

 

Here's one of my biggest challenges … if we have hundreds of lessons learned what’s the best way of capturing and sharing (e.g., making them accessible) those without overwhelming our audiences … while making it easy for them to find the right lesson in the right context?

 

So, bottom line … would love to know good, effective approaches you’ve seen around capturing and sharing those lessons. What have you seen around lessons learned from broad-ranging projects?

 

Looking forward to hearing your thoughts and insights!

 

Best regards,

 

David Graffagna


 
Edited

Hello David - it’s an interesting and fun KM challenge you have described. I’d start by figuring out some categories for the various lessons learned. One way to do this is affinity clustering - just grouping the LL’s like with like, without pre-defining any categories. 
Next, I’d look for a cluster of LL’s that have a focus on process or procedure, and start with those by reviewing how an existing process or procedure could be modified to incorporate the LL. (Last time I did this I used a Miro board - miro.com - and was able to upload a spreadsheet of ideas, which Miro turned into sticky notes - very cool. Free). 

Doing that is a way to get some “quick hits”, and may also lead to insights about other LL’s that were not initially considered to be related.

Next, I’d come up with category names for the other clusters (you could also do this before attacking P&P). I’d then look across clusters and prioritize LL’s that are critical (you’ll need to decide what constitutes “critical”!), and start working on what the best way is to incorporate those LL’s into the work they relate to. 

Doing this will likely give you insight into how to deal with many of the remaining LL’s, or if not that, then at least some idea about how to continue moving forward with your work. 

Good Luck! Let us know how you go with this - it’s an important KM area.
--
-Tom
--

Tom Short Consulting
TSC
+1 415 300 7457

All of my previous SIKM Posts


Dennis Pearce
 

Hi David,

A while back I did a multi-part series of blog posts on Lessons Learned, based on some research I had done.  You might find some of them useful in what you're trying to do.  This is the initial post and then there are links to the successive ones within it.


Dennis Pearce


Stan Garfield
 

David, thanks for your post.  In addition to the excellent responses from Tom and Dennis, these resources may also be helpful:


Gabriela Fitz
 

Hi David:

I am wondering if you would be willing to share the standard set of questions you have been using to solicit the lessons learned? I would be super interested.

Best
Gabi

On Thu, Jan 7, 2021 at 1:56 PM Stan Garfield <stangarfield@...> wrote:
David, thanks for your post.  In addition to the excellent responses from Tom and Dennis, these resources may also be helpful:



--

Gabriela Fitz

Think Twice LLC

773.882.8250 | LinkedIn

www.thinktwicellc.com


Preferred Pronouns: she/her/hers





Joitske Hulsebosch
 

Hi David, I wonder if you know the 5 types of knowledge transfer of Nancy Dixon? she states that you need different things for different types of transfer. Here's summary on my blog: https://joitskehulsebosch.blogspot.com/2005/12/communities-of-practice-nancy-dixon-on.html

For instance when you want to transfer lesson om more complex project it is good to use an advisory approach where one team advises the other. 


Nick Milton
 

David, the best way to deal with massive numbers of lessons, is to embed them into guidance and best practice. You may have hundreds of lessons now, in a few years you will have thousands, and asking people to sift through these, resolving contradictions, sorting through repeat and duplicate lessons, becomes completely impractical.

 

If you look at organisations which are successful in lesson learning, such as NASA, the Oil Sector, the Military etc, you see that the lessons database (or lessons management system) is not the final repository of the lessons, but is a clearing house, directing the lessons to the subject matter experts who will embed them into procedure, process, guidance and doctrine. The lessons management system only holds those lessons which are still in process of being learned, and once that lesson is embedded into working practice it can be considered “learned” and removed from the system.

 

Project managers therefore only really need to follow the updated guidance, into which the lessons are embedded, rather than sifting through hundreds or thousands of entries.

 

You can find more details of this approach on my blog (here for example), and in my book “The Lesson Learned handbook”. The attached article may also be useful.

 

Nick Milton
Knoco Ltd
www.knoco.com

blog  www.nickmilton.com

twitter @nickknoco

Author of the recent book - "The Knowledge Manager’s Handbook"

 

"Ambition without knowledge is like a boat on dry land." 
--Mark Lee

 

 

From: main@SIKM.groups.io <main@SIKM.groups.io> On Behalf Of David Graffagna
Sent: 07 January 2021 16:53
To: main@SIKM.groups.io
Subject: [SIKM] Lessons Learned Storage & Access #lessonslearned

 

Hello all,

 

As I have mentioned in previous messages, my KM Team has a number of work-in-progress efforts aimed at enhancing our overall knowledge sharing environment. One of our targets for this year is a focus on a more standard approach to soliciting, gathering, capturing and providing access to key lessons learned from variety of projects and initiatives.

 

My question to this group regards your knowledge and insight around the storage of those lessons learned and providing access to lessons learned/insights for a broad audience to tap into and consume. Let me set the context so you have a sense of where our challenges lie.

 

Our primary source for lessons learned typically comes from significant, cross-function, multi-year projects … so numerous people involved, a wide variety of functional areas participating, and broad range of potential knowledge areas for learning. Over the past months we have worked with a handful of project managers in soliciting lessons from their project team members as part of the project wrap-up/closeout; helping us get a sense of the breadth and depth of what those teams learned during their initiative.

 

Frankly, the volume and value of what we have received back is beyond our initial expectations. The team members, individually or in small functional groups, have been great in answering the standard set of questions we have crafted and capturing replies in the format we have provided (Excel for now). One team, for example, consisting of 15 individuals provided us with more than 70 individual “line items” of lessons learned on anything from budget/finance, communications, design & development, marketing/commercialization, production planning, risk mitigation … and on and on across a long list of knowledge areas and activities. Currently, from six projects we’ve ‘tested’ we have over 500 lessons learned, but grouped (and captured) specific to each particular project.

 

Here's one of my biggest challenges … if we have hundreds of lessons learned what’s the best way of capturing and sharing (e.g., making them accessible) those without overwhelming our audiences … while making it easy for them to find the right lesson in the right context?

 

So, bottom line … would love to know good, effective approaches you’ve seen around capturing and sharing those lessons. What have you seen around lessons learned from broad-ranging projects?

 

Looking forward to hearing your thoughts and insights!

 

Best regards,

 

David Graffagna


Moria Levy
 

David

I have developed and implemented, over a dozen of times, a methodology for managing lessons, dealing also with the storgae and accessibility issues.
In a few sentences:
a. The lessons are extracted from the document, and a process takes places generalizing them, writing them accoarding to some rules and merging them with existing lessons.
b. They are written into a knowledgebase of lessons, including the lessons with their rational, meta-data, links to the debriefing documents and supplemental info.
c. The lessons knowledgebase is designed to be integrated in the organizational environment in cultural, processes, computting and physical matters.
The full methodology can bre found in  a book descrining it: https://www.amazon.com/Holistic-Approach-Lessons-Learned-Organizations/dp/1138564761#ace-g9859629705
I got positice feedbacks form colleagues woldwide as to this methodology.
If you have any specific questions- please adress me here or directly (moria@...) and I will be happy to explain/answer any issue concerning.
Moria


Chris Collison
 

Fully agree with you regarding the ‘clearing house’ concept Nick, and great chapter by the way.

  

The perfect lessons learned database is an empty one – and conversely, a library of lessons which are starting to gather dust is an indicator of a failure of organisational learning. 

 

I wonder if we need a metaphor with in which lessons have a shorter shelf-life and are a means to an end rather than an end in themselves…    A lessons learned larder perhaps?

 

Chris Collison

Knowledgeable Ltd

Author of the KM Cookbook

@chris_collison

 

 

 

From: <main@SIKM.groups.io> on behalf of Nick Milton <nick.milton@...>
Reply to: "main@SIKM.groups.io" <main@SIKM.groups.io>
Date: Friday, 8 January 2021 at 08:59
To: "main@SIKM.groups.io" <main@SIKM.groups.io>
Subject: Re: [SIKM] Lessons Learned Storage & Access #lessonslearned

 

David, the best way to deal with massive numbers of lessons, is to embed them into guidance and best practice. You may have hundreds of lessons now, in a few years you will have thousands, and asking people to sift through these, resolving contradictions, sorting through repeat and duplicate lessons, becomes completely impractical.

 

If you look at organisations which are successful in lesson learning, such as NASA, the Oil Sector, the Military etc, you see that the lessons database (or lessons management system) is not the final repository of the lessons, but is a clearing house, directing the lessons to the subject matter experts who will embed them into procedure, process, guidance and doctrine. The lessons management system only holds those lessons which are still in process of being learned, and once that lesson is embedded into working practice it can be considered “learned” and removed from the system.

 

Project managers therefore only really need to follow the updated guidance, into which the lessons are embedded, rather than sifting through hundreds or thousands of entries.

 

You can find more details of this approach on my blog (here for example), and in my book “The Lesson Learned handbook”. The attached article may also be useful.

 

Nick Milton
Knoco Ltd
www.knoco.com

blog  www.nickmilton.com

twitter @nickknoco

Author of the recent book - "The Knowledge Manager’s Handbook"

 

"Ambition without knowledge is like a boat on dry land." 
--Mark Lee

 

 

From: main@SIKM.groups.io <main@SIKM.groups.io> On Behalf Of David Graffagna
Sent: 07 January 2021 16:53
To: main@SIKM.groups.io
Subject: [SIKM] Lessons Learned Storage & Access #lessonslearned

 

Hello all,

 

As I have mentioned in previous messages, my KM Team has a number of work-in-progress efforts aimed at enhancing our overall knowledge sharing environment. One of our targets for this year is a focus on a more standard approach to soliciting, gathering, capturing and providing access to key lessons learned from variety of projects and initiatives.

 

My question to this group regards your knowledge and insight around the storage of those lessons learned and providing access to lessons learned/insights for a broad audience to tap into and consume. Let me set the context so you have a sense of where our challenges lie.

 

Our primary source for lessons learned typically comes from significant, cross-function, multi-year projects … so numerous people involved, a wide variety of functional areas participating, and broad range of potential knowledge areas for learning. Over the past months we have worked with a handful of project managers in soliciting lessons from their project team members as part of the project wrap-up/closeout; helping us get a sense of the breadth and depth of what those teams learned during their initiative.

 

Frankly, the volume and value of what we have received back is beyond our initial expectations. The team members, individually or in small functional groups, have been great in answering the standard set of questions we have crafted and capturing replies in the format we have provided (Excel for now). One team, for example, consisting of 15 individuals provided us with more than 70 individual “line items” of lessons learned on anything from budget/finance, communications, design & development, marketing/commercialization, production planning, risk mitigation … and on and on across a long list of knowledge areas and activities. Currently, from six projects we’ve ‘tested’ we have over 500 lessons learned, but grouped (and captured) specific to each particular project.

 

Here's one of my biggest challenges … if we have hundreds of lessons learned what’s the best way of capturing and sharing (e.g., making them accessible) those without overwhelming our audiences … while making it easy for them to find the right lesson in the right context?

 

So, bottom line … would love to know good, effective approaches you’ve seen around capturing and sharing those lessons. What have you seen around lessons learned from broad-ranging projects?

 

Looking forward to hearing your thoughts and insights!

 

Best regards,

 

David Graffagna


Nirmala Palaniappan
 

Hi David,

You’ve already received some excellent answers and pointers. Here are some insights and suggestions I am happy to share. Hope you find these to be useful and relevant to your business environment 

  1. As far as possible, it is a good idea to extend and enhance existing systems to capture lessons learned on the go as opposed to setting up a separate technology platform. For example, if you have a product management system or a CRM platform, it may be more effective to upgrade/customise them to include lessons learned 
  2. If you have no option to customise existing systems and are setting up a separate system, do integrate it with existing systems and bring it under a common search umbrella 
  3. Conduct brainstorming sessions with subject matter experts and key users to decide on the metadata for lessons learned. Map it to the processes, type of knowledge, expected benefits, whether it is conceptual or practical, time frame and so on
  4. To add to Nick’s excellent input regarding embedding lessons learned into procedures, processes, checklists etc, you could include a status box in the lessons learned platform and archive those that have been institutionalised and converted into a “habit”
  5. If your organisation enjoys video-based learning, do remember that it is not always necessary to document lessons learned in a conventional manner. Some lessons learned can be curated into an impactful video 
  6. If you can afford it, have content writers work on polishing and making the lessons learned consumable and enjoyable 
  7. Create and provide a lot of sample templates to bring in at least some amount of standardisation of content 
  8. Doing #7 might help you leverage on Machine Learning/NLP algorithms to discover patterns, analyse them and use them as inputs for decision-making/Management 
  9. If feasible, identify and employ champions and give them the responsibility of “managing” lessons learned in business critical and/or evolving areas. Engage them in curating and assisting in the application of lessons learned in the said areas 
  10. Get creative in the way you brand the initiative/programme and make it enjoyable and rewarding (though, it seems like your colleagues don’t particularly need encouragement in submitting lessons learned)

If you would like to discuss this or have further queries, please do not hesitate.

Regards
Nirmala 

On Fri, 8 Jan 2021 at 5:43 PM, Chris Collison <chris.collison@...> wrote:

Fully agree with you regarding the ‘clearing house’ concept Nick, and great chapter by the way.

  

The perfect lessons learned database is an empty one – and conversely, a library of lessons which are starting to gather dust is an indicator of a failure of organisational learning. 

 

I wonder if we need a metaphor with in which lessons have a shorter shelf-life and are a means to an end rather than an end in themselves…    A lessons learned larder perhaps?

 

Chris Collison

Knowledgeable Ltd

Author of the KM Cookbook

@chris_collison

 

 

 

From: <main@SIKM.groups.io> on behalf of Nick Milton <nick.milton@...>
Reply to: "main@SIKM.groups.io" <main@SIKM.groups.io>
Date: Friday, 8 January 2021 at 08:59
To: "main@SIKM.groups.io" <main@SIKM.groups.io>
Subject: Re: [SIKM] Lessons Learned Storage & Access #lessonslearned

 

David, the best way to deal with massive numbers of lessons, is to embed them into guidance and best practice. You may have hundreds of lessons now, in a few years you will have thousands, and asking people to sift through these, resolving contradictions, sorting through repeat and duplicate lessons, becomes completely impractical.

 

If you look at organisations which are successful in lesson learning, such as NASA, the Oil Sector, the Military etc, you see that the lessons database (or lessons management system) is not the final repository of the lessons, but is a clearing house, directing the lessons to the subject matter experts who will embed them into procedure, process, guidance and doctrine. The lessons management system only holds those lessons which are still in process of being learned, and once that lesson is embedded into working practice it can be considered “learned” and removed from the system.

 

Project managers therefore only really need to follow the updated guidance, into which the lessons are embedded, rather than sifting through hundreds or thousands of entries.

 

You can find more details of this approach on my blog (here for example), and in my book “The Lesson Learned handbook”. The attached article may also be useful.

 

Nick Milton
Knoco Ltd
www.knoco.com

blog  www.nickmilton.com

twitter @nickknoco

Author of the recent book - "The Knowledge Manager’s Handbook"

 

"Ambition without knowledge is like a boat on dry land." 
--Mark Lee

 

 

From: main@SIKM.groups.io <main@SIKM.groups.io> On Behalf Of David Graffagna
Sent: 07 January 2021 16:53
To: main@SIKM.groups.io
Subject: [SIKM] Lessons Learned Storage & Access #lessonslearned

 

Hello all,

 

As I have mentioned in previous messages, my KM Team has a number of work-in-progress efforts aimed at enhancing our overall knowledge sharing environment. One of our targets for this year is a focus on a more standard approach to soliciting, gathering, capturing and providing access to key lessons learned from variety of projects and initiatives.

 

My question to this group regards your knowledge and insight around the storage of those lessons learned and providing access to lessons learned/insights for a broad audience to tap into and consume. Let me set the context so you have a sense of where our challenges lie.

 

Our primary source for lessons learned typically comes from significant, cross-function, multi-year projects … so numerous people involved, a wide variety of functional areas participating, and broad range of potential knowledge areas for learning. Over the past months we have worked with a handful of project managers in soliciting lessons from their project team members as part of the project wrap-up/closeout; helping us get a sense of the breadth and depth of what those teams learned during their initiative.

 

Frankly, the volume and value of what we have received back is beyond our initial expectations. The team members, individually or in small functional groups, have been great in answering the standard set of questions we have crafted and capturing replies in the format we have provided (Excel for now). One team, for example, consisting of 15 individuals provided us with more than 70 individual “line items” of lessons learned on anything from budget/finance, communications, design & development, marketing/commercialization, production planning, risk mitigation … and on and on across a long list of knowledge areas and activities. Currently, from six projects we’ve ‘tested’ we have over 500 lessons learned, but grouped (and captured) specific to each particular project.

 

Here's one of my biggest challenges … if we have hundreds of lessons learned what’s the best way of capturing and sharing (e.g., making them accessible) those without overwhelming our audiences … while making it easy for them to find the right lesson in the right context?

 

So, bottom line … would love to know good, effective approaches you’ve seen around capturing and sharing those lessons. What have you seen around lessons learned from broad-ranging projects?

 

Looking forward to hearing your thoughts and insights!

 

Best regards,

 

David Graffagna

--
"The faithful see the invisible, believe the incredible and then receive the impossible" - Anonymous


Tom Barfield
 

David - based on the many responses this sounds like a topic that would benefit from a live discussion.  Would you be interested in having the community host a live peer assist discussion to focus on your question?  If so, I will work with others in the community to set this up.

Tom


Barbara Fillip
 

Hello David,
Perhaps to complement the excellent answers already provided, I would ask a slightly provocative question.  Are you sure a lessons learned database is the right answer?  While it is satisfying to collect lessons, organize  them and do everything possible to make them accessible, I have become increasingly skeptical of the focus on collecting and storing,  which can become overwhelming when you arrive at a certain volume of lessons to process. Having worked with Excel-style lessons learned capture processes, I am wondering how much duplication and overlapping or related lessons you may be seeing? How are you validating the lessons? Do you have a process for reviewing and culling lessons? Sometimes lessons emerging from projects are full of useful cues for training departments about what to focus on in terms of training rather than truly original lessons.  In other words, while a majority of the focus of such efforts tends to be placed on collect and store for access, it is probably more effective to 1) identify critical knowledge gaps that can be addressed by learning from the project teams themselves; 2) collect lessons specifically around these knowledge gaps rather than a general appeal for lessons; 3) process the lessons for the purpose of embedding them in training, job aids, guidance documents, etc... and don't bother trying to get individual employees to access a general lessons learned repository. 
While a general lessons learned process might be beneficial for projects to go through, if the processing and repackaging is focused on priority themes (critical knowledge as previously mentioned) it should be both more manageable and more effective in terms of uptake.

So to go back to my original question, is a lessons learned database the right answer to your challenge? A lessons learned process might be part of the answer, but storing and making the lessons accessible to a broad audience may not be the optimal approach if you really want the lessons to be shared and utilized. 

Best,
Barbara Fillip


 

On Sun, Jan 10, 2021 at 8:35 PM Tom Barfield <thomas.m.barfield@...> wrote:
David - based on the many responses this sounds like a topic that would benefit from a live discussion.  Would you be interested in having the community host a live peer assist discussion to focus on your question?  If so, I will work with others in the community to set this up.

Tom


Stephen Bounds
 

Hi David,

I would echo Barbara's sentiments and suggest that it would be very valuable to ensure that you understand the ROI (and/or relative ROI) of your work. For example, can you answer these questions:

  • What actions are going to yield the biggest results from a lessons learned exercise?
  • How often will this happen?
  • Are lessons mostly going to improve one team's work or lots of teams' work?

Knowing this will help you to frame how much effort you put into each of capture, categorisation, discovery, and application. Unfortunately too many KM efforts fail because they lack the sustainable returns to justify the effort involved, and having a clear sense of value is critical to overcoming this barrier.

Cheers,
Stephen.
====================================
Stephen Bounds
Executive, Information Management
Cordelta
E: stephen.bounds@...
M: 0401 829 096
====================================
On 11/01/2021 9:13 pm, Barbara Fillip wrote:

Hello David,
Perhaps to complement the excellent answers already provided, I would ask a slightly provocative question.  Are you sure a lessons learned database is the right answer?  While it is satisfying to collect lessons, organize  them and do everything possible to make them accessible, I have become increasingly skeptical of the focus on collecting and storing,  which can become overwhelming when you arrive at a certain volume of lessons to process. Having worked with Excel-style lessons learned capture processes, I am wondering how much duplication and overlapping or related lessons you may be seeing? How are you validating the lessons? Do you have a process for reviewing and culling lessons? Sometimes lessons emerging from projects are full of useful cues for training departments about what to focus on in terms of training rather than truly original lessons.  In other words, while a majority of the focus of such efforts tends to be placed on collect and store for access, it is probably more effective to 1) identify critical knowledge gaps that can be addressed by learning from the project teams themselves; 2) collect lessons specifically around these knowledge gaps rather than a general appeal for lessons; 3) process the lessons for the purpose of embedding them in training, job aids, guidance documents, etc... and don't bother trying to get individual employees to access a general lessons learned repository. 
While a general lessons learned process might be beneficial for projects to go through, if the processing and repackaging is focused on priority themes (critical knowledge as previously mentioned) it should be both more manageable and more effective in terms of uptake.

So to go back to my original question, is a lessons learned database the right answer to your challenge? A lessons learned process might be part of the answer, but storing and making the lessons accessible to a broad audience may not be the optimal approach if you really want the lessons to be shared and utilized. 

Best,
Barbara Fillip


 

On Sun, Jan 10, 2021 at 8:35 PM Tom Barfield <thomas.m.barfield@...> wrote:
David - based on the many responses this sounds like a topic that would benefit from a live discussion.  Would you be interested in having the community host a live peer assist discussion to focus on your question?  If so, I will work with others in the community to set this up.

Tom


Tim Powell
 
Edited

Hi all,

 

I second Stephen’s comments below about the relative ROI of lessons learned databases (LLDs).  The big challenges in my experience are (1) INPUT – that there may not be consensus on what issues to cover and/or what the resolutions were -- especially where non-optimal results occurred; and (2) OUTPUT, the applicability of any given “lesson” to any novel situation.  Relevance and timeliness may both be at issue. 

 

Though appealing in theory, I have yet to see a LLD provide user value on a sustained basis.  I would be glad to hear of examples where they did.

 

Regards, 

Tim

TIM WOOD POWELL | President, The Knowledge Agency® Author, The Value of Knowledge

New York City, USA | DIRECT/MOBILE +1.212.243.1200 | ZOOM 212-243-1200

SITE www.KnowledgeAgency.com | BLOG www.KnowledgeValueChain.com

 

 

From: <main@SIKM.groups.io> on behalf of Stephen Bounds <km@...>
Reply-To: "main@SIKM.groups.io" <main@SIKM.groups.io>
Date: Monday, January 11, 2021 at 4:45 PM
To: "main@SIKM.groups.io" <main@SIKM.groups.io>
Subject: Re: [SIKM] Lessons Learned Storage & Access #lessonslearned

 

Hi David,

I would echo Barbara's sentiments and suggest that it would be very valuable to ensure that you understand the ROI (and/or relative ROI) of your work. For example, can you answer these questions:

  • What actions are going to yield the biggest results from a lessons learned exercise?
  • How often will this happen?
  • Are lessons mostly going to improve one team's work or lots of teams' work?

Knowing this will help you to frame how much effort you put into each of capture, categorisation, discovery, and application. Unfortunately too many KM efforts fail because they lack the sustainable returns to justify the effort involved, and having a clear sense of value is critical to overcoming this barrier.

Cheers,
Stephen.

====================================
Stephen Bounds
Executive, Information Management
Cordelta
E: stephen.bounds@...
M: 0401 829 096
====================================

On 11/01/2021 9:13 pm, Barbara Fillip wrote:

Hello David,

Perhaps to complement the excellent answers already provided, I would ask a slightly provocative question.  Are you sure a lessons learned database is the right answer?  While it is satisfying to collect lessons, organize  them and do everything possible to make them accessible, I have become increasingly skeptical of the focus on collecting and storing,  which can become overwhelming when you arrive at a certain volume of lessons to process. Having worked with Excel-style lessons learned capture processes, I am wondering how much duplication and overlapping or related lessons you may be seeing? How are you validating the lessons? Do you have a process for reviewing and culling lessons? Sometimes lessons emerging from projects are full of useful cues for training departments about what to focus on in terms of training rather than truly original lessons.  In other words, while a majority of the focus of such efforts tends to be placed on collect and store for access, it is probably more effective to 1) identify critical knowledge gaps that can be addressed by learning from the project teams themselves; 2) collect lessons specifically around these knowledge gaps rather than a general appeal for lessons; 3) process the lessons for the purpose of embedding them in training, job aids, guidance documents, etc... and don't bother trying to get individual employees to access a general lessons learned repository. 
While a general lessons learned process might be beneficial for projects to go through, if the processing and repackaging is focused on priority themes (critical knowledge as previously mentioned) it should be both more manageable and more effective in terms of uptake.

So to go back to my original question, is a lessons learned database the right answer to your challenge? A lessons learned process might be part of the answer, but storing and making the lessons accessible to a broad audience may not be the optimal approach if you really want the lessons to be shared and utilized. 

 

Best,

Barbara Fillip



 

 

On Sun, Jan 10, 2021 at 8:35 PM Tom Barfield <thomas.m.barfield@...> wrote:

David - based on the many responses this sounds like a topic that would benefit from a live discussion.  Would you be interested in having the community host a live peer assist discussion to focus on your question?  If so, I will work with others in the community to set this up.

Tom

 


David Graffagna
 

Thanks Dennis ... I actually have your series of LinkedIn posts about lessons learned bookmarked and have used the series in the past for reference. Great stuff, very valuable. I appreciate you reminding me about that set of resources.

Best,

David


David Graffagna
 

Gabi ... I'll be happy to share our working set of questions we use to help project leads tackle gathering lessons learned their teams. I will clean them up (e.g., remove any corporate-specific references) and share a copy in this forum. 

Frankly, I have borrowed liberally from other resources to frame how we ask for lessons learned so these may be similar to things you have seen elsewhere, but as I said I'm happy to share ours!

Best,
David


Matt Moore
 

Unless a lessons learned database is an element within an ongoing continuous improvement program, it will not yield value by itself.

Unless you can define who needs to learn a particular lesson and how you can identify when they have learned it, you have not adequately identified the lesson.

If your organisation is fat and happy then people will view learning lessons as an annoying waste of time.


Gabriela Fitz
 

Terrific, thanks! I have been designing some reflection practices (for social sector orgs) and am looking for additional ideas about questions that could serve teams working within quite different issue areas.


On Tue, Jan 12, 2021 at 3:13 PM David Graffagna <davidgraffagna@...> wrote:
Gabi ... I'll be happy to share our working set of questions we use to help project leads tackle gathering lessons learned their teams. I will clean them up (e.g., remove any corporate-specific references) and share a copy in this forum. 

Frankly, I have borrowed liberally from other resources to frame how we ask for lessons learned so these may be similar to things you have seen elsewhere, but as I said I'm happy to share ours!

Best,
David

--

Gabriela Fitz

Think Twice LLC

773.882.8250 | LinkedIn

www.thinktwicellc.com


Preferred Pronouns: she/her/hers





Andrew Trickett
 

Hi David,

I think that the breadth of this topic might benefit from a live discussion as suggested earlier.

I'd be happy to participate in this as I would imagine would others to help you out, or give you some areas for consideration.

I've been posting on Linked in some of my thoughts on lessons learned which engendered some good dialogue, as has Nirmalla who has also responded to this thread.

Maybe if we record it this can be shared with other members of SIKM. 


David Graffagna
 

Gabi,

Most of what we have done with lessons learned to this point has been in the context getting to know our audiences (e.g., project team types), gathering input on any lessons learned approaches they have used in the past, looking for opportunities for consistency (e.g., how we define a lesson learned in our environment, standard lists of knowledge areas/activities), and asking our audiences for their insight on how they would draw value out of any lessons learned solution.

 

The generic questions we ask of individuals/teams in the process of gathering lessons learned are pretty short and straightforward (and I’ve included them below). Typically our project teams span many functional and geographic areas, as well as a wide variety of experience levels and responsibilities. Prior to us even getting those questions in front of team members, we work with the project team leadership to:

  • Understand the breadth of the team (e.g., functions, geography, and so on) so we have a sense of what we are working with,
  • Describe the purpose of the project or a project summary that we’ll share with team members to ensure appropriate context for collecting learnings,
  • State our goal for gathering lessons (e.g., to learn from the project by identifying what we should continue to do, what we should stop doing, and what we should start doing in prep for future, similar efforts/initiatives),
  • Define exactly what we are asking of team members (e.g., knowledge area, function/activity, impact over time, situation - what happened & why, actions taken, lessons learned, future actions/takeaways and recommendations),
  • Prep an email or frame a call/meeting to:
    • give team members background (e.g., why we’re doing this, the importance of gathering learnings, what we’re asking, what we’ll do with their input), 
    • frame key points in capturing meaningful lessons (e.g., don’t exaggerate/rationalize/criticize, all viewpoints and perspectives are important, no right or wrong, ask clarifying questions, and so on), and
    • provide sample questions to get the team thinking about what lessons they actually learned (e.g., what worked well/did not, what would you do differently, what events weren’t anticipated, how were challenges/changes communicated, any changes to scope/costs/schedule, how were issues resolved),
    • to think about both positive results (e.g., things that went well, practices to repeat) and desirable changes (e.g., things that need improvement or replacement),
    • describe for the team how the lessons learned gathering process will work (e.g., as individuals, in small teams, a project team as a whole, in person/on line/email), where they should submit their input, and timing.

After the above we deliver the lessons learned “tool” we use to capture the lessons (typically an Excel or Word document but assessing better solutions). That tool includes:

  • Restatement of the purpose and goal of the effort, and (at a high-level) what we’re asking for,
  • Specific definitions of the information we are gathering (e.g., what does “knowledge area” mean, what does “function/activity” mean and so on),
  • Requested “demographic” information (e.g., location/region/work-stream/business unit, general project responsibilities or function, participants in lessons learned),
  • Specific questions:
    • Knowledge Area and Activity … Indicate the “knowledge area” and “function/activity” that best reflects the topic or are of impact; we provide a standard list of areas, functions, activities from which they can choose,
    • Impact Over Time … What was the impact over time of this specific experience? Choices include: Went well initially & stayed good throughout the project, Started poorly but improved as the project progressed, Started out well but go worse over the course of the project, Started poorly and did not improve over time.
    • Situation & Experience … Succinctly describe the experience, what happened and why it happened.
    • Tasks & Actions Taken … Describe any actions, tasks for measures taken to address the experience.
    • Lessons Learned, Impact on Facilities, Operations, Etc. … Identify key take-aways/lessons learned from the experience that may be applied in the future.
    • Recommendations / Future Actions … Provide any recommendations and resulting future actions/activities to implement the lessons learned (e.g., any planned, in-flight or suggested actions and suggested responsible parties).

 

I hope some of this is of value. We have drawn from a number of different, external resources (some provided by members of this SIKM group), and some of our own past experiences to begin framing out our approach. I don’t believe any of this is very new, it is simply how we are applying what we know and what we’re learning to our environment and our audiences needs.

 

Best,

 

David