Research and Advances
Computing Applications

Managing Risk in Offshore Systems Development

The benefit of low-cost labor must be weighed against the risk of missed deadlines, dissatisfied users, and failure to reduce development costs.
Posted
  1. Introduction
  2. Project Management
  3. Vendor and Contract Management
  4. Strategic Systems
  5. Nonstrategic Systems
  6. Software Products
  7. Direct Costs
  8. Conclusion
  9. References
  10. Author
  11. Figures
  12. Tables

Offshore systems development provides opportunities for savings and growth but can also increase the risk of not achieving quality, cost, and schedule objectives. Other risk follows from a project’s international management, as well as from the nature of the vendor and the contract. This article identifies the various risks associated with offshore development and suggests how to manage them to achieve development objectives.

Many Fortune 500 companies produce their business information systems in developing countries (such as China and India) to take advantage of their relatively low-cost labor. India, which claims about half of the world outsourcing market, exported about $13.3 billion worth of software in fiscal 2005–2006 (ending March 31, 2006) [10]. Offshore development has gained so much importance and attention that in 2004 ACM commissioned a task force to study the subject [2]. Although a number of reports, articles, and books address offshore development, they do not fully address the management of risk.

Inadequate management of risk in IS development (ISD) is a major reason for exceeding a project’s estimated time and cost. Systems developed by a team of people from many countries, speaking a variety of languages and separated by time and distance, have higher risk. Advances in communication technologies enable virtual work in offshore development, but research in such fields as psychology, organizational behavior, management, and communication have found that such work in the global environment has limitations. Managing the project, vendor, and contract in the international context increases risk (see Table 1).

Collaborative work involving creative, knowledge-intensive, problem-solving, and consensus-building tasks requires the face-to-face interaction of team members [3]. Synchronous communication technologies (such as videoconferencing) can substitute for such interaction. Customized collaborative work products (consisting of group support systems, CASE tools, and a shared ISD data repository) can aid the communication process. Synchronous communication is also aided by telephones, conference calls, and chat facilities. However, these media are not suitable for intensive or prolonged teamwork in offshore development, especially when members are separated by multiple time zones. Team members separated by time may have to use asynchronous communication facilities (such as email and file transfers).

Since any team’s effectiveness depends on the fit between task complexity and interaction medium [9], the related teamwork and team composition dictate the choice of communication technology. Teamwork with a high degree of interdependent tasks for a diverse team warrants face-to-face interaction. Teamwork involving interdependent tasks for a homogenous team can use asynchronous communication technologies. User background, skills, knowledge, and training can help guide the selection of appropriate technology for performing such virtual work. A bad fit among development task, team, and communication technology reduces task effectiveness, increases time and cost, and jeopardizes development quality.

The quality of methods, tools, and procedures (collectively the “development process”) in systems development and its quality assurance influence the overall quality of a system. An appropriate development process is necessary for addressing such issues as lack of user knowledge of an application, lack of user involvement, incorrect requirements, and the inherent risk associated with technology and quality. A major risk factor in offshore development is the lack of an effective development process with the offshore company. Reducing this risk involves rigorous evaluation of development capabilities, certification, benchmarking against Capability Maturity Model levels, and the hiring of reputable vendors. The risk of miscommunication is high if the onshore and offshore teams use different sets of methods and tools.

Team processes involve collaborative activities, the progress and outcome of which are documented to reinforce, complement, synergize, and reciprocate the work of team members. Inadequate documentation and support systems can negatively affect team performance. Projects need to use a shared ISD data repository or synchronize their documentation in dispersed locations to enable work to flow coherently from one place to another in time.

Systems development processes can be classified into two approaches: structured and iterative/incremental. Most methodologies in the structured approach follow the waterfall model. The extent of task dependencies and user involvement required during a development stage and the extent to which communication technologies facilitate collaborative work determine offshore development risk in these projects. Requirements analysis and quality assurance of user requirements have high task dependencies and need intense user involvement. Regardless of the methods and tools employed, the success of requirements analysis depends on how well users and analysts communicate and collaborate [7]. Offshore requirements analysis, even with the best available communication infrastructure and collaborative work tools, has a high risk of producing infeasible, excessive, unrealistic, missing, and/or incorrect requirements.


Unless the onshore company executes large and frequent projects, the offshore company may not participate in the investment or be responsive to onshore company needs.


The user interface design follows from an iterative team process with significant user involvement and interdependent tasks. A prototype of user interfaces with shared ISD data repository and interactive group support can facilitate offshore development of this activity. Logical data design involves moderate user involvement and moderate risk. Most other design activities, coding, and testing for systems with stable requirements require little user involvement and involve low risk. Coding and testing of even large projects with stable requirements are suitable for offshore development. Adaptive maintenance, corrective maintenance, and enhancements with onshore documented requirements are also prime candidates for these projects. Overall, development activities that use well-defined, well-documented, frozen requirements without user collaboration or innovation have low risk.

Iterative and incremental approaches include rapid prototyping, rapid application development (RAD), and agile development methods (ADMs). Due to their high task dependencies and required face-to-face interaction with users during their iterative analysis, design, and trial stages, they are not suitable for mid- and large-size offshore projects. However, these methods are less time-consuming and costly for simple, small, or short-lived systems. In the offshore development of such systems, all that’s needed to manage a few users and their interactions is a prototype, a shared ISD data repository, desktop videoconferencing, and collaborative work products.

Back to Top

Project Management

Accurate estimation of the development effort in each stage is needed to determine a project’s schedule, resource allocation, and cost savings. In insourced ISD projects, the development effort often exceeds the estimate by 100% or more. Available estimation methods that assume work in collocated places may not estimate project effort accurately because the project calls for varied levels of communication, coordination, and management, depending on the development process and which stages of the development are done on-site and which are done offshore.

Lack of required knowledge and skills by project personnel and inappropriate project staffing cause failures in ISD projects. These risks are higher in offshore projects because software companies in developing counties have skewed skill profiles, with more programming expertise than any other skill [2, 6]. In addition, the productivity of workers in developing countries is much lower than the productivity of their U.S. counterparts. This lower productivity requires larger-size teams that may not be optimal. Moreover, productivity losses, increasing offshore IT salaries, and declining dollar value relative to the local currency may offset any cost advantage. Local outsourcing is common in many companies, but offshore development causes emotional and politicized debate. Organizations employing selective offshore development may face morale issues that affect in-house projects.

Loss of control is a major disadvantage in local IT outsourcing, especially in projects in which the offshore company manages the project. Bureaucratic procedures, time-consuming communication, and coordination of resources, including personnel, jeopardize flexible project management. A project manager from the onshore company familiar with the language and culture of the offshore company can reduce the loss of control. This manager may have to travel frequently and stay close to the place where task complexities or team-member differences are high. To prevent confusion in communication and control, both onshore and offshore companies should use mutually accepted, standardized, well-documented project-management procedures, change- management methods, and interaction protocols.

Back to Top

Vendor and Contract Management

IT skills at low cost, good communication infrastructure, political stability, favorable government policies, and peace determine the location of an offshore facility. Consulting with experts in international relations and outsourcing can reduce the risk of choosing the wrong offshore company. Unless development work is done in small chunks and passed on to an offshore facility for further development, with little interaction between users and developers, extended time zones pose communication difficulties. Risk in vendor and contract management depends on the ownership of the offshore facility and the type of contractual relationships (see Table 2).

The vendor-related risk for offshore projects with fee for contract, joint venture, and strategic partnerships is similar to the risk in local outsourcing [12]. Major risk factors include the lack of active management by the vendor, incomplete contracting, trust, and knowledge transfer. A project involving multiple offshore companies requires investment in costly communication facilities with each of them. Unless the onshore company executes large and frequent projects, an offshore company may not participate in the investment or be responsive to onshore company needs. Offshore companies with local presence can be held accountable for lapses in contract obligations. Startup companies and companies without outsourcing experience can turn to brokers (such as IBM Offshore Services) to reduce this risk, but brokerage fees and third-party management of projects create risk in achieving cost savings.

An offshore subsidiary of the onshore company can avoid the risks in vendor management and contracts, but without a sufficient number of projects, development resources will be underutilized, increasing overhead costs. Additional risks include varied tax, labor, and contract laws, protection of intellectual property rights, and enforcement of copyrights in developing countries.

Back to Top

Strategic Systems

Strategic information systems often involve new and untried technologies that require continuous updating to sustain competitive advantage. Offshore companies in developing countries are not well equipped to develop these systems on their own because they spend little on R&D and have skewed skills profiles. Developing countries produce a large number of IT graduates but few IT teachers and lack skills in the latest technologies and development processes [5]. Offshore developers may also lack knowledge of new business applications. Since users may lack knowledge of these technologies and their applications, developers may be unable to define user requirements. New technology, lack of experience with the technology, and technological complexity create uncertainty in both development and implementation. Although RAD and ADMs address these uncertainties, they have limitations and risk in offshore projects, as discussed earlier. Strategic systems depend on innovation and experimentation involving new technologies, users, and pilot projects in consultation with users. Separating users and developers by time and distance would further affect innovation and experimentation.


The production costs of developing an IS and the transaction costs of managing the virtual work, vendor, contract, project, and risks with a single vendor are much higher than the corresponding costs with a subsidiary.


Strategic systems usually have differentiated and new business processes that evolve, even during coding and testing. Offshore companies in developing countries are less likely to be familiar with current and evolving business practices that become the core of strategic systems.

Changes in scope, business processes, and organization may occur during systems development due to lack of top-management commitment, failure to gain user involvement, and conflict among user departments. Reconciling user differences and ensuring user participation depend on effective communication between developers and users. Gaining top management commitment and finding a top-management sponsor from the user department can reduce the risk of changing systems. Difficulty estimating development effort and planning, combined with changing requirements, warrant project management by users in a steering committee that includes developers. However, users separated from developers by distance and time find management difficult, even with the help of the best communication infrastructure.

Changes may also occur if users are unsure of their requirements, identified requirements are incorrect or incomplete, or the requirements change with evolving business needs. These changes may compromise the quality of a project, escalating its cost and time due to increased coordination, communication, problem resolution, user management, and change management. Systems that evolve during development need requirements verification, user involvement, and newer development methods (such as RAD and ADMs) but have limitations in offshore development.

Companies that develop strategic systems face high business risk and are unable to estimate the related costs and benefits [8]. Uncertainties in development schedules, cost, and quality of offshore projects compound the uncertainty of the return on investment. The offshore development of strategic systems also involves the risk that vendors will leak the strategies to competitors or use the gained expertise in competitors’ projects. Companies that accept the high risk involved in offshore development of strategic systems are also likely to develop nonstrategic systems offshore. This raises the exit barrier for a company wanting to abandon offshore development and return to in-house development. As a contingency plan, these firms need to maintain their in-house IT capability, scanning new technology, experimenting with pilot projects, and innovating in consultation with users.

The compounded risks of technology, changing and evolving requirements, and differentiated business processes in the offshore development of strategic systems are higher than the sum of their individual risks. The costs of communication infrastructure, coordination, project management, vendor management, contract management, and management of business and offshore development risks are much more than the production cost savings.

Back to Top

Nonstrategic Systems

The individual risks of technology, changing and evolving requirements, and differentiated business processes in nonstrategic systems can be managed as follows:

Technology. Hiring developers with certification and experience and experts as consultants can reduce technology risk. Moreover, the system can be prototyped for the purpose of exploring integration uncertainties; following a successful prototype, the full-fledged system can be designed and developed using the waterfall model approach. The IT team can manage these projects using such tools as the Program Evaluation and Review Technique (PERT). Since developers interact with users less frequently, an infrastructure that includes synchronous and asynchronous communication technologies would be adequate. The contingency plan would involve transferring the project to in-house developers or to a local vendor with demonstrated experience and success with the technology.

Evolving systems. Since the system is nonstrategic, developing a prototype onshore, validating it with users, analyzing requirements at the user site, and freezing the requirements after user sign-off can reduce development risk. Design and coding can be done in the offshore facility. Excellent communication structure and change management procedures are essential for handling changing and evolving requirements.

Differentiated business processes. Organizations should avoid differentiated business processes in nonstrategic systems because they add to costs without producing corresponding benefits. If such processes are unavoidable, analysis and verification of requirements at the user site would improve the correctness and completeness of requirements. Requirements can be frozen and the waterfall model employed to provide modularity in offshore development. Using a prototype, shared ISD data repository, group support systems, adherence to time and cost schedules, and formal project management tools like PERT can control risk during the design and coding stages.

Nonstrategic systems with known technology, common business processes, and stable requirements and that are developed through the waterfall method have low risk in the design, coding, and testing stages.

Back to Top

Software Products

A firm using an offshore subsidiary to develop a software product would have better team cohesion, standardized and compatible development processes, protection of intellectual property rights, control over development, compatible project management and management style, and lower costs than other types of offshore facilities. Using an offshore subsidiary also avoids the legal issues related to contracting and engaging vendors. However, the subsidiary needs a sufficient number of projects to fully utilize its resources and gain the flexibility of a vendor in procuring the necessary development skills in the local market.

Since software products compete in an international market, it makes no difference whether they are developed in Germany, India, or the U.S. The onshore company can conceptualize the product, provide the proof of concept, and define the requirements. With appropriate software configuration management, it can distribute the design, coding, and testing of its components to the subsidiary. The modularity in development, which needs less face-to-face interaction, reduces the development risk. Table 3 outlines the risks associated with a range of development scenarios, from the offshore systems development of software products in a subsidiary at one extreme to development of strategic systems with a single vendor at the other.

Back to Top

Direct Costs

The direct costs of setting up an offshore subsidiary and communication infrastructure are much higher than the direct costs of finding a vendor with the necessary communication infrastructure. However, the related risks are inversely proportional (see Figure 1). The production costs of developing a system and the transaction costs of managing the virtual work, vendor, contract, project, and related risks with a single vendor are much higher than the corresponding costs with a subsidiary (see Figure 2). Whereas strategic systems have high risk and high costs, nonstrategic systems and software products involve relatively low risk and costs (see Figure 3).

The risks and costs associated with systems in offshore facilities are additive. Thus, a single offshore vendor developing a strategic system for an onshore company would involve the greatest risk and cost. Many software companies (such as Oracle and SAP) are expanding their offshore centers, with Oracle employing about the same number of employees offshore as it employs in its onshore centers. A survey of more than 5,000 corporate executives worldwide showed that offshoring produced less than 10% cost savings over systems developed onshore [11].


A single offshore vendor developing a strategic system for an offshore company would involve the greatest risk and cost.


Back to Top

Conclusion

The relatively low-cost labor in developing countries is a major incentive for offshore systems development. One study found that production costs influenced onshore outsourcing decisions six times more than transaction costs [1]. Another found that the transaction costs for just two actors separated by time were higher than when they worked at the same time in the same place [4]. Firms that ignore transaction costs in offshore development may not achieve their cost-saving objectives while trying to meet quality and schedule objectives. Development plans should consider the portfolio of ISD projects and evaluate the candidate systems in various types of offshore facilities, with all costs included, to determine the expected savings.

Back to Top

Back to Top

Back to Top

Figures

F1 Figure 1. Risks and direct costs in various types of offshore facilities.

F2 Figure 2. Risks and production and transaction costs in various types of offshore facilities.

F3 Figure 3. Risks and production and transaction costs in various types of systems.

Back to Top

Tables

T1 Table 1. Risks, sources, and controls in offshore development.

T2 Table 2. Offshore facility ownership.

T3 Table 3. Risks in two extreme types of offshore projects.

Back to top

    1. Ang, S. and Straub, D. Production and transaction economies and IS outsourcing: A study of the U.S. banking industry. MIS Quarterly 12, 4 (Dec. 1998), 535–548.

    2. Aspray, W., Mayadas, F., and Vardi, M., Eds. Globalization and Offshoring of Software: A Report of the ACM Job Migration Task Force. ACM, New York, 2006.

    3. Baltes, B., Dickson, M., Sherman, M., Bauer, C., and LaGanka, J. Computer-mediated communication and group decision making: A meta-analysis. Organizational Behavior and Human Decision Processes 87, 1 (Jan. 2002), 156–179.

    4. Espinosa, J. and Carmel, E. Modeling coordination costs due to time separation in global software teams. In Proceedings of the International Workshop on Global Software Development (Portland, OR, May 9, 2003), 64–68.

    5. Gupta, P. Growth scenarios of IT industries in India. Commun. ACM 44, 7(July 2001), 40–41.

    6. Heeks, R. Software strategies in developing countries. Commun. ACM 42, 6 (June 1999), 15–20.

    7. Holtsblatt, K. and Beyer, H. Requirements gathering: The human factors. Commun. ACM, 38, 5 (May 1995), 30–32.

    8. Lucas, Jr., H. Information Technology and the Productivity Paradox. Oxford University Press, New York, 1999.

    9. Maznevski, M. and Chudoba, K. Bridging space over time: Global virtual team dynamics and effectiveness. Organization Science 11, 5 (May 2000), 473–492.

    10. National Association of Software and Service Companies. Press Release, New Delhi, India, 2006; www.nasscom.in/Nasscom/templates/NormalPage.aspx?id=28833.

    11. Pallato, L. and Lacity, M. Offshore savings can be elusive, survey shows. CIO Insight (July 15, 2005); www.cioinsight.com/article2/0,1540,1837328,00.asp.

    12. Willcocks, L. and Lacity, M. Strategic Sourcing of Information Systems: Perspectives and Practices. John Wiley & Sons, New York, 1997.

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More