In this first part of the series, I will talk about some of the challenges of leading a lessons learned practice and how I tried to address them, in other words, how I learned to sell lessons learned.
Part 1: Selling Lessons Learned as a KM Practice
Part 1: Selling Lessons Learned as a KM Practice
KM is a sales job. When I was working at NASA/Goddard helping project teams document their lessons, I was at times confronted with resistance in the form of remarks such as "no one uses the lessons learned databases, why should we bother contributing lessons to the system?" This had been exacerbated by successive reports criticizing the Agency level lessons database called the LLIS. Regardless of the merits of the critique of that system (which isn't the point of this post series), I still had to do my job.
Since I needed to convince project teams to meet with me and document lessons, I developed an approach that would overcome this resistance. It was based on a simple diagram (below) that allowed me to address the issue upfront by redirecting the conversation by saying "you're right, the lessons are not being used the way they were expected to in the databases, but that's not the right way to look at lessons."
I would use this diagram as a handout during planning meetings with the project leaders to convince them to hold a Pause and Learn (PaL) session (group reflection activity) and I would use it again (hand drawn on a flip chart) at the very beginning of the PaL session to explain why we were all there and what the benefits were. For a valuable conversation to happen, I needed both the buy-in from the project management team and the buy-in from the rest of the team. Sometimes the project management team does a good job of bringing the team to the table with the right attitude. Sometimes it's the job of the facilitator to quickly elicit that attitude at the very front-end of the meeting. There is nothing worse than a senior scientist showing up for a PaL session determined to wreck it with sarcasm about how useless these meeting seem to be since we keep repeating the same mistakes (in their opinion) or a team showing up because they've been told to be there but they really think they should be back in their office working on real immediate and tangible problems.
I would use this diagram as a handout during planning meetings with the project leaders to convince them to hold a Pause and Learn (PaL) session (group reflection activity) and I would use it again (hand drawn on a flip chart) at the very beginning of the PaL session to explain why we were all there and what the benefits were. For a valuable conversation to happen, I needed both the buy-in from the project management team and the buy-in from the rest of the team. Sometimes the project management team does a good job of bringing the team to the table with the right attitude. Sometimes it's the job of the facilitator to quickly elicit that attitude at the very front-end of the meeting. There is nothing worse than a senior scientist showing up for a PaL session determined to wreck it with sarcasm about how useless these meeting seem to be since we keep repeating the same mistakes (in their opinion) or a team showing up because they've been told to be there but they really think they should be back in their office working on real immediate and tangible problems.
Source: Rogers, E. & Fillip, B. Mapping Lessons Learned to Improve Contextual Mapping at NASA. APQC Webinar, August 18, 2017. |
Related Resources
- Philip R. Diab. "Documented Lessons Learned on Projects is a Waste of Time." July 2017 Podcast.
- Nick Milton, "Leaving Lessons in a Lessons Learned Database Doesn't Work - An Example from NASA." July 21, 2017.
No comments:
Post a Comment