Available online at www.sciencedirect.com
Information & Management 45 (2008) 96–108 www.elsevier.com/locate/im
Developing a knowledge-based perspective on coordination: The case of global software projects Julia Kotlarsky a,*, Paul C. van Fenema b, Leslie P. Willcocks c a
Warwick Business School, The University of Warwick, CV4 7AL Coventry, United Kingdom b Netherlands Defense Academy, The Netherlands c London School of Economics, United Kingdom
Received 22 November 2006; received in revised form 14 November 2007; accepted 2 January 2008 Available online 20 February 2008
Abstract We have attempted to bring together two areas which are challenging for both IS research and practice: forms of coordination and management of knowledge in the context of global, virtual software development projects. We developed a more comprehensive, knowledge-based model of how coordination can be achieved, and\illustrated the heuristic and explanatory power of the model when applied to global software projects experiencing different degrees of success. We first reviewed the literature on coordination and determined what is known about coordination of knowledge in global software projects. From this we developed a new, distinctive knowledge-based model of coordination, which was then employed to analyze two case studies of global software projects, at SAP and Baan, to illustrate the utility of the model. # 2008 Elsevier B.V. All rights reserved. Keywords: Knowledge management; Knowledge flows; Coordination; Coordination mechanisms; Global software projects; Software development
1. Introduction Coordination is the achievement of concerted action [14]; it is essential for the development and delivery of products and services. Coordination theory was previously considered from an information processing perspective. But though this perspective has been useful, its assumptions, combined with recent developments in organization theory, have made a revision necessary. Organizational economists and knowledge management researchers have been moving gradually towards a knowledge-based perspective of organizations, they seen as consisting of intelligent, learning, reflexive, creative and, communicative knowledge workers. As a result many organizations are becoming more knowledge-intense and, due to worldwide activities, globally distributed. Coordination is then perceived as a problem of sharing, integrating, creating, transforming, and transferring knowledge. * Corresponding author. Tel.: +44 2476 524692; fax: +44 2476 522736. E-mail address:
[email protected] (J. Kotlarsky). 0378-7206/$ – see front matter # 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.im.2008.01.001
The change to a knowledge-based perspective has received attention from organizational economists, who have revised their theory of the firm [16], and knowledge management researchers, who consider knowledge as a dependent variable requiring coordination across the organization. Consequently some have proposed that transactive memory, mental models, and frames can support the needed coordination [2,12,18]. However, the mechanics of how cognitive similarities and linkages lead to coordination is often unclear. Therefore, we have attempted to provide a knowledge-based perspective on coordination. Specifically, we sought to answer the following question: How do coordination mechanisms contribute to knowledge processes so that coordination is achieved? 1.1. Research context: globally distributed software development projects Globally distributed software development projects consist of two or more teams working together to
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
accomplish project goals from different geographical locations. Difficulties of accomplishing this effectively include distance, time-zone, and cultural differences; these, may include also different languages, values and traditions, norms, and behavior. The practices recommended to overcome such difficulties focus on (i) inter-site coordination through a division of work that minimizes cross-site communication and synchronization [10,24] and (ii) technologies that support collaboration in a distributed environment. Studies focusing on global software team performance point to the importance of knowledge sharing in building trust and improving effectiveness, while recognizing the additional complexity in sharing knowledge across geographically dispersed sites, not least because of the tacit dimension of so much knowledge [17,28]. Following Wegner [33], Faraj and Sproull found that transactive memory is important in globally distributed software teams—instead of sharing specialized knowledge, individuals should focus on knowing where expertise is located and needed [e.g., 2,21,29]. Despite the fact that most of the problems reported in global software projects are fundamentally to do with information and knowledge, past research not focused on the role of knowledge sharing and social aspects of global software projects.
2. Theoretical background 2.1. Coordination mechanisms Since the development and delivery of software products and services exceeds the capacity of individuals, work on them must be divided and coordinated. The literature distinguishes various of coordination mechanisms [22]; they usually include ones emphasizing the formal, dimension of organizations, and others based on their social and informal dimensions, i.e., interpersonal adjustment and feedback [8,32]. Following this concept, categories of coordination mechanisms include: organization design, work-based, technology-based, and social mechanisms. These are usually considered in terms of their information processing properties. We mere reconsider them in the light of the data-information-knowledge continuum. Organization design mechanisms encompass formal structures such as hierarchies, linking pins, teams, and direct contacts. These structures can be considered ‘mental traces’ that are enacted and modified in practice [27]. The objective of organization design is to accomplish the integration of differentiated tasks. Professionals and units with unique tasks must work together to integrate knowledge and achieve a common output. How their accomplishments are linked at a general level is determined by the roles to which people and units
97
are assigned, and how these roles are linked. Direct forms of design (direct contacts, teams) have higher information processing capacity than indirect forms (hierarchy, liaisons). The former is more suited to complex, uncertain tasks that may involve diversely skilled professionals. Organization design mechanisms define roles for knowledge workers and patterns of dependence and cooperation. These provide structures for managing knowledge flows that constitute organizational learning and value creating [15]. Organization design contributes to concerted action by making explicit who is responsible for what, who is supposed to know what, and how individuals are supposed to collaborate. This aids alignment of their actions. Work-based mechanisms involve the specific structuring of tasks to be accomplished. They include plans, specifications, standards, categorization systems, and representations of work-in-progress, such as prototypes and design documents. The mechanisms include data (specifications), information (instructions), and explicit knowledge. They coordinate activities. For instance, a detailed procedure and schedule for manufacturing a product instructs individuals how to behave and contribute so that they will be perceived as wellcoordinated and value-adding, without a need for further communication. People tend to rely more on work-based practices if tasks are complex, if communication opportunities are limited, if many people are involved, and when achieving common understanding is very important. Technology-based mechanisms support coordination by enabling information capturing, processing, storage, and exchange (e.g., electronic calendaring and scheduling, groupware, shared databases); that is, through IS services. Thus, technology replaces humans for coordinating tasks. In project management this may include automated scheduling, automated file version control, and automated notification when tasks are finished. Coordination is achieved by IS components that operate and interact with their environment so that resource conflicts (e.g., version problems or use of shared resources) are resolved. Technologies allow people to communicate asynchronously and possibly remotely. Technology thus coordinates indirectly, by allowing individuals to coordinate their activities. Social (inter-personal) mechanisms involve communication activities, working relationships, and social cognition. Firstly, communication has been traditionally recognized as a mode for adaptive coordination. When people encounter novel circumstances or counterparts, they communicate in order to establish a shared understanding [8,20]. Secondly, working relationships enhance the accuracy of expectations about another person’s thoughts, activities, and expectations. This promotes coordination and communication efficiency. And thirdly, social cognition involves the frames and mental models
98
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
that people share because of similar personal experiences or education. Achieving concerted action is more likely when such social practices occur: they improve interpersonal anticipation and adjustment [30]. Organizations select and deploy them when they work on novel or tightly linked tasks, or when people from different functional areas must cooperate [9]. Social mechanisms concern both information and knowledge. A number of recent IS and management studies have stressed the importance of various social mechanisms for coordination among both co-located and globally distributed teams.
[7]. The ability to interpret data on an object in a meaningful manner does not imply possession of knowledge. The meaningfulness of data thus depends on knowledge:
Typically coordination mechanisms are considered as complementary. For example, work-based mechanisms, such as plans and specifications, are generally made available for all teams members in a project repository and made accessible on the Web. The choice of mechanisms from each category needs to match information processing, and therefore coordination needs depends on contingency factors, such as diversity, work unit size, and task uncertainty.
The positioning of the same data on the data-informationknowledge continuum thus varies across organization units, levels and roles. Knowledge work depends on meaningful interactions amongst experts. In information system development (ISD) projects, knowledge of a business context, applications, infrastructure, and project management is transferred, combined, and integrated to achieve collective understanding of the emerging system [6]. We took a knowledge-based view of coordination. Table 1 compares this with an information processing perspective. We feel that an information processing researcher tends to emphasize the pragmatic dimensions of coordination (e.g., who does what?), commonly perceived in task environments where knowledge requirements of work are well known and where much of the work has been clearly structured. However, the knowledge management researcher focuses on individuals’ understandings and how they interrelate [3]. Coordinating the work from knowledge workers involves synchronizing, adapting, and fine-tuning the processes of sharing, integrating, creating, transforming,
2.2. Towards a knowledge-based perspective of coordination Over the past decades, organizational processes have become more complex and knowledge intense, and therefore require more awareness and capability in the area of knowledge management. Knowledge has been defined as ‘‘information combined with experience, context, interpretation, and reflection. It is a high-value form of information that is ready to apply to decisions and actions’’
[. . .] one person’s knowledge is often another’s raw data. What a vice president for marketing, production, or finance thinks he knows is just data to the chief executive officer’s staff. What a scientist thinks he knows about the merits of a flu vaccine or the safety of a nuclear reactor is just data for presidential policy and politics. Data or knowledge are just types of information content—of greater or lesser value, of greater or lesser cost’’ [26].
Table 1 Comparing information processing and knowledge-based perspectives on coordination Dimensions
Assumptions of an information processing perspective on coordination
Assumptions of a knowledge-based perspective on coordination
Work, work division, task dependencies
Larger task outcome and processes are known
Larger tasks are known only in intention and broad terms, not in detail Emphasis on knowledge specialization and knowledgebased contribution of individuals rather than task and work division
Subtasks are defined and assigned to individuals Task dependencies are known Interpretations of tasks are unequivocal Coordination challenge
Coordination of activities Who does what, when, in cooperation with whom? After answering relatively straightforward ‘tip of the iceberg’ questions, coordination can be achieved These questions require information processing
Coordination of experts’ thoughts How do individuals interpret work? How can they understand what others think?
Role of coordination mechanisms
Selection and use of coordination mechanisms is straightforward, and will lead to coordination Coordination mechanisms have primarily a role as enablers of information processing for addressing the coordination challenge
Coordination mechanisms enable coordination through their influence on knowledge processes Coordination mechanisms promote building of social capital, facilitating knowledge flows, making knowledge explicit, and amplifying knowledge
Workers
Accomplish physical activities or simple routine services Process information for coordinating tasks with others
Accomplish knowledge processes for knowledge outputs Process information and knowledge for coordinating tasks with others
How can they interrelate their understandings and work towards coordinated processes and outcomes? These challenges require knowledge processes
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
and transferring knowledge, rather than merely processing information that represents work. The knowledge-based perspective suggests that coordination is less about scheduling pre-defined tasks and more about interrelating the efforts of knowledgeable professionals in a concerted manner, i.e., to achieve order [19].
3. Research model: a knowledge-based perspective on coordination When coordination is considered from a knowledge point of view, the coordination mechanisms are important because of their role in knowledge processes. Key questions become: How do these mechanisms contribute to knowledge processes? and What must happen to knowledge in order to achieve coordination? Organizations must coordinate activities that are performed in different time-space configurations and across a variety of units, teams, and communities. If they do not, their performance suffers from asymmetries, knowledge being ‘stuck’ at a particular site, and the unrealized potential of lost knowledge creation. Coordination mechanisms become knowledge management instruments, with a focus on their contribution to the coherence of knowledge processes and activities in achieving a coordinated outcomes. Our research model (Fig. 1) suggests how each category of coordination mechanism impacts on knowledge processes and thus ultimately on a coordinated outcomes.
99
Organization design mechanisms facilitate knowledge flows by providing a structure through which knowledge workers can channel their expertise. To achieve coordination, the knowledge must flow, be connected, and various perspectives must be determined [4]. Organization design clarifies who is supposed to know what and who is supposed to communicate with whom. It therefore economizes knowledge flows. Work-based mechanisms that capture knowledge are important for making knowledge explicit, as they enable activity replication and commonality [1]. We considered the explicitation–internalization cycles proposed in Nonaka et al.’s socialization, externalization, combination, internalization model in the light of achieving coordination. The use of work-based mechanisms implies that knowledge and expectations are made explicit and thus are known and useful to other people working at different sites or times. In such dispersed organizations, knowledge must be rapidly disseminated by means of technology. Knowledgeintense multinationals and service firms amplify their knowledge management processes using intranets, knowledge databases, and groupware. While IS processes data and information, to knowledge workers within the same community and organization these constitute knowledge that trigger new ideas and enable coordinated actions. Social mechanisms establish social capital [13] and knowledge (who knows and does what) [12,25]. Individuals are thus knowledge workers who negotiate points of view and transform their understanding to generate innovative
Fig. 1. Research model.
100
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
outputs; they have relational needs that are relevant for coordinating their work.
4. Research design and methods 4.1. Design and case selection A case study method was selected for our work. A qualitative, interpretive approach was adopted. Selection of the location of the case studies was driven by the question: How do coordination mechanisms contribute to knowledge processes so that coordination is achieved? To analyze the role of coordination mechanisms we compared two organizations: one has been successful in generating coordinated outcome the other was not. To be consistent with other studies that have evaluated success in IS development projects, we put emphasis on the project outcomes: on-time delivery, within budget, having process quality, and with reuse of components [5]. The nature of success and failure is therefore assessed based on whether an organization has succeeded or failed in producing a coordinated outcome through the use of (one or more) coordination mechanisms. Based on this criterion we selected one successful project at SAP and one project that failed at Baan. By comparing the coordination mechanisms used to facilitate knowledge processes in the cases, we drew conclusions about the role of knowledge processes in achieving coordination and demonstrated how the research model could be applied in practice. 4.2. Data collection Evidence was collected from interviews, documentation and observation, as suggested by Yin [34] and Eisenhardt [11]. Interviews were conducted at two remote sites per company: in India and Germany for SAP; in India and The Netherlands (NL) for Baan. To reflect the perceptions of participants in different roles on the coordination mechanisms and knowledge required to achieve coordination, we focused on project teams and, within project teams, interviewees were chosen to include counterparts working closely at remote locations, and diverse roles, such as managers, team leaders, and developers. In total, 19 interviews were conducted in two companies; they lasted about 1.5 h, were recorded, and fully transcribed. A semi-structured interview protocol was used; this allowed the interviewers to clarify specific issues and follow up with questions. The interview protocol served as a tool to enable consistency in the data collection to enhance reliability of the results. 4.3. Data analysis Data analysis relied on an iterative reading of the data using open-coding techniques [31], and sorting and refining
themes emerging from the data with some degree of diversity [23]. In particular, four themes were carefully studied: coordination by organization design, work-based coordination, technology-based coordination and social coordination. Statements that were found to correspond with mechanisms that support these four types of coordination were selected, coded and analyzed using Atlas.ti—Qualitative Data Analysis software. The first step involved reading the interview transcripts and collected documents, creating a list of coordination mechanisms that were employed or were lacking in the projects under study, and marking evidence of the existence of or lack of knowledge processes, according to the four types of knowledge processes: designing knowledge flows, amplifying knowledge management processes, making knowledge explicit and building social capital. During this stage text (paragraphs or sentences) describing coordination mechanisms and evidence or lack of knowledge processes were coded. Second, statements (i.e. codes) illustrating coordination mechanisms were grouped into the four categories of coordination mechanisms. Finally, we analyzed statements in each of the four categories to identify the impact of coordination mechanisms on knowledge processes and, through knowledge processes, to achieving a coordinated outcome. Thus, statements grouped into each of the four categories were analyzed in the light of knowledge processes supported or not supported by the coordination mechanisms. To ensure the validity of this research interpretation of selective codes and grouping codes into categories, this was performed by several investigators and differences discussed.
5. Analysis and results The results of the two case studies were examined to determine how the use of coordination mechanisms facilitated knowledge processes between globally dispersed teams and enabled remote counterparts to share and integrate their knowledge. 5.1. The SAP case 5.1.1. The project under study The SAP Collaboration tools project was originated by the Knowledge Management (KM) Collaboration group, a part of its Enterprise Portal Division. The goal of the project was to develop a comprehensive collaborative platform that would allow both individuals and teams in different locations to communicate both real-time and asynchronously, and to support the teamwork of distributed project
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
teams. The tools were developed to be part of their next generation application and integration platform (SAP NetWeaver), and to allow integration with tools of different providers. The development of the SAP Collaboration tools started in September 2001. By June 2002, its first version was released and the group had started working on the second release. 5.1.2. Software team The KM Collaboration group, in which one of our case studies was conducted, is part of SAP Portal. From a geographical perspective, the software team was distributed in three locations; it consisted of four teams: two in Walldorf, Germany (ten people in each team), one in Bangalore, India (six people) and one in Palo Alto, USA (five people). Each team worked on a different part of the Collaboration tools (see Fig. 2). The development managers of each team reported directly to Stefan, who was the director of the group. Two development architects, Christoph and Martin, worked on the conceptual design of the architecture. Their responsibility was to drive the architectural design and ensure that everything fit together. 5.2. SAP case: analysis In September 2001, when the Collaborative tools project started, key players (managers and architects) and team members from remote locations had not met one another.
101
Some of the team members had previous experience of working in a globally distributed environment, but not necessarily with Indian, German, or American cultures. For the majority of the key players and team members a crosscultural setting was new. Furthermore, at the beginning of the project, there was a knowledge gap between individuals involved in the project: People have different profiles: here [in Bangalore], the maximum experience is 5 years. But if you take these three colleagues travelling to the team-building exercise [Stefan, Christoph, and Thomas], two of had about 12–15 years of experience, and the minimum experience [in Bangalore] was about 2.5 years, so that’s a huge experience gap that they have to bridge (Sudhir). From the very beginning managers of the KM Collaboration group realized the importance of sharing and coordination of knowledge across dispersed locations, and put a lot of effort into setting up and facilitating the knowledge process. 5.2.1. Coordination by organization design The organization design of the KM Collaboration group tried to facilitate knowledge flows in order to reduce existing gaps and prevent knowledge and information gaps in the future. In particular, a clear division was made between technical and social supervision (management of local teams); the technical architects were located in Walldorf while the local development manager were tasked with ensuring the quality of the product and effective team
Fig. 2. Organizational structure of KM Collaboration group (as of June 2002).
102
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
operations. The local development manager divided specific assignments (tasks) between team members and resolved social issues. The development manager and team members were of the same culture. Furthermore, mini-teams were created and reporting channels across the globe were established. For example, Christoph and Martin (development architects in Walldorf) served as technical contact persons for the remote teams: Christoph was a contact person for Bangalore, and Martin was a contact person for the Palo Alto team. The architects provided technical supervision for the assigned remote team and were responsible for technical issues and the quality of software developed by the team. Creating cross-continental miniteams was helpful in shaping communication patterns, providing clarity and thus facilitating knowledge-sharing processes between the Head Office in Walldorf and remote sites. Moreover, direct communications were encouraged in the KM Collaboration group to facilitate knowledge sharing. After the key players visited Bangalore and met the remote team members, centralized communications (via Sudhir) were replaced by direct communications. Christoph explained: From a code perspective, what I did before I met all of them was to send all things to Sudhir and he was the one to distribute it within the team; this has changed now. I address most of the things directly to the team members [. . .]. Quick and direct communication as far as possible is the most important thing. ‘Direct’ means: do not communicate through other people but with the people. If you have one contact person who distributes all the information, you lose some of the information, because you do not reach the right people.
related documents], so even the specifications look more or less the same (Christoph). A sharing of knowledge embedded in the standards aided coordination across the locations, as people performed interrelated tasks coherently. 5.2.3. Technology-based coordination A variety of technologies were used to communicate, coordinate and share knowledge, thereby amplifying knowledge sharing of the team. These allowed remote team members to share explicit knowledge resources and increased the speed and flexibility of knowledge sharing independent of place and time (via remote/asynchronous collaboration). Furthermore, these facilitated the reuse of knowledge and software components across locations, and this reduced time-to-market of new product versions. For example, videoconferences (VC) with members from all remote teams were used to identify opportunities for reuse: The team in Walldorf should be aware of what is being developed in Bangalore or Palo Alto, so that we don’t reinvent the wheel again and again. So we communicate about things that are being done, and if there is something reusable which we are developing, or have they developed something which somebody else can use. Then you are not rewriting the whole product again and again. Maybe they can just use our package available, make some changes according to what they need, and use it. For things like that we need to interact with each other (Akhilesh).
5.2.2. Work-based coordination Work-based coordination aimed to capture knowledge and make it explicit and accessible to all team members despite their geographical location. First, work was divided by feature, providing dispersed teams with full ownership of and responsibility for an entire block of functionality: [‘you are responsible for what you have taken up’ (Stefan)]. This approach reduced knowledge dependencies in the newly formed global team, thus reducing the possibility of misunderstandings and conflicts. Moreover, it was important, for offshore teams, to have full ownership of their work. It gave them a feeling of being valuable and motivated them to collaborate and share knowledge. Second, to ensure consistency in the methods and tools used by dispersed teams and to facilitate common understanding of the product, the managers of KM Collaboration group decided to standardize tools and methods across dispersed locations:
Moreover, Internet and Web-technologies allowed the centralization of technologies under a single environment accessible from all remote locations; this was important to ensure that everybody was working with the same, most upto-date versions. For example, SAP Intranet (called SAPNet) served as a central place with links to all updated information. Thus, technologies allowed remote counterparts to update their knowledge about on the situation, including plans and the progress. A variety of collaborative technologies were used for different situations. The phone was used for urgent matters, for regular updates between managers, and to resolve misunderstandings. For knowledge sharing between remote counterparts an application sharing tool (AST) or VC were used. For example, AST was used remotely for discussions that involved showing slides (usually, to show a presentation, and simultaneously use the phone to explain the slides and discuss issues); and for discussing technical issues (e.g., code reviews or debugging): in this case the AST was used to take control of a computer remotely. Twice a month VC sessions that involved managers and developers from all three locations were initiated to discuss progress and other issues:
We use all the same tools, so there is no difference. We even use the same Word templates [for project activities and
Whenever a new colleague joins our team or any of the teams in the other locations, in the next VC we will have an
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
introduction round like ‘these are new colleagues that have joined’. So though you have not met them physically, you get to know that this is the person, he exists there, things like that (Akhilesh). Thus, counterparts from dispersed locations learned the composition of a remote team and knew who to contact. Finally, email was used for low priority tasks and issues, and tasks that could not be completed in real-time because of time-zone differences. 5.2.4. Social coordination Social coordination mechanisms aimed to create social capital for the global team. A particular effort was put into building up shared experiences, and creating transactive memory among team members. Social mechanisms included team-building activities and mutual adjustment were aimed at reducing knowledge gaps, building relationships and maintaining team atmosphere. Furthermore, frequent interactions and systematic communications between remote counterparts were considered important to ensure effective coordination over distance. The transactive memory in the group started with the project initiation. Having transactive memory was important as it influenced the information that had to be shared, and this had an impact on the efficiency of communication, as illustrated by the following: A simple one-line question can result in a 10-page answer. It can be a very lengthy answer to a one-line reply. The level of detail you get in the answer depends on how well you know that person. Because if the person knows me very well and knows in what areas I am working, then he can decide how much information I will need. Is one line good enough for him or should I explain to him over three pages so that he knows what is happening? (Sudhir). To bridge the knowledge gap and facilitate knowledge sharing between the teams in the early stages of the project, Sudhir organized a team-building exercise in Bangalore in which key team members from all the sites participated. This gave an opportunity for key members to meet, learn about areas of expertise of remote counterparts, learn about cultural differences, and create space for social interaction. This exercise helped to reduce the possibility of conflicts and misunderstandings: The team-building exercise improved relationships among the KM Collaboration group, because earlier communications were only in a formal way, and after the team-building activity we really knew people much better, it became easier to communicate and communications became more informal (Jyothi). Thus, the team-building exercise promoted knowledge sharing processes. It was the first major step towards bridging knowledge gaps between the team members, and towards developing trust:
103
The end result of that exercise was that the entire team feels more comfortable to work together. Now they know each other and trust each other better (Stefan). Mutual adjustment included setting up rules of communications which helped people adjust to communication styles and reduced the misunderstandings and confusions that typically happened as a result of different cultural backgrounds. For example, Indian team members learned not to feel threatened when Germans were too direct. Facilitating interactions between remote counterparts included face-to-face interactions and organizing frequent distant interactions. For example, regular teleconferences between software managers in Walldorf, Bangalore and Palo Alto, and transatlantic VCs with all team members every 2 months helped to keep the knowledge of all parties up to date. 5.3. The Baan case 5.3.1. The project under study This case study focused on the development of an EEnterprise Suite. It was conducted in early 2002, when two globally distributed locations, Hyderabad (India) and Barneveld (The Netherlands), were joined in developing the E-Enterprise Suite, which had been designed to allow users to extend their Baan manufacturing, financial, and distribution software on the Web and thus to collaborate better with customers, suppliers, and partners. In March 2002 the E-Enterprise Suite consisted of seven products that were all based on one platform: the E-Enterprise Server. Products included in it were developed to be stand-alone as well as integrated with the Baan ERP package. 5.3.2. Software team Development of the E-Enterprise Suite was organized by feature/product function. The group was distributed was in Hyderabad (about 60 people working on five products of the Suite) and Barneveld (about 35 people working on two products and the common platform of the Suite) (see Fig. 3). In addition to the E-Enterprise group, the Marketing and Alliances group and the Project and Process office were involved in managing the E-Enterprise Suite. 5.4. Baan case: analysis The E-Enterprise group was relatively young: the first EEnterprise products were released in 1999. Some people in Hyderabad had been working in a globally distributed environment before joining the group. However, because of a general Baan policy to reduce travel expenses, and because the E-Enterprise organization structure had changed several times since the group was established, team members had not worked together: the majority of them did not know the composition of the dispersed team. Therefore, a transactive memory of dispersed team members was never developed.
104
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
Fig. 3. Organizational structure of E-Enterprise development group (as of March 2002).
Furthermore, team members in NL and India had different cultural backgrounds and organizational culture (newcomers and people from the Baan ERP group), nor did they have a common technical background. Therefore, there was a gap in common understanding of the technology and the processes that team members were supposed to follow. Moreover, people in the Hyderabad office were often unaware of the current efforts in the Barneveld office: they were not updated about changes in requirements and dependencies between the products, and were not aware of product and technology roadmaps. 5.4.1. Coordination by organization design The organization design of the E-Enterprise group was continuously changing: the people, their roles, the products, product requirements, processes, ownership and physical locations of tasks were all changing rapidly. Moreover, too many people in different roles were involved in the management of each product in the Suite, so that some responsibilities overlapped. This resulted in a situation where everybody was involved but nobody was responsible. Interviewees were asked to list the people involved in the management of different E-Enterprise products and to describe their roles and responsibilities. From the responses of the interviewees it became obvious that people often had different views on their own or their colleagues’ responsibilities. Lack of stable organization design and clearly defined roles created flaws in knowledge flows: some information was lost because there were no clearly defined communication channel, team members had very limited knowl-
edge of their remote counterparts, and often did not know who to contact at a remote site when issues occurred. 5.4.2. Work-based coordination Work-based coordination in the E-Enterprise group was limited. First, there was no clear division of work between the Indian and Dutch teams. For example, between 1999 (when the first version of the E-Enterprise Suite was developed) and 2002 (when the interviews were curried out) ownership of the common platform – E-Enterprise Server – was transferred from India to NL and then back to India. Changing ownership had implications for knowledge processes: there was always a need to understand the product developed by another team (which was often more difficult than to develop a new product), and there was never complete knowledge of the product and the logic behind it at either location. For example, as Sujai explained: It’s difficult to visualize the idea when it is not yours. If we have the knowledge of the existing product then we’re building on top of it, it’s easy. But sometimes it happens that the understanding of the existing architecture is not very good because we are not there from the beginning: the initial product has been transferred from there [NL] to here [India]. Furthermore, there was no feeling of ownership, because the product was inherited from another team: [I expect one of the important things that should happen within E-Enterprise Baan or anywhere is that more ownership must be felt by everybody (Vijaya)]. Everything seemed to be in transition and to be unstable. This situation reduced morale in the group and increased tensions between Indian and Dutch group
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
members. This tense relationship, in turn, reduced the motivation of team members to share knowledge. Moreover, there were strong technical dependencies between the E-Enterprise Server and the seven products comprising the Suite. The dependencies existed because the combinations of products had to work together. Technical dependencies on the E-Enterprise Server caused problems: specifications and schedules across products needed to be synchronized. Technical dependencies caused knowledge and information dependencies between the dispersed teams. Vijaya explained: The dependency on NL is causing problems. Dependency on information, dependency on knowledge (even in terms of simple design documents, for example, functional designs, or technical designs, they are not complete), dependency on requirements, because everything is centralized in Holland and then that has to be shared with us so that we can proceed. Because of the many unspecified dependencies, there was no structured approach to identify and coordinate them: One thing that is missing right now in E-Enterprise is that at any time you can’t look into any document to see what are the exact dependencies involved. Right now they’re coming with something like a dependency matrix. But so far we didn’t have that. So it’s generally like if you want to know tomorrow whatever dependency with another product, you have to actually talk to the team members or the Architect or the Consultant. There is no central store or central repository (Satish). However, it is important to note that there were some attempts in the E-Enterprise group to establish work-based coordination. For example, Baan tried to standardize development methods and processes: We want to have common processes across the locations. We try to achieve a uniform standard for all these. So that is a basic aim of this. Though we have not reached it in all the areas, in certain areas we are making steps (Jeevan). As work-based coordination was very limited, the remote team members suffered from incorrect information and lack of knowledge sharing. In particular, the lack of common knowledge about the evolving product was critical: We have an existing architecture and we need to build future products based on this architecture, so understanding the existing architecture is most important to be able to build on top of it. We have completed realization from our side [EProcurement and E-Sourcing] and E-Enterprise Server has also completed their realization. But now we need to integrate E-Enterprise Server into our applications. So for that we need a lot of knowledge about E-Enterprise Server (Sujai). 5.4.3. Technology-based coordination The E-Enterprise group had all the technologies required to enable them to work in a globally distributed environ-
105
ment. Technologies were considered important: [this is actually one of the most important things: technology comes to our rescue in working in a distributed environment (Venkat)]. Various technologies were used to save on travel costs, as Venkat explained: Quite some time back, before all of these tools came into practice, we used to travel to NL and they used to travel here in order to meet us, especially at the start of a new release or to work out some important issues that stretch over a long time. Even for small purposes people used to travel. That was becoming expensive and they [Baan] had to think of alternatives, then all of these media came into the picture. Then the VC was immediately applied. We started using VC, and we don’t have to go to NL: we are saving a lot of dollars. A variety of collaborative technologies were used in different situations. Typically, email was used for quick queries and describing a problem prior to a phone-call. The phone was used in situations when an urgent response was required and to resolve conflicting situations: Telephone usually involved when a lot of emails have been exchanged and certainly we feel that everyone is talking differently and it is taking too much time and no one is coming to any conclusions, then we start organizing a telephone call (Srinnivas). Overall, there was a tendency to minimize the use of the phone because of its costs. ASTs – particularly NetMeeting and Webex – were often used for knowledge sharing during meetings between sites and with customers. VC was used occasionally for updates between managers from dispersed locations. In the E-Enterprise group collaborative tools were mainly used for coordination and knowledge sharing purposes between individual team members. However, there was no configuration management tool in place to coordinate technical dependencies between products included in the E-Enterprise Suite (problems caused by lack of compatibility between versions of different products). 5.4.4. Social coordination In the E-Enterprise group, social coordination between dispersed team members was limited. Visiting the other country was difficult for people in the E-Enterprise group [because Baan was making cost-cutting measures, and had tried to shift everything to one location to reduce communication costs (Sridar)]. Therefore, the majority of team members had never been to the remote location and did not know their remote counterparts. Lack of social coordination caused problems. In particular, there was a lack of team atmosphere between Hyderabad and Barneveld: from interviews with members of both teams, tensions between teams became evident: The major issue is that people don’t perceive that on the other side, they’re not reciprocating our needs: what we
106
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
want, during which time, what priority we have. They don’t see the same priority as our people see, and vice versa. So there is always a gap (Jeevan). Interviewees were convinced that meeting their remote counterparts would allow them to develop rapport, learn about cultural differences and share views on the issues. This would have helped to bridge cultural and knowledge gaps: Personally I feel meeting the people would help you resolve the tasks more quickly, because you can really think and feel the person when you are actually talking. For example, assume two people, one has never come to India and the other has never gone to Holland. If they are interacting, there would be some gaps. But if they had an interaction at a personal level at some point in time, then the interaction would really be better, the response will be generally quicker (Phani). Understanding cultural differences could also have helped to bridge knowledge gaps and improve working relationships. For example, Ganesh (Process Manager for Hyderabad) explained that understanding cultural differences could have helped to define better processes that would be acceptable for both Dutch and Indian cultures: When we write the process plan there are a lot of cultural issues that come into the picture. How to deal with this particular area? I can give you an example on quality assurance—a critical area. In the Indian culture, quality assurance is an important topic—people don’t mind someone checking the work they do, but if you compare with our counterpart, in NL sometimes people don’t like this. Because the counterpart, the NL team, have a different culture— individualistic. So there will be some resistance on that front sometimes. Once we understand this and appreciate the cultural factors, then we can define a better plan. 6. Discussion 6.1. Coordination mechanisms at SAP and Baan Managers of the SAP KM Collaboration group implemented a number of coordination practices that were intended to facilitate knowledge processes between dispersed teams; managers of the E-Enterprise group of Baan did not. Table 2 lists the coordination mechanisms identified in the SAP case, grouped according to the four categories of coordination mechanisms. A ‘+’ indicates existence of a coordination mechanism, while ‘ ’ indicates lack of the mechanism. 6.2. Coordination mechanisms and knowledge processes 6.2.1. Organization design At SAP, a number of coordination mechanisms facilitated sharing and integration of knowledge. Various forms of
Table 2 Coordination mechanisms: comparison of results across cases Coordination mechanisms Coordination by organization design Contact person/liaison Mini-teams Direct contact Work-based coordination Enabling flexible PM techniques, planning by milestones Making efficient division of work Using specifications to guide the work Using standard tools, SOP and methodologies Technology-based coordination Shared Software Development tools Internet enabled ICT infrastructure Wide range of media and collaborative technology Shared databases Technology-enabled representation/visibility Social coordination Team-building Mutual adjustment Facilitating interactions Designing systematic communications
SAP case (successful)
Baan case (unsuccessful)
+ + + + + + +
+
+ + +
+ + +
+ +
+ + + +
organization design enabled different handling of the knowledge processes. For example, direct contacts were used to promote unbiased and efficient knowledge transfer. This established and maintained transactive memory and enabled knowledge integration. By contrast, at Baan, organization design did not define clear communication channels; this caused breakdowns in the coordination of work done at remote sites. This did not help the teams to achieve a coordinated outcome. 6.2.2. Work-based coordination Both companies used project plans and product specifications to coordinate work. However, the companies used these coordination mechanisms differently. SAP updated specifications were available on the intranet, and remote teams were informed about any modifications through their contacts. New knowledge was captured and made explicit and accessible to all team members. However, at Baan there was no central point of access to updated documents and, often, employees used outdated specifications to design their products. Both companies put efforts into the standardization of tools and methods across locations to reduce knowledge gaps and create common knowledge about these tools and procedures. Baan was implementing standard development methods and processes across locations. At SAP, standard tools and methods were implemented at the very early stages of the project.
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
6.2.3. Technology-based coordination Various technologies deployed at SAP helped to amplify knowledge processes throughout the locations: Web access and synchronization of data ensured that all teams had access to the latest files. At Baan there was an attempt to build a central requirements database. However, requirements were changing rapidly and the database was not up to date. At SAP, various collaborative technologies were available for team members: internal phone lines (a five digit number) between Bangalore and Walldorf made it easy to contact remote counterparts. These technologies were used in a proactive manner. In Baan, team members had a variety of collaborative technologies. However, at Baan these collaborative technologies were used largely in a reactive manner, to fill in knowledge and information gaps; for clarifications and to resolve problems. 6.2.4. Social coordination At SAP, the three dispersed teams were merged into one group at the start of the project, members of these teams built relationships with short visits organized to give developers and key players the opportunity to meet in an informal environment. This helped to create transactive memory and build relationships among the team members. By contrast, Baan did not have coordination mechanisms in place for building social capital. Furthermore, many of the people interviewed did not know their remote counterparts. Baan tried to reduce project costs by avoiding travelling, reducing the opportunity for team members to meet. As a result, there were tensions and less motivation to communicate and share knowledge. Therefore, communications were often postponed causing problems. 6.3. Knowledge processes and coordinated outcomes In SAP, the managers of the KM Collaboration group realized the importance of the sharing and integration of knowledge at the start of the project and put effort into setting up and facilitating knowledge processes. Interviewees from SAP said that knowing who knew what a enabled them to reduce development lifecycle because team members knew who to contact for a specific problem. As a result, they were able to achieve a successful coordinated outcome: We just went through a merger, so setting up a global project was not an easy task. Despite all the difficulties we managed to have a successful second software release within 8 months (Stefan). At Baan, managers of the E-Enterprise group had limited coordination mechanisms in place to facilitate knowledge processes. Subsequently, there were numerous knowledge gaps between team members. Moreover, the E-Enterprise global team did not develop transactive memory. Often interdependencies between products developed at remote locations were found to be a problem at the last moment and
107
this resulted in integration problems. As a result, working in a globally distributed environment proved to be a problem for the E-Enterprise group and in summer 2002 the development office in NL was closed.
7. Conclusions We developed a knowledge-based perspective on coordination and demonstrated its applicability in the context of globally distributed software projects. In terms of practical implications, we illustrated micro-coordination practices in relation to four types of knowledge processes and compared a successful project (SAP) with an unsuccessful one (Baan). But an even more important finding emerged managers should consider their organization in terms of knowledge processes, not just information flows. They must focus on how coordination mechanisms facilitate knowledge processes. Our research suggests that technologies are most useful for amplifying knowledge management processes to allow knowledge sharing. Organization design facilitates knowledge flows across organizations and teams. Work-based mechanisms make knowledge explicit and accessible, while social mechanisms are needed to build social capital and exchange knowledge and ideas. It is clear that unless management practices utilize their various knowledge payoffs, coordination in increasingly knowledge-intensive work environments will become problematic. Our research however has some limitations: the framework includes a one-directional, singular relationship between coordination mechanisms and knowledge processes. However, it is possible that one coordination mechanism (or a combination) affects more than one knowledge process. Finally, it is important to note that our findings are based on only two case studies of two different software packages and therefore are not truly generalizable.
References [1] P.S. Adler, Interdepartmental interdependence and coordination: the case of the design/manufacturing interface, Organization Science 6 (2), 1995, pp. 147–167. [2] A.E. Akgun, J. Byrne, H. Keskin, G.S. Lynn, S.Z. Imamoglu, Knowledge networks in new product development projects: a transactive memory perspective, Information & Management 42 (8), 2005, pp. 1105–1120. [3] G.A. Bigley, K.H. Roberts, The incident command system: high reliability organizing for complex and volatile task environments, Academy of Management Journal 44 (6), 2001, pp. 1281–1299. [4] R.J. Boland, R.V. Tenkasi, Perspective making and perspective taking in communities of knowing, Organization Science 6 (4), 1995, pp. 350–372. [5] I. Crnkovic, M. Larsson, Challenges of component-based development, The Journal of Systems and Software 61 (3), 2002, pp. 201–212. [6] K. Crowston, E. Kammerer, Coordination and collective mind in software requirements development, IBM Systems Journal 37 (2), 1998, pp. 227–245.
108
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108
[7] T.H. Davenport, D.W. De Long, M.C. Beers, Successful knowledge management projects, Sloan Management Review 39 (2), 1998, pp. 43–57. [8] A. Donnellon, B. Gray, M.G. Bougon, Communication, meaning, and organized action, Administrative Science Quarterly 31 (1), 1986, pp. 43–55. [9] D. Dougherty, Interpretive barriers to successful product innovation in large firms, Organization Science 3 (2), 1992, pp. 179–202. [10] C. Ebert, P. De Neve, Surviving global software development, IEEE Software 18 (2), 2001, pp. 62–69. [11] K.M. Eisenhardt, Building theories from case study research, Academy of Management Review 14 (4), 1989, pp. 532–550. [12] S. Faraj, L. Sproull, Coordinating expertise in software development teams, Management Science 46 (12), 2000, pp. 1554–1568. [13] J.J. Gabarro, The development of working relationships, in: J. Galegher, R.E. Kraut, C. Egido (Eds.), Intellectual Teamwork: Social and Technological Foundations of Cooperative Work, Lawrence Erlbaum Associates, Hillsdale, NJ, 1990, pp. 70–110. [14] D.L. Goodhue, R.L. Thompson, Task-technology fit and individual performance, MIS Quarterly 19 (4), 1995, pp. 213–235. [15] S.-C. Kang, S.S. Morris, S.A. Snell, Relational archetypes, organizational learning, and value creation: extending the human resource architecture, Academy of Management Review 32 (1), 2007, pp. 236–256. [16] B. Kogut, U. Zander, What firms do? Coordination, identity, and learning Organization Science 7 (5), 1996, pp. 502–518. [17] J. Kotlarsky, I. Oshri, Social ties, knowledge sharing and successful collaboration in globally distributed system development projects, European Journal of Information Systems 14 (1), 2005, pp. 37–48. [18] L.L. Levesque, J.M. Wilson, D.R. Wholey, Cognitive divergence and shared mental models in software development project teams, Journal of Organizational Behavior 22, 2001, pp. 135–144. [19] R. Lorand, Aesthetic Order, Routledge, London, 2000. [20] S. Maitlis, The social processes of organizational sensemaking, Academy of Management Journal 48 (1), 2005, pp. 21–49. [21] A. Malhotra, A. Majchrzak, Enabling knowledge creation in far-flung teams: best practices for IT support and knowledge sharing, Journal of Knowledge Management 8 (4), 2004, pp. 75–88. [22] J.E. McCann, J.R. Galbraith, Interdepartmental relations, in: P.C. Nystrom, W.H. Starbuck (Eds.), Handbook of Organizational Design, Oxford University Press, New York, 1981, pp. 60–84. [23] M.B. Miles, A.M. Huberman, Qualitative Data Analysis: An Expanded Sourcebook, 2nd ed., Sage, CA, 1994. [24] A. Mockus, D.M. Weiss, Globalization by chunking: a quantitative approach, IEEE Software 18 (2), 2001, pp. 30–37. [25] R.L. Moreland, in: L. Thompson, D. Messick, J. Levine (Eds.), Transactive Memory: Learning Who Knows What in Work Groups and Organizations, in Shared Cognition Organizations: The Management of Knowledge, Lawrence Erlbaum, Mahwah, NJ, 1999, pp. 3–31. [26] A.G. Oettinger, in: B.M. Compaine, W.H. Read (Eds.), Introduction, in the Information Resources Policy Handbook: Research for the Information Age, The MIT Press, Cambridge, MA, 1999. [27] W.J. Orlikowski, The duality of technology: rethinking the concept of technology in organizations, Organization Science 3 (3), 1992, pp. 398–427. [28] W.J. Orlikowski, Knowing in practice: enacting a collective capability in distributed organizing, Organization Science 13 (3), 2002, pp. 249–273.
[29] I. Oshri, J. Kotlarsky, P.C. van Fenema, Transactive memory and the transfer of knowledge between onsite and offshore teams, International Conference on Outsourcing Information Systems (ICOIS), Heidelberg, Germany, 2007. [30] I. Oshri, J. Kotlarsky, L.P. Willcocks, Global software development: exploring socialization in distributed strategic projects, Journal of Strategic Information Systems 16 (1), 2007, pp. 25–49. [31] A.L. Strauss, J.M. Corbin, Basics of Qualitative Research, 2nd ed., Sage Publications, Thousand Oaks, CA, 1998. [32] A.H. Van de Ven, A.L. Delbecq, R. Koenig Jr., Determinants of coordination modes within organizations, American Sociological Review 41, 1976, pp. 322–338. [33] D.M. Wegner, in: G. Mullen, G. Goethals (Eds.), Transactive Memory: A Contemporary Analysis of the Group Mind in Theories of Group Behavior, Springer Verlag, New York, 1987, pp. 185–205. [34] R.K. Yin, Case Study Research: Design and Methods, vol. 6, Sage, Newbury Park, CA, 1994. Dr. Julia Kotlarsky is an Associate Professor of Information Systems, Information Systems and Management Group, Warwick Business School, UK. Her research interests revolve around managing knowledge, social and technical aspects of globally distributed software development teams, and IT outsourcing. She has published widely her work in journals such as Communications of the ACM, European Journal of Information Systems, Journal of Information Technology, Journal of Strategic Information Systems, MISQ Executive and a number of book chapters. Julia is the co-author of ‘‘Knowledge Processes in Globally Distributed Contexts’’, Palgrave Mcmillan, 2008. Dr. Paul C. van Fenema is an Associate Professor at Netherlands Defence Academy, The Netherlands. His research focuses on coordination and knowledge management in global IS projects and High Reliability Organizations. His work has been published in books and journals such as MIS Quarterly, European Journal of Information Systems, Information Systems Journal, European Management Journal and others. Paul is the co-author of ‘‘Knowledge Processes in Globally Distributed Contexts’’, Palgrave Mcmillan, 2008. Prof. Leslie Willcocks is Professor of Technology, Work and Globalization at London School of Economics, UK. He has an international reputation for his research, educational and advisory work on outsourcing, IT management, developing IT leaders, IT evaluation and organizational change. Leslie is the co-author of 25 books. He has published his work in numerous journals including Harvard Business Review, Sloan Management Review, California Management Review, MIS Quarterly, MISQ Executive, Journal of Management Studies and others.
