Developing a knowledge-based perspective on coordination...

www.elsevier.com/locate/im

Available online at www.sciencedirect.com

nt 45 (2008) 96–108
Information & Manageme
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 Kingdomb Netherlands Defense Academy, The Netherlandsc 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 consid-

ered 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 knowl-

edge 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 knowl-

edge.

* 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

mailto:[email protected]

http://dx.doi.org/10.1016/j.im.2008.01.001

J. Kotlarsky et al. / Information & Management 45 (2008) 96–108 97

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 difficul-

ties focus on (i) inter-site coordination through a division of

work that minimizes cross-site communication and syn-

chronization [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 geo-

graphically 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, indivi-

duals 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.

� O
rganization 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

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 knowl-

edge workers and patterns of dependence and coopera-

tion. 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.

� W
ork-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 well-

coordinated 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.

� T
echnology-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 asynchro-

nously and possibly remotely. Technology thus coordi-

nates indirectly, by allowing individuals to coordinate

their activities.

� S
ocial (inter-personal) mechanisms involve communica-
tion activities, working relationships, and social cogni-

tion. 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 under-

standing [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

J. Kotlarsky et al. / Information & Management 45 (2008) 96–10898

that people share because of similar personal experiences

or education. Achieving concerted action is more likely

when such social practices occur: they improve inter-

personal 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.

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.

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, inter-

pretation, and reflection. It is a high-value form of

information that is ready to apply to decisions and actions’’

Table 1

Comparing information processing and knowledge-based perspectives on coordi

Dimensions Assumptions of an information processing perspec

on coordination

Work, work division,

task dependencies

Larger task outcome and processes are known

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 t

iceberg’ questions, coordination can be achieved

These questions require information processing

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

Workers Accomplish physical activities or simple routine s

Process information for coordinating tasks with ot

[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:

[. . .] 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].

The positioning of the same data on the data-information-

knowledge continuum thus varies across organization units,

levels and roles. Knowledge work depends on meaningful

interactions amongst experts. In information system devel-

opment (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,

nation

tive Assumptions of a knowledge-based perspective

on coordination

Larger tasks are known only in intention and broad

terms, not in detail

Emphasis on knowledge specialization and knowledge-

based contribution of individuals rather than task and

work division

Coordination of experts’ thoughts

? How do individuals interpret work?

he How can they understand what others think?

How can they interrelate their understandings and work

towards coordinated processes and outcomes?

These challenges require knowledge processes

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

ervices Accomplish knowledge processes for knowledge outputs

hers Process information and knowledge for coordinating tasks

with others


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.

Fig. 1. Researc

Organization design mechanisms facilitate knowledge

flows by providing a structure through which knowledge

workers can channel their expertise. To achieve coordina-

tion, 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, inter-

nalization 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. Knowledge-

intense multinationals and service firms amplify their

knowledge management processes using intranets, knowl-

edge 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

h model.


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 knowl-

edge 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—Quali-

tative Data Analysis software.

The first step involved

� r
eading the interview transcripts and collected docu-
ments,

� c
reating a list of coordination mechanisms that were
employed or were lacking in the projects under study, and

� m
arking evidence of the existence of or lack of knowledge
processes, according to the four types of knowledge

processes: designing knowledge flows, amplifying knowl-

edge management processes, making knowledge explicit

and building social capital.

During this stage text (paragraphs or sentences) describ-

ing 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 mechan-

isms 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 asynchro-

nously, and to support the teamwork of distributed project


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.

Fig. 2. Organizational structure of KM Co

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 cross-

cultural 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

llaboration group (as of June 2002).


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 (develop-

ment 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 mini-

teams 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.

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 under-

standing of the product, the managers of KM Collaboration

group decided to standardize tools and methods across

dispersed locations:

We use all the same tools, so there is no difference. We even

use the same Word templates [for project activities and

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).

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 up-

to-date versions. For example, SAP Intranet (called SAPNet)

served as a central place with links to all updated

information. Thus, technologies allowed remote counter-

parts 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 presenta-

tion, 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:

Whenever a new colleague joins our team or any of the

teams in the other locations, in the next VC we will have an


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 relation-

ships 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 communica-

tions 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 infor-

mal (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:

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 commu-

nications 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 E-

Enterprise 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 E-

Enterprise 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.


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’ respon-

sibilities.

Lack of stable organization design and clearly defined

roles created flaws in knowledge flows: some information

was lost because there were no clearly defined commu-

nication 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.


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


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 [E-

Procurement 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).


The E-Enterprise group had all the technologies required

to enable them to work in a globally distributed environ-

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).


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


Table 2

Coordination mechanisms: comparison of results across cases

Coordination mechanisms SAP case

(successful)

Baan case

(unsuccessful)

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 + �

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 differ-

ences 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 imple-

mented 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

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.


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 pro-

cesses across locations. At SAP, standard tools and

methods were implemented at the very early stages of

the project.



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, require-

ments 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.


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 post-

poned 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. Intervie-

wees 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

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 coordi-

nation 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 knowl-

edge 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 pay-

offs, coordination in increasingly knowledge-intensive work

environments will become problematic.

Our research however has some limitations: the frame-

work includes a one-directional, singular relationship

between coordination mechanisms and knowledge pro-

cesses. 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, Knowl-

edge 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 develop-

ment, 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.


[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, Acad-

emy 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. Gale-

gher, 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, organiza-

tional 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, Acad-

emy 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 Manage-

ment 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 Infor-

mation 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 cap-

ability 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, Interna-

tional 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 mana-

ging 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 Pro-

fessor 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 Technol-

ogy, Work and Globalization at London School of

Economics, UK. He has an international reputa-

tion 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 Manage-

ment Review, MIS Quarterly, MISQ Executive, Journal of Management

Studies and others.

Developing a knowledge-based perspective on coordination...

Documents

Transcript of Developing a knowledge-based perspective on coordination...