Offshoring Transition Management part I : Manage the Knowledge Transfer
HOW would you transfer the knowledge of eating at a restaurant to someone who never has? You don’t really know about it unless you go there yourself. You can have someone to tell you about it. You can order takeout from a restaurant. You can buy a cookbook from a restaurant. But, to really understand how it works and feels and tastes, you have to go to one.Knowledge transfer deals with moving specific kinds of knowledge and experience into the minds of the people collaborating on the software work. Some of the knowledge transfer is from home location to offshore location; some of it goes the other way.
Knowledge transfer is one of the principal reasons for failures in the first few years of offshoring, regardless of whether one is dealing with offshoring by outsourcing or offshoring inside the firm. Executives, intoxicated by offshore euphoria, demand a quick payback, leading their subordinates and their providers to take short-cuts. These short-cuts often prove to be expensive.
The root cause of this failure is that companies do not manage the patient process of knowledge transfer. And, perhaps the offshore outsourcing provider is pressured to deliver quick returns and reluctantly agrees to overly ambitious transition plans that hinge on rapid knowledge transfer. When complex applications are produced offshore without sufficient attention to knowledge transfer, the problems will be discovered during the costly integration and implementation phases. In such a case, the offshore development costs are, indeed, cheaper, but they are washed away in the final stages of the project life cycle when extra resources are required to correct mistakes. Similar dynamics occur when infrastructure management activities are offshored without patient knowledge transfer. Many issues will revert back to knowledgeable experts at the home location, thus negating the labor cost savings.
Some of the knowledge that needs to be transferred offshore can be codified and written down. This is often called explicit knowledge. These are the facts, principles, and specifications. In general, explicit knowledge tends to be the easiest one to transfer. Such knowledge may be captured in Knowledge Management Systems that many organizations have today. But in many organizations much of the knowledge that can be codified is not documented. So, time and effort must be invested to document this knowledge when the offshore engagement begins.
The more difficult knowledge transfer is for tacit knowledge. Tacit knowledge is that which is difficult to write, document, or codify. It is fuzzy knowledge learned from practice, exposure, and experience: in other words, the “ know-how”. It is also the “know-who” of social relations. Much of the tacit knowledge can only be transferred through learning by doing, through “ show-how,” when one person learns on-the-job through mentoring and coaching.
To use an analogy in the game of chess, the game rules can be documented in just a few pages. These rules represent the explicit knowledge. But this is not sufficient to become a strong chess player. The knowledge to play chess well is the tacit knowledge learned from experience, from trail and error, from coaching, and from very specialized books on chess strategy.
The four types of knowledge that need to be transferred offshore are (see Figure):
• Skills, such as new programming language.
• Process, such as harmonizing methodologies between onshore and offshore sites.
• Domain, such as business, scientific, algorithmic, and artistic.
• Work and cultural norms, such as organizational and national culture.
The first type of knowledge transfer is the least problematic: transferring specific skills, such as new tools, special programming languages, or specialized packages. Much of this knowledge can be transferred in writing. Additionally, classes are offered in most countries, so travel is not required for transfer.
Transferring process knowledge is somewhat more difficult. In essence it is about harmonizing methodologies between the distant units so that they can collaborate effectively. This issue has appeared most prominently in the mismatch between the large Indian providers practicing advanced process methodologies (such as the Capability Maturity Model (CMM)) and their clients in which process maturity is low or lacking. In these cases it is the client staff, rather than the offshore staff, that must acquire knowledge in order to make the offshore engagement work more effectively. Ideally, the client elevates its internal software practices to CMM Level 3 or ISO 9001 before beginning the offshore work. However, this is uncommon because moving up the CMM levels requires, at the very least, 6 months per level. Most client organizations are not interested in making such a commitment and instead, a sufficient alternative is to faithfully comply with the requirements of the provider’s CMM processes.
The last two types of knowledge are largely tacit knowledge that cannot be easily transferred via training and documentation. The first of these knowledge transfer types, domain knowledge encompasses specialized business, scientific, algorithmic, or artistic knowledge.
Some organizations recognize the difficulty of domain knowledge transfer and are proactive in managing it. For example, when the internal information systems staff at Wal-Mart, the largest retailer in the world, embarks on a project, they go through a rotation in the end-user area. If, for example, they are tasked with working on the Point-of-Sales systems, they go work at the registers for a few weeks helping customers to checkout their purchases.
Domain knowledge transfer often fails when the offshore engineers do not fully understand how the software will be used. Domain knowledge is vital in nearly all activities offshored. When application maintenance tasks are transferred offshore, then the new software engineers need to understand the implicit, tacit link between the code, the data, the business rules, and the ways they are used. When new software development is conducted offshore, knowledge transfer is straightforward if the software can be precisely specified but software is rarely specified precisely. Sometimes the difficulty revolves around usability issues, such as how credit cards are used or how decision-making is actually conducted.
The last knowledge transfer type is labeled “Work and cultural norms.” This is the most difficult type of knowledge transfer. It encompasses deeply set cultural norms that have to do with foreign cultures, how foreign clients work, as well as organizational cultures.
Since tacit knowledge transfer is primarily about transferring knowledge into the minds of people (rather than into systems), the principle solution revolves around face-to-face interactions. Human beings traveling between distant sites are the principle conduit for knowledge transfer. Travel can be of any duration, but extended rotations may be necessary.
One large American financial services company institutionalized knowledge transfer in an interesting way. The firm had been working offshore for three years and regularly rotated offshore staff to the USA every 3 months. Four to eight people would come in from India every 3 months. Once they returned then another group came to the USA. This would be repeated every 3 months. Over time, some of the offshore staff had been to the USA several times. Naturally, this was costly, reducing the offshore savings, but the company felt that the expense was justified because of successful knowledge transfer.
Offshore providers have recognized that knowledge transfer is a serious difficulty and needs to be managed properly. One offshore provider developed a knowledge transfer methodology it called knowledge acquisition process (KAP). Such knowledge transfer methodologies are based on two principles: extensive documentation and intentional face-to-face interaction. Specifically, they call for onsite presence in the first few months, shadowing employees to learn their jobs, and documenting the knowledge as much as possible into service level agreements (SLA), plans, and technical documentation.
No comments: