By Steve Trautman February 1, 2013

Inform Your Knowledge Transfer Strategy with Relevant Historical Context [KT Strategy Series, 4 of 9]

Posted by Steve Trautman on Feb 1, 2013 8:54:40 AM

A knowledge transfer strategy should state in a few paragraphs the way knowledge transfer has historically happened in an organization. Even if your organization has not engaged in formal knowledge transfer, there is still relevant history. Knowledge transfer is already happening in any workforce—it's just may not be as efficient, consistent, or complete as needed to meet the talent needs of the business. The knowledge transfer strategy needs to reference the history so that it can surface any investments of time, money, and political capital that will inevitably affect execution of the strategy and adoption of the solution.

Your strategy's relevant historical context might reference:

  • Evidence of any formal or informal knowledge transfer structures
  • The results of prior efforts including how consistently and accurately knowledge is typically transferred
  • Anecdotal data such as how long it has typically taken a new hire to get up to speed and be productive a critical job position or instances of rework in a given team
  • Whether unique knowledge and talent has been lost to avoidable circumstances, e.g. subject matter experts retiring before having transferred their critical knowledge to the next generation; poor load-leveling for a workforce’s experienced experts (employee burnout); attrition of marginalized new employees who were not given a chance to learn and be challenged; generational differences that were mismanaged and causing departures due to work stress
  • What other strategies have been tried or confused with knowledge transfer and acted as ineffective substitutes (e.g. knowledge management, mentoring programs, competency models, succession planning)

Using a client of my consulting company, here's an example of relevant historical context:

A major insurance company outsources roughly half of its IT Division's workforce. They maintain IT offices in three countries, have an aging workforce, and—due to many legacy systems that go back to the early day 's of software programming—have lots of unique critical knowledge that can't be learned elsewhere. More than two years ago they began handing off major blocks of IT work to the outsourced vendor in order to increase efficiency and reduce costs. This outsource partner marketed their services to the insurer as including a knowledge transfer system—but this system turned out to be knowledge management and not knowledge transfer. Effectively, the “knowledge transfer” process used over the past two years of outsourcing handover has been for the insurer to create a document on some particular knowledge to be transferred (e.g. a certain IT process that the outsource partner is absorbing) and for the insurer and outsource partner to talk through the document. This amounted to explaining vocabulary and steps in the process and then handing over the document and considering the knowledge transferred. The problem with this process is that it lacks the necessary depth to be called knowledge transfer; it doesn't get at any related wisdom and tacit knowledge (e.g. What's the relationship between x and y? What are the top three things to troubleshoot if a process fails? Who do you have to know to get something done? How you know when you are in over your head? Etc.) Evidence that the needed depth is lacking is clear: two years after the transfer of outsourced IT roles, the outsource partner is still not working independently. Outsourced workers cannot perform their assigned roles and handle all the IT problems that arise, enough for ineffectiveness to be visible at the executive level.

The insurer did not have an alternative formal knowledge transfer system of their own and their response has been a reactive and costly one. They put their best people on planes and fly them out to the outsource partner to solve the problems and retrain the partner resources in real-time. Their IT experts are running around putting out fires, instead of getting ahead of the problem or focusing on their own jobs. Even the outsource partner acknowledges that it would be more helpful if their client was clearer about their expectations—but clearer how? The insurer is not holding the vendor accountable to outcomes because they can’t under the current system. Two years into the changeover and the insurer is still following the status quo for lack of an alternative knowledge transfer process or better strategy—and it's not working. It’s the opposite of the anticipated efficiency and costs savings expected from the outsource effort.

In addition, the insurer is facing the imminent retirement of a large percentage of their current IT workforce. Some of these professionals write code in programming languages that date so far back that the next generation has never even heard of the languages, let alone been trained in them. For example, for one critical system used to collect money to interface with banks and move funds, there is literally one employee who knows how to make programming changes—and he's at retirement age. The insurer knows that he and many other experienced professionals will be leaving in the next 1 – 5 years and leadership wants to retain their tribal knowledge before it goes out the door. There was no methodical, measurable knowledge transfer system in place to do this until my consulting company was asked to help.

This sample overview makes the organization's knowledge transfer history clear, even to a reader not familiar with the business unit or experienced in the field of knowledge transfer. It can be summarized in a few bullets:

  • Knowledge transfer was typically driven by the outsource partner and most people thought it was “handled,” but time and the results showed that it clearly was not.
  • The outsource partner will need to be incorporated into the strategy.
  • The insurer wasn’t clear enough about their expectations for the outsource partner’s required skill sets. The strategy needs to include a solution for setting these expectations better.
  • Departing workers with unique knowledge have no track record of transferring skills. Our employees will be starting from scratch, so the strategy must include ways to state the urgency of this problem and motivate people to accept a new way of doing things.

SUMMARY: After framing your organization’s talent problem, your knowledge transfer strategy should next provide relevant historical context to show how knowledge transfer has typically occurred in the organization, what benefits or problems have resulted, and what other methods have been tried or confused with the work of knowledge transfer. It should clearly state the ways in which your knowledge transfer strategy needs to respond to this history.

Topics: Outsourcing, Knowledge Transfer Strategy, Best Practices

Steve Trautman

Steve Trautman

Steve Trautman is corporate America’s leading talent risk management and knowledge transfer expert. With two decades of application inside blue chips and Fortune 1000s, his pioneering work in the field of talent risk management and related knowledge transfer tools are now the nationally-recognized gold standard. He is known for a high energy style that combines humor, street smarts, and board room wisdom.

Continue Reading...

Subscribe to Our Blog