Effect of Outsourcing on Software Development Approaches
Min Chen
Master of Software Engineering
Carnegie Mellon University
Pittsburgh, PA
amchen@cmu.edu
Abstract
Economic forces are turning national markets into global
markets. Globalization of business has caused companies
to be more competitive and to find less costly ways to
build better products. In the software industry, companies
have been outsourcing software development projects and
using the distributed development model in their quest for
lower costs and availability of skilled resources.
Traditional software development approaches are
conceived with the assumption that teams are collocated.
Hence, they do not address the challenges of having
projects outsourced. Many of these approaches have to be
changed in order to be applied to outsourced projects.
There are two ways to address the challenges of
outsourced projects. The first one is to enable effective
communication and, thereby, coordination. The second is
to rely on methodologies and techniques to enable
coordination while minimizing the need of communication
across distributed teams.
The most effective way of coordination with minimum
communication is the use of shared mental models.
Shared mental models are defined as knowledge structures
shared by team members that enable them to form accurate
explanations and expectations for the task. This helps to
coordinate their actions and adapt their behavior to
demands of the task and other team members.
This paper explains new ways of using traditional software
engineering practices to achieve high coordination by
using shared mental models. Planning, defining a process
and managing requirements with shared mental models
allow coordination while minimizing the need for
communication.
1. Introduction
Globalization of business has caused companies to be
more competitive and to find less costly ways to build
better products. In the software industry, companies have
been outsourcing software development projects and using
1
the distributed development model in their quest for lower
costs and availability of skilled resources.
Software development projects include three
interdependent dimensions – people, process, and
technology. The interaction among these three dimensions
becomes even more complex in outsourced projects
because of the coordination and communication overhead.
The outsourcing model is based on distributed
development teams where team members are scattered in
different places. The lack of effective communication is a
major concern in distributed teams because of the distance,
language, culture, time difference and working
environment. Team members are interdependent even
though they have different roles and responsibilities. In
other words, team members must rely on each other’s
work to accomplish their own tasks. Therefore,
communication and coordination are very important. The
major sources of problems in distributed teams are
interdependencies among work items and difficulties of
coordination.
Traditional software development approaches are
conceived with the assumption that teams are collocated.
Hence, they do not address the challenges of outsourcing.
Many of these approaches have to be changed in order to
be applied to outsourced projects.
Basically, there are two ways to address the challenges of
outsourced projects. The first one is to enable effective
communication and, thereby, coordination. The second is
to rely on methodologies and techniques to enable
coordination while minimizing the need of communication
across distributed teams. For example, software
architecture, process and tools help in the coordination of
teams. A plan is critical in dividing the work to be
assigned to different teams. An architecture based on
components with independent functionalities helps divide
the work across sites and reduces the amount of interaction
among teams.
Building on the work of previous researchers about
globally distributed teams, this paper proposes changes in
traditional software approaches to encompass the concern in distributed environments. For that reason, we
challenges of outsourced software projects by reducing the should not rely on communication to achieve coordination.
need of communication.
The following are suggestions to achieve coordination
2. Less Communication but More Coordination while minimizing communication.
The lack of communication across sites makes
1) Keep planning cycles short for higher visibility. High
coordination of the distributed teams difficult. Several
visibility allows teams to solve problems before they
researchers have proposed the use of architecture, process
become critical. This is a good practice for collocated
and tools to coordinate the work of distributed teams. A
development teams but it is necessary for distributed
plan with well-defined boundaries is critical in dividing
teams because we cannot rely on communication to
work, so that it can be assigned to different teams. Also, an
achieve visibility.
architecture based on components with independent
2) Avoid dependencies among distributed teams within a
functionalities helps divide the work across sites and
cycle. In other words, avoid assigning interdependent
reduces the necessity of interaction among the teams
tasks to distributed members within a planning cycle.
[Herbsleb 1999a].
If a team cannot deliver on time, the code of all the
other teams will not work because they depend on the
Although architectures, plans and processes are very useful
code of the first team. Furthermore, if there was not a
for coordination, they need to be adapted to a distributed
clear understanding in the interfaces, the other teams
development environment.
may have to modify their code in accordance to the
actual interfaces. This rework could have been avoided
“Architectures, plans and processes are all vital
if the interdependent tasks are distributed across
coordination mechanisms in software projects. However,
different planning cycles. By the time a team’s
their effectiveness extends only as far as our ability to see
members begin to code, the modules they depend on
into the future. Handling the unanticipated both rapidly
are already available. This allows them to have a clear
and gracefully requires flexible ad hoc communication.”
understanding of the interfaces and to test their code.
[Herbsleb 1999b].
3) Keep coordination centralized. A team or a person
must be responsible for looking after the activities at
Advanced telecommunication and collaboration
the different sites. This team or person should enable
technologies help teams to communicate and collaborate.
channels of direct communication with each
However, tools do not guarantee good communication.
distributed team.
“Technology merely enhances team effectiveness when
4) Define a process for coordination. The following
team members already have established relationships and a
section of this paper has more details about defining
sense of common affinity” [Carmel 1999]. “Email was
processes.
found weak in managing ambiguous information about
requirements. Its lack of interactivity results in lowered
4. Using a Process
ability to handle ambiguity” [Damian 2003]. In spite of the
collaboration tools, distance increases the coordination and Processes are empirically understood by collocated teams
decreases communication [Carmel 1999][Herbsleb 1999b]. members. However, they must be defined clearly when
teams are distributed in order to have a good
The following sections show how software engineering understanding of the coordination. This is the reason many
approaches can be adapted for a distributed development organizations choose CMM level 5 companies to
environment. outsource the software project.

3. Planning a Project Researchers have demonstrated that work familiarity and

shared mental models help teams coordinate. Tools only
Many software development plans allow concurrent
go so far in helping distributed teams to increase
execution of tasks in order to use the resources more
communication and productivity. When team members
efficiently. The drawback of this approach is it creates a
are familiar with their work and have shared knowledge of
high number of task interdependencies; therefore,
the process and other team members, they are more
coordination is critical to avoid rework. Often,
coordinated and perform better [Espinosa 2002].
communication is necessary to have a good coordination,
but we already know that communication is the major

2
The following are suggestions when defining a process in
a distributed development environment.
1) Define a global process to be followed by all the
distributed teams to allow coordination without
communication. This global process should only take
care of the high-level tasks, such as a global code
integration process and coding standard. Local
processes define the low-level tasks. A global process
facilitates the coordination of development by
providing a shared understanding of the purpose and
desired outcomes. It gives all the members of the team
a common direction.
2) Define the requirements for local processes. In
addition to being geographically distributed, members
of the distributed teams come from different corporate
cultures, use different tools, follow conflicting
standards, and often speak different languages. Thus, a
process that works for teams in one place might not
work for teams in other places. Therefore, distributed
teams should be allowed to have a local process that is
compliant with the global process. As long as the
teams deliver what is specified in the global process,
they can do whatever works best for them locally. For
example, each team is allowed to have their own
configuration management process, but the team must
follow the rules of the global process when integrating
its code with other teams.
5. Managing Requirements
“Requirements engineering is a task difficult enough when
done locally -- but it is even more difficult when cross-
functional stakeholder groups specify requirements across
cultural, language and time zone boundaries.” [Damian
2003].
The lack of informal communication diminishes the
awareness of local work context because it causes
insufficient familiarity with the activities of remote group
members and background information that make work
contexts meaningful. This leads to misinterpretation of
actions, due to stereotyping about cultures and working
styles [Damian 2003]. Hence, it makes more sense to have
a local team gather the requirements from the customer in
order to minimize the misinterpretations. Local team in
this context means a team whose members are original
from the place where the customer is from. The advantage
of using a local team is that the members understand the
local rules, working styles, and culture. Members also
speak the same language as the customer.
3
Another challenge when dealing with requirements is how
to communicate them in an unambiguous way to the rest of
the teams whose members might be in other countries and
speak different languages.
The most effective way of coordination without
communication is the use of shared mental models.
“Shared mental models are defined as knowledge
structures held by members of a team that enable them to
form accurate explanations and expectations for the task,
and, in turn, to coordinate their actions and adapt their
behavior to demands of the task and other team members”
[Cannon-Bowers 1993]. “These models help team
members develop accurate explanations and expectations
about tasks and other members’ behavior” [Espinosa
2002].
An architecture design can be a form of shared mental
model if all the team members understand it. Software
architectures describe how a system is decomposed into
components, how these components are interconnected,
and how they communicate and interact with each other.
When poorly understood, these aspects of design are major
sources of errors.
The problem of using an architecture design to
communicate the requirements is that there is no standard
and unambiguous way to do this without writing a
document. Language issues arise regardless of the
language the architecture document is written in.
Members of other teams might not speak the same
language. Furthermore, natural languages, such as English
and Spanish, are full of ambiguities.
Besides an architecture design, teams can use the project’s
programming language to communicate the requirements.
In fact, the programming language is the only shared
mental model that all the team members have. The
programming language of a particular project is well
understood by all the distributed teams.
To use the programming language as a requirements
definition tool, teams should write the testing code before
the functional code. This technique is called Test-Driven
Development (TDD).
TDD is also known as test-first programming or test-first
development. It was introduced by Kent Beck in his
eXtreme Programming (XP) method.
TDD is one way of specifying the acceptance tests. These
tests can form an important part of the requirements
documentation because they define exactly what the
stakeholders expect from system; therefore, they specify Haywood, M., Working in Virtual Teams: A Tale of
[Haywood 2000]
the critical requirements. Two Projects and Many Cities. IEEE, 2000

[Herbsleb 1999a] Herbsleb, J. and Grinter R., Splitting The Organization

6. Conclusion and Integrating the Code: Conway's Law Revisited.
International Conference on Software Engineering,
Traditional software engineering practices assume that 1999
development teams are collocated; hence, they rely on Herbsleb, J., and Grinter, R., Architectures,
[Herbsleb 1999b]
communication among team members to help in Coordination, and Distance: Conway's Law and
coordination. These practices have to be adapted for Beyond. IEEE, 1999
outsourced projects because these projects follow the [Herbsleb 2001b] Herbsleb, J., and Moitra, D., Global Software
distributed development teams model. Development. IEEE Software, 2001

[Herbsleb 2003] Herbsleb, J., and Mockus, A., An Empirical Study of

This paper explained new ways to use traditional software Speed and Communication in Globally-Distributed
Software Development. IEEE, 2003
engineering practices in a distributed development
environments. However, there is no formula to make a [Johansson 1999] Johansson, C., Dittrich, Y., and Justila, A., Software
Engineering Across Boundaries: Student Project in
distributed development project successful, but only Distributed Collaboration.
general rules of thumb.
[McBreen 2003] McBreen, P., Questioning Extreme Programming.
Addison-Wesley, 2003
References
[Mockus 2001] Mockus, A. and Herbsleb J., Challenges of Global
Software Development. IEEE, 2001
[Aoyama 1998] Aoyama, M., Agile Software Process and Its
[Ramesh 2002] Ramesh, G., Managing Global Software Projects.
Experience. IEEE, 1998
McGraw-Hill, 2002
[Beck 2000] Beck, K., Extreme Programming Explained: Embrace Wake, W., Extreme Programming Explored. Addison-
[Wake 2002]
Change. Addison-Wesley, 2000 Wesley, 2002
[Cannon-Bowers Cannon-Bowers, J., Salas, E., and Converse, S., Shared [Williams 2003] Williams, L. and Kessler, R., Pair Programming
1993] Mental Models in Expert Team Decision Making. Illuminated. Addison-Wesley, 2003
Lawrence Earlbaum and Associates, Inc., 1993

[Carmel 1999] Carmel, E., Global Software Teams. Prentice-Hall, 1999

[Cubranic] Cubranic, D., and Booth, K., Coordinating Open-

Source Software Development. Canada

[Damian 2003] Damian, D., and Zowghi, D., Requirements Engineering

challenges in multi-site software
development organizations. Requirements Engineering
Journal, 2003

[Dustdar 2002] Dustdar, S., and Gall, H., Process Awareness for
Distributed Software Development in Virtual Teams.
IEEE, 2002

[Edwards 2002] Edwards, H., and Sridhar V., Analysis of the

Effectiveness of Global Virtual Teams in Software
Engineering Projects. IEEE, 2002

[Espinosa 2001] Espinosa, J., Kraut, R., Lerch, J., Slaughter, S.,
Herbsleb, J., and Mockus, A., Shared Mental Models
and Coordination in Large-Scale, Distributed Software
Development. Twenty-Second International Conference
on Information Systems, 2002

[Espinosa 2002] Espinosa, J., Kraut, R., Lerch, J., Slaughter, S.,
Herbsleb, J., and Mockus, A., Shared Mental Models,
Familiarity, and Coordination: A Multi-method Study of
Distributed Software Teams. Twenty-Third
International Conference on Information Systems

[Goodman 1991] Goodman, P., and Leyden, D., Familiarity and Group
Productivity. Journal of Applied Psychology, 1991

[Grinter 1999] Grinter, R., Herbsleb, J., and Perry, D., The Geography
of Coordination: Dealing with Distance in R&D Work.
ACM, 1999