Application 2 – Annotated Bibliography

Ariskprofileofoffshore-outsourceddevelopmentprojects.pdf

Home >Information Systems homework help >Application 2 – Annotated Bibliography

Y CHARALAMBOS L . IACOVOU AND ROBBIE NAKATSU

A RISK PROFILE OF OFFSHORE-OUTSOURCED DEVELOPMENT PROJECTS

Even the bedt project management dkilld will not guarantee duccedd in the complex world of offd ho re outdourcing.

As part of a development initiative, Life Time Fitness, a U.S.-based health club chain, outsourced the implementation of a software application to an Indian information technology (IT) services vendor. The application was a decision support system to eval- uate prospective gym locations. The company's decision to pursue offshore outsourc- ing for its development was motivated by the opportunity to tap into low-cost, well-trained IT talent.

Life Time Fitness pursued this initiative with fervor. The vendor was evaluated carefully and the project was planned in detail, but despite these efforts the devel- opment initiative ran into problems. The quality of the early deliverables was poor due to inadequate knowledge transfer

between the U.S. resources and the Indian professionals. Moreover, miscommunica- tion between the two groups compounded the project troubles, resulting in delays and overspending. The woes continued to escalate until Life Time Fitness terminated the contract and brought the system back

COMMUNICATIONS OF THE ACM June 2008/Vol. 51. No. 6 8 9

in-house for its own programmers to rework [10].

While this story is troubling, it is not atyp- ical in the offshore out- sourcing of software development [1]. Unless an organization is well- equipped to deal with the challenges of off- shore outsourcing, its projects are bound to go awry. Indeed, a survey reveals that eight out every 10 businesses that have entrusted applica- tion development to an offshore vendor have experienced major problems due to inade- quate preparation and ineffectual manage- ment [3]. Still, given the significant eco- nomic benefits that

Original set of requirements is miscommunicated

Failure to manage end user expectations

Lack of business know-how by offshore team

Failure to consider all costs

Low visibility of project process

High turnover of vendor employees

Lack of continuous, face-to-face Interactions across team members

Negative impact on employee morale

Differences in development methodology/processes

Negative impact on image of client organization

* The following rating scale was used to assign importance by the experts: IO=very important: 7=important: 4=slightly important; and I =unimportant.

Table i. Rankings of risk factors.

and importance.

stantly seeking ways to increase the success record of their development efforts. To assist such managers, we conducted a study of the risk factors of offshore-outsourced development. These fac- tors refer to conditions that can present a serious threat to the successful completion of a project if left unmanaged [9]. Given the evidence linking proj- ect risk factors to out- comes [11], we believe that a clear identification of the risk profile of such projects will help managers steer their projects to successfiil completion [1].

While prior studies have examined the risks of software development [9], such investigations did not

specifically consider the offshore outsourcing context. Rather, these studies focused on in-house and domesti- cally outsourced initiatives. Due to the increased com- plexity and the distinctive managerial challenges that exist in offshore outsourcing environments [1, 2, 4, 6],

5.2

KyllfeuflEDfiWteftfi) (toEDDH&SSf) 6in3feR^)p 331(5338 tesS': :':ft,' • ! v l i l : t e i ' * « S

companies can poten- tially reap, it is not at all surprising that offshore outsourcing is growing in size According to Forrester Research, 65% of American we expected that the risk profile of oflFshore projects and European enterprises (with 1,000 or more would be somewhat different from that of non-off- employees) currently use offshore providers for appli- shore ones. Thus, our goal was to produce a set of proj- cation development; another 13% plan to begin ect risks that specifically applies to offshore outsourcing doing so in the next year. Two years ago, only 45% by building upon the earlier research.

To identify the risk factors, we sought the input of the individuals that companies recruit to manage off- shore projects: experienced senior project managers and directors. To identify such experts, we contacted certified project management professionals (PMP),

W who are senior IT executives and members of thehile problems can develop in both in-house Project Management Institute (PMI). We asked these managers to complete a form summarizing their experience. After screening the qualifications of 57 such individuals, we selected 15 of them to partici-

of such organizations utilized offshore vendors to develop applications [7]. Given this trend, there is a clear need to better understand how to manage off- shore projects more effectively.

hile problems can develop in both in-house and domestically outsourced projects, offshore-out- sourced projects are especially prone to failure. This is a significant concern for IT managers who are con-

As a recent A C M report suggests, outdourcing "magnified exidting ridkd and created new threatd." Tnus, oFfshoring clients will be well advised to spend the resources needed to assess the increased exposure

to risk and its sources, and to identify w âys to mitigate it.

9 0 June 2008/Vol. 51, No. 6 COMMUNICATIONS OF I H E ACM

pate in our study. Each of the selected executives had managed multiple ofFshore projects in the past; in total, the panelists had managed 135 such projects. On average, each panelist had over 17 years of IT-related experience and over 15 years of project manage- ment experience, and had man- aged 51 projects, nine of which were offshore development ones. This level of expertise suggests that the selected panel was well- qualified for the task.

To solicit the input of these experts, we utilized the Delphi survey method. A brief descrip- tion of how their input was col- lected and analyzed is provided in the sidebar "How the Study was Conducted." Table 1 summarizes the risk factors as identified and rated by the experts.

The results of our study repre- sent a set of conventional risk fac- tors that have been previously identified by well-cited research [5, 9, 11], as well as threats that are more distinctive to offshoring. On average, the risks that relate to long-established factors (risks 1, 2, 4, 6-10, 12, 13 and 16) have been ranked higher than the factors that are relatively unique to offshoring (risks 3, 5, 11, 19-21 and 23-25). This suggests that, for the most part, offshore initiatives experi- ence the same fiindamentai issues that affect non-offshore

ones.

Lack of top management commitment Without meaningful top management support and commitment, projects face challenges that can lead to political batdes, delays and even rejection. Top management support is essential in securing the needed resources and cooperation across organizational groups, and for enhancing the legitimacy ofthe project

j Original set of requirements is nniscommunicated 1̂ Ensuring that the developers and the end users have a consistent understanding of the requirements can be a ll challenge in offshore development because of the reduced ^ce-to-face, informal communications between J these two groups. No matter how specific the requirements report is, there is often a window for assumptions ll to be made. This is especially true in development situations that are based on long-distance collaborations.

Language barriers in project communications Language differences make project communications difficult and can iead to delays and conflicts. Even when all parties speak English, there may be misunderstandings because much of our language is based on cultural assumptions. Also, slang terminology and accents can create problems and may slow down communications. Conducting reviews over the phone can be problematic (due to the linguistic differences among team members). Frequent give-and-take may be needed to reach understanding. Overall, it takes more time and effort to communicate effectively in offshore projects.

I Inadequate user involvement I Effective user involvement is a critical success factor in any project. However, many offshore projects are |i stewarded by IS groups without significant participation by users. This can lead to conflicts, delays and other Ij problems. Participation helps educate users about the risks and challenges of software development

Lack of offshore project management know-how by client Offehoring is new to many companies. Many of them don't have the in-house expertise that is needed to adequately monitor offshore work and to incorporate effectively the new technology into their existing portfolios. In addition to traditional project management factors, offshore development requires effective management of several specialized issues. For example, the need to delineate responsibilities across the duplicate project management structure is not always fully understood. The lack of project management know-how can lead to cost and time overruns.

Failure to manage end user expectations Expectations must be managed to ensure that the project deliverables will be consistent with the perceptions of the users. This is a difficult task in all projects, but it is especially challenging in offshore situations because the users are not in direct contact with the developers. If expectations are not managed properly, the software may not be accepted by the end users.

Poor change controls Changes to the initial set of requirements can cause delays, overruns, and other problems if they are not managed properly. Even when changes are documented and justified properly, there may be delays due to the exchange of questions and answers that must take place before the change is understood. Also, remote offshore resources may not obtain the sense of urgency for the changes without extended effort If scope modifications are not managed well, they can resuit in overruns and hostile situations, especially in fixed price or penalty contracts.

I Lack of business know-how by offshore team Frequently, overseas resources do not have an intimate understanding of the client's business context and don't get sufficient training on i t Lack of business know-how and lack of access to key business contacts

I (to get things done) can cause delays. Choosing a vendor (with good technical skills) without regard to I domain expertise can lead to trouble. Domain understanding is critical in of^hore projects as normal I workflow in one country may be inappropriate (even illegal) in another.

Lack of required technical i<now-how by offshore team Ensuring that the development team consists of quality resources can be a challenge. Sometimes the skills and knowledge of ofkhore resources are misrepresented by vendor management In other situations, the level of technical sophistication in a country is lower than that of the USA, limiting the pool of expert resources. Moreover, good vendor resources may be overcommitted. Even though some vendors are "process capability" certified, their depth of expertise could be limited.

Faiiure to consider all costs Typically, firms do not consider all the costs associated with offshore outsourcing. Many hidden costs can

I exist in such arrangements. For example, travel expenses for moving and hosting development resources I on-site in the U.S are often underestimated. Costs associated with delays and rework due to miscommunication also tend to be ignored. Finally, costs associated witfi the "duplicate" project team structure (for having a manager onshore and another offshore) are often overlooked.

Table 2. Top risk factors.

However, as the panelists' ratings and insights reveal, these tradi- tional risks are likely to pose more severe threats in the offshoring context due to the complexity and the specific challenges that are inherent in multina- tional, distance-based working teams. While the nov- elty of some of the risks could be questioned, their importance to effective project management should not be discounted. As a recent ACM report suggests, outsourcing "magnifies existing risks and creates new threats" [2]. Thus, offshoring clients will be well advised to spend the resources needed to assess the increased exposure to risk and its sources, and to iden- tify ways to mitigate it [2].

IMPORTANT RISK FACTORS IN OFFSHORE PROJECTS While we recognize the significance of all identified risks, we concentrate our discussion on the top 10 factors as described and ranked by the experts in our panel (see Table 2). These 10 were rated as "very important" or "important" by the expert panel in its final evaluation. Given the significant level of con- sensus among the experts, we believe that this list represents the most notable set of risks salient to off- shore projects.

As the findings indicate, the risks focus on three major areas of concern: the communication between the client and the vendor, the clients internal man-

COMMUNICATIONS OF THE ACM June 2008/Vol. 51, No. 6 9 1

"You w îll get exactly what you asked for, so you better make sure you are askuig For exactly the right thing."

agement of the project, and the vendors capabilities. The identified risk factors for each of these areas are discussed next. Our discussion focuses on insights by the panelists that highlight the factors' significance to offshoring.

Client-vendor communications. The panel was of the opinion that most offshore projects are suscepti- ble to miscommunications that can complicate the transmission of the original set of requirements and subsequent information exchanges and change requests. These concerns were expressed in three related risk factors.

Miscommunication of the original set of require- ments (factor #2) was identified as a major risk because, as a panelist pointed out:

"Language, environmental, and other factors play a huge part in how people read and understand things. No matter how specific the requirements, there is often a window for assumptions to be made. This is especially dangerous when you are talking about long- distance collaborations."

Nonetheless, according to the panel, getting the requirements straight is essential because "with less opportunity for interaction with development resources oiTshore, a much higher premium is put on the quality of the requirements." Another expert identified a related danger associated with the highly structured processes that are instituted by many ven- dors: "you will get exactly what you asked for, so you better make sure you are asking for exactly the right thing."

language barriers in project communications (#3) also received extensive attention by the experts. This is not surprising given the language and cultural differences that exist in multinational teams and the difficulties of remote collaboration [6]. As an expert pointed out, such challenges exist even when all proj- ect members speak the same language: "even when both parties speak English, there is a major chance for misunderstanding because much of our language is based on cultural assumptions." Due to these differ- ences, even simple information exchanges during the

project execution can become lengthy and complex as "frequent give and take" is needed before the parties understand each other.

The final communications-related risk was poor change controls (#7). Ineffective controls can lead to scope creep, a recognized threat that affects all types of projects. However, the experts suggested that this risk takes on a more prominent role in offshoring because of the communications issues identified above. Moreover, physical distance (and the lack of informal interactions between developers and users) is likely to affect the handling of change requests as "off- shore destinations, being remote and distant, do not have the same sense of urgency as the client organiza- tion about the need for changes."

Client's internal management issues. Three tradi- tional client-related risk factors (lack of top manage- ment commitment, inadequate user involvement, and difficulty in managing end-user expectations) were deemed important by the experts. In addition, they identified two other risks rooted in the newness of the offshoring phenomenon: the lack of relevant project-management know-how, and the inability to fully consider all relevant costs.

Consistent- with prior research [9], lack of top management commitment was ranked as the #1 risk. Several panelists noted that for all types of IT projects, offshore-outsourced or not, senior management sup- port is essential. As a panelist wrote, "this issue is not unique to offshore projects, but is rather a generic project issue faced by all projects regardless of the location ofthe different management and staff."

Inadequate user involvement (#4) was also identi- fied as a critical threat. Several panelists noted that many offshore projects are frequently directed by IS groups with inadequate user participation. Given the significance of such involvement and its positive impact on system acceptance and usage [9], it is imperative to meaningfully engage users in the proj- ect. As a panelist pointed out, involvement is also important because of its political value.

"Most offshore projects are stewarded by IT groups on behalf of the users. If you think your IS depart- ment is far removed from the development work, you

9 2 June 2008/Vol. S I. No. 6 COMMUNICATIONS OF THE ACM

will probably find that your user (who is paying for the software) is even farther removed. If there is a ven- dor problem, then it is much better that the user sees the vendor messing up, so rhat the IT group does not end up with the entire blame for the failure."

Lack of offshore project management know-bow by the client (#5) was identified as a significant threat because, as a panelist observed, "ofTshoring is new to many companies, and their lack of experience in deal- ing witb outsourced vendors introduces risks in most areas of tbe project operation." Another expert pointed out tbat such a lack of experience makes clients vulnerable because "tbe vendor tends to 'run tbe sbow' and the project becomes a case of tbe 'tail wagging tbe dog'." Many experrs indicated that spe- cialized project management know-bow is needed to deal with tbe unique cballenges of offshore projects. One sucb challenge relates to tbe duplicate manage- ment structure (tbe offsbore team and tbe client orga- nization) tbat is typically found in offshore projects: "splitting management causes confusion at tbe project level tbrougb difficulties in scbeduling resources and tasks, determining overall project direction, and adds anotber full communications layer." Overall, tbe pan- elists warned tbat clients who are inexperienced or ill-equipped to manage remote collaborative environ- ments are likely to experience major project problems.

Managing end-user expectations (#6) was identi- fied as a major project risk as well. As a panelist indi- cated tbis is "always in tbe top risks for any project. It does not matter if ir is offsbore. Managing end-user expectations is one of tbe largest and most difBcult jobs a project manager is tasked witb." Given tbe dis- tance and communication issues tbat exist in ofFsbore environments, understanding, influencing, and meet- ing sucb expectations can be particularly difficult.

Failure to consider all costs (#10) rounds out our discussion on client-focused risk factors. Participants stated tbat in offsboring, several communication- related, overbead, and intangible costs are likely to get overlooked because of tbe newness of tbe offsbore pbenomenon. One panelist relayed tbe following example: "tbe offsbore resources bad to come to tbe states to be trained for several weeks. Tbe cost of air- fare, lodging, and food as well as time lost getting tbe individuals to our local sites, were bigber tban expected and continued longer tban expected." Anotber spoke about tbe frequently unanticipated cost of longer working bours due to time differences: "Tbe client project manager should be willing to work longer bours—in addition to doing bis or ber normal work during tbe day time at tbe office, be or sbe is also expected to bandle calls and questions from tbe out- sourced company at odd bours."

HOW THE STUDY WAS CONDUCTED This study utilized a three-round Delphi survey to solicit and analyze

the input ofthe expert panelists. The Delphi method allowed us to

elicit their input through an iterative, controlled feedback process. To

execute the study, we followed the methodology prescribed by Schmidt

[8] that aims to achieve consensus among the experts and provides a

statistical analysis for assessing the level of such consensus.

In the first round, we asked the experts to identify the most impor-

tant risk factors that could influence the outcome of an offshore-out-

sourced application development project. The experts were asked to

describe at least six such risk factors. The goal of this round was to dis-

cover the possible set of all relevant risk factors. To allow the experts to

consider prior work on risk factors (which refer to non-offshore devel-

opment situations), we provided them with a list ofthe top 18 risk fac-

tors identified by a well-cited study [9]. After reviewing the experts'

input, we consolidated it into 25 unique risk factors. This consolidation

process was conducted independently by the two researchers. Any dis-

crepancies, between them were resolved through discussion and by

consensus. The generated list was validated by the experts in round

two.

In the second round ofthe study, we presented the 25 identified

risk factors and asked the experts to confirm that they were consistent

with their initial input. We also asked them to rate each risk factor

according to its importance to the successful completion ofthe project.

After receiving their input, we calculated the average importance rating

for each risk factor.

In the third and final round, for each risk factor, we provided the

experts with their own rating from round two along with the average

rating ofthe panel. We asked them to consider the input of their peers

and revise their importance ratings if necessary. We also asked them to

rate the effectiveness ofthe Delphi process as a way for them to

express their opinions.

An analysis ofthe ratings indicated that the level of consensus in

the opinions ofthe experts increased significantly between rounds two

and three. The average standard deviation between the two rounds

decreased from 2.1 to 1.5. More importantly, statistical analysis (using

Kendall's Coefficient of Concordance) suggested that the level of con-

sensus at the conclusion ofthe study was moderate-to-strong (W=o.53)

and was statistically significant (p<o.ooi). The experts' rating scores

overwhelmingly indicated that the Delphi process was an effective way

for them to provide their input.

Vendor capabilities. Tbe last two factors—a lack of business know-bow (#8) and a lack of tecbnical know- bow (#9) by tbe offsbore team—relate to tbe qualifi- cations of tbe cbosen vendor. Witb respect to business know-bow, tbe panel observed tbat an uninformed vendor is more likely to miss things or develop deliv- erables tbat need rework. As a panelist noted, "tecbni- cal decisions are made daily by tbe offsbore teams we manage. Tbeir incomplete understanding of business

COMMUNICATIONS OF THE ACM June 2008/Vol. 5 I. No. 6 9 3

Unless organizations recognize the unique challenges associated with remote management in offshoring and provide appropriate training to their project managers, their uiduitwed

are likely to face increased leveld of failure ridk.

needs almost always results in a high number of flawed technical decisions rhat must be revisited and correcred at later stages." Thus, it may be useful to work with a vendor familiar with the native business context of the client. This may be especially valuable when the project requirements are not well structured and design decisions will need to be made during the project execution.

With respect to technical know-how, most pan- elists acknowledged that offshore vendors are more often than not adept in software development work. But the experts also indicated that without easy access to the assigned resources and a clear visibility of their working patterns, assessing vendor capabilities can be tricky. For example, one panelist warned that "any large ofFshore outsourcer will likely have a claim of a high CMMI [Capability Maturity Model Integra- tion] level. However, this is not fully indicative of the process maturity of the actual team that will be work- ing on the project." Another cautioned that "the available skills and knowledge are sometimes misrep- resented by ofFshore management or are not available when needed on the project schedule." While a pre- contract evaluation can help, the experts commented that assessing a vendors technical capabilities can be difFicult due to the "black box" nature of the ofFshore team.

CONCLUSION Offshore projects are by rheir very nature risky undertakings. As the study findings reveal, such projects face a combination of traditional project risks as well as a set of threats that are fairly unique to the offshore environment. Unquestionably, fun- damental project management skills are essential in guiding such projects. However, such skills alone are likely to be insufficient in directing offshore initia- tives effectively. Unless organizations recognize the unique challenges associated with remote manage- ment in offshoring and provide appropriate training to their project managers, their initiatives are likely to face increased levels of failure risk.

Because our fmdings represent the input of a panel of experts with extensive ofFshore outsourcing experi- ence, we believe these findings are broadly applicable across diverse project types and business contexts.

Nevertheless, we recognize that individuals in charge of ofFshore projects may sometimes Face unique orga- nizational settings (such as a heightened sensitivity to PR issues surrounding oFFshoring, or a lack oF needed resources). Such distinctive circumstances will require the development oF a customized risk profile For the project, that may differ from the one presented here. We hope that the set of the risk factors and the insights that were generated by the expert panel will provide a useful starting point for such managers. D

R E F E R E N C E S 1. Aron, R. and Singh, J.V. Getting offshoring right. Harvard Business

Review 83, 12 (2005), 135-143. 2. Aspray, W., Mayadas, F., and Vardi, M.Y. Globalization and Offshoring

of Software: A Report of the ACM Job Migration Task Force. A C M , NY, (2006).

3. Firms take outsourcing risks. TT Week (June 14, 2004). 4. Gopal, A., Mukhopadhyay T., and Krishnan, M.S. The role of soft-

ware processes and communication in ofFshore software development. Commun. ACM 45, 4 (Apr. 2002), 193-199.

5. Keil, M., Cule, P.E., Lyytinen, K., and Schmidt, R.C..A framework for identifying software project risks. Commun. ACM-41, 11 (Nov. 1998), 76-83.

6. Ktishna, S., Sahay, S., and Walsham, G. Managing cross-cultural issues in global sofiware outsourcing. Commun. ACM 47, 4 (Apr. 2004), 62-66.

7. McCarthy, J.C. The State of Development of the IT Services Global Delivery Model Forrester Research Inc., Cambridge, MA, 2007.

8. Schmidt, R.C. Managing Delphi surveys using nonparanietric statisti- cal techniques. Decision Sciences 28, 3 (1997), 763-774.

9. Schmidt, R., Lyytinen, K., Keil, M., and Cule, P. Identifying software project risks: An international Delphi study. / Management Informa- tion Systems 17, 4 (2001), 5-36.

10. Stone, B. Should 1 stay or should I go? Newsweek 143, 16 (2004), 52-53.

11. Wallace, L. and Keil, M. Software project risks and their effect on out- comes. Commun. ACM 47, 4 (Apr. 2004), 68-73.

C H A R A L A M B O S L . iACOVOtJ (charles.iacovou@mba.wfu.edu) is an associate professor of management at tbe Babcock Graduate School of Management at Wake Forest University in Winston-Salem, NC. R O B B I E N A K A T S U (rnakatsu@lma.edu) is an associate

professor of computer information systems at tbe College of Business Administration at Loyola Marymount University in Los Angeles, CA.

Permission Co make digital or hard copies of all or part of tliis work for persona! or class- room use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

DOI: 10.1145/1349026.1349044

9 4 June 2008/Vol. 5 I. No. 6 COMMUNICATIONS OF THE ACM