When you set out to build a knowledge transfer strategy, one of the first things you’ll need to define is the scope of the strategy. Will this work guide knowledge transfer for a team, a business unit, a division or a global organization? Will it set the knowledge transfer expectations for an entire enterprise? Do you even need a knowledge transfer strategy—or at what point will implementing a knowledge transfer program probably fail without one? Here’s some simple guidance.
The Degree of Scope That Requires A Knowledge Transfer Strategy
One way to approach this issue is to look at hard numbers and logistics for guidance. Typically, once you expect to address the knowledge transfer needs more than 60 employees, or plan to implement knowledge transfer in more than one location, then you should think about writing a knowledge transfer strategy. In my consulting company’s process, we usually first do one or two proof-of-concept pilots that puts our 3-step knowledge transfer solution in place for about 20 to 60 workers, and usually at one or two locations. Then we quickly move to strategy conversations for wider rollout. In short, the size of the organization or its complexity does not have to be very high for a strategy to be needed. (Here’s more from earlier in this blog series about why have a knowledge transfer strategy.)
Setting the Knowledge Transfer Strategy Scope
Once you’ve agreed that knowledge transfer urgency is high for more than 60 employees or in multiple locations and a strategy is needed, you might wonder if it’s best to craft one strategy for a whole enterprise or a number of unique strategies owned by individual teams or units. I recommend incorporating as much breadth into your knowledge transfer strategy as possible. At the earliest stage of strategy development, ask how wide of a net can you cast. Typically, this means you'll be writing the strategy for a division or maybe a global job family.
For example, the strategy my company helped Costco write was for their entire IT division. At John Hancock we are writing a strategy for their IT division plus related outsourced partners. And at one international manufacturer, the strategy was written for one job family… in 19 global locations. It’s true that “bigger is better” when thinking about strategy.
I would rather write a strategy for all software engineers in a company or all employees in a division than for a subset of them because of the clarity it affords. Consider this: one possible outcome of your scope conversation is that you’re going to write a knowledge transfer strategy for your entire division and part of the strategy will be to focus knowledge transfer efforts on one-third of the employees deeply, one-third in a moderate way, and one-third not at all for reasons X, Y and Z. So you’re clarifying expectations to both upper management and all division employees right off the bat.
Our client Goodyear is a great example of why this important. As soon as we had success in our knowledge transfer pilot team, Goodyear’s knowledge transfer process owners started getting inundated with requests for help from other teams not included in the pilot. “What about us? When are we going to get our knowledge transfer process over here?” With the clarity provided by a broad-scoped knowledge transfer strategy, management is able to say to everyone, “We’re going to take care of you and here’s when and how,” or “We’re not going to take care of you and here’s why.” At least people know, at least you’re setting their expectations and they’re not frustrated waiting for something that is not coming or not coming in the manner they assumed.
So the scope of your knowledge transfer strategy is an important issue to settle early, to set wide, and to clarify in your written strategy.