Chapter 7: Managing the Knowledge Transfer Process - The Case of Sierra and its Indian Subsidiary

7.1 GSW: a knowledge perspective

This chapter introduces the importance of taking a knowledge perspective to under- stand the process of growth of a GSA. Software development in general is an example of knowledge- intensive work. When taken in the context of global separation, the knowledge intensity is magnified many times over. In addition to domain-specific product knowledge, it requires a deep understanding of the multiple local contexts involved and the ongoing and changing development requirements. Many of these requirements remain undocumented and tacitly held by individuals and groups.

The significance of the knowledge transfer process can be analysed at multiple levels: institutions, project teams and individuals. Institutional reflexivity, which Giddens (1990) has described to be a defining feature of globalization, is particularly emphasized in knowledge-intensive software development work. Continuously and reflexively, firms must monitor new knowledge about technologies, organizations and markets. They must make changes in their own processes as the situation demands. The need for continuous reflexive action is significant because of the speed at which new knowledge about software is being generated and the tremendous interconnectivity between global systems (including electronic) that facilitates the spread of new knowledge from one part of the world to others.

The knowledge perspective is equally significant at the level of project teams and the individuals in the teams. Most software development firms comprise multiple teams working with different clients , engaging in different technologies and serving various markets and products. There is thus a significant amount of localized knowledge which is confined to these project teams. Access of this knowledge by the rest of the organization is often limited for a number of reasons, including the informal and tacit nature of such knowledge. The activity of software development is dependent largely on the level of skills and expertise of individuals. Hence attrition is one of the biggest challenges to effective management of GSA relationships. Movement of developers and their individual preferences for particular hardware and software development platforms affect the status of certain types of knowledge availability. For example in 1998, some Bombay software programmers we interviewed perceived Powerbuilder to be a more lucrative platform to work on as compared to Oracle. Their reason was that Powerbuilder made possible employment opportunities in North America. As a result, many Indian software outsourcing firms and their foreign clients who utilized Oracle platforms were left facing a shortage of appropriately skilled staff, and the problem of retaining them over time.

The knowledge perspective in GSA needs to be integrated with the temporal dimension. Organizations have different demands for information and knowledge at various stages of their evolution. They require different strategies to deal with the different demands over time. In the cases discussed so far, we have pointed to the different phases of a relationship from initiation, to growth and varying degrees of stabilization (or lack thereof). Many organizations, when establishing a GSA, start with small projects where a team of developers from the vendor company go on-site to the client s premises (Nicholson 1999; Nicholson and Sahay 2001). Most often, a structured approach to development is adopted to understand the various products, processes, practices and notations through which ˜knowledge becomes readable and usable by those involved in the software development process (Telioglu and Wagner 1999). Products could include programming languages and application tools. Technical processes relate to development and project management methodologies and management includes a quality process such as ISO 9000 and the Capability Maturity Model (CMM). Practices involve culturally accepted norms such as approaches to learning, problem solving and communication. Notations include specifications, flow charts and other similar inscriptions.

As the developers from both sides of the GSA sit in conditions of co-location during the initial stages, it can be expected that knowledge on various facets of the process can be ˜transferred . An increased proportion of the development tasks can then be moved offshore where the costs of development are cheaper. This movement to offshore development is facilitated by the creation of trust arising from the early experiences and interactions which had supported the building of personal relationships ( ˜I trust X because I know him/her and she/he won t let me down ). Trust is also based on confidence that deadlines and quality standards will be consistently met when committed to, which is backed up by structural controls and contracts.

Managing the balance between offshore and on-site work is one of the key ongoing challenges in a GSA. Both budgets and knowledge levels must be considered . Budget constraints are crucial since tangible costs are reduced with increased offshore presence, even though the intangible costs of management overheads required for coordinating offshore work might be significantly higher. The transfer of knowledge about products, processes and practices to the offshore development team is also crucial since it gives the vendors a sense of trust that work can be done effectively at a distance. This onshore “offshore mix is not static, it shifts over time depending on the demands of either new work or peaks and troughs in the current workload. Firms try to deal with these variations through policies of staff rotation and the use of ICTs to maintain some form of ˜presence even in conditions of physical absence. As trust levels increase, higher-value activities may be undertaken but these activities in turn place demands for subtler forms of knowledge and understanding. We use the concept of knowledge transfer to refer to ˜the transfer of knowledge to places and people where it is needed to be used to fulfil some activity or task (Alavi and Leidner 2001). In our research, we rarely saw any explicit transfer of knowledge taking place directly from the offshore site to the client, other than the transmission of information required for project monitoring and control. The process of knowledge transfer in GSAs is extremely problematic and shaped by various socio-cultural “political dynamics, which in turn influence and are influenced by the broader trajectory of the GSA relationship.

The purpose of this chapter is to study the dynamics of knowledge transfer and the manner in which it interplays with the process of GSA evolution. The perspective is grounded in the ideas of a ˜community of practice (Brown and Duguid 1991; Lave and Wenger 1993). While knowledge is largely the property of individuals, some knowledge is regarded as being produced and held collectively and generated when people work together in tightly knit groups known as ˜communities of practice . Such communities are able to muster collective ˜know how , the transfer of which is deeply rooted in practice, and through which members develop a shared understanding of what it does, of how to do it and how it relates to other communities of practice. The processes of developing the knowledge and the community are interdependent; the practice develops the understanding, which reciprocally changes the practice and extends the community. We use this ˜communities of practice idea to refer to the software development teams who are separated by time, space and cultural differences but still interact with each other using their common knowledge of various products, processes and practices. The community of practice idea is important to GSW, as software development is a knowledge-intensive activity that involves a large body of knowledge ( know what ) with a strong emphasis on practice ( know how ). Although the role of sharing knowledge and building trust has been described as being important in the functioning of communities of practice, little is yet understood of how distance, absence and cultural differences influence the effective functioning of these communities of practice (Little 2001) and with it the trajectory of the GSA process.

A ˜community of practice perspective on GSAs helps to go beyond a view that emphasizes the inherent capacity of ICTs to transfer all facets of knowledge required for software development. This ˜information-processing view conflates information with knowledge, as it assumes that knowledge is neutral, easily packaged, reduced and transmitted. Such a view is of limited usefulness in understanding GSW, since it presents a static and rationalistic impression of what in practice is a much more complex, socially negotiated and evolving process. To grasp this complexity, it is important to differentiate between information, learning and knowledge (Brown and Duguid 2000). Knowledge requires a person or knower; knowledge is harder to detach from the knower than information, as it requires background understanding . When an attempt is made to stretch communities of practices across time and space, it is this aspect of knowledge and the need for background understanding that make the process problematic. While the information-processing view remains a dominant one in information systems research, various critiques of it have been presented, arguing for the inherently subjective nature of knowledge (e.g. Baumard 1999), which has also been established empirically in different settings. For example, Lam (1997) describes a collaboration between a British and Japanese company and suggests that while one firm s design approach relied on experimentation, intensive interaction and learning by doing, the other used a formalized high-level design language. Although the first firm s design was not always consistent and logical, they had a better understanding of the tacit nature of knowledge than the second firm which used more formal methods .

Much of the knowledge in GSA is ˜sticky and difficult to transfer because of its personal and tacit nature (Polanyi 1962, 1966), thus posing limits on what can be effectively articulated and transferred. In a GSA, the knowledge to be transferred varies with the stage of the GSA process and is shaped by the use of different ICTs, which in turn raise new demands on knowledge. For Polanyi, while tacit knowledge is applicable in practical settings (like cooking), especially involving skilled tasks, it is equally applicable to mental activity such as language. Since formalizing and passing on such knowledge is problematic, it is best transferred in conditions of proximity where the learner can watch the expert, try to establish mentally what is done to make things work and engage in action through practice. Tacit knowledge (for example, recognizing a face) and explicit knowledge (for example, the height and weight of a person) are mutually dependent. Tacit knowledge forms the background necessary for assigning the structure to develop and interpret explicit knowledge.

A community of practice approach draws attention to the importance of tacit or background knowledge (Winograd and Flores 1987) and the need to integrate it with explicit knowledge, for effective knowledge transfer to take place between human know- ers including individuals and groups. Examples of such integration are seen in Orr s (1990) study of Xerox technicians who formed tacit background knowledge through a process of face-to-face socialization , storytelling and ˜hands-on experience. This made the talk and the work, the communication and the practice inseparable. The Xerox technicians were co-located for at least some periods during the working week, making their learning deeply related to their everyday practice. There are, however, far different and greater complexities involved when the communities of practice are separated by time, space and culture. We study some of these dynamics relating to knowledge transfer in the case of Sierra and its Indian subsidiary and how these dynamics led to the shaping of the relationship.