IEEE Software (March/April)

76 Pages·2001·2.291 MB·English

focus
guest editors’ introduction
Global Software
Development
James D. Herbsleb and Deependra Moitra, Lucent Technologies
he last several decades have witnessed a steady, irreversible trend
T
toward the globalization of business, and of software-intensive
high-technology businesses in particular. Economic forces are re-
lentlessly turning national markets into global markets and
spawning new forms of competition and cooperation that reach across na-
tional boundaries. This change is having a profound impact not only on
marketing and distribution but also on the way products are conceived,
designed, constructed, tested, and delivered to customers.1
Software engineers have recognized the in some quarters and moving others to try to
profound influence of business globalization capture and emulate models that have met
for some time, generating alarmist reactions with success. More recently, attention has
turned toward trying to understand the fac-
tors that enable multinationals and virtual
corporations to operate successfully across
geographic and cultural boundaries.
Globalization and software
Over the last few years, software has be-
come a vital component of almost every
business. Success increasingly depends on
using software as a competitive weapon.
More than a decade ago, seeking lower
costs and access to skilled resources, many
organizations began to experiment with
remotely located software development fa-
cilities and with outsourcing. Several fac-
tors have accelerated this trend:
(cid:2) the need to capitalize on the global re-
source pool to successfully and cost-com-
petitively use scarce resources, wherever
located;
16 IEEE SOFTWARE March/April 2001 0740-7459/01/$10.00 © 2001 IEEE
(cid:2) the business advantages of proximity at the other end of a long corridor, severely
to the market, including knowledge of reduces communication. Solutions that help
Cultures differ
customers and local conditions, as well globally distributed colleagues work to-
as the good will engendered by local gether more effectively will often help those on many critical
investment; in the same zip code as well.
dimensions,
(cid:2) the quick formation of virtual corpora-
tions and virtual teams to exploit mar- Dimensions of the problem such as
ket opportunities; Physical separation among project mem- the need for
(cid:2) severe pressure to improve time-to- bers has diverse effects on many levels.
structure,
market by using time zone differences in
“round-the-clock” development; and Strategic issues attitudes
(cid:2) the need for flexibility to capitalize on Once a particular set of project sites has
toward
merger and acquisition opportunities been determined (a decision outside the scope
wherever they present themselves. of this issue), deciding how to divide up the hierarchy,
work across sites is difficult. Solutions are
communication
As a result, software development is in- constrained by the resources available at the
styles, and
creasingly a multisite, multicultural, glob- sites, their levels of expertise in various tech-
ally distributed undertaking. Engineers, nologies, the infrastructure, and so on. An sense of time.
managers, and executives face numerous, ideal arrangement would let the sites oper-
formidable challenges on many levels, from ate as independently as possible while pro-
the technical to the social and cultural. viding for easy, flexible, and effective com-
Is working at a distance really such a munication across sites. A number of
problem? Nearly everyone with GSD expe- models are possible and appropriate under
rience, it seems, has anecdotes illustrating different circumstances and require differ-
difficulties and misunderstandings. While ent coordination mechanisms.6
these stories are compelling, they do not Another fundamental challenge is the or-
give us a clear picture of its cumulative ef- ganization’s resistance to GSD. This resist-
fects. However, we have strong evidence,2 ance often surfaces because of misalignment
based both on statistical modeling of devel- between senior and middle management on
opment interval and on survey results, that the intent and perceived benefits of GSD.
multisite development tasks take much Many individuals might believe their jobs
longer than comparable colocated tasks and are threatened, experience a loss of control,
that communication and coordination play and fear the possibility of relocation and the
major roles in this delay. need for extensive travel.
While we focus primarily on the prob-
lems of GSD, we should not neglect the po- Cultural issues
tential benefits of geographic dispersion. GSD requires close cooperation of indi-
For example, if an organization can manage viduals with different cultural backgrounds.
daily handoffs of work between remote sites Cultures differ on many critical dimensions,
and focus attention around the clock on such as the need for structure, attitudes to-
critical-path tasks, it is possible to take ad- ward hierarchy, sense of time, and commu-
vantage of widely dispersed time zones.3We nication styles.7 While many people find
could theoretically extend the productive such differences enriching, they can also
hours of the day from the current 8- to 10- lead to serious and chronic misunderstand-
hour norm to somewhere near the limit of ings, especially among people who do not
24. This is perhaps a distant goal as a gen- know each other well. An email, for exam-
eral model for development, but occasional ple, from someone in a culture where com-
benefits—for example, accelerated problem munication tends to be direct might seem
investigation or a distributed daily test-and- abrupt or even rude to someone from a dif-
fix cycle—are possible. ferent background. A different sense of time
Moreover, we probably think of “distrib- can lead to acrimony over the interpretation
uted” work in much too limited a way. Dis- and seriousness of deadlines.
tances need not be global to be important.4-5 Cultural differences often exacerbate com-
In fact, being in another building or on a munication problems as well. When people
different floor of the same building, or even are puzzled as to how to respond to odd-
March/April 2001 IEEE SOFTWARE 17
sounding messages, they often just ignore but cannot be located and hence is not ex-
them or make uncharitable attributions ploited. Also, owing to poor knowledge and
Developers
about the sender’s intentions or character. information management, teams miss many
not located reuse opportunities that otherwise would
Inadequate communication have saved cost and time.
together have
Software development, particularly in the Poor documentation can also cause inef-
very little early stages, requires much communication.8 fective collaborative development. The re-
informal, In fact, software projects have two comple- sistance to documentation among develop-
mentary communication needs. First, the more ers is well known and needs no emphasis. In
spontaneous
formal, official communications need a clear, GSD, however, in addition to documenting
conversation well-understood interface. For crucial tasks the various artifacts, updating and revising
like updating project status, escalating proj- the documentation is equally important. To
across sites.
ect issues, and determining who has respon- prevent assumptions and ambiguity and to
sibility for particular work products, a fuzzy support maintainability, documentation must
or poorly specified interface loses time and be current and reflect what various teams
lets problems fall through the cracks. are using and working on.
Disruption to a second, vital communica-
tion channel can be surprisingly crippling9: Project and process management issues
developers not located together have very When teams hand off processes between
little informal, spontaneous conversation sites, the lack of synchronization can be
across sites. Informal “corridor talk” helps particularly critical—for example, if the de-
people stay aware of what is going on around velopment team at one site and the test
them, what other people are working on, group at another site define “unit-tested
what states various parts of the project are code” differently. Synchronization requires
in, who has expertise in what area, and commonly defined milestones and clear en-
many other essential pieces of background try and exit criteria. Though concurrent de-
information that enable developers to work velopment process models have been sug-
together efficiently. One result is that the is- gested in the literature and used,11-13
sues, big and small, that crop up on a nearly effectively implementing concurrent engi-
daily basis in any software project can go neering principles in GSD often becomes
unrecognized or lie dormant and unresolved difficult because of volatile requirements,
for extended periods. The absence of ongo- unstable specifications, the unavailability of
ing conversation can also lead to surprises good tools that support collaboration
from distant sites, potentially resulting in across time and space, and the lack of in-
misalignment and rework. The more uncer- formal communication. Some groups prac-
tain the project, the more important this tice risk management in a traditional fash-
communication channel is.10 ion, not taking into account the possible
These issues are even more complex in impacts of diverse cultures and attitudes.
outsourcing arrangements. The fear of loss of
intellectual property or other proprietary in- Technical issues
formation about products or schedules leads Since networks spanning globally dis-
to restricted or filtered communication, often persed locations are often slow and unreli-
seriously impairing this critical channel. able, tasks such as configuration manage-
ment that involve transmission of critical
Knowledge management data and multisite production must be metic-
Without effective information- and ulously planned and executed. The need to
knowledge-sharing mechanisms, managers control product changes and to ensure that
cannot exploit GSD’s benefits. For example, all concerned hear about them is much
they might fail to promptly and uniformly greater in GSD. Other common issues in-
share information from customers and the clude using incompatible data formats and
market among the development teams. different versions of the same tools.
When project leaders disseminate status in-
formation inadequately, teams cannot deter- The articles in this issue
mine what tasks are currently on the critical Each article in this issue provides some
path. Needed expertise might be available answers to managers and engineers navigat-
18 IEEE SOFTWARE March/April 2001
ing these difficult waters. They describe new geographically distributed testbed for pub-
tactics and techniques as well as hard-won lishing educational software applications,
Synchronization
practical lessons from experience. the authors outline a rapid production
As we noted earlier, distance is a major process using components suited for distrib- requires
issue in GSD leading to coordination, com- uted development. This enables each site to
commonly
munication, and management problems. In take ownership of particular components
“Tactical Approaches for Alleviating Dis- and work on them independently without defined
tance in Global Software Development,” much need for intersite communication and
milestones and
Erran Carmel and Ritu Agarwal provide coordination.
several approaches that can be applied In our experience, training programmers clear entry and
across a range of geographically distributed to think and behave like software engineers exit criteria.
projects. Audris Mockus and David M. is an uphill task. Many educational pro-
Weiss, in “Globalization by Chunking: A grams now include team-oriented work,
Quantitative Approach,” offer a method for and with globalization so pervasive, they
using code change history to compute the also need to train their students with geo-
degree of “relatedness” of the work items at graphically distributed development in
two sites. They further propose a method mind. Jesús Favela and Feniosky Peña-
for distributing work in a way that mini- Mora, in “Geographically Distributed Col-
mizes the need for coordination across sites. laborative Software Development,” describe
In “Using Components for Rapid Dis- a project-oriented software engineering
tributed Software Development,” Alexan- course and show how students in two dif-
der Repenning, Andri Ioannidou, Michele ferent countries collaborated using an Inter-
Payton, Wenming Ye, and Jeremy Roschelle net-based groupware environment. While
describe their experiences using a compo- their objective in designing the project was
nent architecture to support work dis- educational, their experiences are signifi-
tribution across sites. Based on their large, cant to the business community.
About the Authors
Software outsourcing is increasingly pop- products for distributed development. We
ular among corporations as an economi- hope the advances in collaborative tools
James D Herbsleb is currently a cally and strategically attractive business and multimedia, Web technology,14-15and a
member of
model. As companies outsource their soft- refined understanding of concurrent-engi-
the Software
Production Re- ware needs to software houses across national neering principles will help us address these
search Depart- borders, the two independent organizations challenges.
ment and
must interact—causing the dynamics of glob-
leader of the
Bell Labs Col- ally distributed software development to
laboratory surface rather strongly. In a thought-pro-
project. For
voking article, “Synching or Sinking: Global Acknowledgment
the last three years, his work has focused
on collaboration technology to support Software Outsourcing Relationships,” We thank the reviewers who contributed their
valuable time and expertise toward development of
large, globally distributed projects. For Richard Heeks, S. Krishna, Brian Nichol-
this special issue. Our sincere thanks also to Dawn
the past 10 years, he has conducted re-
son, and Sundeep Sahay report on three in- Craig at IEEE Softwarefor her meticulous efforts
search in collaborative software engineer-
ing, human–computer interaction, and teresting case studies and capture their suc- helping us put together the issue.
computer-supported cooperative work. He cessful outsourcing strategies to maximize
holds an MS in computer science from the
business value.
University of Michigan and a PhD in psy-
chology from the University of Nebraska. Finally, we offer three excellent articles
References
Contact him at herbsleb@research. summarizing real organizational experi-
1. M. O’Hara-Devereaux and R. Johansen, Globalwork:
bell-labs.com.
ences, lessons learned, and good practices. In Bridging Distance, Culture, and Time, Jossey-Bass, San
“Surviving Global Software Development,” Francisco, 1994.
2. J.D. Herbsleb et al., “An Empirical Study of Global
Deependra Moitra is currently Christof Ebert and Philip De Neve narrate Software Development: Distance and Speed,” to be
general man- Alcatel’s experience in globally distributed published in Proc. Int’l Conf. Software Eng. 2001,
ager of engi- IEEE CS Press, Los Alamitos, Calif., 2001.
neering at the software development and synthesize the 3. E. Carmel, Global Software Teams, Prentice Hall, Up-
Lucent Tech- good practices they observed in a large oper- per Saddle River, N.J., 1999.
nologies India ation involving 5,000 engineers. Robert Bat- 4. T. J. Allen, Managing the Flow of Technology, MIT
R&D Program. Press, Cambridge, Mass., 1977.
His interests tin, Ron Crocker, Joe Kreidler, and K. Sub- 5. R.E. Kraut, C. Egido, and J. Galegher, “Patterns of
are in soft- ramanian, in “Leveraging Resources in Contact and Communication in Scientific Research Col-
ware engi- laborations,” Intellectual Teamwork: Social Founda-
Global Software Development,” report on
neering management, management of tions of Cooperative Work, J. Galegher, R.E. Kraut, and
technology and innovation, new-product their experiences and approaches while C. Egido, eds., Lawrence Erlbaum Assoc., Hillsdale,
innovation, R&D globalization, and entre- working on Motorola’s 3G Trial Systems N.J., 1990, pp. 149–172.
6. R.E. Grinter, J.D. Herbsleb, and D.E. Perry, “The Geog-
preneurship in software and high-tech in-
project, which spans six countries. In “Out- raphy of Coordination: Dealing with Distance in R&D
dustries. He serves on the editorial boards
of Research-Technology Management, sourcing in India,” Werner Kobitzsch,Dieter Work,” Proc. Int’l ACM SIGGROUP Conf. Supporting
Group Work, ACM Press, New York, 1999, pp. 306–
Technology Analysis and Strategic Man- Rombach, and Raimund Feldmann capture
315.
agement, International Journal of Entre-
their experiences and lessons learned with 7. G.H. Hofstede, Cultures and Organizations: Software
preneurship and Innovation, Journal of of the Mind—Intercultural Cooperation and Its Impor-
Small Business Management, Journal of distributed software development at Teno- tance for Survival, revised ed., McGraw-Hill, New
Knowledge Management, and IEEE Soft- vis, a German company. Interestingly, while York, 1997.
ware. He is a member of IEEE, IEEE Com- these articles are from different companies 8. D.E. Perry, N.A. Staudenmayer, and L.G. Votta, “Peo-
puter Society, IEEE Engineering Manage- ple, Organizations, and Process Improvement,” IEEE
ment Society, and ACM. Contact him at operating in different cultural settings, there Software, vol. 11, no. 4, July/Aug. 1994, pp. 36–45.
[email protected]. is a marked commonality in experiences 9. J.D. Herbsleb and R.E. Grinter, “Architectures, Coordi-
nation, and Distance: Conway’s Law and Beyond,”
gained and approaches that worked.
IEEE Software, vol. 16, no. 5, Sept./Oct. 1999, pp.
63–70.
10. R.E. Kraut and L.A. Streeter, “Coordination in Soft-
ware Development,” Comm. ACM, vol. 38, no. 3, Mar.
1995, pp. 69–81.
Given the global reach of today’s large 11. M. Aoyama, “Managing the Concurrent Development
of Large-Scale Software Development,” Int’l J. Technol-
corporations and the global market
ogy Management, vol. 14, no. 6/7/8, 1997, pp. 739–
for software products, few software 765.
12. J.D. Blackburn, G. Hoedemaker, and L.N. van Wassen-
engineers will remain unaffected as the
hove, “Concurrent Software Engineering: Prospects and
globalization trend surges forward. As we Pitfalls,” IEEE Trans. Eng. Management, vol. 43, May
increasingly work in virtual, distributed 1996, pp. 179–188.
13. F. Rafii and S. Perkins, “Internationalizing Software
team environments, we will more and more
with Concurrent Engineering,” IEEE Software, vol. 12,
face formidable problems of miscommuni- no. 5, Sept./Oct. 1995, pp. 39–46.
14. S. Murugesan, “Leverage Global Software Development
cation, lack of coordination, infrastructure
and Distribution Using the Internet and Web,” Cutter
incompatibility, cultural misunderstanding, IT J., vol. 12, no. 3, Mar. 1999, pp. 57–63.
and conflicting expectations—not to men- 15. M. Aoyama, “Web-Based Agile Software Development,”
IEEE Software, vol. 15, no. 6, Nov./Dec. 1998, pp.
tion the technical challenges of architecting 56–65.
20 IEEE SOFTWARE March/April 2001
focus
global software development
Tactical Approaches for
Alleviating Distance in
Global Software
Development
Erran Carmel, American University
Ritu Agarwal, University of Maryland
o overcome the problem of distance in global software develop-
T
ment, various managers are experimenting and quickly adjusting
their tactical approaches. We discuss some emerging approaches
and explain their motivations from conceptual and practical per-
spectives. The most intuitive approach for alleviating distance is to apply
communication technologies, but this is not Upwards of 50 nations are currently par-
our focus. Rather, we examine tactics that ticipating—at least minimally—in collabo-
go beyond communication technologies— rative software development internationally.
tactics aimed at reducing intensive collabo- In India, there are now 800 IT service firms
ration, national and organizational cultural competing for work globally.3Many Ameri-
The authors
differences, and temporal distance. can firms are in the process of a radical push
describe three
to send their key software processes off-
tactical The phenomenon of global shore, and critical centers of software R&D
approaches to software development are growing outside the traditional centers
Only a decade ago, the number of enti- (such as the US)—in Ireland, Israel, Singa-
reducing
ties engaging in global software develop- pore, Finland, and many other nations. Fi-
intensive
ment was small—but this has rapidly nally, the marketplace is responding to the in-
collaboration, changed. Today, 203 of the US Fortune 500 creased demand for IT labor through the
national and engage in offshore outsourcing.1In a recent construction of new commercial mecha-
study, we found that within the largest US nisms. IT business-to-business intermediaries,
organizational
firms, the median ratio of IT work out- such as ITsquare.com and IT-radar.com, serve
cultural
sourced—but consumed largely in the US— as exchanges between worldwide IT services
differences, and is 6.5 percent.2 Meanwhile, in the much vendors and small- and medium-size busi-
temporal smaller Netherlands, about 250 Dutch nesses with IT needs.
companies of various sizes engage in some There are two critical, strategic reasons
distance.
kind of offshore work.3 for moving to offshore software develop-
22 IEEE SOFTWARE March/April 2001 0740-7459/01/$10.00 © 2001 IEEE
Other Solutions to Alleviating Distance
The literature on virtual teams addresses a wide array of approaches for
alleviating the problems of distance in global software development. Erran
ment: cost advantage and a large labor Carmel organized1(and later refined2) these approaches into six centripetal
pool. Furthermore, the radical rethinking in forces that exert inward pressure on the team for more effective perform-
our collective concept of a firm enables soft- ance: collaborative technology, team building, leadership, product architec-
ware globalization. Transaction-cost eco- ture and task allocation, software development methodology, and telecom-
nomics posits that if it is cheaper to transact munications infrastructure.
internally within the corporation, the or- Of these, technology-based solutions are perhaps the most obvious. For
ganization will grow larger. This occurred example, a distributed Software Configuration Management (for managing
historically because of coordination require- the system component versions) reduces miscommunication because it en-
ments.4 Now that we can more effectively forces a common work process and a common view of the project.1,3An-
coordinate over long distances, organiza- other use of technology is the team Web site that encompasses all facets of
tions are either staying small or shrinking individual- and task-related information—from the programmers’ photos to
and conducting transactions externally (ex- the test documentation.4Other nontechnology approaches are more subtle.
ternalizing sales, distribution, manufactur- Martha Maznevski and Kathy Chudoba found that effective virtual teams had
ing, management information systems, le- a “deep rhythm” of regular team meetings, both face-to-face and over dis-
gal, payroll, and so forth). The growth of tance.5Of course, a meeting is but a communication formalism. Communica-
contract manufacturing is another manifes- tion need not always occur within a formal, hierarchical configuration. When
tation of this trend.5Whereas 25 years ago, global software teams collaborate on innovative projects, informal channels
20 percent of US workers worked in the of coordination—or lateral channels—are critical. They “help developers fill
Fortune 500, today the figure stands at 10 in the details in the work, handle exceptions, correct mistakes….”6
percent and is falling.4
The critical challenge of distance
We need to examine how distance con- References
tributes to heightened complexity in organi- 1. E. Carmel, Global Software Teams: Collaborating across Borders and Time Zones, Prentice
Hall, Upper Saddle River, N.J., 1999.
zational processes. An organizational unit
2. E. Carmel, “Global Software Teams: A Framework for Managerial Problems and Solutions,”
cannot function without coordination and
Global Information Technology and Electronic Commerce: Issues for the New Millennium,
control; unfortunately, distance creates dif- Ivy League Publishing, Marietta GA, to be published, 2001.
ficulties in both. 3. R.E. Grinter, “Doing Software Development: Occasions for Automation and Formalisation,”
Proc. Fifth European Conf. Computer Supported Cooperative Work(ECSCW ’97), Kluwer
Coordinationis the act of integrating each
Academic Publishers, Dortrecht, The Netherlands, 1997, pp. 173–188.
task with each organizational unit, so the
4. S. McConnell, Software Project Survival Guide, Microsoft Press, Redmond, Wash., 1998.
unit contributes to the overall objective. Or- 5. M.L. Maznevski and K. Chudoba, “Bridging Space Over Time: Global Virtual Team Dy-
chestrating the integration often requires in- namics and Effectiveness,” Organization Science, vol. 11, no 5, Sept./Oct. 2000, pp.
473–492.
tense and ongoing communication. Control
6. J. D. Herbsleb and R. E. Grinter, “Splitting the Organization and Integrating the Code:
is the process of adhering to goals, policies,
Conway’s Law Revisited,” Proc. 21st Int’l Conf. Software Engineering(ICSE ’99), ACM Press,
standards, or quality levels. Controls can be New York, 1999, pp. 85–95.
formal (such as budgets and explicit guide-
lines) or informal (such as peer pressure).
We recognize today that, for knowledge
workers, coordination and control have in
many ways blended together. Communica- software development. Distance negatively
tion is a mediating factor affecting both co- affects communication, which in turn re-
ordination and control. It is the exchange of duces coordination effectiveness. We briefly
complete and unambiguous information— discuss the array of approaches for alleviat-
that is, the sender and receiver can reach a ing distance problems in the “Other Solu-
common understanding. Gary Anthes pres- tions to Alleviating Distance” sidebar.
ents a telling example of poor communica- Given the critical role of effective com-
tion in a global software development proj- munication in the successful orchestration
ect, when a tester interpreted a spacebar of a global software project, it is not sur-
instruction as a “b-l-a-n-k,” clearly not the prising that new tactics for addressing dis-
intended message of the sender.6 tance are being adopted. Using data from
Distance exacerbates coordination and different software organizations around the
control problems directly or, as Figure 1 world, the literature on global software de-
shows, indirectly through its negative effects velopment, and our current fieldwork, we
on communication. The bold arrows in Fig- extended and refreshed these approaches to
ure 1 represent the main challenge of global develop our three tactics.
March/April 2001 IEEE SOFTWARE 23
hard to define and unstructured, with an it-
erative solution method and unclear solu-
Communication
tion. We have a tendency to associate more
unstructured tasks with increased levels of
Negative
coordination complexity between the Cen-
ter and the Foreign Entity, but this is not al-
ways the case, as Figure 3 shows. Further-
1 Dis2tance3 4 Negative Coordination more, firms have become more adept at
parsing out tasks (and functions) that re-
quire low levels of coordination.
The lower-left region in Figure 3 represents
Negative relatively straightforward tasks with low
complexity such as Y2K remediation. For
Control many companies in the Center, these tasks of-
ten represent their first offshore activities.
Projects such as Y2K remediation also reflect
Figure 1. Impacts of distance. a very small part of the individual system’s
life-cycle effort. Such projects are more man-
ageable over distance, because the need to
Tactic 1: Reduce intensive
communicate and clarify requirements is rela-
collaboration
tively limited and tasks are relatively stable.
Researchers have depicted a global soft- The region at the top of Figure 3, at the
ware development maturity function that maxima, is characterized by a very dense web
increases over time to higher levels of of coordination that is needed to transfer
knowledge work. Figure 2 shows the typical knowledge and collaborate on tasks. In such
maturity function Carmel developed7 but an environment, two or more development
with some augmentations. We deal with the units are working together on the same proj-
transition of tasks between the Center and ect. At the extreme, this is done using the fol-
Foreign Entity. We use these terms as short- low-the-sun approach, in which work passes
hand for the dyad typically involved in from site to site on a daily basis. For example,
global software development. The Center is when developers in California finish the day’s
usually (but not always) a firm (or unit) in tasks, they pass their work (such as code) to
one of the triad areas of North America, the their colleagues in India, who will shortly be
European Union, or Japan. The Foreign En- arriving at work. In turn, at the end of the
tity might be in another triad nation or in a day, the Indian developers pass their work
newly industrialized or developing nation. back to California. Coordination complexity
Other collaborations do take place, prima- is high because, on a daily basis, each side
rily in R&D, some of which involve a web must package its added value so that the other
of several national sites. side can quickly proceed to add its own value
The Foreign Entity engages in tasks that without further clarifications. Near this ex-
range from those that are well-defined and treme of complex coordination lie all varieties
structured, with easy-to-use methods and of innovative R&D activities, because they
unambiguous outcomes, to tasks that are tend to be unstructured.8
As a consequence of the complexity of co-
ordination, many organizations are moving
in one of two directions (depicted by the ar-
Unstructured rows in Figure 3)—to either the graph’s far
Visioning
tasks left or far right. In both cases, coordination
Ownership
Functional specs complexity remains relatively low. The key
High-level design difference is the relative life-cycle effort of the
Low-level design tasks the Foreign Entities perform. In the left-
New programming
hand side of the graph, for a large corpora-
Structured Maintenance/Y2K
Figure 2. A software tion, this move often represents transferring
tasks Port
task maturity maintenance activities (also known as sus-
Time
function. taining work), help desks, and data centers.
24 IEEE SOFTWARE March/April 2001
The lower-right side of the graph shows a
Complex
relationship in which the Foreign Entity takes
full responsibility for (or ownership of) a sys-
Follow-the-sun
tem, product, or corporate process. This alle-
viates many of the distance problems, be-
cause the Foreign Entity is not using links
Data center
with the Center as frequently. In other words, Full product ownership
ongoing collaboration is not as intense. For Help desk Contract
programming
software product companies (packaged soft-
ware), ownership can be over individual soft- on Port, Y2K
ware components, individual modules, re- ati
n
leases, or entire products. ordi
o
Consider the following case in point. One C
major American product software firm opened
Straight-
an Indian development center and, within the forward 100%
span of a few years, transitioned from the
Share of the life-cycle effort performed by the foreign entity
lower left of the graph to the lower right. Al-
though tasks were initially structured mainte-
nance activities, the Indian center soon mi- Figure 3. Alternative paths to alleviating intensive collaboration.
grated to complete ownership of point releases
(for example, from release 2.1 to 2.2), includ-
ing enhancements. Meanwhile, R&D in the US
could devote nearly all its resources to major sourcing work from Korea of becoming
release cycles (for example, 3.0). “too American” in that they were devoting
An instance of firms operating on the too much attention to documentation and
left-hand side of Figure 3 and moving up the were too stringent about deadlines.
Y axis are two of the largest US megatech- National culture encompasses an ethnic
nology companies we recently studied, who group’s norms, values, and spoken language,
are in a continuous process of migrating in- often delineated by political boundaries of the
ternal IT processes offshore, one chunk at a nation-state. It stems from the relative dis-
time, to their rapidly growing Indian IT cen- tance between the Center and Foreign Entity.
ters. These processes include support at var- American firms generally prefer to situate de-
ious levels of criticality as well as data cen- velopment units in foreign locations where
ters. Of course, this movement is facilitated cultural distance is smaller—for example, in
in no small part by the nature of IT today, Ireland—or where language barriers are min-
which permits increasingly larger levels of imal, such as in India or the Philippines.
modularity in both the development process Figure 4 organizes common structural
as well as the final product. arrangements for global software develop-
ment plotted along the cultural distance
Tactic 2: Reduce cultural distance continua. The two axes represent national
Cultural distance stems from the degree cultural distance and distance from the core
of difference between the Center and the organizational culture. At one extreme, the
Foreign Entity. This difference typically least problematic arrangement is to build IT
manifests itself in one of two forms: organi- and R&D work teams domestically and in-
zational culture and national culture. side the firm. At the other extreme, cultural
Organizational culture encompasses the distance is greatest when a foreign out-
unit’s norms and values, where the unit sourcing or contracting company performs
could range from a small technology com- the work. These two extremes appear, re-
pany to a multinational enterprise. Organi- spectively, in the upper-left and lower-right
zational culture includes the culture of sys- sections of Figure 4.
tems development, such as the use of Five types of foreign structures are com-
methodologies and project management mon, with large multinational enterprises of-
practices. For example, an Indian source ten making use of a combination of all five.
told the authors that Korean customers re- Beginning with the upper-right quadrant of
cently accused an Indian company out- Figure 4, three common arrangements are
March/April 2001 IEEE SOFTWARE 25
Bridgehead
Distance from center's national culture
The first of these arrangements is the off-
Domestic Foreign shore–onshore bridgehead (depicted by the
bridgehead arrow, suggesting a reduction in
ure Foreign both national culture and organizational cul-
cult m Domestic internal subsidiary ture distance). Some have begun labeling this
er's organizational Intra-fir software Cwuoltrukral liaison deOvcefeflsonhptoJemorreiennttacFqouriesIniitegtrnianlo foren apwtThsehhe ri ticslhce eauen r 2str7t 5aoo5 nmfp/g 2eepe5rrmec rersesuinnotlteten — oonocpeffclot uirtmwr hseoiu zxromeaknsmb sco:hpo coElscertsu, es sr eais(nnv u tiostniuafhgflaeslsl yh l(,Uyo o 7Srfaef)5t-.,
nt m Language venture or alliance ig shore) while maintaining closeness to the cus-
Distance from ce External to fir coonuwDtsprtooosaaofmrcrtktutwnoe rwaerscsitrreti,esrhc sa,nd Bridgehewadith foocuorFtensoitogrrueanric cfgtiiinrnnmgg, n entity tscsothuamolntruederr .aa tlThrleyeh tecya uipsnssitdciomaivmlililydea rutt’ehsad elrs. e maqTsoushriieregey nem exadepcn etttro si etwosnp coeeurcdkni f daiocennard---
tions and translate them to the offshore pro-
grammers. Perhaps more importantly, the
face-to-face interaction reduces miscommu-
Figure 4. A taxonomy of structural arrangements for software nication between customer and vendor. The
development. 25 percent of project personnel that are on-
shore effectively serve as a bridge—reducing
cultural distance.
possible. An existing foreign subsidiary is Our field work suggests that the 75/25
typical for the internal IT of a multinational arrangement has now become part of the
enterprise. A foreign acquisition is typical for marketing pitch by offshore (primarily In-
technology or software firms. For example, dian) firms reassuring their customers that
in 1999, European firms acquired 229 US they have found the right solution to dis-
technology firms, while US firms acquired tance. Many of thelargest Indian firms (such
405 European technology firms.9 The soft- as Tata Consultancy Services) now have
ware professionals in these firms were then considerable corporate presence in the US,
compelled to work together. An offshore de- further enhancing the cultural buffer and re-
velopment center is usually set up from the ducing cultural distance. In an approach that
ground up. is conceptually similar, large US IT services
At the lower-right quadrant of Figure 4, firms, such as EDS, maintain IT outsourcing
two arrangements are common. A foreign professionals at the customer’s site to act as
outsourcing or contracting firm might a bridgehead between a US-based customer
be India-based Tata Consultancy Services, and some offshore workforce.
Mexico-based Dextra Technologies, or
Pakistan-based Askari Information Sys- Internalization of Foreign Entity
tems, to name three of several thousand Some American and European companies,
such firms. A joint venture or alliance with primarily technology firms, are opening in-
a foreign firm is an arrangement in which a ternal-to-the-firm foreign software centers.
designated group of software developers We see this phenomenon in large global cor-
from the Center and Foreign Entity collab- porations, as well as in rather small compa-
orate. This is typical in technology compa- nies, such as dotcoms that acquire a small In-
nies undertaking innovative product devel- dian professional services firm to support
opment or product extensions. their internal needs. Thus, some of these
With these structural arrangements in units are greenfields (created from scratch)
mind, companies and vendors have devised while others are acquisitions or conversions
four approaches to alleviate distance. These from other functions. By internalizing global
are depicted graphically in Figure 4 as the ar- software development and shunning collabo-
rows that “pull” left (reducing national cul- ration with external foreign partners (such as
ture distance), up (reducing organizational outsourcers, contractors, or joint venture
culture distance), or both. partners) these firms are reducing cultural
26 IEEE SOFTWARE March/April 2001