Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
www.elsevier.com/locate/im
Available online at www.sciencedirect.com
nt 45 (2008) 96–108
Information & ManagemeDeveloping 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
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 formalstructures 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 structuringof 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 byenabling 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
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108 99
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.
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108100
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 wereemployed or were lacking in the projects under study, and
� m
arking evidence of the existence of or lack of knowledgeprocesses, 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
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108 101
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).
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108102
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
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108 103
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.
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108104
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.
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 105
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).
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-
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
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108106
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.
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 pro-
cesses 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 107
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, 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.
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 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.
J. Kotlarsky et al. / Information & Management 45 (2008) 96–108108
[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.