Transferring lessons from one project to another seems like it ought to be a simple task. The team that has learned something writes it up, then the team that needs the lesson reads the report – knowledge transferred, end of story. But unfortunately too many attempts at lessons learned don’t work. Critical lessons end up in repositories that few people visit and when they do log in, the reports they find are often not helpful. Regrettably “Lessons learned” has earned a reputation for being a waste of time in many organizations.
It is easy to fault employees for not retrieving lessons from repositories, or to blame teams for doing a poor job of reporting, but the reality is that transferring lessons learned is a very complex task, not a simple one. It is a task that requires much more than writing, storing and reading of reports. The fault, if there is one, is the lack of recognition of the complexity involved in transferring knowledge.
To speak to that complexity it is helpful to deconstruct the process of transferring project knowledge into smaller components, each of which has associated practices that are involved in making the transfer process work:
1. Sensemaking: The members of the project team jointly make sense of what they have learned.
2. Formatting: Designers assemble, translate, aggregate, and mine projects lessons in such a way that they are useful to different groups in the organization
3. Moving: KM professionals create both pull and push mechanism so that lessons are accessible to those who need them.
In order to talk about each of the components above, I first want to establish some shorthand terms. Rather than having to repeat, “the team that learned the lessons” each time I want to refer to this group, I will use the term “originators” and for, “anyone who might make use of the lessons the originators learned,” I will use “recipients.” There are two other terms that will be useful to this discussion, “actions” and “outcomes.” “Actions” refers to what team members 1) say, 2) do, even do not do, and 3) decide as they work on a project. “Outcomes” refers to both the positive and negative results of team members’ actions. The assumption underlying the idea of lessons learned is that there is a causal relationship between team members’ actions and project outcomes. Lessons learned are primarily descriptions of actions team members took, within a certain context, and the relationship of those actions to the project outcomes. I discussed this concept in greater depth in an earlier post, “The Value of Lessons Learned.”
There are two actions that need to be taken even before the project starts. The first is to build lessons learned into the project’s budget. The second is to think through what learning is anticipated from the project, so that the project has both a performance goal and a learning goal. For example, does this project address some unique issues? Are new processes being implemented? Not every project has lessons that need to be transferred. Many projects are conducted over and over again in much the same way and unless something unexpcted happens during the course of the project, there is little need for lessons learned to go beyond the first step of sensemaking.
Sensemaking
The first step in transferring knowledge is for the originating team to figure out what it has learned. That idea may seem overly simplistic, but in the speeded up environment in which many organizations function, they often fail to bring project members together, either face-to-face or virtually, to jointly make sense of what they have learned.
I am using the term “sensemaking” rather than the more familiar term “capture” for this step because the language or label we put on a task, prefigures how we approach it. “Capture” connotes getting hold of something that already exists, like capturing a wild animal or a crook. “Sensemaking” more accurately reflects the creative process of a project team jointly building their understand of what they have learned. Although the outcome of a project is known before the sensemaking meeting, the understanding of what team members did that brought about that outcome, does not exist until the team members put it together.
The Whole Team in Conversation: A jigsaw puzzle is a useful analogy for the sensemaking step. Each team member has a piece of the puzzle, that is, knowledge of what actions he/she took and the specific outcomes that resulted from those actions. It requires the whole team, in conversation, to put the puzzle together so that a picture is
revealed. However, the analogy of the jigsaw is not totally accurate because each person also shapes their piece of the puzzle as they talk with others about it. For example, I know what I did and what outcome resulted from my actions, but I may not know the way your actions also impacted that same outcome. Moreover in attempting to spell out my own actions and the reasons behind them to you, I may come to a new understanding myself. (see We Learn When We Talk) It is in conversation that the team uncovers a fuller account of the relationship between action and outcome and therefore a more accurate picture is revealed – more accurate than could have been developed by any one individual. As tempting as it is, for cost reasons, for a project manager to try to collect each team member’s lessons sequentially, that process forgoes the conversation that shapes each piece of the puzzle and therefore diminishes the richness of the picture that is created.
The reality in many organizations is that teams disperse quickly when the project ends, making it difficult to get everyone together. But because 100% of the team cannot come together is not a reason to forgo bringing 80% or 60% of the team together for sensemaking. Even if only a portion of the team can meet they will still be able to compile a richer and more complete picture than sequential interviews can produce. And there will be more project workers who can carry that more complete picture of the project lessons across the organization.
Multiple Lessons: The lesson that is learned by a team is the picture or story that they are able to put together at that time. It is a story that suffices; an approximation that team members can use to take next steps. But it is not the only story or lesson that could have been constructed from that set of actions and outcomes. Lessons constructed at any one point are not so much “truth” as they are the team’s current perspective. The Challenger disaster provides a useful illustration. Because the data (congressional transcripts, participant accounts, etc.) from the Challenger disaster was publically available, people from many disciplines have been able to apply their unique lens to the action/outcome relationships that occurred. The disaster has been usefully reframed from those perspectives to illustrate such things as groupthink, the troubling relationship between management and engineering, and engineering detail about how an O-ring functions - all viable, elucidating insights. I have myself often used the script from the Challenger disaster testimony to teach Argyris’ concepts of advocacy and inquiry. Inviting into the sensemaking meeting observations from different disciplines increases the knowledge that grows out of such meetings. Both time and perspective reframe a team’s actions and outcomes to provide new lessons.
Psychological Safety: To make sense of what has been learned, team members need to be able to speak openly and freely with each other, without concern for rank or blame. The meeting environment needs to have, what Edmondson calls, psychological safety, where members feel free to question and challenge each other. A skilled facilitator can help to establish psychological safety for the team. Team members, in striving for openness and honesty, occasionally say things in a way that others’ experience as blaming or critical. A skilled facilitator can help team members rephrase statements and clarify meanings so that both honesty and civility are maintained. A facilitator can also bring structure to a group conversation, identifying issues for the agenda, making sure needed data are in the room before the meeting, setting the tone, and keeping the group focused.
Sensemaking Separate from Documentation: When team members know that what they are saying will become part of a permanent record, psychological safety is reduced. For this reason sensemaking needs to be separated from constructing a document for the retention of the lessons learned. Without getting the sensemaking step right, there is little to transfer that is worth the cost.
Periodic Sensemaking: Particularly with lengthy projects, there is a need to make sense of what is being learned at appropriate stages rather than waiting until project end. When memories fade what is often lost is not the action itself, but the reasoning behind the action, as well as the context in which the action took place – both vital elements of lessons learned
Team Members as Brokers for Project Lessons Learned: Having spent the time to jointly make sense of what they have learned, every team member becomes a broker of the
team's knowledge carrying it to his/her next project. The implications of in-depth lessons being networked by individuals from multiple project teams across the whole organization are profound. If knowledge transfer went no farther than sensemaking, a considerable amount of transfer across the organization would have been achieved.
Formatting
The second component is constructing the originator’s lessons in such a way that they would be useful to recipients in the organization. That requires several steps, e.g. prioritizing the lessons, anticipating whom the recipients might be as well as their absorptive capacity for this content, and then identifying the medium through which the content would be best expressed.
The originating team is the best source of information about many of those issues. They are, however, not the main players in formatting the lessons. Formatting requires writers, videographers, and instructional designers, who have the right skills.
Even if the originators had the needed skills, they would not be the best people to format the lessons. They suffer from the “curse of knowledge,” a paradoxical phenomenon in which the more we know about something, the harder it is for us to explain it to someone who has not been involved. As experts we have a hard time being able to imagine what it is like not to know and we therefore leave out critical elements needed to make effective use of the knowledge. An example of this phenomenon is the way computer manuals were written in the 1980s. Programmers who had developed the software wrote most of the manuals and the result was that you almost had to be a programmer in order to read them. Now, people with journalism skills, who probably know very little about programming, write the manuals, resulting in them being much more useable.
The formatting step starts from the assumption that there is no way to construct everything that has been understood by the originating team. Long ago Polanyi noted, “We know more than we can say,” and more recently Dave Snowden has added, “and we can say more than we can write.” Even having spent time making sense of what they have learned, there is much that the originating team understands that is tacit and is available to others only in response to a specific need or question that calls forth that knowledge from a team member.
Prioritize Which Lessons Need to be Formatted: Prioritizing is necessary because transferring knowledge is costly. Granted that it is not costly to just stick a lesson in a database, but that is not transfer- it’s storage. Because real transfer is costly, it is critical to be selective about what lessons to put time and energy into formatting. Clearly, not every project and not every lesson that has been learned in a project rises to the level of needing to be transferred to others. Many project lessons are instructive to the originating team, but are in no way unique. In those situations lessons may not be worth the cost of formatting. The central question for prioritization is: Is understanding this lesson important to the future work of the organization? To answer that question requires input from the originating team, but because it is a resource question, it is also a question that requires management involvement.
Identifying Potential Recipients: The more a lesson is targeted to specific recipients, the more useful it becomes. In trying to make a lesson useful to a wide range of needs, it can become so general and so lengthy that it is of little use to anyone.
The originating team can be helpful in identifying potential recipients for its lessons; for example, team members know other projects doing similar work, follow-on projects, and up-coming related projects. They know about training courses that their lessons could update or lessons that should be added as a step in the project management process. Targeting recipients allows designers to know what content to include, what to leave out, and how much context is necessary for understanding.
Translate for Different recipients: Having identified target recipients it is necessary to translate what has been learned for each. Translation involves tailoring content, language, and context. For example, management may be most interested in lessons related to time and cost savings, while other project teams may be most interested in how specific actions would reduce their travel time, and project managers may need detail about the sequencing of activities.
Lesson often need to be modularized so that pertinent knowledge is made available to each type of recipient, eliminating the need for recipients to have to read through lengthy reports that do not pertain to them in order to fine a single useful nugget. And of course, recipients are more likely to review and digest knowledge in smaller segments, as all of us are learning from the popularity of YouTube and blogs.
An important issue for translation is the absorptive capacity of the recipient. This term refers to the existing knowledge recipients have that will allow them to connect the new knowledge in the lesson to their own understanding. The lessons of the originating team may have the potential to critically impact the work of a recipient team that draws on a very different discipline. That team may be equally smart and experienced, but still lack the background to make use of the originating team's knowledge without considerable additional detail. The same problem arises with inexperienced teams who need to make use of the lessons of their more advanced colleagues. Lessons learned, like courses, need to be tailored to the anticipated learner.
Mining Lesson Learned for Themes: There is great value in aggregating lessons in order to pull out topics for specific recipients. There are important lessons that are not evident in the reports from a single project team, but are found in the trends across multiple projects. For example, the US Army, Center for Army Lessons Learned (CALL) regularly receives After Action Reviews (AARs) from units in Iraq and
Afghanistan. One of the troubling realities of combat is that soldiers are in the greatest personal danger at the beginning of their combat experience. Lessons about how soldiers should protect themselves are embedded in many of the AARs CALL receives. But it would be unreasonable to expect soldiers to search through thousands of
AARs to find the knowledge needed for their own safety. CALL has aggregated those lessons into a handbook called, “The First Hundred Days”. This re-purposing of the lessons from those many AARs illustrates the need to translate what was learned to serve specific needs. The First Hundred Days handbook is also an illustration of taking absorptive capacity into account. The manual, directed at new combatants, has very different language than it would have had for experienced soldiers. As a second re-purposing, a handbook has also been prepared for leaders about how they need to work with their soldiers who are in their first hundred days.
Selecting Formats: There are lessons that are best told as a story, others that are effective as case studies, or as displays of charts or graphs. Some require pictures or video to make them understandable. The question of what format would best convey the lesson is an instructional design decision but it is informed by the knowledge of the originating team. As an example, The 10th Mountain unit of the US Army developed a much
needed way to quickly remove the door of a humvee that had been overturned by an IED, often leaving soldiers trapped inside. This specialized crowbar, which they called the Rat Claw, was attached to every humvee. Knowledge about the Rat Claw was transferred to other operational units first by pictures and then quickly followed by a “how to” video.
To summarize, formatting lessons learned so that they are relevant and understandable to recipients takes specialized skills and resources. Without that effort lessons tend to languish in repositories, no matter how good the search engine. It is helpful to employ multiple pathways to increase the flow of lessons throughout the organization. Being able to read a case study, listen to a brief video, engage originators in an on-line conversation all work to put lessons in motion.
Moving
The third component of transferring lessons learned is to put processes in place that will move lessons around the organization. I am again struck by the flawed implication of the label we typically use for this step, “transfer.” (A term I am guilt of using in the title of this post as well.) Transfer implies that knowledge that has been made available through some media and can be inserted into the minds of others in the same form. And of course we know that is not the way we as human beings develop new knowledge. Any uptake of others’ knowledge is modified by the current knowledge the team or individual already has and in the best of cases is adapted, not adopted. I’m using the term “moving” here as in putting into motion. Moving lessons learned is accomplished through both push and pull.
Pull is the most powerful, it works when recipients are aware of what they don’t know. There are many ways pull can happen, all of them initiated by someone who recognizes he/she needs help with a question or a problem; 1) on-line search enables recipients to quickly find pertinent lessons in repositories, 2) expert locator systems or facebook-like systems enable recipients to find colleagues willing to share their lessons directly, 3) the Q & A of on-line communities provides a place to ask questions and receive answers from multiple originators, 4) peer assist sets up face-to-face conversation with originators.
The Fluor Corporation is a great example of on-line communities where recipients pull lessons from their colleagues. Almost all of Fluor’s work is done on a project basis. They construct major facilities like airports and power plants in remote parts of the world. Because local knowledge is often unavailable, Fluor engineers need to tap into the lessons other projects have learned - lessons that speak to critical issues like climate conditions, the availability of equipment locally, and national regulations. Fluor relies on its functional communities to spread project lessons learned. Because these communities have such importance to Fluor, they are set up through a rigorous development process. And they are held to demanding standards including responding to questions within 48 hours and a high level of expectations for the participation of subject matter experts. Both standards help Fluor live up to the motto, “When I hire Fluor I hire the whole company.”
Increasingly facebook-like media are becoming the way people connect more fully than the earlier expert locator systems were able to do. I have described A-Space Download A_Space_Study.pdf (276.4K) the system that spans all sixteen intelligence agencies. Deloitte’s D-street is also an excellent example and has greatly increased collaboration across Deloitte. On D-Street, a Deloitte employ looking for someone to ask about lessons on a specialized topic, has, at a glance, a host of information about the potential originator including, their picture, projects they have worked on, their blog, their publications, a visual map of their colleagues, and if the originator chooses to reveal it, their personal interests, family pictures, languages, on and on. The availability of more expansive information provides the asker a way to establish rapport. It is the equivalent of the small talk that precedes more serious conversation between relative strangers. To ask you a question, it helps if I know something more about you than your position.
Peer assist is another great pull mechanism as well as being a way for recipients to put themselves “in the company of smart people” so that they can learn ideas of which they were unaware. Peer assist is a team-to-team exchange. A team (the recipient) that is just starting a new project invites a team (or members from several teams) who have had greater or different experiences with that topic to meet with them. The meeting is a conversation. There are no presentations from the originating team, rather a peer assist is an opportunity for the recipient team to ask in-depth questions about how to achieve their objectives given the context they face - to learn from colleagues what they did not know that they did not know. Nick Milton tells this story about peer assist. His North America client wanted to establish a presence in Europe in order to quickly become the dominant player in that particular market. While the client had extensive experience of the North American market they had no experience of the European market. The client created a strategy and implementation plan for approaching the European market, including such diverse topics as how to work with the regulators, standards, marketing and local supply. Then with Nick’s help the client held a peer assist with a local organization that had European knowledge to improve on their plans and accelerate their progress in becoming market leaders in Europe.
Knowledge Harvesting: Knowledge Harvesting Download KM assessment conducted using KM principles.pdf (62.4K)is a process developed at Intel and now used by other corporations. It is the reverse of a peer assist. The originating team calls for the knowledge harvest in order to spread a critical lesson they have learned to other parts of the organization. But they are very selective about who they invite as recipients - only inviting those who have some current use for the lessons. That might include someone from a similar project who can put the lessons to immediate use, or someone from a function like marketing or training. And again rather than presentations, it is a small group conversation in which the recipients have enough air time to ask the originating team questions directly related to their own needs. For example, if the originating team has made an exciting new development that will save customers money, the marketing team representative would have very specific questions to ask them. The facilitator of the meeting takes notes formatted on a computer so that they are visible to all participants whether they are in the room or on-line. Both the facilitator and the invitees are brokers of the lessons learned. The facilitator tracks ideas in the meeting and follows up with the invitees to ensure that the lessons are implemented.
Drawing Out Tacit Knowledge: Both of these process (and many others) draw out the tacit lessons the originating team has learned, using conversation as the mechanism for accessing those lesson. As these processes, as well as communities illustrate, to be in motion lessons learned don’t have to be written down, they can emerge through conversation. But even conversational exchanges require planning and carefully thought to make the knowledge exchange happen.
Knowledge brokers: A Peer Assist is pull, while Knowledge Harvesting is a push mechanism. Brokers make push work. They are the KM professionals who know what knowledge is needed for a particular group and proactively provide them that knowledge.
The Center for Army Lessons Learned, L2I Net, is a good example of a push mechanism. The job of members of L2I Net is to be aware of the lessons that come into CALL through AARs, community exchanges, and the many other sources for lessons that CALL has developed. Each L2I Net member is embedded with an internal customer, e.g. in the Army’s
schoolhouses, the combat training centers, and the combatant commands. They keep track of the lessons learned their customer needs so they can push relevant lessons to them. And because they are connected through the network with other L2I Net members, they have enhanced awareness of key information from other operational forces and schools. The L2I Net has significantly reduced the speed at which lessons are pushed to those who need them - what the army calls “flash to bang.” They were responsible, for example, for pushing the much-needed knowledge about the rat claw out to commands within a day of learning about it. Push is extremely valuable, but only when those who are doing the pushing have good insight into the needs of the recipients - without that insight, pushing lessons just adds to the information overload.
• Prioritize what lessons need to collected, taking into account that transferring lessons is costly
• Conduct sensemaking sessions with the project team to derive lessons learned
• Use skilled facilitators to create a sense of psychological safety in sensemaking sessions
• Recognize that any lessons is only one of many perspectives
• Employ professional designers to format lessons
• Identify potential recipients for the lessons
• Format lessons targeted to specific recipients
• Find patterns and trends across lessons learned
• Put lessons in motion using both push and pull
• Create multiple pathways for recipients to pull lessons
• Use knowledge brokers to push knowledge to recipients, but only when the brokers know the recipients well.
