IEEE SOFTWARE 0740-7459/01/$10.00 © 2001 IEEE
Vol. 18, No. 2; MARCH/APRIL 2001, pp. 22-29

Global Software Development
Tactical Approaches for Alleviating Distance in Global Software Development
Erran Carmel
American University

Ritu Agarwal
University of Maryland

The authors describe three tactical approaches to reducing intensive collaboration, national and organizational cultural differences, and temporal distance.

Download PDF for this article Download PDF for this article

 

To overcome the problem of distance in global software development, various managers are experimenting and quickly adjusting their tactical approaches. We discuss some emerging approaches and explain their motivations from conceptual and practical perspectives. The most intuitive approach for alleviating distance is to apply communication technologies, but this is not our focus. Rather, we examine tactics that go beyond communication technologies[mdash]tactics aimed at reducing intensive collaboration, national and organizational cultural differences, and temporal distance.

THE PHENOMENON OF GLOBAL SOFTWARE DEVELOPMENT

Only a decade ago, the number of entities engaging in global software development was small[mdash]but this has rapidly changed. Today, 203 of the US Fortune 500 engage in offshore outsourcing.1 In a recent study, we found that within the largest US firms, the median ratio of IT work outsourced[mdash]but consumed largely in the US[mdash]is 6.5 percent.2 Meanwhile, in the much smaller Netherlands, about 250 Dutch companies of various sizes engage in some kind of offshore work.3

Upwards of 50 nations are currently participating[mdash]at least minimally[mdash]in collaborative software development internationally. In India, there are now 800 IT service firms competing for work globally.3 Many American firms are in the process of a radical push to send their key software processes offshore, and critical centers of software R&D are growing outside the traditional centers (such as the US)[mdash]in Ireland, Israel, Singapore, Finland, and many other nations. Finally, the marketplace is responding to the increased demand for IT labor through the construction of new commercial mechanisms. IT business-to-business intermediaries, such as ITsquare.com and IT-radar.com , serve as exchanges between worldwide IT services vendors and small- and medium-size businesses with IT needs.

There are two critical, strategic reasons for moving to offshore software development: cost advantage and a large labor pool. Furthermore, the radical rethinking in our collective concept of a firm enables software globalization. Transaction-cost economics posits that if it is cheaper to transact internally within the corporation, the organization will grow larger. This occurred historically because of coordination requirements.4 Now that we can more effectively coordinate over long distances, organizations are either staying small or shrinking and conducting transactions externally (externalizing sales, distribution, manufacturing, management information systems, legal, payroll, and so forth). The growth of contract manufacturing is another manifestation of this trend.5 Whereas 25 years ago, 20 percent of US workers worked in the Fortune 500, today the figure stands at 10 percent and is falling.4

THE CRITICAL CHALLENGE OF DISTANCE

We need to examine how distance contributes to heightened complexity in organizational processes. An organizational unit cannot function without coordination and control; unfortunately, distance creates difficulties in both.

Coordination is the act of integrating each task with each organizational unit, so the unit contributes to the overall objective. Orchestrating the integration often requires intense and ongoing communication. Control is the process of adhering to goals, policies, standards, or quality levels. Controls can be formal (such as budgets and explicit guidelines) or informal (such as peer pressure). We recognize today that, for knowledge workers, coordination and control have in many ways blended together. Communication is a mediating factor affecting both coordination and control. It is the exchange of complete and unambiguous information[mdash]that is, the sender and receiver can reach a common understanding. Gary Anthes presents a telling example of poor communication in a global software development project, when a tester interpreted a spacebar instruction as a "b-l-a-n-k," clearly not the intended message of the sender.6

Distance exacerbates coordination and control problems directly or, as Figure 1 shows, indirectly through its negative effects on communication. The bold arrows in Figure 1 represent the main challenge of global software development. Distance negatively affects communication, which in turn reduces coordination effectiveness. We briefly discuss the array of approaches for alleviating distance problems in the "Other Solutions to Alleviating Distance" sidebar.

Figure 1. Impacts of distance.

Given the critical role of effective communication in the successful orchestration of a global software project, it is not surprising that new tactics for addressing distance are being adopted. Using data from different software organizations around the world, the literature on global software development, and our current fieldwork, we extended and refreshed these approaches to develop our three tactics.

TACTIC 1: REDUCE INTENSIVE COLLABORATION

Researchers have depicted a global software development maturity function that increases over time to higher levels of knowledge work. Figure 2 shows the typical maturity function Carmel developed7 but with some augmentations. We deal with the transition of tasks between the Center and Foreign Entity. We use these terms as shorthand for the dyad typically involved in global software development. The Center is usually (but not always) a firm (or unit) in one of the triad areas of North America, the European Union, or Japan. The Foreign Entity might be in another triad nation or in a newly industrialized or developing nation. Other collaborations do take place, primarily in R&D, some of which involve a web of several national sites.

Figure 2. A software task maturity function.

The Foreign Entity engages in tasks that range from those that are well-defined and structured, with easy-to-use methods and unambiguous outcomes, to tasks that are hard to define and unstructured, with an iterative solution method and unclear solution. We have a tendency to associate more unstructured tasks with increased levels of coordination complexity between the Center and the Foreign Entity, but this is not always the case, as Figure 3 shows. Furthermore, firms have become more adept at parsing out tasks (and functions) that require low levels of coordination.

Figure 3. Alternative paths to alleviating intensive collaboration.

The lower-left region in Figure 3 represents relatively straightforward tasks with low complexity such as Y2K remediation. For many companies in the Center, these tasks often represent their first offshore activities. Projects such as Y2K remediation also reflect a very small part of the individual system's life-cycle effort. Such projects are more manageable over distance, because the need to communicate and clarify requirements is relatively limited and tasks are relatively stable.

The region at the top of Figure 3, at the maxima, is characterized by a very dense web of coordination that is needed to transfer knowledge and collaborate on tasks. In such an environment, two or more development units are working together on the same project. At the extreme, this is done using the follow-the-sun approach, in which work passes from site to site on a daily basis. For example, when developers in California finish the day's tasks, they pass their work (such as code) to their colleagues in India, who will shortly be arriving at work. In turn, at the end of the day, the Indian developers pass their work back to California. Coordination complexity is high because, on a daily basis, each side must package its added value so that the other side can quickly proceed to add its own value without further clarifications. Near this extreme of complex coordination lie all varieties of innovative R&D activities, because they tend to be unstructured.8

As a consequence of the complexity of coordination, many organizations are moving in one of two directions (depicted by the arrows in Figure 3)[mdash]to either the graph's far left or far right. In both cases, coordination complexity remains relatively low. The key difference is the relative life-cycle effort of the tasks the Foreign Entities perform. In the left-hand side of the graph, for a large corporation, this move often represents transferring maintenance activities (also known as sustaining work), help desks, and data centers.

The lower-right side of the graph shows a relationship in which the Foreign Entity takes full responsibility for (or ownership of) a system, product, or corporate process. This alleviates many of the distance problems, because the Foreign Entity is not using links with the Center as frequently. In other words, ongoing collaboration is not as intense. For software product companies (packaged software), ownership can be over individual software components, individual modules, releases, or entire products.

Consider the following case in point. One major American product software firm opened an Indian development center and, within the span of a few years, transitioned from the lower left of the graph to the lower right. Although tasks were initially structured maintenance activities, the Indian center soon migrated to complete ownership of point releases (for example, from release 2.1 to 2.2), including enhancements. Meanwhile, R&D in the US could devote nearly all its resources to major release cycles (for example, 3.0).

An instance of firms operating on the left-hand side of Figure 3 and moving up the Y axis are two of the largest US megatechnology companies we recently studied, who are in a continuous process of migrating internal IT processes offshore, one chunk at a time, to their rapidly growing Indian IT centers. These processes include support at various levels of criticality as well as data centers. Of course, this movement is facilitated in no small part by the nature of IT today, which permits increasingly larger levels of modularity in both the development process as well as the final product.

TACTIC 2: REDUCE CULTURAL DISTANCE

Cultural distance stems from the degree of difference between the Center and the Foreign Entity. This difference typically manifests itself in one of two forms: organizational culture and national culture.

Organizational culture encompasses the unit's norms and values, where the unit could range from a small technology company to a multinational enterprise. Organizational culture includes the culture of systems development, such as the use of methodologies and project management practices. For example, an Indian source told the authors that Korean customers recently accused an Indian company outsourcing work from Korea of becoming "too American" in that they were devoting too much attention to documentation and were too stringent about deadlines.

National culture encompasses an ethnic group's norms, values, and spoken language, often delineated by political boundaries of the nation-state. It stems from the relative distance between the Center and Foreign Entity. American firms generally prefer to situate development units in foreign locations where cultural distance is smaller[mdash]for example, in Ireland[mdash]or where language barriers are minimal, such as in India or the Philippines.

Figure 4 organizes common structural arrangements for global software development plotted along the cultural distance continua. The two axes represent national cultural distance and distance from the core organizational culture. At one extreme, the least problematic arrangement is to build IT and R&D work teams domestically and inside the firm. At the other extreme, cultural distance is greatest when a foreign outsourcing or contracting company performs the work. These two extremes appear, respectively, in the upper-left and lower-right sections of Figure 4.

Figure 4. A taxonomy of structural arrangements for software development.

Five types of foreign structures are common, with large multinational enterprises often making use of a combination of all five. Beginning with the upper-right quadrant of Figure 4, three common arrangements are possible. An existing foreign subsidiary is typical for the internal IT of a multinational enterprise. A foreign acquisition is typical for technology or software firms. For example, in 1999, European firms acquired 229 US technology firms, while US firms acquired 405 European technology firms.9 The software professionals in these firms were then compelled to work together. An offshore development center is usually set up from the ground up.

At the lower-right quadrant of Figure 4, two arrangements are common. A foreign outsourcing or contracting firm might be India-based Tata Consultancy Services, Mexico-based Dextra Technologies, or Pakistan-based Askari Information Systems, to name three of several thousand such firms. A joint venture or alliance with a foreign firm is an arrangement in which a designated group of software developers from the Center and Foreign Entity collaborate. This is typical in technology companies undertaking innovative product development or product extensions.

With these structural arrangements in mind, companies and vendors have devised four approaches to alleviate distance. These are depicted graphically in Figure 4 as the arrows that "pull" left (reducing national culture distance), up (reducing organizational culture distance), or both.

Bridgehead

The first of these arrangements is the offshore-onshore bridgehead (depicted by the bridgehead arrow, suggesting a reduction in both national culture and organizational culture distance). Some have begun labeling this as the 75/25 rule of thumb: Essentially, 75 percent of personnel work occurs offshore, while 25 percent occurs onshore (usually at the customer site[mdash]for example, in the US). This arrangement optimizes cost savings (offshore) while maintaining closeness to the customer. The individuals assigned to work onshore are typically the more experienced and culturally assimilated. They act to understand the customer's requirements specifications and translate them to the offshore programmers. Perhaps more importantly, the face-to-face interaction reduces miscommunication between customer and vendor. The 25 percent of project personnel that are onshore effectively serve as a bridge[mdash]reducing cultural distance.

Our field work suggests that the 75/25 arrangement has now become part of the marketing pitch by offshore (primarily Indian) firms reassuring their customers that they have found the right solution to distance. Many of the largest Indian firms (such as Tata Consultancy Services) now have considerable corporate presence in the US, further enhancing the cultural buffer and reducing cultural distance. In an approach that is conceptually similar, large US IT services firms, such as EDS, maintain IT outsourcing professionals at the customer's site to act as a bridgehead between a US-based customer and some offshore workforce.

Internalization of Foreign Entity

Some American and European companies, primarily technology firms, are opening internal-to-the-firm foreign software centers. We see this phenomenon in large global corporations, as well as in rather small companies, such as dotcoms that acquire a small Indian professional services firm to support their internal needs. Thus, some of these units are greenfields (created from scratch) while others are acquisitions or conversions from other functions. By internalizing global software development and shunning collaboration with external foreign partners (such as outsourcers, contractors, or joint venture partners) these firms are reducing cultural distance. This is depicted by the Internal Foreign Entity arrow in Figure 4, suggesting a reduction in organizational culture distance. When employees are inside the firm, it reduces organizational distance, operationalized as coordination complexity and organizational culture. These IT workers are within the corporate network[mdash]inside the firewall[mdash]with access to all knowledge-bases, calendars, Web pages, and so forth. They are also trained in the corporate methodologies, policies, and systems.

The cultural liaison

The culture liaison might be a project manager or key executive who travels back and forth between the key stakeholder sites. The liaison's informal role is to facilitate the cultural, linguistic, and organizational flow of communication and to bridge cultures, mediate conflicts, and resolve cultural miscommunications. This is depicted in Figure 4 by the cultural liaison arrow, suggesting a reduction in both national and organizational culture distance. Cultural liaisons are usually expatriates, repatriates, or well-traveled individuals with broader global perspectives. For instance, a native of Ireland settled in the US might serve as the cultural liaison with an offshore site in Ireland. Carmel found that 47 percent of global software teams had someone who fit the characteristics of a cultural liaison.7

Language

Spoken language is an important component of national cultural distance. Many decision-makers at the executive level hesitate to engage in international alliances and express reservations about collaborating with nations in which the command of English is weak. The language factor is one of the reasons for the success of offshore IT work in countries with strong English language capabilities such as the Philippines and Singapore. The language arrow of Figure 4 suggests a reduction in national culture distance. In some instances, US companies invest in English as a Foreign Language courses for those who are not fluent in English to improve professional communication. We have found this to be common in Russia.

TACTIC 3: REDUCE TEMPORAL DISTANCE

Despite the considerable power of today's asynchronous technologies for dispersed work[mdash]email, voice mail, online discussion groups, project management tools, Software Configuration Management, and issue and defect-tracking databases[mdash]there are still powerful reasons for synchronous[mdash]if not face-to-face[mdash]communication. Synchronous communication includes telephone, audio conferencing, videoconferencing, application sharing, and sometimes synchronous online code walkthroughs.

The advantages of synchronous communication include resolving miscommunications, misunderstandings, and small problems before they become bigger problems. A small issue can take days of back-and-forth discussion over email to resolve, but a brief conversation can quickly clarify the problem. Thus, asynchronous communication often delays or complicates problem resolution. In addition, synchronous communication can also help improve quality of life. IT professionals involved in global work frequently complain about the need to compromise personal life to speak to colleagues far away, many time zones removed.

Working within time-zone bands facilitates effective synchronous communication. The goal is to minimize time-zone differences, with zero being best (gradually degrading as the two sites approach an eight-hour difference and beyond). Figure 5 shows typical collaboration pairings in such time zone bands. For the US East Coast, minimal temporal distance means Canada, Mexico, and the Caribbean nations. In fact, Mexican and Caribbean providers market themselves as being "near shore" (as opposed to offshore) to capitalize on this. The potential for synchronous work with Latin America is also great. For Europe, this means intra-EU collaboration or collaboration with South Africa or low-cost nations such as Romania, Hungary, Russia, and Ukraine. The Japanese can work synchronously with Singapore, China, Philippines, and India. Another example is Israel, which, along with most industrialized nations, suffers from an undersupply of software professionals. One of its largest software firms, Amdocs, opened an offshore development center in Cyprus (+0 Hr), now staffed with 400 IT professionals.

Figure 5. Centers and foreign sites in time-zone bands (time differences use daylight-savings time).

Reducing temporal distance presents a trade-off between the advantages and disadvantages of synchronous and asynchronous communication. For example, it eliminates the advantage of follow-the-sun type work, which requires large differences in time zones.

Synchronous communication is also mediated by cultural distance. Japanese managers use less synchronous communication than do managers in North America or Europe (because the lingua franca of IT is English). Asian IT professionals working with Japanese firms in the Center will typically conduct almost all of their communication using asynchronous technologies unless at least one key person on each side has fluency in English or Japanese.

CAVEATS AND HYBRIDS

Not all companies practice all or even some of these tactical approaches. First, and most important, there are other tactical approaches to alleviate the problems of distance, the most significant of which is technology (as mentioned earlier). Second, decision criteria for tactic usage are based in part on task and organization type. Organizations developing and supporting their internal IT (as opposed to software R&D) are more likely to be interested in Tactics 1 and 2. Third, the three tactics can be traded with cost. For example, a firm that has reduced intensive collaboration (Tactic 1) by spinning off structured tasks is unlikely to invest heavily in reducing cultural distance (Tactic 2). Finally, it is rational to engage in only a subset of these tactics. For example, the typical relationship of a US-Indian (Center-foreign) collaboration fails the temporal criterion (India is 10.5 hours apart from the Silicon Valley workday), but does well on the other two distance alleviation tactical approaches (Tactics 1 and 2). Similarly, if a firm invests in a foreign strategic alliance (Tactic 2) that is also in the same time-zone band (Tactic 3), then intensive collaboration (the opposite of Tactic 1) might actually be desirable to reap the advantages of the reduced temporal distance.

Sometimes, rather than reduce intensive collaboration as prescribed in Tactic 1, intensive collaborative is desirable for new application development and innovative R&D, despite its coordination difficulties. There are many cases in which a geographically dispersed team might be the only way to gather all talented IT professionals around the world. It is clearly desirable if the company can use time-zone differences to decrease time to market (for example, Ford's design centers or IBM's development of the VisualAge JavaBeans product suite), although very few companies have done it successfully.

Paradoxically, as opposed to reducing cultural and organizational distance as prescribed in Tactic 2, increasing cultural distance from the Center can be advantageous[mdash]allowing companies to tap diverse know-how and ideas. Eric von Hippel found that successful companies assimilate innovations that emanate from their most important customers.10 For example, Japanese firms, which dominate the computer game market, develop some of their game software in the US to be close to the large community of game players and designers.

Although Tactic 3 prescribed reducing temporal distance by using synchronous communication over distance, this is no panacea because synchronous communication does have its limitations. Many IT professionals shun videoconferencing because of various behavioral problems such as the awkwardness of interrupting or the inability to see all the participants. Moreover, while face-to-face work often uses multiple applications and channels, today's synchronous application sharing tools unnaturally restrict collaboration to a single application informational space.11 And even small time zone differences can be disruptive: James Hersleb and Rebecca Grinter found that in a British-German collaboration (with only a one-hour time-zone difference), after deductions for lunch and different work hours, few windows of common (synchronized) time were left.12 Synchronous communication can even be inferior to asynchronous communications. After all, a telephone conversation (synchronous) does not address such communication problems as, "I already told you that," wheras email and fax (asynchronous) automatically leave a written communication history.

CONCLUSION

Our view of the future is that software development projects will increasingly look like a global virtual archipelago with several separate clusters of co-located professionals sprinkled with dispersed individuals working remotely. To overcome the increased burdens that realizing this vision presents, IT managers will continue to experiment with new tactics that overcome some of the liabilities of distance.

References


1. "Offshore's New Horizons," Global Technology Business, vol. 3, no 3 Mar. 2000, pp. 12-15.
2. E. Carmel and R. Agarwal, Offshore Sourcing of Information Technology Work by America's Largest Firms, tech. report, Kogod School of Business, American Univ., Washington D.C., 2000.
3. GPI consultancy and P. Tjia, Computer Software and IT Services: A Survey of the Netherlands and Other Major Markets in the European Union, The Center for the Promotion of Imports from Developing Countries, Netherlands, 1999.
4. T.W. Malone and R.J. Laubacher, "The Dawn of the E-Lance Economy," Harvard Business Rev., vol. 76, no 5, Sept./Oct. 1998, pp. 145-152.
5. "Have Factory, Will Travel," The Economist, vol. 354, no. 8157, Feb. 12 2000, pp. 61-62.
6. G.H. Anthes, "Software Development Goes Global," Computerworld Online, June 26 2000; http://www.computerworld.com/cwi/story/0,1199,NAV47_STO46187,00.html(current 13 Feb. 2001).
7. E. Carmel, Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall, Upper Saddle River, N.J., 1999.
8. R.E. Grinter, J.D. Herbsleb, and D.E. Perry, "The Geography of Coordination: Dealing with Distance in R&D Work," Proc. Int'l ACM SIGGROUP Conf. Supporting Group Work (GROUP '99), ACM Press, New York, 1999, pp. 306-315.
9. Broadview Technology M&A Report, 1999; http://www.broadview.com/(current 13 Feb. 2001).
10. E. von Hippel, The Sources of Innovation, 2nd edition, Oxford Univ. Press, New York, 1994.
11. C. Geisler and E.H. Rogers, "Technological Mediation for Design Collaboration," working paper, Rensselaer Polytechnic Inst., New York, June 2000.
12. J. D. Herbsleb and R. E. Grinter, "Splitting the Organization and Integrating the Code: Conway's Law Revisited," Proc. 21st Int'l Conf. Software Eng. (ICSE '99), ACM Press, New York, 1999, pp. 85-95.


Erran Carmel is an associate professor at the Kogod School of Business at American University in Washington, D.C., where he cofounded and shares leadership of the program in Management of Global Information Technology. His research focuses on global software development, and he wrote the 1999 book Global Software Teams. Contact him at the Program in Management of Global Information Technology, Kogod School of Business, American Univ., Washington D.C. 20016-8044; ecarmel@american.edu.


Ritu Agarwal is an associate professor of Information Systems at the Robert H. Smith School of Business, University of Maryland. Her recent work has focused extensively on information technology workforce issues. She is the coauthor of Coping with Labor Scarcity in Information Technology, published in 1999. She is an associate editor for MIS Quarterly and the International Journal of Human Computer Studies. Contact her at Decision and Information Technologies, Robert H. Smith School of Business, Univ. of Maryland, College Park, MD 20742-1815; ragarwal@rhsmith.umd.edu.

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 Carmel organized1 (and later refined2) these approaches into six centripetal forces that exert inward pressure on the team for more effective performance: collaborative technology, team building, leadership, product architecture and task allocation, software development methodology, and telecommunications infrastructure.

Of these, technology-based solutions are perhaps the most obvious. For example, a distributed Software Configuration Management (for managing the system component versions) reduces miscommunication because it enforces a common work process and a common view of the project.1,3 Another use of technology is the team Web site that encompasses all facets of individual- and task-related information[mdash]from the programmers' photos to the test documentation.4 Other nontechnology approaches are more subtle. Martha Maznevski and Kathy Chudoba found that effective virtual teams had a "deep rhythm" of regular team meetings, both face-to-face and over distance.5 Of course, a meeting is but a communication formalism. Communication need not always occur within a formal, hierarchical configuration. When global software teams collaborate on innovative projects, informal channels of coordination[mdash]or lateral channels[mdash]are critical. They "help developers fill in the details in the work, handle exceptions, correct mistakes...."6

References


1. E. Carmel, Global Software Teams: Collaborating across Borders and Time Zones, Prentice Hall, Upper Saddle River, N.J., 1999.
2. E. Carmel, "Global Software Teams: A Framework for Managerial Problems and Solutions," Global Information Technology and Electronic Commerce: Issues for the New Millennium, Ivy League Publishing, Marietta GA, to be published, 2001.
3. R.E. Grinter, "Doing Software Development: Occasions for Automation and Formalisation," Proc. Fifth European Conf. Computer Supported Cooperative Work (ECSCW '97), Kluwer Academic Publishers, Dortrecht, The Netherlands, 1997, pp. 173-188.
4. S. McConnell, Software Project Survival Guide, Microsoft Press, Redmond, Wash., 1998.
5. M.L. Maznevski and K. Chudoba, "Bridging Space Over Time: Global Virtual Team Dynamics and Effectiveness," Organization Science, vol. 11, no 5, Sept./Oct. 2000, pp. 473-492.
6. J. D. Herbsleb and R. E. Grinter, "Splitting the Organization and Integrating the Code: Conway's Law Revisited," Proc. 21st Int'l Conf. Software Engineering (ICSE '99), ACM Press, New York, 1999, pp. 85-95.

Send general comments and questions about the IEEE Computer Society´s Web site to webmaster@computer.org.
This site and all contents (unless otherwise noted) are Copyright ©2000, Institute of Electrical and Electronics Engineers, Inc. All rights reserved.