Outsourcing - The Benefits Involved

1. Outsourcing - The Benefits Involved As globalization and technology continue to bridge people closer together and create new business opportunities, companies decide which operations are fundamental to the business and which can be outsourced in order to gain efficiency or save money. All business processes are open for the outsourcing consideration, from information technology to human resource management, from manufacturing, distribution, to customer service. Lee, Huynh, Kwok, and Pi (2003) state that identifying and concentrating on the core function of the company is the new trend in business nowadays. This paper analyzes costs and benefits of outsourcing as well presents a real life example of the failed outsourcing of software development work in order to reduce time to market. There are two types of outsourcing – strategic and tactical. Tactical outsourcing is straightforward and cost-driven and can be evaluated annually to ensure best value. Strategic outsourcing is more complicated and requires careful consideration since it involves complete business function, such as customer service, not just a project. Businesses have an objective to lower total cost while at the same maximizing beneficial value of outsourcing. Axelrod (2004) defines two groups for costs and benefits – tangible and intangible, each with two sub categories and two types. Using these categories, an analyst for the organization can measure whether the outsourcing initiative was successful. Assessing costs and benefits of outsourcing presents unique sets of challenges as some costs are hard to measure and probability of other costs are very remote to be accurately accounted for. Nevertheless, assessing costs and benefits of outsourcing relationship is a necessary step in measuring the success. A Michigan-based company started working on the enterprise-level software development project in 1999 with official project launch date of January 2000. The team consisted of seven people in United States, five people in United Kingdom and three teams of five people in various parts of India. Management wanted to leverage spatial and temporal separation by having teams work around the clock in order to minimize time to market. According to Gupta (2009), product design is a semi-structured task that can be addressed with “24-hour Knowledge Factory” paradigm.

2. However, currently, this project is being entirely managed and developed in Michigan. Below is the analysis of what has transpired. The goal of the project was to develop a global asset management application with multi-currency, localization, and non-logographic language support. System architecture of the project was created in Michigan and was communicated to teams in England and India. During this period, frequent conference calls were required, and because of time difference, someone was always inconvenienced. During one conference call, someone fell asleep and snored loudly, because it was 1am in that country. In addition, time difference caused some software to malfunction. When code was checked-in to Microsoft Source Safe, a source-code repository, in England, and then checkout in Michigan, the program thought that code was written in the future and caused problem with versioning and code merging. As a result, some source code was corrupted. As a work-around, teams in five places had installed local versions of MSS and program source code was shared via e-mail and then synchronized in a local source code repository. Microsoft has since addressed this problem by replacing the client-side date stamp with the server-side. Language differences presented some challenges as well. Though everyone spoke and wrote in English, teams from around the world used their own spelling – for example, in US, word “organization” is spelled with “Z,” whereas in England it is spelled with “S.” Same items also have different names in these countries. For example, in US, a vehicle’s unique ID is called “VIN” and in UK and India is it called “Chassis Number.” Sometimes teams experienced spoken language barrier so strong that written communication was necessary to clarify what the person meant to convey. Cultural differences presented their own set of problems. Team had hard time bonding because if someone shared a joke, people in other countries did not understand them and it created awkward situation. Because of labor laws in Britain, team members had vacations that lasted up to six weeks. In addition, it was permitted in England to have beer at lunch, so after lunch conference calls were not productive. India’s growing outsourcing demand created attrition problem for the project and team members would often be switched on a weekly basis. Due to the size of the group and the fact that it was scattered around the globe, there was little accountability. Individual team members practiced finger pointing and would not complete assigned tasks on time. Because of that, some of the conference calls were degraded to a project manager trying to control the situation and question each member of their task assignment and status. To remedy this issue,

3. a “go to person” was established at every location in order to communicate project progress and to resolve any questions that may arise within teams. Team members also had very different skill levels. Members in United States had broad expertise and were highly skilled in Microsoft environment and software architecture. Developers in United Kingdom contained great expertise in Unix and IBM as well as software architecture in general. India team members had varied level of narrow specialization and people with good, broad knowledge were hard to keep because of the high demand for highly skilled labor in India. Ten months and many conference calls later, the team produced the core database structure. Management noticed that they were not able to reach the expected economies by working the “24-hour Knowledge Factory” (Gupta, 2009) and pulled the software development under a single roof. Currently, the team functions within scrum framework with daily short stand-up motivational meetings; sprint meetings, usually every 2-4 weeks, during which tasks are defined and developers choose the tasks that they will work on; and face-to-face interaction whenever questions arise. As a result, the team of seven developers was able to complete the core of the application within ten months and start the work on various additional modules. The example above presented a failed outsourcing project because of many issues that were not accounted for in the beginning. Perhaps because of the relatively small size of the development team, it was easier handled locally. There are plenty of successful outsourced teams, including large IT teams at Chrysler, Toyota, and Nissan. References Axelrod, W. C. (2004). Outsourcing Information Security. Norwood, MA: Artech House, Inc. Gupta, A. (2009). Deriving Mutual Benefits from Offshore Outsourcing. Communications of ACM , 52 (6), 122-126. Lee, J. N., Huynh, M. Q., Kwok, R. C., & Pi, S. M. (2003). IT Outsourcing Evolution – Past, Present, and Future. Communications of the ACM , 46 (5), 84-89. Mintz, S. M. (2004, August 4). The ethical problems of outsourcing. Retrieved June 19, 2010, from The San Diego Union-Tribute: www.signonsandiego.com/uniontrib/20040806/news_lz1e6mintz.html CxT Group Michigan,2415 E.Hammond Lake DriveSte,219 BloomfieldHills, MI 48302 Contact No:(248) 282-5599 Toll Free:(877) 439-2539