Information Systems Frontiers

, Volume 10, Issue 2, pp 259–275

A US Client’s learning from outsourcing IT work offshore

Authors

    • University of Missouri—St. Louis
  • Mary C. Lacity
    • University of Missouri—St. Louis
Article

DOI: 10.1007/s10796-007-9061-4

Cite this article as:
Rottman, J.W. & Lacity, M.C. Inf Syst Front (2008) 10: 259. doi:10.1007/s10796-007-9061-4

Abstract

Based on 45 interviews and significant documentation, we explore the offshore outsourcing experiences of a US-based biotechnology company. This company offshore outsourced 21 IT projects to six suppliers in India. Senior managers and the official documents from the Program Management Office consistently reported that offshore outsourcing was successful in reducing the company’s IT costs. But interviews with knowledgeable participants actually managing the projects suggest that many projects were not successful in meeting cost, quality, and productivity objectives. We found evidence that this company’s offshore strategy to simply replace domestic contractors with cheaper, offshore suppliers was a poor fit with its social and cultural contexts. Specifically, we found that strong social networks between the company’s internal IT employees and domestic contractors were not easily replicated with offshore suppliers. Furthermore, the internal project management processes were often incompatible with offshore suppliers’ processes. This paper also analyzes seven project characteristics that differentiate highly-rated projects from poorly-rated projects. These project characteristics are type of IT work, size of supplier firm, location of supplier employees (onsite/offshore), dollar value of the contract, duration of the project, timing of the project, and client unit managing the project. The paper concludes with four overall insights for clients and suppliers.

Keywords

OutsourcingITOffshore

1 Introduction

Offshore outsourcing is the outsourcing of information technology (IT) work to a 3rd party supplier located on a different continent than the client1. Although client organizations have outsourced manufacturing services offshore for decades, the practice of offshore outsourcing IT services is still maturing. The offshore IT outsourcing (ITO) market (primarily India) will conservatively represent about 25% of the global $56 billion ITO market by 2008 (E-business Strategies 2006). Forrester, McKinsey and NASSCOM predict that India alone could grab $142 billion of the ITO market by 2009 (E-business Strategies 2006; Ross 2004). Although there have been recent reports that India is struggling with high turnover, wage increases, and infrastructure issues associated with rapid growth (McCue 2005; Srivastava 2005), evidence suggests that India will continue to be a dominant player in the global ITO market (Carmel and Tjia 2005; Engardio 2006; Minevich and Richter 2005).

Western clients, particularly in the US, are attracted to offshore outsourcing to India (and other destinations) because of the promised benefits of lower IT costs, faster delivery speed, the ability to focus in-house IT staff on more higher-value work, access to supplier resources and capabilities, and process improvement (Carmel and Tjia 2005). But juxtaposed to the promised benefits of offshore outsourcing, many IT executives we interviewed struggle to realize its full potential. Although offshore outsourcing is technically possible because any work that can be digitized can be moved, there are many managerial challenges. One common complaint was that overall cost savings was less than anticipated due to the high transaction costs associated with finding suppliers, coordinating, and monitoring work done offshore. Other common complaints were that quality was initially poor, delivery was slow, and personnel issues such as high supplier turnover interfered with success (Lacity and Rottman 2008).

Western clients have a significant learning curve to conquer. Several academic researchers found that Western clients initially engage offshore suppliers to lower IT costs (Carmel and Agarwal 2002; Kaiser and Hawk 2004). Clients are frequently shocked at the lack of in-house capabilities they have to ensure offshore outsourcing expectations are realized. Frequently, Western clients have to re-launch their offshore outsourcing efforts to be successful (Rottman 2006). In this paper, we present a highly realistic picture of a client’s experiences with offshore outsourcing of IT work for the first time and how best and worst practices quickly emerge from experience. In telling this story, we hope that other clients may apply insights to accelerate their own path on the learning curve.

The client company, assigned the pseudonym Biotech, employs approximately 15,000 employees spread across 400 locations in more than 40 countries. Our research, based on 45 interviews and over 2,000 documents, focuses on the IT group at US headquarters. This group engaged six Indian offshore suppliers on 21 IT projects during 2003 through 2005. The official documents from the Program Management Office (PMO) report that offshore outsourcing was successful in reducing Biotech’s IT costs. But interviews with knowledgeable participants suggest that many projects were not successful in meeting cost, quality, and productivity objectives. Thus, different stakeholders within Biotech often had drastically different views on the success of offshore outsourcing. This case study is important because it suggests that merely surveying CIOs on offshore outsourcing practices and outcomes may not reveal a very realistic or rich picture.

The paper is organized as follows. We briefly summarize the growing body of academic research on offshore outsourcing of IT work, describe the research method, and tell Biotech’s offshore outsourcing story. We then explain Biotech’s mixed results with offshore outsourcing at two levels of analysis. At the organizational level of analysis, we found evidence that Biotech’s offshore strategy to simply replace domestic contractors with cheaper, offshore suppliers was a poor fit with Biotech’s social and cultural contexts. At the project level of analysis, we analyzed seven project attributes to differentiate highly-rated projects from poorly-rated projects. We conclude the paper with four overall insights for clients and suppliers.

2 Prior research on IT outsourcing

Academics have been studying domestic outsourcing2 since the early 1990s. The first published outputs from academic research appeared in 1991, which documented companies pursuing large-scale domestic IT outsourcing (Applegate and Montealegre 1991; Huber 1993). More quantitative research and multiple-case studies followed, focusing on why firms outsource (Loh and Venkatraman 1992) and how firms benefit (or do not benefit) from IT outsourcing (Lacity and Hirschheim 1993; Whang 1992). Between 1994 and 2000, at least 79 other academic studies were published (Dibbern et al. 2004).

Overall, we learned why firms outsource (mostly to reduce costs, access resources, focus internal resources on more strategic work3), what firms outsource (mostly a portion of their overall IT portfolio), how firms outsource (mostly by formal processes), and IT outsourcing outcomes as measured by realization of expectations, satisfaction, and performance (Dibbern et al. 2004). Overall, we know that client readiness, good strategy, good processes, sound contracts, and good relationship management are key success factors (Cullen et al. 2005; Feeny and Willcocks 1998; Teng et al. 1995; Willcocks and Lacity 2006).

In the area of offshore outsourcing of IT work, academics are trying to understand how offshore outsourcing differs from domestic outsourcing. So far, researchers have found that offshore outsourcing poses additional challenges than domestic outsourcing (Rottman and Lacity 2006). For example, offshore outsourcing is more challenging because of time zone differences (Carmel 2006), the need for more controls (Choudhury and Sabherwal 2003), cultural differences (Carmel and Tjia 2005), defining requirements more rigorously (Gopal et al. 2003), and difficulties in managing dispersed teams (Oshri et al. 2007). Researchers are also looking at offshore outsourcing at both the decision and relationship levels (Rivard and Aubert 2007). There are also several special issues forthcoming in MIS Quarterly and the Journal of Information Technology that should be available in 2008, as well as a collection of current academic research forthcoming from the Third International Conference on Outsourcing of Information Systems.4

Our case study contributes to this body of knowledge by showing how emerging “best” practices need to be compatible with an organization’s social context or the practices will likely be ineffective. However, the possibility for managers to change a social context always exists. In practice, we see this in the form of CIOs and other IT leaders who re-launch offshore outsourcing initiatives more successfully the second time. We hope that other agents will benefit from Biotech’s lessons.

3 Research method

This case study emerged over a 2-year period that involved cycles of data collection, interpretation of data, and participant feedback on data interpretation. As will be shown, different stakeholders have different views on offshore outsourcing. They did not uniformly share a clear, consistent, objective “reality.” The analysis was mostly an iterative process of letting the data drive the story, searching for patterns across the interviews, looking for documents to shed light on the interviews, and re-reading interviews to shed light on the documents. We used prior empirical research on project management and outsourcing to help us look for clues in the data. Thus, although our findings are organized and clearly presented, the process of inquiry was mostly iterative and emergent.

The project consisted of three distinct phases. Data was collected in the first two phases and the findings reviewed and data analyzed in phase three.

  1. Phase I:

    Five interviews conducted with senior IT managers. During Phase I, we approached Biotech to participate in a study that examined the best practices for managing offshore outsourcing. (See Rottman and Lacity 2004 for a full description of this project.) In February of 2004, we interviewed five people from Biotech—the then CIO (since promoted and replaced by a direct report), three IT Leads who report directly to the CIO, and the Head of the Program Management Office (PMO) who managed all offshore outsourcing activities.

     
  2. Phase II:

    Forty interviews conducted and over 2000 documents gathered. In spring of 2005, the Head of the PMO asked us to systematically assess IT employees’ perceptions of offshore outsourcing. He felt that the IT employees would be more honest if they were interviewed by academics and if their identities would not be revealed. He also wanted us to identify the practices that contributed to project outcomes. He said he would allow us access to any people we wanted for interviews. Additionally, he offered us access to all documents pertaining to offshore.

    The authors developed the interview guide (see Appendix) and the interview questions were designed to create a project rating, to investigate potentially important attributes that may contribute to project outcome based on prior research, and to explore new ideas, practices, and experiences with offshore outsourcing.

    The lead author then interviewed 40 Biotech employees (including the new CIO who was appointed in February, 2005) and re-interviewed the Head of the PMO. Participants held various titles including Project Manager, Project Lead, Team Lead, and Architect. All interviews were conducted face-to-face, tape-recorded, and lasted approximately 90 min. Over 1,000 pages of transcription were generated.

    In addition to the interviews, we had access to documents Biotech generated related to their offshore efforts. We examined over 200 statements of work (SOW), over 400 spreadsheets tracking various projects, and all the PMO’s presentations relaying the status of offshore projects. We also examined the PMO’s extensive database of all offshore contractors, invoices, requisitions, timesheets and disbursements. Additionally, individual participants provided project timelines, supplier correspondence, and code samples.

     
  3. Phase III:

    Participant feedback and data analysis. In September 2005, the Head of the PMO and CIO were independently debriefed on the research findings. Despite our criticisms of the PMO office and senior management’s role in implementing offshore, both accepted the report as accurate. Most of their questions centered on “How can we do this better?”

    Using the transcripts of the interviews, internal documents and the feedback of participants, project ratings and project characteristics were analyzed. Besides assessing participants’ views on project outcomes, we assessed which attributes differentiated highly-rated projects from poorly-rated projects. We coded the documents and transcribed interviews into data categories and mapped these categories against the project rating. The data categories were selected based on prior research as well as data categories that emerged from the interviews. We examined the following data categories:
    1. 1.

      Size and number of offshore supplier(s) engaged on the project

       
    2. 2.

      Supplier engagement model used on the project as indicated by the physical location of offshore supplier managers and developers

       
    3. 3.

      Contract value in terms of dollars paid to the supplier on a project

       
    4. 4.

      Project size in terms of duration in number of days

       
    5. 5.

      Organizational unit within IT managing the project

       
    6. 6.

      Project type as either development of new applications or maintenance/support of existing applications

       
    7. 7.

      Year the project was started

       

    These categories and the relationship to project ratings are examined in the project analysis section.

    The next section describes Biotech’s offshore journey. We wrote this case description based on the socially constructed “facts” from the interviews and documents.

     

4 Biotech’s journey offshore

As stated above, Biotech is a Fortune 500 company and a leading provider of biotechnology-based products. According to 10-K (annual) reports, Biotech experienced flat revenues yet increasingly positive net income from 1999 to 2001. According to the CIO, in 2001, senior management was beginning to feel the financial pains of a major litigation, increased competition, and rising costs of inputs. Predicting losses for 2002, senior management sought to cut the budgets of overhead departments. For 2002, the CIO’s IT budget was reduced by 5%. “Doing more with less” became the CIO’s major challenge for 2002.

Senior IT Leads explore offshore outsourcing as a means to reduce IT costs

In spring 2002, the CIO tasked the senior IT Leadership Team, comprised of 12 senior IT managers (called IT Leads), to develop a strategy to cope with the tighter IT budget. One of their proposals was to possibly move some IT work offshore.

The CIO and IT Leads intend to replace domestic contractors with cheaper offshore IT workers

The participants were in agreement pertaining to reasoning behind the projected cost savings. Most of Biotech’s IT workforce resides in the corporate IT department on the headquarters campus. The corporate IT department comprises about 600 people, including 200 domestic contractors. The domestic contractors earn hourly wages of about $65. If domestic contractors were replaced with offshore workers who typically earn $25 per hour, then the CIO and IT Leads reasoned they would save at least $40 per hour. Thus, their number one objective was to reduce IT costs, primarily by replacing some of the domestic contractors with cheaper offshore equivalents. (There was no evidence that the CIO or IT Leads intended to use offshore outsourcing to replace any Biotech IT employees.) According to the CIO:

“One was simply looking at how much work do we give India? And if you make the assumption that we would be doing that work anyway, it’s pretty easy to calculate the cost if you [would] have done it in the US versus doing it in India. It becomes a pretty straightforward calculation.”

The CIO mandates offshore outsourcing

Because offshore outsourcing would likely meet with resistance from the internal IT staff, and to reach what the CIO called “a critical mass of projects and people”, the CIO implemented the strategy as a mandate: New projects would require that at least 15% of the budget be outsourced offshore. In total, the CIO budgeted $6.2 million for offshore outsourcing during 2003 to 2005.

The Head of the PMO and IT Leads select suppliers

The offshore consultant helped the IT Leads and Head of the PMO identify potential suppliers. The IT Leads and PMO Head were interested in engaging suppliers with significant science domain knowledge as well as the willingness to participate in small projects during the start-up stage. Ultimately, Biotech engaged six Indian suppliers. Two suppliers were large, earning more than $1 billion in revenues in 2005. Four suppliers were small, the largest of which earned less than $150 million in 2005.

Biotech launches 21 projects offshore in 2003 to 2005

To kick off the offshore initiative, the CIO and the IT Leads held a town hall meeting for all IT employees. During this meeting, the offshore strategy and the role of the PMO were introduced. IT employees were told that no Biotech employee would lose their job as a consequence of offshore outsourcing.

IT Leads started bringing projects to the PMO in early 2003. The PMO was tasked with coordinating project selection, project management, tactical duties (bringing supplier employees on-site, facilitating system account creation, interfacing with Biotech IT security for login IDs, etc.) and tracking all statements of works (SOWs), invoices, and timesheets. During 2003 and 2004, the PMO and IT Leads met to discuss successes and failures in the offshore initiative and to assess supplier performance. Two small suppliers were identified as poor performers and when the engagements expired, contracts were not renewed.

In all, 14 projects were launched in 2003, six projects in 2004, and one project in 2005. The number of offshore supplier workers peaked in October, 2004 at 68 and as of June, 2005, Biotech engaged 35 offshore workers. As of summer, 2005, a total of $4.1 million dollars had been paid to offshore suppliers.

The official word from the PMO: offshore outsourcing is realizing projected cost savings

During the 2003–2005 timeframe, the PMO was in charge of reporting on the project status of offshore projects. The PMO created monthly and yearly reports on the total costs of offshore outsourcing. Every document reports a total cost savings. For example, the document titled “2004 IT Offshore Accomplishments”, states that as of July 23, 2004, Biotech saved $560,000 with offshore outsourcing. According to the Head of the PMO and the Offshore Project Coordinator, the number is based on multiplying the costs of the offshore hours and comparing this number with what it would have cost had they used domestic contractors. The number does not consider transaction costs, productivity, or quality. Thus, month after month, the PMO documents report that offshore outsourcing is successful in meeting Biotech’s cost savings targets.

The burning question: is offshore outsourcing really worthwhile?

The Head of the PMO questioned whether these cost savings were realistic. During our first interview with him, he said:

“It is clear that we saved money on a per hour basis, there is no way to argue about that, but did [the offshore supplier] do it as fast as we would do it? The other big complaint came from the project managers: ‘Managing offshore projects is really hard….’ If I had to count up how hard this is, then we lost money. That is clearly anecdotal since they don’t keep track of how much they spend on domestic project in terms of project management.”

However, two other IT Leads seemed to think offshore outsourcing, in general, was successful. The first quote by an IT Lead claimed that overall economic benefits were met:

“They all delivered on the date. They all delivered at the economic level we expected. And when I say, pretty much on the dates, we probably had one or two that missed a little bit, but I wouldn’t call those significant.”—IT Lead

The CIO concludes:

“Our offshore experiences have certainly been mixed. I am working with the IT Leads now to do a kind of ‘good, bad and ugly’ analysis to see where we are and what worked and how we can utilize the offshore model. I think that some of the setbacks were due to the suppliers’ shortcomings and some of them were due to how we do business at [Biotech]. We need to understand which were which and go from there.”

Thus, there were different opinions as to whether Biotech actually met their offshore objective to reduce IT costs. To move beyond random anecdotes, the Head of the PMO wanted to capture the opinions of all the IT employees involved in offshore outsourcing. We assessed their opinions at a project level so that we could find attributes to help explain differences in project outcomes. The next sections explain the project outcome indicator we used, the attributes we measured, and the overall project level findings.

5 Participants’ project ratings

Traditionally, practitioners define project success5 as a project being delivered on time, on budget, with promised functionality (Nelson 2005; Standish Group International 2003). At Biotech, there were no formal metrics to uniformly assess project success across the 21 projects, other than to compare offshore expenses with what those hours would have cost if Biotech had used domestic contractors. We created a project indicator of success based on subjective evaluations of the people knowledgeable of the project.

Subjective evaluations are the most common form of IT project evaluation for projects of less than 1-year duration. For example, researchers found that most small and medium-sized IT projects (less than 1 year to complete) are subjectively evaluated by people involved in the project in a technical, business, or managerial capacity (Gudea 2005; Willcocks and Lester 1999). In comparison, they also found that most large projects (more than 1 year to complete) are evaluated using hard numbers such as return on investment, payback period, and net present value (Gudea 2005). This difference in evaluation methods is likely due to the fact that small projects are expensed, whereas large projects typically pass through a capital budgeting process.

We asked the 44 participants: “Considering the degree to which project objectives were met, budgets and schedules were met, and the quality of the delivered product, what letter grade would you assign the project?”

For each specific project discussed by a participant, the participant assigned a standard US letter grade (A, B, C, D, or F). We used the standard US grading system because it is a common frame of reference for the US participants. Based on the interviews, it was clear that all participants could clearly articulate and defend a letter grade.

Among the 21 projects for which participants graded the project outcome, 17 projects had at least two participants independently assign a grade. For four projects, one participant assigned a grade. To calculate the average grade for each project, we converted letter grades reported by participants to numbers. We assigned A = 4, A−/B+ = 3.5, B = 3, B−/C+ = 2.5, C = 2, C−/D+ = 1.5, D = 1, D− = 0.5, and F = 0. In Table 1, we show the 21 projects (labeled A through U), the number of participants that graded the project, the letter grades assigned, the average project rating after converting letters to numbers, and the standard deviation. The overall mean project rating was 1.73 and the median was 1.75 (indicating a grade of between a C and a C−).
Table 1

Participants’ ratings of project outcomes

Project

Number of Participants who assigned a grade

Letter grades assigned by participants

Average project rating using A = 4, A−/B+ = 3.5, B = 3, B−/C+ = 2.5, C = 2, C−,D+ = 1.5, D = 1, D−,F+ = 0.5 and F = 0

Standard deviation of average project rating

A

3

C+, D, F

1.17

1.26

B

1

C−

1.50

n/a

C

3

D+, D, A−

2.00

1.32

D

5

F, F, F, F,F

0.00

0.00

E

3

F, C, B

1.67

1.53

F

4

C, B, B, D

2.25

0.96

G

5

A, A, A, B, B

3.60

0.55

H

4

F, F, F, D

0.25

0.50

I

1

D

1.00

n/a

J

2

B, C−

2.25

1.06

K

2

F, D,

0.50

0.71

L

3

A, A, C

3.33

1.15

M

4

C, D, C−, B

1.88

0.85

N

4

C, F, F, F

0.50

1.00

O

3

B+, B+,B+

3.50

0.00

P

3

B, C+, D+

2.33

0.76

Q

9

D, C, D, D, B, B, F, B, B

1.89

1.17

R

2

C+, D

1.75

1.06

S

1

C−

1.50

n/a

T

1

D

1.00

n/a

U

3

C−, B, B

2.50

0.87

Overall

1.73 (mean)

1.02

1.75 (median)

 

In some instances, participants had a shared view of project outcome as evidenced by the similar grades for a project. For example, all five participants independently graded Project D as an “F.” Project D entailed Database Administration (DBA) support tasks. The project was managed in the US and delivered by Biotech’s captive center in Bangalore. The project deliverables were late and frequently wrong. According to one DBA Team Lead: “The project was bloody awful! I had business users demanding, ‘Don’t send it to Bangalore—they will just screw it up and we will have to redo all the work and it will take five times as long!’”

In other instances, participants had different perceptions of project outcome. Project C provides an example. Project C entailed the visual mapping of DNA to help scientists manage the lineage of traits. Project C was graded by three participants: an IT Team Lead graded the project a D, a Software Architect graded the project a D+, and a Project Lead graded the project an A−. One explanation for the divergent views may be that participants viewed different outputs. The IT Team Lead and Software Architect viewed the project outputs directly from the supplier. They defended their grades as follows:

“[The offshore supplier] would send me code that would not compile! I would have to fix the code, submit it to the code repository and then run it. That is the code that feeds the status: the vendor’s bad code that we fixed.”—Software Architect

In contrast, the Project Lead viewed the outputs only after the IT Team Lead and Software Architect fixed the supplier’s errors. This may explain his higher grade: “I never talked with the supplier’s developers, just the Project Lead for the offshore team…I think it went OK, some issues with code, but in general, I think it went well.—Project Lead

It is quite clear from our interviews that the projects sourced offshore were not as uniformly successful as the official PMO reports. Whereas the PMO reports focused only on the cost part of the services, the participants focused on cost, quality, and speed. The participants’ assessments are much richer and less uniformly enthusiastic than the PMO reports. What was really going on at Biotech? To answer this question, we conducted two levels of analysis. At the organizational level, we found evidence that Biotech’s offshore strategy to simply replace domestic contractors with cheaper, offshore suppliers was a poor fit with Biotech’s social and cultural contexts. At the project level of analysis, we found that different project attributes explained differences in project outcomes.

6 Organizational level analysis: Offshore outsourcing was a poor fit

From the case description section, it is clear that the official word in PMO documents was that offshore outsourcing was meeting Biotech’s objective to reduce IT costs. Based on the project ratings from knowledgeable participants, results were obviously mixed, and generally less positive than the “official word”. This section focuses on the broader contextual issues to explain why offshore sourcing of IT work resulted in mixed results at Biotech.

Initially, the CIO and IT Leads’ strategy was to replace, person-for-person, domestic contractors with offshore IT workers. Three findings suggest why this strategy was a poor fit with Biotech’s social and cultural contexts.

  1. 1.
    Strong social networks between Biotech IT employees and domestic contractors were not easily replicated with offshore suppliers. Although prior research suggests significant differences between contractors and permanent employees (Ang and Slaughter 2001), this was not evident at Biotech. At Biotech, we learned that domestic IT contractors are treated like Biotech IT employees. They are housed in the same types of cubicles with permanent workers, wear the same identification badges, attend the same meetings, and are tightly integrated into project teams. One reason for the lack of distinction is that Biotech often uses domestic contractor positions as a precursor to fulltime positions. Indeed, among the 44 people we interviewed, ten were previously domestic contractors before becoming fulltime Biotech employees. The following quotation describes the close integration of domestic contractors and Biotech employees:

    “Our culture is totally different from a contract resource point of view. I came from some other companies. I was shocked when I came into [Biotech] to see how the contractors were actually integrated into the scene. I mean, I couldn’t tell [who was a contractor and who was a fulltime employee]. Same meetings, you have as many responsibilities as some of the senior managers have here. Some [contractors] have been around sometimes for over a decade. This is a totally different paradigm.”—IT Lead

    In contrast, the Indian offshore IT workers were treated differently. Despite efforts to integrate the offshore workers into the teams, internal Biotech employees never felt a sense of connection with them. According to an IT Team Lead, “We even tried bringing over some people from India for team building, and it worked when they were here, but when they went back, the team aspect fell apart.” In addition to the social disconnection, there were technical barriers as well. Due to security concerns and bandwidth constraints, offshore workers were not allowed to access production data or Biotech’s internal systems such as the code repository. This hampered development and created obstacles for the offshore workers.

     
  2. 2.

    Biotech’s “sneaker-net” culture among business users, IT employees and domestic contractors were not easily replicated with offshore suppliers. At Biotech, we learned that requirements analysis is an informal process. Because IT workers reside on the same campus as business users, Biotech’s IT employees and domestic contractors typically walk over to meet business users to seek or clarify functional requirements. Thus, the process was called “sneaker-net” by some participants. Like the social networks that facilitate knowledge transfer between IT employees and domestic contractors, there are also social networks that facilitate knowledge transfer among IT employees, domestic contractors, and business users. According to the CIO, “Here at [Biotech], we have always worked very closely with our contractors and our business sponsors. Tight collaboration is part of our DNA. That makes this offshoring pretty tough.”

    Furthermore, the CIO said that requirements are not only informally gathered, requirements are also informally documented. He said requirements are typically “documented” on white boards or in personal notebooks. A Web Developer corroborated the CIO’s statement:

    “A lot of times in our environment, the developers will be involved in requirements, meaning taking their own notes and gathering that understanding. And that’s not something that happened with offshore. We had to retranslate what he had on paper and then translate it to them, and it doesn’t work very well. I think in a development environment, it’s important that the developers be part of requirements gathering, so that they can understand what it is and why it is.”

    Biotech’s “sneaker-net” culture did not fit well with offshore. Indian-based IT workers did not have access to users to establish the social networks needed to facilitate knowledge transfer. A Project Manager in R&D said:

    “We had no way to get requirements from the user and get them to the offshore team. We could have easily done this project onshore because we know how to go back and forth with the user, but the offshore team just couldn’t do it.”

    In hindsight, an IT Lead acknowledged that Biotech had not thought through the knowledge transfer process: “We didn’t have anything in place that was really allowing us to transfer the knowledge. There was, like, a huge leak.”

     
  3. 3.
    Biotech’s project management processes and expectations were often incompatible with offshore suppliers. Despite the cultural awareness training, many participants were unprepared for the cultural differences between US IT workers and Indian IT workers. In the US, domestic contractors are trusted to speak up when deadlines slip or when they do not understand requirements or processes. An Application Architect describes the trust he has in his domestic contractor to communicate with him:

    “And I make it clear to my contractors, if you don’t understand something, you’re in my office, every day. I mean, I got one contractor who is reasonable, $54 bucks an hour, really reasonable guy. He basically comes in my cube, probably 15 times a day, and that’s what we have to do. We’ve got a couple other guys that are very similar to him and, basically come in all the time for clarification.”

    In contrast, we heard from many participants that the offshore IT workers could not be relied upon to report that the project was behind schedule or that they did not understand the requirements. The following quotes serve as evidence about not reporting project delays:

    “When the project was going so far off course, they never really told us that they were behind on deadlines. They always said everything was going well.”—Offshore Project Coordinator

    “They didn’t feel like they could tell us if they were going to miss a deadline. This seems to be the modus operandi, dig and dig and spade and spade to get anybody to tell you that things are wrong. Because they just simply won’t. They will tell you it is great.”—Head of the PMO

    One IT Lead summed it up by saying, “The place could be on fire and they would say, ‘Oh it’s great, a little warm, but it is great!”

    During an offshore outsourcing class the second author attended, Biotech’s offshore consultant talked about the cultural challenges at Biotech. According to him, Biotech’s Indian suppliers view time more fluidly than Westerners. He said, “If an Indian IT worker knows how to complete a task even though he knows it will be late, then he would view it as unnecessary to contact the customer. He is the expert and the customer should trust that he is professionally completing the task.”

     

7 Project level analysis: For Biotech, bigger was better

Since the project ratings are numeric, there are several ways to divide the data into categories of “success”. We divided the data into two. We categorized individual projects that rated above the mean project rating of 1.73 as the “more successful projects” and projects that rated below the project mean as the “less successful projects”. Given the sample contains 21 projects, dividing the data into two categories by mean seemed the most reasonable criterion. (We note that the mean and median are nearly identical and selecting the median would not change results.) Our analysis yields seven project level findings.

  1. 1.

    Overall, participants rated projects that engaged one large offshore supplier higher than projects that engaged one small offshore supplier or multiple suppliers. Prior research has found that outsourcing to a single supplier, particularly under circumstances of high asset specificity, is riskier than using multiple suppliers (Aubert et al. 1999; Currie and Willcocks 1998; Gallivan and Oh 1999; Williamson 1991). However, multi-sourcing creates higher transaction costs than outsourcing to a single supplier (Lacity and Willcocks 2001). Prior research has used the client as the unit of analysis (Chaudhury et al. 1995; Cross 1995; Gallivan and Oh 1999). Thus, these studies addressed the question, “Did/Should the client engage more than one supplier?” At the client level, Biotech multi-sourced by engaging six offshore suppliers. But we viewed this research as an opportunity to ask the question at a project level: “Does the number of suppliers on a project matter?”

    In addition to single versus multi-sourcing, we also examined the size of the supplier (large versus small). Practitioners and researchers have found that supplier size affects their capabilities (Levina and Ross 2003; Martorelli et al. 2004) which, we reason, would affect a project’s outcome. On the one hand, large suppliers would likely have better sourcing capabilities, economies of scale, and economies of scope to help them deliver successful projects (Feeny et al. 2005; Levina and Ross 2003). On the other hand, small suppliers may pay more attention to the client because the client represents a larger portion of their revenues (Feeny et al. 2005). We did not conjecture whether large or small suppliers would have higher success rates, but instead viewed this research as an opportunity to investigate the effect of supplier size on project outcome.

    Among the 21 projects, Biotech engaged one small Indian supplier on 12 projects, one large Indian supplier on five projects, and multiple suppliers on three projects. In addition, one project used Biotech’s captive center in Bangalore. When mapping suppliers to project outcomes in Table 2, the two most definitive findings based on this analysis are:
    1. 1.

      Participants rated four out of five projects (80%) that engaged one large supplier above the mean project rating.

       
    2. 2.

      Participants only rated five of the 12 projects (42%) that engaged one small supplier above the mean project rating.

       
    Table 2

    Project rating vs. size and number of offshore suppliers

    Offshore supplier size

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    One large supplier (greater than billion in annual revenues)

    4

    1

    80%

    Multi-sourced

    2

    1

    67%

    One small supplier (less than 50 million annual revenue

    5

    7

    42%

    Captive center

    0

    1

    0%

    The participants provide insights to these findings. According to the participants, a major advantage of the larger suppliers was that they had greater access to experienced IT personnel. An IT Lead with over 25 years with Biotech said:

    “[The small vendors] would take forever to find resources with the skills and levels of experience we were needing. The small vendors did not seem to be able to attract and retain good people. That really hurt our projects—it took longer to ramp up and if there was unplanned turnover—we were dead. The larger vendors seemed to have a much deeper bench and turnover seemed much less of an issue with the larger vendors.”

    One Program Lead expressed dissatisfaction with the smaller suppliers. In his experiences, the smaller suppliers lacked the experience to accurately bid and manage projects. He said:

    “[The small supplier] just didn’t get it. We estimated internally (using offshore rates) that a project we had pegged for offshore should cost about $80,000 and take about six to nine months. The supplier’s bid was $40,000 and they estimated it would take four months. I wanted an accurate estimate of the effort and time it would take more so than just trying to get the lowest dollar I could on the project. So I told the supplier they were significantly off in their bid and asked them to resubmit. The second bid came in at $60,000 with a time frame of six months. By this time, we were already running behind schedule and needing to pursue offshore, so we accepted the bid. The supplier ended up spending an additional six months and we ended up fixing a lot of the code and doing the testing ourselves.”

    Table 2 also shows that participants rated two of the three multi-sourced projects above the mean project rating. Because only three projects were multi-sourced, we must be very cautious in deriving conclusions based on this data. However, the Team Lead SAP provided insight into the efficacy of using multiple suppliers on a project:

    “You have to understand what the supplier wants and what the supplier brings to the table and how your project fits in. For example, [a large supplier] should bring in process expertise and great talent, but they aren’t interested in my $5000 little project. However, small suppliers are often hungry for business and can bring in specific skills.”

     
  2. 2.

    Overall, participants rated projects with some offshore supplier employees onsite higher than projects with all supplier employees offshore. We defined the supplier engagement model as the physical location of offshore supplier managers and developers. Biotech used three supplier engagement models to organize the 21 projects. The cheapest model in terms of hourly wages entailed having all the offshore supplier employees (managers and developers) in India. This model was used on 12 projects. The most expensive model had some offshore supplier managers and developers onsite. This model was used on five projects. The middle model had some offshore developers onsite, but no offshore supplier manager onsite. This model was used on four projects.

    We cross-tabulated the supplier engagement model with project rating. Table 3 shows that participants rated seven of the nine projects (78%) that had some supplier managers and/or developers onsite higher than the mean project rating. In contrast, participants rated four of the twelve projects (33%) that located all the supplier employees offshore higher than the mean project rating.
    Table 3

    Project rating vs. supplier engagement model

    Offshore supplier engagement model

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    Some supplier managers and developers onsite

    4

    1

    80%

    Some supplier developers onsite but no supplier managers onsite

    3

    1

    75%

    No supplier managers or developers onsite

    4

    8

    33%

    According to multiple participants, project managers at Biotech were under extreme pressure to keep projects costs low. Because any offshore supplier employee onsite is paid onshore rates (about $65 per hour versus about $25 per hour offshore), project managers were pressured to keep as much of the supplier headcount offshore as possible. However, some participants said that quality suffered when all of a supplier’s employees were offshore because they did not understand Biotech’s requirements and could not easily communicate with Biotech’s IT staff and business users. Several participants concluded that an onsite engagement manager (OEM) and some onsite developers were needed to better understand and communicate requirements and thus ensure quality. According to a Program Lead:

    “We priced in an OEM to interface between the business sponsors and the two offshore developers. We realized that all project cost savings was lost, but the OEM helped us improve our processes, interviewed and managed the developers and was responsible for status updates.”

    According to the Team Lead HR Services, “Even though the OEM is expensive, they are worth it. They interface between our analysts and the offshore developers and save a lot of time and rework. They help to protect our environment.”

     
  3. 3.

    Overall, participants rated projects with greater-valued contracts higher than projects with lesser-valued contracts. Practitioners have frequently told us that the more strategic a client account, the more attention the supplier will pay to the account. The two most important determinants of a supplier’s perception of a strategic account are current revenues generated from the account and the potential for future revenues generated from the account (Feeny 2006). We wondered: Does value of the contract matter?

    We used actual dollars spent as the indicator of contract value because Biotech closely tracked these figures for each project. Using dollars spent, the contract values ranged between $4,300 and $1,363,098, with a mean contract value of $193,000 and a median contract value of $64,473.

    For this analysis, we cross-tabulated contract value with project rating. Because the mean contract value ($193,000) is substantially different than the median contract value ($64,473), we analyzed both. Tables 5 and 6 show the results.

    Table 4 is based on the mean spend as dividing line between greater and lesser-valued contracts. It shows that participants rated 71% of the greater-valued contracts above the mean project rating, compared to 43% of the lesser-valued contracts. Table 5 is based on the median spend as dividing line between greater and lesser-valued contracts. It shows that participants rated 70% of the greater-valued contracts above the mean project rating, compared to 30% of the lesser-valued contracts. Thus, contract value mattered.
    Table 4

    Project rating vs. contract value using mean

    Contract value

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    Greater-value (greater than 93,000 mean spent)

    5

    2

    71%

    Lesser-value (less than the 93,000 mean spent)

    6

    8

    43%

    Table 5

    Project rating vs. contract value using median

    Contract value

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    Greater-value (greater than $64,473 median spent)

    7

    3

    70%

    Lesser-value (less than the $64,473 median spent)

    3

    7

    30%

    Because contract value only captured the offshore part of the project, we also examined an indicator of overall project size in terms of duration of the project.

     
  4. 4.

    Overall, participants rated longer projects higher than shorter projects. For over 25 years, IT researchers have recognized the relationship between project size, risk, and outcome (Gopal et al. 2003; Keil et al. 2003; Keil and Montealegre 2000; McFarlan 1981; Wallace et al. 2004). In general, prior research has found that longer projects are riskier and have lower success rates than shorter projects (Jones 1994). For example, Carroll (2005) found that shorter projects (less than six months) had a success rate of 50%, medium-length projects (six to nine months) had a 40% success rate, and none of the projects in the sample (n = 22) over nine months were successful. Aladwani (2002) in a study of 42 IT projects found that project duration negatively affects project planning, which negatively impacts project success. Practitioners and researchers suggest that large projects should be transformed into smaller projects through phased functionality, prototyping, or pilot testing to reduce risk and increase success (Jones 1994; Standish Group International 2003; Willcocks et al. 1997).

    We were able to use duration of the project in days because Biotech’s PMO closely tracked this number. (Biotech did not track total costs of the project, only the costs directly invoiced by the offshore suppliers.) Using duration, the project sizes ranged from 11 days long to 1,030 days long. The average project was 350 days long and the median project was 272 days long.

    For this analysis, we cross-tabulated project duration with project rating. We initially used three rules to categorize projects as “longer” versus “shorter.” The rules were (1) Gudea’s (2005) cut-off of over/under 1 year in duration, (2) over/under the mean duration of 350 days, and (3) over/under the median duration of 272 days. However, rules (1) and (2) are coincidentally equivalent with our data. Tables 6 and 7 show the results.
    Table 6

    Project rating vs. project duration (mean)

    Project duration

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    Longer (more than 1-year)

    5

    3

    63%

    Shorter (less than 1-year)

    6

    7

    46%

    Table 7

    Project rating vs. project duration (median)

    Project duration

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    Longer (longer than 272 days)

    7

    3

    70%

    Shorter (Less than 272 days)

    3

    7

    30%

    Table 6 is based on the mean and 1-year cut-off as the dividing line between longer and shorter projects. It shows that participants rated 63% of the longer projects above the mean project rating, compared to 46% of the shorter projects. Table 7 is based on the median duration as dividing line between longer and shorter projects. It shows that participants rated 70% of the longer projects above the mean project rating, compared to 30% of the shorter projects.

    Some of the participants claimed that shorter projects could not meet financial objectives because the transaction costs of dealing with the offshore suppliers swallowed the projected cost savings. Below are some of the quotes supporting this interpretation:

    “On the smaller projects, the overhead costs of documenting some of the projects exceeded the value of the deliverables.”—IT Lead

    “A lot of our projects were too small. We had one, maybe one and a half, resources working offshore and the overhead was killing us trying to keep track of what was going on offshore.”—Program Lead

    Conversely, one IT Team Lead explained that longer projects allowed Biotech to recover overhead by benefiting from mounting experience:

    “The larger projects I did seemed to work a little better. It took quite some time to figure things out, and with the smaller projects, they would end at that point. With the larger ones, we could use the learning and relationships we built for longer periods of time and improve as we went along.”

     
  5. 5.

    Overall, some organizational units had higher participant-rated projects than other organizational units. During the interviews, it became apparent that some groups seemed to be experiencing more success with offshore outsourcing than others.

    Participants from five of the six units that report directly to the CIO managed at least one offshore project. Table 8 cross-tabulates these five units against project rating. Projects managed by the Web and ERP units all scored above the mean project rating. The most interesting finding, however, is that the R&D unit did the most offshore projects, yet participants rated only 30% of projects above the mean project rating.
    Table 8

    Project rating vs. organizational unit

    Organizational unit within Biotech

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    Web

    3

    0

    100%

    ERP

    2

    0

    100%

    Marketing

    3

    2

    60%

    R&D

    3

    7

    30%

    Enterprise architecture

    0

    1

    0%

    The level of domain specific knowledge required by these different units may explain the results. Some participants noted that projects within the R&D area required the supplier to have very specific scientific knowledge, whereas the Web and ERP units required more common knowledge. According to an IT Lead in the R&D area:

    “What makes some of this [offshore outsourcing] hard is that we are making up the questions at the same time we are asking the supplier to come up with answers. We are inventing new products with highly scientific processes and foundations. In our area, we are really ‘out there’ in regards to the kinds of things we are creating.”

    Conversely, all of the projects in the less scientifically-intense areas of Web and ERP were rated above the mean. A Team Lead SAP explained:

    “A lot of what we do in our area is more generic than in the [R&D] area. The bulk of our work is change requests to our SAP systems. The suppliers are well equipped in the SAP tools like ABAP. Once we accurately explain the specifications and modifications needed to fulfill the change request, the ABAP part is fairly straight forward.”

     
  6. 6.

    Contrary to expectations, participants rated both development and maintenance/support projects equally. Prior IT outsourcing research has examined the types of IT work that clients outsource (Ang and Straub 1998; Grover et al. 1996): applications development and maintenance, systems operations, telecommunications, end user support, and systems planning and management. In a survey of 188 IT executives, Grover et al. (1996) found that type of IT work affected outcomes. Specifically, outsourcing of systems operations and telecommunications led to increased client satisfaction. They also found that outsourcing applications development and maintenance, end user support, and systems management did not lead to increased client satisfaction. Poppo and Zenger (1998) hypothesized a negative relationship between technological uncertainty and outsourcing satisfaction based on transaction cost economics (TCE). Based on all this research, we conjectured that the new software development projects would entail more uncertainty, and would thus contribute to lower project ratings, as predicted by TCE (Williamson 1991).

    For this analysis, we cross-tabulated project type with project rating (See Table 9). Based on prior research, we speculated that new development projects would have more risk and thus lower project ratings than projects involving maintenance or support of existing systems. However, evidence did not support this speculation. Overall, participants rated both development (53%) and maintenance/support (50%) above the mean project rating nearly equally. According to an interview with a Software Architect, it was evident that the type of project did not matter because all the work was new to the suppliers. He said:

    “It really didn’t matter the types of work we gave to the supplier. Even for what we considered to be routine, like maintenance, they had to learn the system, the tools and how we worked. Even though it was old to us, it was like new development to the supplier. For example, we have a Lotus Notes database to maintain, it was very difficulty to find Notes experts. They had to learn the system from scratch.”

    Table 9

    Project rating vs. project type

    Project type

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    New software development

    8

    7

    53%

    Support and or maintenance of existing software

    3

    3

    50%

     
  7. 7.

    Overall, participants rated recent projects higher than older projects. Based on prior research, we thought that earlier projects would have lower ratings than later projects. For example, researchers (Lacity and Willcocks 1998) found that more recent contracts had higher frequencies of success than older contracts. They attributed this finding to learning curve effects. Three research studies on offshore outsourcing also found learning curve effects (Carmel and Agarwal 2002; Kaiser and Hawk 2004; Rottman and Lacity 2006). All three studies found that clients use offshore outsourcing more strategically over time.

    For this analysis, we compared the project ratings for earlier projects that were launched in 2003 against projects that were launched after 2003. Table 10 shows that participants rated 43% of the earlier projects above the mean project rating, compared to 71% of the later projects, indicating that organizational learning did occur.
    Table 10

    Project ratings vs. project start year

    Project start year

    Project rating

    Number of more successful projects

    Number of less successful projects

    Percentage of more successful projects

    During 2003

    6

    8

    43%

    During 2004 or 2005

    5

    2

    71%

    Several participants stated that as projects and engagements matured, the quality of the deliverables improved.

    Thus far, we have explained Biotech’s experiences with offshore outsourcing at the organizational and project levels. The next section points to learning from Biotech that may be valuable to other practitioners.

     

8 Four insights for clients and suppliers

  1. 1.

    An offshore strategy must either fit with the client’s norms and practices, or the client may have to change norms and practices to achieve offshore success. Offshore suppliers often rely heavily on Capability Maturity Model (CMM) or Capability Maturity Model Integrated (CMMI) processes to ensure that business requirements are properly documented (Adler et al. 2005) However, if their clients are operating at CMM/CMMI levels of two or below, the relationship may struggle with the issues experienced at Biotech. Suppliers may have to help clients improve their CMM/CMMI processes, or be flexible by finding ways to fit into the client’s requirements analysis processes.

    At Biotech, the “sneaker-net” culture and close social networks between business users, IT employees, and domestic contractors were a poor fit with offshore outsourcing. Within some project teams, Biotech participants changed the practices. Some Biotech project managers abandoned the “sneaker-net” process in favor of formal documentation of business, technical, and procedural requirements. Participants pursuing this option generally agreed that it facilitated knowledge transfer. According to a Technical Architect:

    “They [the offshore supplier] improved our internal processes. They all have been documenting procedures and processes. Now, we’ve got it so proceduralized that we’ve anticipated 90% of the questions.”

    But participants also complained that it significantly increased their project overhead. As previously noted, one IT Lead said: “On the smaller projects, the overhead costs of documenting some of the projects exceeded the value of the deliverables.”

     
  2. 2.
    Clients and suppliers should invest in social capital to facilitate knowledge transfer. Although the first insight indicates the importance of process, a corollary to that insight is that the people who perform the processes matter. Nahapiet and Ghosal (1998) argue that social capital (such as social networks) helps to create intellectual capital (such as understanding user requirements). They also posit that organizations have an advantage over markets in creating and sharing intellectual capital. Researchers have begun to apply social capital theory to the IT outsourcing context, concluding that this perspective richly enhances our view of outsourcing (Chou et al. 2006; George 2006; Miranda and Kavan 2005; Rottman 2007) Thus, maybe domestic contractors at Biotech performed better than offshore IT workers because domestic contractors are essentially insiders. We have one anecdote that suggests that offshore IT workers can essentially become “insiders” over time. A quote from an Indian Project Lead who has been a fulltime Biotech employee for 4 years sums up the need for a greater understanding of the social networks in knowledge transfer:

    “Communication was a real issue-even for me and I am from Mumbai. I found it hard during the conference calls to understand what they were saying, especially during the interviews and code reviews. And when we would send emails back and forth, I thought, ‘What are they trying to say, I don’t understand where they are coming from.’ It would take two or three extra emails, just to make sure we were talking about the same things.”

    One good way to build social capital is to let the project team members meet face-to-face. It is much easier to switch to lower cost media such as teleconferences and email after meeting people face-to-face. Some project managers at Biotech bore the cost of bringing the Indian developers onshore to meet Biotech employees face-to-face: “Once you get good at specking out what you need face-to-face, then an awful lot of the work happens by e-mail and it’s just follow up questions and lots of that happens by e-mail.”—Global Leadership Team member

    The downside of course, is the increased expense associated with face-to-face meetings. We do note, however, that one IT Team Lead stated that meeting face-to-face solidified the team at first, but that “the team aspect fell apart” after the Indian workers returned to India. This suggests that social capital requires an ongoing investment to sustain benefits.

    One of the best mechanisms for building sustainable social capital is to invest in onsite engagement managers. Biotech experienced significant challenges in transferring knowledge to the suppliers. The best solution to this challenge was to keep some supplier managers and developers onsite to build social networks. Unlike the “face-to-face” meetings suggested above, onsite engagement managers entail a long-term investment in social capital. Among the 21 projects, Biotech brought offshore supplier employees onsite for nine projects, of which seven scored above the mean project rating. Again, the benefit of this practice is that it facilitates knowledge transfer from user to offshore IT worker. Participants said it was worth the extra cost. The drawback of this practice is that it also increases costs.

    Offshore suppliers must also protect knowledge after it is transferred. Because of increasing employee turnover rates (McCue 2005; Srivastava 2005), Indian suppliers in particular must have good knowledge management processes. Some participants at Biotech said that supplier turnover was a problem because when supplier employees left, they took the hard-earned, client-specific knowledge with them. An IT Lead said:

    “And the other thing, too, is their turnover rates. So those five-year guys on the offshore team, they’re already looking to move. They’re looking to move to a technical lead or architect or programming. And the opportunity is there. So, personally for them, it’s a great opportunity, they could move at five years. And, so we can’t even keep them on the offshore team.”

    Suppliers must find innovative ways to capture tacit knowledge by using, for example, video repositories, interactive training modules, mentoring and shadowing to groom replacements (Rottman 2006).

     
  3. 3.

    Clients and suppliers may achieve greater success with bigger commitments. At Biotech, we found that the larger projects in terms of number of days and contract value had higher frequencies of success. We believe that this finding is attributable to (1) transaction costs and (2) supplier attention. Concerning transaction costs, offshore outsourcing has higher transaction costs associated with coordination, management, communication, and travel compared with insourcing or domestic outsourcing. In order to achieve total cost savings, the volume of work has to be large enough to compensate for the additional transaction costs. Of course, large commitments to offshore suppliers must be made cautiously, but the lesson may be that client managers should not expect significant cost savings while they are still conducting pilot projects and getting to know their offshore suppliers. It is only after progressing along the learning curve that service can be improved in terms of cost savings, quality, and speed.

    Concerning supplier attention, it is no surprise that suppliers are motivated to allocate their top resources to their most prestigious clients. Prestigious clients commit large volumes of work over a long period time. Thus, the larger-sized projects and contracts at Biotech may have commanded more attention from their suppliers than smaller-sized projects and contracts.

     
  4. 4.
    Clients need robust measures and independent audits to manage and assess offshore outsourcing programs. Biotech’s simple formula for calculating cost savings (cost of hours offshore versus what the hours would have cost onshore) disseminated the message that offshore outsourcing was successful. Metrics that capture productivity, quality, process improvement, supplier compatibility, and organizational learning are needed to carefully manage offshore outsourcing. Furthermore, CIOs are advised to occasionally engage an independent third party to assess the effectiveness of offshore strategy. We found that lower level IT employees were less likely to honestly report on sourcing issues. Our favorite quote comes from a Biotech informant was:

    “You didn’t want to tell them [senior management] the bad news too much. Because, this was their baby and you didn’t want to say, “You have a terribly ugly baby!”—Software Architect, biotechnology company

    While a CIO’s strong commitment to success is a key enabler, the commitment cannot come at the price of lost learning. Independent assessments of an offshore initiative will more objectively gather learning across projects without compromising the IT staff’s confidentiality.

     
Footnotes
1

Offshore outsourcing is different than “offshoring”. “Offshoring” occurs when an organization moves work from one location to another location on a different continent.

 
2

We define “domestic outsourcing” as outsourcing to a supplier located in the same country as the client.

 
3

Besides these rational reasons, some studies find personal agendas dominating large-scale outsourcing decisions (Hall and Liedtka 2005; Lacity and Hirschheim 1993).

 
4

Hirschheim, Heinzl & Dibbern (eds.) (2008) Information systems outsourcing, Springer Verlag, Berlin.

 
5

Academics frequently use system use, system adoption, and system diffusion as indicators of success (Jeyaraj et al. 2006), but these measures are more appropriate to assess from users (Nelson 2005).

 

Copyright information

© Springer Science+Business Media, LLC 2007