Keywords

1 Introduction

Information systems development (ISD) is often conducted in the networks of organizations. Those networks include the customer organization, i.e., the organization that requires a new system; its business unit or units, i.e., the future user groups; its IT department, i.e., the unit with adequate IT expertise; and, of course, the system provider or developer organizations. This means that there are several stakeholders from different parts of participating organizations involved [1, 2]. Development may also be partly sourced to low-cost offshore locations [3] where skilled employees may be available or to bridge the capacity constraints [4]. This obviously adds new partners and relationships to the network.

Developing IS in this manner entails several risks and challenges [5, 6]. Inter-organizational boundaries get blurred and relationships become complex. This makes collaboration and knowledge transfer (KT) between the parties difficult [3, 5, 7]. For example, traditional solutions to overcome KT barriers, such as master-apprentice learning or personnel movement, may not be available for transferring tacit knowledge because of the physical distance [4]. Even though the literature coverage on different issues of KT is broad, there are some limitations. For example, such studies are often limited to local settings [8] or do not investigate both the client/customer and vendor-side KT challenges [9]. IS offshore outsourcing studies on KT usually focus on the customer-vendor relationship or the vendor’s capabilities (c.f., [10–12]), not the entire development network and the interactions therein [1, 13]. This motivates our paper.

We study KT within an IS development network by focusing especially on the boundary between onshore and offshore units. However, focusing solely on the issues between onshore and offshore sites is not sufficient as issues and challenges may stem from the customer’s processes, issues, and understandings as well [12]. Consequently, we will incorporate the insights of the operations of the whole network to study KT at this particular boundary. We formulate our research question as follows: Why is knowledge transfer between onshore vendor and offshored unit difficult in ISD networks? To answer this, we conducted an interpretive case study with 30 semi-structured interviews in two separate rounds.

The paper is structured as follows. First, related research about KT challenges in general, and from an IS offshoring perspective in particular, is presented. Then the case and research methods are introduced. The findings include the description of an overall workflow and knowledge transfer within the IS development network, as well as the KT challenges the parties face therein. Identified challenges are organized into four categories knowledge characteristics and difficulties in articulation, vendor-related issues, offshoring-related, and communication channels and tools. In the discussion, the findings are synthesized and their implications in relation to the literature are drawn. Finally, the conclusions summarize the paper and cover limitations and future research directions.

2 Knowledge Transfer Between Onshore and Offshore Units

Although the advantages of outsourcing and offshoring software development [14–16] are promising, a number of challenges have been identified [5]. For example, compared to traditional in-house or onsite projects, globally distributed projects are more complex [17] as coordination and integration of multiple knowledge sources is needed [18]. Project participants may be separated by multiple and overlapping organizational, cultural, national, and professional boundaries [3]. Consequently, cultural differences, separate time zones, varying working and development methods, and the incongruent levels of common understanding of the end-user environment are evident [17, 19]. These issues may potentially hinder the development, for example, by delaying the development that is often considered vital in contemporary projects. Bearing these issues in mind, much stronger efforts in communication and knowledge transfer are required [17].

KT entails both sharing and using the transferred knowledge [20]. It is thus a prerequisite for successful ISD, since effective KT may reduce the time to solve problems. This is because knowledge accumulates and the level of common understanding increases [5, 21]. Systems development is clearly knowledge-intensive work where both technical and business domain knowledge needs to be transferred [4, 22], and hence both explicit and tacit knowledge are important to consider [19, 23]. However, KT is often difficult and laborious because the organizations and individuals have dissimilar experiences, backgrounds, expertise, and cultures. Articulating knowledge across organizational boundaries is particularly problematic as it is sticky and resides in practice [24].

Language barriers are rather obvious challenges for effective KT as the native language of the offshore personnel is usually not the same as the onshore personnel’s language. Language barriers are related to difficulties in translation, e.g., different interpretations of the meanings, or dissimilar business terminology and acronyms [5, 25]. Different dialects and cultural norms and habits may also play a role in hampering the understanding of the message [26].

Spatial difference refers to the lack of face-to-face communication. This makes KT more difficult as alternatives, such as video conferencing, either do not provide similar possibilities for negotiations and/or do not help the offshore personnel to grasp what is really happening in the end-user environment [7, 17, 27]. The work to overcome physical distance takes time, leaving fewer resources for the development work [12]. Temporal distance, e.g., working in different time zones, makes synchronous communication difficult. This affects, for example, decision making by delaying negotiations, handshake arrangements, and problem solving [5, 17].

The distance issues may privilege the onshore vendor over the offshore provider and thus accentuate status inequity. This makes it harder for the offshore developers to form interpersonal bonds or engage in joint discourse [3]. The distance between participants also emphasizes the selection of tools and their capacity. Proper infrastructure for knowledge sharing helps to capture implicit knowledge and to make it explicit [5, 26].

The relationships between organizations and individuals cause certain distinct challenges. The social dimension of the collaborative work needs to be acknowledged [7]. As the relationship between onshore and offshore organizations is often strictly bound by formal contracts and agreements, individual-level social ties and personal connections promoting KT are difficult to establish and maintain [19]. Furthermore, onshore and offshore cooperation generally lasts for a relatively short period of time and thus little shared capital is accumulated [3]. For effective KT, some level of shared understanding is nonetheless needed [28]. To gain such understanding, more effort is required compared to onshore projects.

These issues are just some of the challenges identified in the literature. The list is not exhaustive but still provides an overview regarding which kinds of issues are problematic in KT in offshored ISD. It seems that the KT challenges vary greatly between different projects and environments. This is plausible, as Nidhra et al. [5] found 60 different factors hindering KT in global software development, while Clarke and O’Connor [29] identified 44 contextual factors and 170 sub-factors that are significant in software development. Thus, instead of creating just another list of KT challenges, we try to go deeper by explaining how these challenges appear and what their root causes are.

3 Research Approach

We have conducted an interpretive qualitative case study [30] of an IS development network. The customer organization of 2,000 employees is a global service provider in the retail business with over one thousand sales outlets and operations in 26 countries. The customer’s operations are divided into three primary business areas (consumer, B2B, and wholesale) and several support functions (HR, finance, logistics, IT, and marketing). A customized Enterprise resource planning (ERP) system has been used for more than ten years to satisfy their unique business process needs, including, for example, storage of clients’ property and extremely seasonal business logic.

The initial push for the ERP system renewal project came from the vendor. They wanted to update their current software platform by building a completely new system. The vendor also delivered the customer’s previous customized ERP solution that is used as a basis for the forthcoming system. The vendor also planned to offer and sell the new system to the vendor’s other customers. This added pressure to the development as the vendor had to constantly balance between customer-specific features and generally useful ones. However, in practice, the customer needs were stronger and thus they were prioritized over others. The vendor offshored the majority of the coding to another country (India) in order to acquire both additional resources and technological expertise. The original onshore vendor remained responsible for the overall management and design.

The ISD touches multiple organizations and individuals, each having their own roles and interests. In this case, the following four relevant stakeholder groups are identified: the customer’s business, the customer’s IT department, the onshore vendor, and the offshored unit. There are also other external parties involved, for example, for visual design, but their role in the development activities and decision making were minimal. In principle, communication and management models were straightforward, meaning that there are fixed routes and responsibilities. In practice, however, these strict, well-defined practices were bypassed.

3.1 Data Collection

Data collection relied on semi-structured interviews. In total, 30 interviews were conducted in two rounds of interviews. In the first round in February–April 2013, the informants were selected via a snowball sample [31] so that all relevant stakeholder groups are identified and covered. In the second round in January–March 2014, the informants were hand-picked based on the insights gained from the first-round interviews. We also shifted our focus toward the offshoring part. Table 1 lists the interviewees and their organizations.

In the first round, the interview guide can be described as loose. It only contained open-ended questions, such as who are the most important stakeholders in the development process for each informant; which methods and practices are considered effective/successful; and what could have been done better in terms of systems development. The second-round interviews had more specific questions, which were informed by the first round. The focus in the second-round interviews was on what kind of changes had happened; what are the processes and practices for the system development; what kind of knowledge is relevant for each informant and how is it obtained; and what tools and objects are used in communication with the stakeholders. The duration of the interviews varied between 11 and 98 min, the average being 55 min. All interviews were recorded and transcribed.

Table 1. The interviewees and their organizational positions
Full size table

Some secondary material was also utilized in the data analysis. These included, for example, excerpts from the communication system between onshore and offshore, requirement specification documents, a version of the project plan, meeting minutes (where the decisions were made), priority and rollout lists of errors and needs, original evaluation criteria for the system acquisition, and the original request for information document. Although the impact of secondary material on the case analysis was not very significant, it helped the researchers understand the organizations and their structures.

3.2 Data Analysis

Similar to the data collection, the first author conducted the analysis in two separate rounds. The first round consisted of qualitative data-driven analysis and coding of the themes that emerged from the data. The ISD challenges were searched from the data, and then the first version of coding categories was created. The focus was on knowledge attributes and on challenges in transferring and distributing the knowledge. The findings were further categorized. In the first-round analysis, an overall picture of the development network and its operation was formed.

The second round continued where the first round ended, i.e., the analysis of a new set of data was informed by the previous round. This time the goal was to evaluate the earlier knowledge transfer-related issues, and to gain new insights especially about the offshoring part of the development. Nevertheless, the second-round coding was still done with an open mind for novel issues (c.f., [32]), and thus new issues were found. Coding examples are shown in Table 2.

Table 2. Extracts from the interview data and related codes
Full size table

Even though in practice most of the identified issues are intertwined and have an impact on each other, it is possible to divide the challenges into four categories: knowledge, vendor, offshoring, and relationship-related. This categorization (simplification) was done both for analytical and presentation purposes, i.e., to make reading the findings easier.

In both rounds, the data was revisited iteratively to gather more detailed information and to confirm earlier identified issues. Initial findings were also discussed with the main contact persons in the case organizations and further revised according to their feedback.

4 Findings

We will begin by explaining the IS development practices and processes in our case network. This provides an overview of the environment, and its particular limitations and impacts on the KT between the onshore vendor and the offshored development team. In the case, certain KT challenges stem from the customer’s business domain and from their relationship with the vendor. These must be taken into account when addressing the “end-part KT.”

Within each organization, there is a dedicated person or a group in charge of the inter-organizational relationship and communication. The official guidelines for cooperation are rather straightforward. As the customer has various business areas that the system will serve, different needs and requirements are gathered and synthetized by the customer IT department. The IT department is further responsible (and is expected) to handle the communication with the vendor.

From the vendor’s side, there is a dedicated customer liaison person responsible for communication with that particular customer. The customer’s needs and requirements are further discussed and negotiated within the vendor. Only the lead designers are supposed to forward these needs and requirements to the offshored unit.

…we have received a requirements definition document from the customer, or a list of features that they would like to have. I examine the specifications regarding what we are actually going to do, and I describe to India how it should be coded (Lead Designer).

At the offshore site, a team leader is appointed to manage the vendor relationship and to communicate with the onshore designer. The team leader forwards information to the appropriate developers. Similarly, when information is transferred to another direction, i.e., from the developers to the customer, the team leader discusses with the lead designers. The development network and the flow of the work are depicted in Fig. 1, which is nevertheless a simplified situation.

The main “line” of both requirement management and solutions development thus consists of intra-organizational negotiation and inter-organizational gatekeepers. In practice, communication practices are not as mechanistic.

Fig. 1.
figure 1

The development network and the flow of work

Full size image

4.1 Knowledge Characteristics and Difficulties in Articulation

The customer organization obviously holds the most in-depth knowledge about its business domain and about its processes and functional aspects of the work where the system will be implemented. However, most of the knowledge related to the customer’s business processes is tacit and embedded in practices (as a way of doing things is a part of culture, for instance). This knowledge is not well documented. Although the customer has its own process handbook describing the processes, it is not updated or used in cooperation with the vendor. The vendor has to make extra effort to understand why certain functionalities need to be designed as the business needs are not always accurate. The vendor’s product manager commented as follows:

After getting a request from the customer, we have to unwind it backwards in order to identify what is the actual need behind it, why a certain button must be there, and so forth.

The complexity and stickiness of domain knowledge was also acknowledged among the parties. Particular methods to achieve the transfer of domain knowledge were utilized. These included, for example, the observation of work practices and how the current system was used, and bringing the offshore developers onto the customer premises.

Situatedness and difficulties in articulating the business domain knowledge were evident as well:

After releasing a feature, it became apparent how the users are actually using it, what issues they are facing, and what are the exact requirements for more efficient use. So only then will I be able to work and fine-tune those features according to the customer’s needs (Offshore Developer).

Despite these difficulties in the vendor’s understanding of the business domain and processes, the customer still had strong confidence in the vendor’s competences. However, this led to poor documentation of issues and had unfortunate consequences for the offshored unit as we will demonstrate later.

On the other hand, the offshored personnel are experts in the technology. They thus possess the most detailed knowledge about how to utilize the technology and implement it. This knowledge is crucial to make the best out of the system, for example, in terms of developing functionalities that may provide competitive advantages. However, some informants argued this potential was not redeemed:

They would like to be more involved. How to take advantage of their expertise and insights is a challenge for which we have no solution now, and thus is an area where we have not achieved much progress (Technology Leader).

Despite the previously mentioned activities, the developers still had limited knowledge of the customer’s business environment, which makes it more difficult for developers to suggest new ideas or alternative solutions. This further hinders the development, at least from the customer’s perspective, as the technology behind the system is not exploited to its full potential. Quality and performance issues are also evident. For example, in the piloting phase the customer ordered an outside consultant to do capacity/stress tests on the system. For some reason, when running the system as designed, power consumption at the terminal end and the server load increased. Consequently, scaling the system to all the customer’s office sites would not have been possible. Because of these results, the planned rollout was postponed.

Understanding the requirements and communicating them to the right people is a matter of each team member’s individual skillset. A certain degree of flexibility is required since different people are involved in the development network. The individuals’ skills are tested in such situations:

Every team member is not the same. If I want to talk to A, if I want to talk to B, both are giving me the requirements, and then there will be a change in the communication methodology between the two of us (Offshore Team Leader).

4.2 Vendor-Related Issues

KT challenges related to poor documentation were not only a result of the customer-side. The vendor’s internal documentation practices seemed to be equally lacking rigor, or at least they were not done thoroughly: “The requirement specification done with the vendor can just be a set of email conversations” (Customer IT support).

Requirements from the customer were not explicitly written down as official documents; requirements and changes were just added as complements to the issue management system’s tickets. Detailed descriptions were indeed missing, making the systems development very difficult as the bigger picture was not seen. The customer understood that the system under development included at least all the same functionalities and features as the former system, which was also provided by the vendor. This was problematic because:

The old version has many features that are not documented anywhere. So digging them up and finding out what is there has been quite a big part of the work (Lead Designer).

Although this level of documentation might be sufficient for the vendor’s internal work, it was certainly not adequate for the offshored unit. The vendor’s employees work in two locations in Finland. They did not perceive any problems because of their continuous collaboration with a small team of developers. In other words, current documentation practices were adequate as their weaknesses were compensated by communication and tacit knowledge. Yet, at the same time, these practices did not allow the offshored personnel to grasp the necessary information. New, more specific documentation was required. The Lead Designer made the following suggestion:

…currently the best way would be to have some kind of wiki-based instructions for the end-user. This should be kept as up-to-date as possible. Customer support, lead designers, product managers, and developers could then use that to see how a particular function works (Lead Designer).

This would assist the offshored developers not only to gain important insights about the customer’s business domain but could also bring them into the same discourse with the onshore personnel. This would be even more important as the offshore unit had no access to the old system, which was constantly referred to as a “requirement specification” in the onshore cooperation.

The fixed organizational routines and rigid structure caused, to a certain extent, an unwillingness to share the vital knowledge. This appeared, for example, in terms of allocating the project responsibilities. Everyone in the project had their own duties. They were thus reluctant to share their knowledge or potential problems and solutions. The Technological Leader sees this as problematic: “…there are some silos so that I do this part and you then do yours.” Such an approach was not sufficient as excessive work arises when different parts of the system are integrated and the code is harmonized. This was particularly difficult for the offshore developers. They were not aware of the other modules or of the general functionalities developed by the others. They were then either doing duplicate work or rework. The offshored developer explained this as follows:

We are not getting the latest updates about what are the new features and what modules are done elsewhere. We could actually use those, reuse them in our code and modules, and even enhance that use (Offshore Developer).

The offshored unit’s only contact point was the lead designers. This was not, however, considered sufficient. Developers felt they were left without important information, especially related to the end-user environment and overall scope of the system:

I’m getting a technical specification that needs to be implemented in a certain way. But how the customer is going to use the system, it’s not exactly clear to me (Offshore developer).

Being a gatekeeper between the organizations and trying to understand the whole system and its requirements requires tremendous effort from the lead designers. In other words, the success of transferring knowledge between these organizations is largely on the shoulders of a few individuals. For example, the Product Manager, who is responsible for the overall product design and for prioritizing and integrating the modules, was not in direct contact with the developers or even with the team leader. This practice hindered the vendor’s ability to take full advantage of the developers’ knowledge and competence. This can be seen as a matter of attitudes among the onshore personnel: “It is about how much freedom we are willing to give these Indian guys. It seems a little bit like people would not like to give it up” (Technological Leader).

This is again linked to the fixed routines and habits. Earlier system development and maintenance involved only personnel from within the vendor organization. The offshored unit acknowledged this, and stated that they were only independent to a certain degree. That is, they can divide the given task within the team as they please, but any kind of long-term planning is difficult due to the small scope of given tasks.

If you know in advance where to go and what to reach, then it is easier to plan, to achieve that thing… But, I am working on just some particular module. I should know how that is related to the bigger picture, what I need to do, or as a team what we need to reach (Offshore team leader).

4.3 Offshoring-Related

The offshore team conceptualized all problems related to communication, and its exiguousness:

This is not about the technical incapability. Rather, this is about communication (Offshore Team Leader).

The vendor’s personnel shared this feeling. They felt the offshoring scheme has been successful even though certain challenges have occurred and needed to be taken into account.

It brings certain inconvenience on the work, there are language barriers and other barriers as well. One must describe things more accurately than to someone sitting next to one, to whom it can be explained in Finnish or you can draw a picture for and so on (Vendor CEO)

Further on, the Lead Designer complained of extra work, caused by the offshoring scheme:

It brings an additional layer, in the sense that I have to transform and translate the knowledge. And when translating that to English, I have to open up the terms and different needs more precisely. It is much easier if I can do it myself directly (Lead Designer)

One evident issue affecting the KT between the teams was the technology-oriented mindset of the offshore personnel. For them, the customer’s business environment consisted basically of just production data. They were not concerned with real manual work, such as using a cash machine at the sales offices. Certainly this is related to restrictions in terms of how often they are in contact with customers. Yet, even when asked several times, the offshored personnel kept referring to the testing environment, its deficiencies, and the integration between the modules. The vendor perceived this as the offshored developers were not motivated to accumulate the customer-specific knowledge, perhaps due to the nature of the onshore-offshore relationship.

Another issue impeding KT was the type of relationship between onshore and offshore staff. Onshore staff had the contractual power to decide how the development is going to happen. This left no room for negotiation:

We have to follow such processes that have been followed by the on-site team… Whenever something is happening, changes in the task descriptions or anything, then they just sent us an email telling that somebody has changed the values of description, remaining work hours, or the type of a task, or assignment, whatever (Offshore Team Leader).

Due to the hierarchical relationship with predefined contracts, the offshore personnel were reluctant to tell whether certain things or processes were not working well:

In Finland, there is an on-site team that is a technical team, but that is our client. We don’t know the end-client [i.e., the customer]. My first job is to make my client happy. I’m not here to raise the concern (Offshore Team Leader).

Another challenge related to the offshore team was their expectations, and their lack of independent decision-making power and desire to make innovations. The vendor considered this as their own fault since they had become accustomed to their partners’ work as being only “according to the specifications.” There has never even been a thought to offer them a possibility to gain an overview of the whole system.

The cultural and language barriers were also evident. Almost all information had to be translated by the onshore lead designer. This obviously left room for errors as often only one person was responsible for this translation. However, the document translations were not sufficient. The offshored unit could not fully comprehend the situation. A developer commented as follows:

…the testing environment is not in my local environment. It is in Finland. They have a different database, different culture, and different languages. In my development environment, I’m testing the test cases in the English language, as I only know the English language (Offshore developer).

4.4 Communication Channels and Tools

The vendor set the tools and practices for communication. Yet collaboration following a rigid process and certain tools did not always support knowledge exchange sufficiently, or at all. This was particularly the case when dealing with more abstract concepts or novel issues. The offshore team leader explained the shortcomings of their current methods:

Sometimes the tool makes the [collaboration] process somewhat complex and even time consuming. If there is a tool and I want to draw a diagram and design something, to suggest something, I should have the bigger picture and an understanding about the context. Let’s consider you are building your house in the summertime. If you are in Finland, you also think about winter and temperature differences. If you forget them, and just consider the current environmental condition, then you will face problems later for sure (Offshore Team Leader).

The level of formality of the methods used by the customer and the vendor, and by the onshore unit and the offshore, differed significantly. In the former case, communication took place via multiple channels and the documentation was vague, while in the latter case the situation was very different, as discussed earlier. Nevertheless, knowledge that needed to be transferred was somehow the same: business domain knowledge, process information, and technical constraints and possibilities, among others. This further highlights the difficulty in explicitly articulating domain knowledge from the end-user environment. Sticking with rigid tools did not enable technical knowledge to be transferred from the offshore team to the vendor.

Currently we are not involved as production team members, and we are not talking to the end-client [customer] directly. So, whatever is happening at the end-client side, they are transferring that to the [onshore team]. And they are creating those bugs or tasks or features, whatever they want, or whatever they’re creating, into the [product development tool] (Offshore Team Leader).

Furthermore, the structure of the development network did not nurture KT. The physical distance between the developers and the designers hindered the development. More negotiation and discourse was preferred and more explicit tools needed to be utilized:

In cooperative work, it is nice to have all the video conferencing tools, etc. But it is still not the same (Customer ICT Manager).

The offshored team leader continues:

It is not a question of how much some team member is communicating with his/her counterpart, or how the goal is achieved with 99 % accuracy. It’s more about the level and intensity of communication when the two teams are sitting very far across the globe (Offshore Team Leader).

Furthermore, the lack of formality was also evident in the use of different communication channels. Often email and telephone calls were preferred instead of filling out standard forms, or using the issue management system. This obviously caused misunderstandings:

There are individuals calling each other over the phone and everyone is uncertain what the current state of the system is (System Specialist).

This hindered, or at least slowed down, KT as all necessary bits and pieces of information had to be “fished” from various stakeholders. This fishing became even more problematic when it became clear that the customer’s project manager, who had already resigned from the project, was actually the one coordinating the activities within the vendor organization. Avoiding strict standard forms and guidelines also offered flexibility and speed for collaboration between the customer and the onshore vendor. This flexibility was considered necessary for responding to the business ideas and needs quickly.

5 Discussion

Identified KT challenges can be categorized as knowledge, vendor, offshore, or communication-related. The challenges from the vendor’s and offshored unit’s perspectives are rather similar – yet their causes are not. For example, the vendor’s unwillingness to articulate or share the vital knowledge is caused by fixed routines and rigid structure, while at the offshored unit it is caused by the hierarchical position, e.g., not having the desire to accumulate the business knowledge. The challenges are summarized in Table 3.

Table 3. A summary of the findings: the KT challenges in the ISD network
Full size table

Some of the identified challenges are, of course, idiosyncratic to our case; however, general implications can also be drawn. Even though KT is a major issue in offshored ISD networks, and may lead to serious problems or failures [17, 26], most challenges are not only caused by the nature of the knowledge itself. Besides that, in relation to our research question, the KT challenges also stem from unsuitable development practices, from too many middlemen, and from political issues. We thus argue these are the four root causes generating KT challenges between onshore vendors and offshored units in offshored ISD. Their relation to current literature and implications are discussed below.

The nature of the knowledge.

As expected, the tacitness and stickiness of knowledge was causing problems for KT. From this perspective, our findings are in line with the literature. Explicitly articulating the business domain knowledge is difficult and does not allow the necessary building of shared understanding [28, 33]. This was evident as certain issues and requirements emerged only after the system was in use. Relying only on explicit documentation is not sufficient as, for instance, contextual issues and logic are difficult to articulate in a universally understandable form [34]. This parallels with the earlier studies’ implications by showing how personal and informal ways of communication are preferable to more rigid methods when dealing with more complex knowledge (c.f., [5, 19]). In fact, focusing narrowly on the codification of knowledge may even be counterproductive [25, 33]. Whether informality is chosen because of practicality, habit, or simply because of communication speed, it introduces additional troubles, especially for the onshore-offshore collaboration. Due to the poor level of documentation or not being allowed to utilize similar methods, the offshore unit was not really grasping the meaning as they were supposed to. This further troubled the development activities.

Unsuitable development practices.

The current development practices, which are largely controlled and dictated by the onshore vendor, also do not allow knowledge to be transferred effectively. Sometimes inappropriate inter-organizational processes, management styles, and development practices determined by the onshore vendor hinder KT [4, 12, 26, 35]. This was particularly evident when the vendor assigned only very small tasks to the offshored team. As a result, real debate of issues was missing, diminishing the utilization of the offshored developers’ expertize. Another issue related to the development practices is the unsuitable tools. The current tools may serve the customer and onshore vendor reasonably well. However, although they are not suitable for KT between the onshore and offshore units, no one mentioned whether different, more descriptive communication tools would have been available or discussed their limitations. Other tools were not employed even though the offshored unit had clearly stated this concern. This gives us a reason to believe that the reason for selecting certain tools and practices had more to do with politics and attitudes than the lack of competence. On the other hand, these tools could have been “chosen” since they were already there as they were used in earlier occasions when doing in-house development. These shortcomings in development practices and routines could be due to a higher level management problem. The Customer ICT Manager explicitly speculated in this regard as follows:

The project was not managed as a software project should be managed. This was maybe the biggest mistake in the first place. There were no clear responsibilities, plans, or milestones in place…A real attitude for working was missing. It was already suggested that someone should “cast the CEO aside and get a real manager in.” I think it is completely a matter of leadership. They do have good people at the [Vendor].

Too many middlemen.

Communication practices and strict flow of development needs was also a source of KT challenges. As the customer needs and requirements were difficult to articulate, the developers would have needed to be closer to the actual users. Currently there were too many middlemen and nodes between them. Not only does the number of middlemen influence the virtual distance of these ends of the development, but it also makes the whole chain likely to suffer from the “broken telephone” syndrome. In other words, having multiple gatekeepers disturbs the message, and blurs its nuances and details. Consequently, the final outcome, i.e., the shared understanding, may not reflect the original needs. The long chain of actors is definitely not supporting the utilization of the offshore personnel’s competences, which, ultimately, was one of the prime reasons for engaging them in offshoring.

Political issues.

Finally, different political tensions between the organizations add complexity. Regardless of whether it is the vendor not willing to give up its power or the offshored unit not interested in accumulating the customer-related knowledge, the situation is detrimental. This affects the motivation and attitudes of the people involved (see also [36]). Furthermore, political issues were also causing rigidness in the operating model. For example, rigid practices do not support KT as requirements are difficult to articulate. To understand them, the developers and designers need to often take a different stance (e.g., more abstract viewpoint, directive debate, or managerial approach), or communicate directly with other people, not just with the gatekeepers. Consequently, both personal preferences and attitudes and organizational obstacles and practice prevent such dynamicity. This, in turn, made KT difficult.

Besides political issues and client-supplier mentality, another reason for low motivation to transfer knowledge might be the job switching. For example, almost one fifth of the offshore outsourcing company’s staff left the company within a yearFootnote 1. The low level of retention of the offshored employees or organizations influences KT and knowledge accumulation [9, 37]. This eventually leads to additional efforts to bridge the knowledge gap [5]. As KT is a time-consuming activity, this issue necessitates special attention. Thus, considering the enormous efforts needed for KT, the companies must really take this possibility into account and come up with a suitable solution. Nevertheless, if the team members are expected to leave, they are lacking motivation to study and understand this particular customer’s business. However, the turnover of the offshore personnel is not the only dynamic element in the ISD network; other employees, such as the project manager in this case, and organizations may also change. In fact, the whole network evolves during a project (c.f. [38]).

Furthermore, addressing the development network introduces additional insights. Offshore outsourcing literature has often focused on the vendor’s absorptive and retentive capacities [12]. Our findings highlight that the customer organization and its knowledge, along with knowledge processes between the customer and the vendor, have a significant impact on the KT between onshore and offshore parts of the vendor. Thus, focusing solely on tools for transferring knowledge over that boundary is not sufficient. The whole network needs to be taken into account. Additionally, communication tools and practices developed and used between some parties may not be adequate for all the other parties in the network because they do not provide an adequate level of abstraction or allow detailed discourse regarding different, emerging issues [28].

The difficulty of using and deploying different development methods and practices also has an impact on KT. The practices were not alike in both dyadic relationships: between the customer and the vendor, and between the vendor and the offshored unit. Harmonizing and developing development practices have proven to be difficult, as discussed by Fitzgerald et al. [39] and Larsen et al. [40]. This implies that KT practices and tools, possibly integrated with systems development practices and tools, need to cope with similar rational, political, organizational, contextual, and individual issues as ISD methods and their organizational deployment. How this can be accomplished remains to be seen, although its importance of succeeding in offshored development work is evident.

6 Conclusions

In this paper, we have studied knowledge transfer and its challenges in a situation where the customer organization has outsourced the systems development to a vendor, which, in turn, has offshored the development to a cheap-labor country. Although the findings mostly parallel the previous literature, especially the nature of the knowledge to be transferred, systems development methods that are inappropriate and unsuitable for the networked collaboration, the number of middlemen in the network, and all kinds of political issues seem to be major challenges. They seem to be root causes for traditional KT challenges – at least in this case. Whether they are root causes elsewhere and in other contexts requires future research.

The study contributes to research by providing a rare snapshot of KT in a networked situation. This snapshot highlights that some challenges and their impact multiplies when there are several parties involved. The paper thus opens up new research avenues to focus on the relationships between the organizations and individuals, and on their different issues. For example, ISD method researchers and developers could utilize these findings when designing development practices and tools for offshored systems development. The study contributes to practice by showing some potential points of problems so that they can be tackled when one organization plans whether and how to outsource or offshore their systems development.

The IS development network we have studied has not been successful. The customer organization has not received what they expected. On the other hand, the vendor has struggled to produce both a customized system for the customer and to develop a generic software product. We argue that some of these problems can be explained by an inexperienced development practices and KT: the customer and the vendor have had no experiences on offshoring the development. Consequently, they have not been able to proactively prepare for different challenges that are ahead. It seems that they are riding for a fall.