Author: Nick Milton
This is a very readable book in the Nick Milton/Patrick Lambe tradition (see KM Approaches, Methods and Tools, and The Knowledge Manager's Handbook) providing a menu of approaches, in this case focusing on knowledge capture methods and more specifically, lessons learned.
Regardless of books and guidance in other forms, there is nothing like working with real projects and real teams to understand the complexity of lessons learned activities (and why they are often so maligned).
Two key points about lessons learned:
1. Lessons stored in a database have very little use (that's almost a cliché). No one uses them. There is some benefit to whoever documented the lesson (whether an individual or a team), but once it is in storage, it is almost certainly lost. Therefore, why bother? An exception would be a lesson that was so critical that it resulted in a process or policy change, at which point it can be removed from the lessons learned database. The danger, even in that case, is that people will forget why the process or policy is the way it is and eventually revert to previous practice, thereby unlearning or forgetting. Unlearning is not always a bad thing. In fact, it can be necessary, but that would be the subject of another post.
It's not that the databases of lessons are completely useless. They are not useful in the ways most people expect them to be useful. There are instances where lessons stored in a database can be useful. The database curator can and should do some regular data mining and analysis to identify possible trends, recurring lesson themes, etc... and advise management on possible actions. At NASA/Goddard, I've used the database of lessons to help identify themes to be addressed in knowledge sharing workshops (aka Critical Knowledge Conversations). The database was never the only source of information I relied on for that purpose but it contributed to decisions about what topics to address. There are other ways lessons could and should be better integrated into the project life cycle, but that should be yet another post.
2. Documenting lessons learned well is more difficult than most people imagine. I can't stress that enough. Individual lessons learned can be heavily biased. Group lessons are less likely to be biased by any single individual perspective but they will tend to have a group/team bias. A project team's lessons are lessons from the team's perspective, not the organization's perspective. The challenge is for an experienced facilitator to guide teams through the process of identifying and documenting valuable lessons without requiring the teams to take any kind of special lessons learned training on the part of teams. This can be done over time, with lots of iterations of discussions around lessons. Discussing what constitutes a valuable lesson in the abstract is not as useful as struggling with a real lesson and documenting it with some guidance.
We need a broader vocabulary to discuss lessons. In most cases, when I facilitate group discussions to discuss and document lessons, we end up with a lot of valuable observations and insights, lots of opinions, some whining or venting, and sometimes a lesson or two.
I have more books left on my shelf than there are days to complete this 30-day challenge. When appropriate, I will group them if they address a very similar topic within Knowledge Management. Another book on my shelves addressing lessons learned is Post-Project Reviews to Gain Effective Lessons Learned, by Terry Williams. This book was published by the Project Management Institute (PMI) and it has a strong project management angle. PMI has done more recently to emphasize the knowledge dimension of project management, but PM and KM haven't yet really been fully integrated.
A little further on the relatedness scale is Katrina Pugh's Sharing Hidden Know-How: How Managers Solve Thorny Problems with the Knowledge Jam. The Knowledge Jam is a detailed, well thought-out methodology for engaging groups in purposeful facilitated conversations that have impacts in terms of integration or adaptation for use. In other words, it's not a question of whether the lessons and insights will ever be used, but rather how to ensure they are used. That part of the process isn't left to chance or to other knowledge management activities (like a separate workshop).
- Revisit Sharing Hidden Know-How.
Post a Comment