The evolution of coordination in outsourced software development ...

Information and Organization 13 (2003) 153–202 www.elsevier.com/locate/infoandorg

The evolution of coordination in outsourced software development projects: a comparison of client and vendor perspectives Rajiv Sabherwal ∗ CCB 206, University of Missouri-St. Louis, 8001 Natural Bridge Road, St. Louis, MO 63121-4499, USA

Abstract This paper examines the coordination of outsourced information system (IS) development, focusing on two sets of questions: How are these projects coordinated, and why? How do the coordination mechanisms evolve during a project, and why? Coordination mechanisms were classified into standards, plans, formal mutual adjustment, and informal mutual adjustment. Two studies were conducted, including seven and four cases from vendor and client perspectives, respectively. Based on these cases, the coordination mechanisms used in outsourced IS projects are examined, factors influencing the evolution of coordination mechanisms are identified, and a model of evolution of coordination is developed. The cases also revealed three scenarios for the evolution of coordination (non-coordination, consistent coordination, late coordination). The results show the client as pulling the outsourcing relationship toward a hierarchy structure, characterized by informal mutual adjustment, while the vendor pulls the relationship toward a market structure, characterized by standards, plans, and formal mutual adjustment. Implications for future research and practice are examined.  2002 Elsevier Science Ltd. All rights reserved. Keywords: Information system development; Outsourced development; Coordination mechanisms; Interorganizational relationships; Evolution; Project management

∗

Tel.: +1-314-516-6490; fax: +1-314-516-6827. E-mail address: [email protected] (R. Sabherwal).

1471-7727/02/$ - see front matter  2002 Elsevier Science Ltd. All rights reserved. doi:10.1016/S1471-7727(02)00026-X

154

R. Sabherwal / Information and Organization 13 (2003) 153–202

1. Introduction Over the last decade, firms have shown an increasing tendency toward outsourcing their information systems (IS) activities (Ang & Straub, 1998; Cross, 1995; Huber, 1993; Lacity & Willcocks, 1998). This paper focuses on one kind of IS outsourcing, outsourced IS development, i.e., the design and/or development of an IS by an external vendor1. Client and vendor share the responsibilities for managing outsourced IS projects. Problems arise from the differences between their goals and structures, which cause each side to feel vulnerable to opportunism or shirking of responsibilities by the other (Lacity & Hirschheim, 1993; McFarlan & Nolan, 1995). The two sides may therefore pull project coordination in different directions (Heiskanen, Newman, & Simila, 1996). These factors, along with the difficulties in obtaining quick feedback, meeting frequently, and building interpersonal relationships, make the management of outsourced IS development projects an arduous task. However, such problems are sometimes ignored in the IS outsourcing literature, which portrays “an overly optimistic view of IS outsourcing” (Lacity & Hirschheim, 1993; 256). McFarlan and Nolan (1995) compare outsourcing alliances to marriage: “Like marriage, however, these arrangements are much easier to enter than to sustain or dissolve” (p. 9). Indeed, “the truly critical success factors associated with successful outsourcing are those associated with vendor governance (Clark, Zmud, & McCray, 1998; p. 72; emphasis in original). Despite the recognition of the importance of outsourced IS development as well as the difficulties in managing it, prior research has given little attention to coordination of outsourced IS development projects. This paper seeks to advance our understanding of the coordination of outsourced IS development projects by addressing two sets of questions: (1) What kind of coordination mechanisms are used in these projects, and why? (2) How do these mechanisms evolve over time during a project, and why? In doing so, both client and vendor perspectives, and similarities and differences between them, are considered. Given the desire to address these ‘what’, ‘how’, and ‘why’ questions, a qualitative approach using detailed case studies was considered suitable. Also considering the desire to examine the coordination mechanisms and their evolution from both client and vendor perspectives2, the empirical research was comprised of two studies, including: (a) seven cases viewed from the perspective of four large Indian vendors; and (b) four cases viewed from the client’s perspective. Thus, 11 outsourced IS development projects constitute the empirical basis for the paper. Overall, the projects were heterogeneous in terms of clients, vendors, and systems, enabling the coordination mechanisms to be examined in a variety of situations. 1 This includes conversion of an information system from one hardware platform to another, and the design of the system with the software to be developed by another party, but not the maintenance of existing systems or technology infrastructure. 2 To the best of my knowledge, only Heiskanen, Newman and Simila (1996) have examined the differences between the two perspectives on coordination in IS outsourcing. However, they did not examine the reasons for the differences in the two perspectives.


155

The next section develops the foundation for the paper using literature on coordination and evolution of interorganizational relationships. The research methods and the findings from the two studies are subsequently described. The overall findings are then discussed, followed by the implications and limitations of this research.

2. Background 2.1. Coordination Studies in several diverse areas (e.g., organization theory, computer science, economics, and biology) have investigated the topic of coordination. Malone and Crowston (1994) review the discussion of coordination in these fields. Two representative definitions of coordination follow: “integrating or linking together (of) different parts of an organization to accomplish a collective set of tasks” (Van de Ven, Delbecq, & Koening, 1976; 322). “In software development, it [coordination] means that different people working on a common project agree to a common definition of what they are building, share information, and mesh their activities. To build the software efficiently, they must share detailed design specifications and information about the progress of software modules. In sum, they must coordinate their work so that it gets done and fits together, so that it isn’t done redundantly, and so that components of the work are handed off expeditiously” (Kraut & Streeter, 1995; p. 69). Coordination differs from control3. Coordination focuses on managing interdependencies among multiple individuals or activities involved in the overall task (Crowston, 1997; Kraut & Streeter, 1995). Control focuses on improving performance relative to a certain overall goal (e.g., organizational goal) when the goals of individual stakeholders (e.g., employees) differ from those of the larger overall entity (e.g., the organization) (Beath, 1987; Henderson & Lee, 1992; Kirsch, 1996; Mantei, 1981). Both coordination and control streams of IS literature primarily focus on internal development. In contrast, this paper focuses on outsourced IS development projects, which are difficult to manage, due to the differences in organizational goals and structures, the distance involved, as well as the inability to use hierarchies which help in internal IS development. Coordination and control are both important issues in outsourced IS development projects. However, the two streams of literature are quite different in terms of the problems studied, the theories employed, and the ways 3 However, control and coordination are interrelated in three ways. First, they both affect the overall performance of the project. Second, since IS development involves multiple goals and participants, coordination and control are both needed and problems and successes in one area also affect the other. Finally, coordination and control may be achieved through similar mechanisms.

156


of classifying the mechanisms. In fact, Bensaou and Venkatraman (1995, p. 1475) view control and coordination as opposites, describing one attribute of structure as “the extent to which the information exchange is for coordination vs control purposes.” In order to avoid the undue complexity that would arise from examining both coordination and control of outsourced IS development projects, this paper focuses on one aspect, i.e., coordination mechanisms; unlike control mechanisms, which have been examined for internal IS development (e.g., Kirsch, 1996), coordination mechanisms have not been examined for either internal or outsourced IS development projects. 2.2. How are outsourced IS projects coordinated? And why? 2.2.1. Types of coordination mechanisms Prior literature on IS (e.g., DeSanctis & Jackson, 1994; Kumar & van Dissel, 1996), and other areas (e.g., Daft & Lengel, 1986; Egelhoff, 1991; Olson, Walker, & Ruekert, 1995) identifies several specific coordination mechanisms, including standards, hierarchy, targets or plans, slack resources, vertical information systems, direct contact, liaison roles, task forces, and integrating roles. Possible ways of classifying coordination include formal impersonal, formal interpersonal, and informal interpersonal (Kraut & Streeter, 1995); non-coordination, standards, schedules and plans, mutual adjustment, and teams (Adler, 1995); task-task, task-resource, and resourceresource coordination (Crowston, 1997); vertical and horizontal coordination (Nidumolu, 1995, 1996); coordination by programming and by feedback (March & Simon, 1958; Van de Ven et al., 1976); and coordination by standards, plans, and mutual adjustment (Thompson, 1967; Kumar & van Dissel, 1996). After considering these classifications, coordination mechanisms were classified into four broad types—standards, plans, formal mutual adjustment, and informal mutual adjustment. This classification builds on the classifications used by Thompson (1967) and Kumar and van Dissel (1996) by incorporating Kraut and Streeter’s (1995) distinction between formal and informal mechanisms. Fig. 1 summarizes this classification scheme, and Table 1 identifies several coordination mechanisms of each type. Mechanisms that seek coordination through standards and plans rely on a priori specification of codified blueprints, action programs, or specific targets (March & Simon, 1958; Thompson, 1967). They are impersonal in nature as once they are implemented, their application does not require much verbal communication between participants (Galbraith, 1974, 1977). These mechanisms generally have high fixed costs (for setting up the mechanism) but low variable costs (for each application of the mechanism). In contrast, coordination mechanisms involving mutual adjustment use interpersonal interaction to make changes based on information obtained during the project (March & Simon, 1958; Thompson, 1967). Being more interactive in nature, they incur higher variable cost but lower fixed cost. Informal mutual adjustment differs from formal mutual adjustment in that the adjustments are made in a more structured and formalized fashion. Informal mutual adjustment may therefore be more related to team interdependence, while formal mutual adjustment may be more related to reciprocal interdependence. Also, informal mutual adjustment mech-


157

Fig. 1. The classification of coordination mechanisms.

anisms would incur greater variable costs but lower fixed costs than mechanisms involving formal mutual adjustment; the latter seek mutual adjustment in a more structured fashion, and therefore require the delineation of mutual adjustment mechanisms. These relative costs are shown on the right side of Fig. 1. 2.2.2. Factors affecting coordination mechanisms Based on prior literature, four factors were identified as potentially affecting coordination of outsourced IS projects. Three of these factors—efficiency, equity, and relational quality—were based on prior literature on interorganizational relationships (Ring & van de Ven, 1994; Arino & de la Torre, 1998), while the fourth—uncertainty—is based on the literature on coordination within organizations (Daft & Lengel, 1986; Galbraith, 1973). Ring and Van de Ven view evolution of interorganizational relationships as depending on the two sides’ perceptions of efficiency and equity. As indicated in the transaction cost economics literature, efficiency considerations pertain to the benefits from the particular governance structure relative to others available for undertaking a transaction (Ring & van de Ven, 1994; Arino & de la Torre, 1998). Thus, within the context of outsourced IS development projects, efficiency would reflect the benefits obtained from the outsourcing arrangement, in terms of timely and within-budget delivery of high-quality software. Equity, in contrast, concerns fairness in the dealings between the two sides, requiring reciprocity but not necessarily equality (Blau, 1964; Ring & van de Ven, 1994). In outsourced IS projects, equity would be reduced through perceived opportunistic actions by either the vendor or the client as well as perceptions that the other party is not adequately performing its expected role. Arino & de la Torre suggest that a third factor, relational quality,

Compatibility standards Data dictionaries Design rules Error tracking procedures Modification request procedures Delivery schedules Project milestones Requirements specifications Sign-offs Test plans Code inspections Coordination committees Design review meetings Hierarchies Liaison roles Reporting requirements Status review meetings Co-location Impromptu communications Informal meetings Joint development Transition teams

Coordination by standards

Coordination by informal mutual adjustment

Coordination by formal mutual adjustment

Coordination by plans

Coordination mechanisms

Type of coordination

Table 1 The typology of coordination mechanisms

Adler (1995) Kraut and Streeter (1995) Adler (1995) Kraut and Streeter (1995) Kraut and Streeter (1995) Kraut and Streeter (1995) Kraut and Streeter (1995) Kraut and Streeter (1995) Adler (1995) Kraut and Streeter (1995) Kraut and Streeter (1995) DeSanctis and Jackson (1994); Adler (1995) Adler (1995); Kraut and Streeter (1995) Galbraith (1974); Van de Ven et al. (1976); Van de Ven et al. (1976); DeSanctis and Jackson (1994) DeSanctis and Jackson (1994) Kraut and Streeter (1995) Kraut and Streeter (1995) Van de Ven et al. (1976) DeSanctis and Jackson (1994); Kraut and Streeter (1995) Adler (1995) Adler (1995)

References

158 R. Sabherwal / Information and Organization 13 (2003) 153–202


159

along with efficiency and equity considerations, influences the evolution of interorganizational relationships. Relational quality depends on personal bonds between participants from both sides, their trust in each other, their reputations for fair dealing, and their previous contributions to the relationship (Arino & de la Torre, 1998; Zaheer & Venkatraman, 1995). Therefore, relational quality would be enhanced in outsourced IS projects by prior interactions between the vendor and the client as well as similarity of language and culture. Whereas prior literature on interorganizational relationships has recognized the importance of these three factors, their effects on coordination mechanisms have not been explicitly examined. Prior literature on coordination identifies uncertainty (i.e., lack of information), as an important factor influencing coordination mechanisms. As uncertainty increases, horizontal channels and group meetings increasingly replace impersonal coordination (Adler, 1995; van de Ven et al., 1976). A study of the effectiveness of impersonal, personal, and group coordination mechanisms under different conditions found that “as task uncertainty increases, horizontal channels and group meetings are substituted for, or increasingly replace, the impersonal mode of coordination” (Van de Ven et al., 1976; p. 329). Similar results were obtained in a recent study of coordination in the context of computer-aided design/computer-aided manufacturing (Adler, 1995). A study of organization of IT functions also suggested that more interactive coordination mechanisms might be more appropriate under high uncertainty (Blanton et al., 1992). In addition to uncertainty, prior coordination literature also examines the effect of equivocality (i.e., existence of several conflicting interpretations) in the relationship (Daft & Lengel, 1986; Galbraith, 1973), but this aspect was not considered separately in this study since it is closely related to the relational quality attribute discussed above. 2.3. How do coordination mechanisms evolve during the project? And why? The coordination mechanisms established initially in the project may change as the project unfolds. While there is little research on the evolution of coordination mechanisms in IS projects, there has been some valuable research on the evolution of interorganizational relationships (Arino & de la Torre, 1998; Doz, 1996; Ring & Van de Ven, 1994). Ring and Van de Ven propose a process framework wherein the interorganizational relationship evolves through sequences of negotiation, commitment, and execution. Each stage includes repeated interactions, whose outcome affects assessments of efficiency and equity, discussed above. Doz explains how the evolution of interorganizational relationships depends on certain initial conditions and learning activities. As the two sides learn from their interactions, they reassess the alliance in terms of efficiency and equity and make adjustments to the nature of the alliance. Doz found successful alliances to undergo cycles of learning, reevaluation, and readjustment, whereas failed alliances were highly inertial, with little learning and readjustment. This research on evolution of interorganizational relationships provided an initial understanding for examining the evolution of coordination mechanisms, suggesting that as the factors affecting coordination mechanisms change during the course of a project, the coordination mechanisms used might change as well.

160


The empirical cases enabled further development of this argument into a research model. 2.4. Client and vendor perspectives In outsourcing, both client and vendor may feel vulnerable to opportunistic behavior by the other. For example, the client may be concerned about the vendor providing inadequate effort or developing poor quality software while the vendor may be concerned about the client not providing the needed help in requirements analysis or adding new requirements as the project proceeds. Moreover, the two sides may also have different perceptions of vulnerability and coordination. The client may be less concerned about the costs the vendor incurs in developing the system, especially in fixed-price contracts. However, agency theory suggests that the client (i.e., the principal) may feel more vulnerable to opportunism by the vendor (i.e., the agent) than the other way around (Chakravarthy & Zajac, 1984; Jensen & Meckling, 1976; Pratt & Zeckhauser, 1985). As a result, the use of coordination mechanisms to minimize potential opportunism by the vendor may be important to the client, but the vendor may view such coordination mechanisms as constraining and expensive. The two organizations may therefore prefer different kinds of mechanisms (Heiskanen et al., 1996; Sabherwal & Elam, 1995). The differences between vendor and client views may be amplified when the relational quality is poor, e.g., when there are considerable differences in the two organizations’ goals and outsourcing is across national boundaries. 3. Research methods Given the lack of prior research on the coordination mechanisms used in outsourced IS projects, and my interest in studying them within their organizational contexts, a qualitative approach was considered appropriate. In order to identify a variety of coordination mechanisms, and to achieve some understanding of their evolution over time, it was also important to examine them in a number of projects. Furthermore, given the interest in examining the differences between the views of the client and the vendor, an attempt was made to incorporate both these perspectives. Two studies were conducted to simultaneously pursue these goals. The data collection methods are discussed next, and the data analysis methods are described in the subsequent subsection. 3.1. Data collection Study 1 was based on the vendor’s perspective. Ten large vendors in India were contacted by phone4. A senior executive at six of these vendors could be interviewed. 4

The author had no prior relationship with any interviewee in Study 1. One interviewee in case C10 in Study 2 had been the author’s student several years prior to the study, but was encountered unexpectedly during the study.


161

In the initial interviews, the vendor’s commitment to the case study was sought and one or more recent projects were identified. The projects were briefly discussed with the senior executive and the ones to study further were identified, based on the availability of the key informants. Following this interview, the project manager and one or more other participants in each project were interviewed. Seven projects, involving four of these vendors, were studied in some detail and are used in this paper. The vendors are among the largest, and most experienced, software vendors in India. The clients varied in size and industry, and were based in the US, the UK, The Netherlands, Thailand, and Oman. The interviews were semi-structured. An interview protocol, given in Appendix A was used, but interviewees were encouraged to develop their own views rather than forcing their experiences into a priori categories. Study 2 included cases studied primarily from the clients’ perspective. Senior IS executives at eight potential clients were first contacted by phone. An attempt was made to identify an outsourced IS development project. Three clients were excluded due to the lack of a recent outsourced IS project. At another client, the case could not be completed due to the turnover of several IS executives. The other four projects, involving large clients based in the US, were then examined. This was done mainly through interviews with key participants at each client, although a two-hour interview was conducted with the CEO of the vendor (V—E, with head office in Colombia) that developed two of these systems. Another vendor was based in the US, in a different city than its client, while the fourth was the Indian vendor V—B that was earlier visited in Study 1 to examine some other projects. Interviews in Study 2 were also semi-structured, based on the interview protocol given in Appendix A. Table 2 summarizes the nature of the projects examined in the two studies. All the projects were examined primarily through interviews with several participants. Table 3 provides information on the interviews, including the interviewees’ titles. The informants were encouraged to illustrate general observations with more specific comments, and frequently asked additional questions, based on the information collected earlier. In all two studies, clarifications were sought for conflicting answers either during the same interview or in later interviews. All the interviews were taperecorded, with notes taken when necessary, and then transcribed. Personal interviews were supplemented with organizational charts, annual reports, and internal documentation. 3.2. Data analysis The objective of the data analysis was to understand the coordination mechanisms used, their evolution during the project, and the factors influencing them. Interviews for the 12 cases in the two studies produced over 650 pages of transcripts and over 80 pages of field notes. There was thus a vast amount of qualitative data (i.e., interview transcripts) that was not easily amenable to analysis. Two goals were pursued in analyzing this data: (a) to use the rich insights available in each case, which can best be obtained from thorough immersion into the transcripts for that particular

Size (budget in U.S. $/man-months)

The Client

Study 2: Four cases from the client’s perspective P8. Development of software to add functionality to $0.5 million C8: Fortune 500 financial services a global customer service system firm P9. Executive information system on company sales License fee per user plus C9: Fortune 500 software $15,000 and “future manufacturer considerations” P10. Legislature tracking system $0.25 million C10: Large county P11. Executive information system for field $0.5 million C11: One of the 10 largest food management teams products firms

Study 1: Seven cases involving five vendors, studied from the vendor’s perspectives P1. Works management system $3 million C1: Utility company P2. Reengineering of stocks and bonds system $0.5 million C2: Large software house P3. System for customers to order software from 150 man-months C3: Software vendor home P4. Conversion of a distribution system from $0.5 million C4: Distribution firm AS400 to UNIX P5. Taxation system $0.3 million C6: Supplier to Thai government P6. Word-processing software $0.3 million C6: Software vendor P7. Human resource management system $0.6 million C7: Government organization

The Project

Table 2 The sample of projects

V—E

V—F V—E

US

US US

V—C V—C V—D

Thailand US Oman

V—B

V—B

UK

US

V—A V—A V—B

The Vendor

UK UK Netherlands

Client location

U.S. Colombia

Colombia

India

India India India

India

India India India

Vendor location

162 R. Sabherwal / Information and Organization 13 (2003) 153–202

Individuals

Titles

Project manager, lead programmer analyst (project leader) Regional manager, manager Presidenta Division director (development), senior system analyst, system analyst, project manager Vice president (is), director (is), manager, project manager (subcontractor) President

9.5

4.5

6

3

1

4

1 1 4

2

5

2 2 6

3

6

4

2

10

Total duration (hours)

5

Interviews

P9 and P11 involved the same vendor (V—E), and project P9 was also discussed in the interview with V—E’s CEO in the context of P11

1

Vendor interview

P11

a

4

Client interviews

P10

2 1 4

Client interviews Vendor interview Client interviews

P9

Study 2: Four cases from the client’s perspective P8 Client interviews 2

Study 1: Seven cases involving four vendors, studied from the vendor’s perspectives P1, P2 Vendor interviews 3 Executive director, development manager, project leader P3, P4 Vendor interviews 4 Resident manager, two project managers, project leader P5, P6 Vendor interviews 6 General manager, resource manager, two project managers (titled senior manager, senior divisional manager), two project leaders (senior consultants) P7 Vendor interviews 3 Sales manager, group leader, senior it engineer (project leader)

Cases

Table 3 The Interviews

R. Sabherwal / Information and Organization 13 (2003) 153–202 163

164


case; and (b) to compare across cases, which requires a more macro view of each case, and cannot be effectively obtained from detailed transcripts and notes. To simultaneously achieve these goals, the data analysis was done in a systematic and comprehensive, but not rigid, fashion. The analysis was necessarily somewhat interpretive in nature. The interview transcripts were first read to identify the coordination mechanisms used in each case. Concerns expressed about too much or too little coordination were identified. Unmarked copies of all the transcripts were then read again. At this time, comments related to the timing of the coordination mechanisms and the factors affecting coordination were also identified. While reading the transcripts during these steps, portions of interviewee comments were highlighted, which helped segment the data into relevant and meaningful pieces of text, or units (Tesch, 1990). Some of these pieces of text described an underlying coordination mechanism in an interviewee’s words, while others represented the interviewee’s perceptions of the reasons a particular mechanism was used. Special attention was given to comments related to considerations of efficiency, equity, and relational quality. Analytical comments, or ‘memos’, were also written on the margins adjacent to each piece of text. After reading the transcripts for each case and identifying the comments about coordination mechanisms and the factors affecting them, a one-page summary was constructed for each case. This summary identified the coordination mechanisms used during analysis and design, development, and implementation, and also included remarks concerning changes in coordination mechanisms or factors (related to efficiency, equity, and relational quality) affecting them. These summaries also included links to memos in transcripts, in terms of the interview and the transcript page number. Each case summary used a standard form and was prepared by examining the memos and, where necessary, looking at the transcripts. Together, the above analytical devices—highlighting to segment data into pieces of text, memos identifying the nature of each piece of text, case summaries, and the links between case summaries and memos—enabled me to decontextualize the interviewee comments and then recontextualize them (Tesch, 1990). In other words, they helped take the interviewee comments out of their original context (i.e., an interview) and present them in a different context (i.e., the coordination mechanisms and their evolution over time). This helped me to surface patterns that I may have otherwise missed, while at the same time suppressing spurious patterns that may have resulted from examining the interviewee comments only within their original context5. This process led to the coordination mechanisms being classified into the four types, discussed earlier (see Fig. 2). Appendix B provides a condensed version of the case summaries. Appendix C provides some illustrations of interview quotes that helped develop these summaries. Thus, recognizing the unreasonableness of asking another knowledgeable coder to read over 700 pages of transcripts and notes, as well as the risks of relying on

5 I am grateful to Richard Boland for identifying this as a potential benefit of the analytical approach used in this paper.


Fig. 2.

165

Emergent model of evolution of coordination mechanisms.

one researcher’s interpretations, some systematic procedures were devised and used. By providing a structure for the analysis of the qualitative data, these procedures helped minimize the possible effects of subjectivity. One accepted goal in reporting research like this is transparency, i.e., allowing the reader to trace the researcher’s steps from the selection of sites, through data collection to the interpretation and presentation of the results. Use of ‘thick’ description (verbatim quotations) from the transcripts facilitates transparency, and this is done in the next section while recognizing space constraints. In addition, the above description hopefully provides insights into the ways in which the data were analyzed and the conclusions were derived.

4. Findings from the case studies The eleven cases are summarized in Appendix B. The coordination mechanisms and the factors affecting them are summarized for each case in Appendix C. The findings from the cases are presented here, including: the coordination mechanisms, the factors affecting coordination, and the evolution of coordination over time. Differences across vendor and client perspectives are also examined. 4.1. The coordination mechanisms The 11 cases across Study 1 and Study 2 provided considerable insights into the coordination of outsourced IS projects. As shown in Table 4, a variety of coordination mechanisms, supporting all four types of coordination, were used in the 11 cases. Standards used in Study 1 included numbering schemes for FAX messages, a form for client personnel to inform the vendor about problems, pre-specified procedures for client to change system requirements, and categorization of issues by importance or according to their technical or functional nature.

166


Table 4 Coordination mechanisms used in various projects Study 1: Vendor Perspective Coordination mechanisms Standards

Plans

Formal mutual adjustment

Cases -⬎

Problem/issue query form Change control mechanisms FAX numbering scheme Categorization of issues Confirmatory follow-ups Documentation procedures Programmer productivity standards Checklist Contract/budget Client involvement plan Project management plan Delivery schedule Sign-offs Test/training plans Design specifications Pricing mechanisms for changes Periodic reports Periodic software downloads Delineation of coordination roles Liaison roles Acceptance criteria Parallel structures

Informal mutual adjustment

1

2

3 4

5

✓ ✓

6

7

Study 2: Client Perspective 8 9 10 11

✓ ✓ ✓

✓ ✓ ✓

✓ ✓ ✓ ✓ ✓

✓ ✓ ✓

✓

✓ ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓

✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

✓ ✓

✓ ✓

✓ ✓ ✓

✓ ✓ ✓

✓

✓ ✓

✓ ✓

✓ ✓ ✓ ✓

✓ ✓ ✓

✓ ✓

Co-location

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

Personal visits Impromptu communications (phone calls, FAX, e-mail, need-based conference calls) Maintenance of record of changes Interaction through local office On-site (at vendor) coordinator On-site (at client) coordinator Documentation of changes Help desk

✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓

✓ ✓

✓ ✓

✓ ✓

✓ ✓

✓ ✓

✓ ✓

Project Manager, P2: “What one has to do is define that every time a FAX goes there is a particular number of that... So, there is a scheme that is created... in the beginning didn’t set those things. We assumed that, to begin with, the FAXes are easy. No, one has to build into the system, checks and balances... There are


167

more such issues. So, the important thing is really set the process, over a period over which one learns. Then those processes get fixed for a particular customer, processes continue...” Senior Consultant, P6: “Our feeling is that why can’t they make up their mind in the beginning? … So we put in a lot of change control mechanisms, either through a process or contractually, although a lot of customers are concerned that it deprives them of their right to make later changes.” Standards were also used in the cases in Study 2, including FAX numbering scheme, categorization of issues, and confirmatory follow-ups, as illustrated by the following remarks by the Project Leader for P8. “During the acceptance period where we found the majority of the problems. We essentially divided the problems into (a) show stopping problems, in other words we cannot continue; (b) problems that could be addressed later but had to be addressed; and (c) problems that we felt we could fix at a later phase. The problems that require immediate attention, we communicated to V—B people immediately and they would set about fixing these problems and releasing the software or preparing the software for retest as soon as possible.” “When we sent a FAX we followed it up with an email saying, did you get the FAX? We had controls in terms of that. We just wouldn’t send things off and not expect a return.” Plans included delivery schedules and design specifications in several projects. Two types of detailed plans were called ‘client involvement plan’ and ‘project management plan’; both specified ways in which the client personnel would contribute to the project although the project management plan was somewhat broader in nature. The following quotes illustrate some of these coordination mechanisms. Development Manager, V—A: “One of the first jobs is to develop a Project Management Plan. This plan will talk about what is the scope of the system, what is the duration, persons to be contacted, … what are the reporting procedures, what other standards are to be used, what are the communication procedures? All these things I am talking about must be documented with the understanding of the client, because this is how we are going to operate. Whether it is a fortnightly, monthly, quarterly meeting we are going to have, it is all defined in the Project Management Plan.” Project Manager, V—B: “After the requirements were identified, the design was done offshore. The high-level design also. The design document was then sent to the client for approval. Once they approved the high-level design, we did the lowlevel design also in our Indian office. During that we do need a lot of clarifications from the client. So we planned for client’s involvement in issues. E.g., we say,

168


the client, that the project manager will be required to come here for 10 to 15 days and who else is required from the client side is identified. When they came over to India, they approved our specifications, etc.” Plans used to coordinate projects in Study 2 included development schedule, design specifications, the contract, a training plan, and client-involvement plan. For example, in P9, the client’s Regional Manager remarked about the design specifications given to V—E: “It was a written document with specs of what the field name should be, the sizes, and exactly the format and timeliness and the data base format that we had to present the feeds to them and they would process it from their side. So, there was a very clear line as to where we stopped and they started.” Formal mutual adjustment was achieved in Study 1 through parallel structures, periodic reports, deliverables (including, in P1, vendor programmers’ time sheets!), and periodic conference calls. In some cases (P1, P2, P6), in order to reduce the potential for contradictory communications each side nominated one or two (for technical and functional issues) points of contact, and clearly demarcated the roles to be performed by these coordinators. The following quote by the Project Manager illustrates the use of a single point of contact in P6. “Three different perspectives of the problems were coming from the same organization... So balancing has to be done obviously. Sitting here, the project manager cannot balance those views. It is to be balanced internally out there. That is the learning that even they had. So they also started funneling after some point of time and they found that the contradictions were happening there.” Some formal mutual adjustment mechanisms were also used in Study 2. They included delineation of coordination roles (P10, P11), periodic reports (P8, P9), and periodic software downloads (P10, P11). Director (IS), C11: “Because they were Colombian, Spanish was their native language, I made sure I recruited a project manager who was learned in Spanish.” Informal mutual adjustment was observed in Study 1 as well as Study 2. In some cases in Study 1, vendor’s project managers, analysts, and programmers visited the client. In some cases, a vendor executive, who was positioned at the client site, facilitated mutual adjustment, for example through the clarification of system requirements, renegotiations of interim schedules, and, ensuring that FAX or e-mail messages from the vendor reached the client and received adequate attention. In some projects, client executives also visited the vendor, generally during early parts of the project, to meet vendor personnel and examine its technical and reporting infrastructure. Moreover, in P2 and P6, the clients positioned one or more employees at the vendor site to answer possible questions from analysts and programmers and also


169

track progress. Co-location was also used in P7, but under considerable pressure from the client. Much of the coordination in Study 2 was achieved through informal mutual adjustment. Mechanisms enabling informal mutual adjustment included personal visits, and, of course, regular phone calls, FAX, e-mail, and conference calls. The following quotes illustrate the emphasis on interpersonal interaction. C8’s Project Leader: “We had one person go to India to interview with V—B and take a look at some of the people that were going to be participating in the project. There were some discussions about the overall, what we were doing, etc., to see their facilities, to make sure that it would meet our needs.” Division Director (Development), C10: “Phone conversations were more for clarifications, follow up to “hey, we talked to the end-users about this and that,” and the FAXes were mostly coming from them to us than from us to them. It was more “this is our understanding of what you are asking us to do now, and we must have A, B, C, D.” Director (IS), C11: “(The project manager) met the team, we wanted the team to come up here so they could meet with our people and they could take a look and understand some of the culture they’d use, the customers they were delivering to. And they therefore formed a relationship with the project manager.” Vendor and Client Perspectives: Overall, in Study 1, V—D hardly used any impersonal coordination mechanisms (standards, plans, or formal mutual adjustment) in P7, but all other vendors (V—A, V—B, and V—C in P1–6) preferred impersonal mechanisms. They perceived these mechanisms as less costly (due to lower demands of time and personalized attention) than informal mutual adjustment. Indeed, the impetus for informal mutual adjustment was directed mainly from the client rather than from the vendor, except during the initial stages. Early in the project, vendors sought to earn the client’s confidence through interpersonal interactions, and by demonstrating their rigorous reporting arrangements and quality assurance measures. Thus, the vendors focused on efficiently developing the system. They saw clients as more concerned about the system being developed as quickly as possible (despite the potential increase in vendor’s coordination costs). Some vendor executives also complained that the clients were not very enthusiastic about standards and plans. Study 2 supported the differences between client and vendor perspectives that were revealed in Study 1. The clients’ placed considerable emphasis on informal mutual adjustment, which was in sharp contrast to their relative indifference toward standards and plans, especially early in the project. C9 seemed to depend on the system’s long-term benefits to the vendor, while the client executives delegated project coordination entirely to the sub-contractor hired as project manager. C8 and C10 executives gave greater attention to standards and plans, but they also relied on informal mutual adjustment. C10 incorporated formal coordination only after its IS group, which was initially excluded from the project, got involved.

170


Further support for the above findings was clearly provided by interviewees at C9, C10, and C11, who acknowledged that they were less formal than their vendors. Moreover, several client executives believed that they should have been more formal. For example: Division Director (Development), C10: “They (vendor personnel) were documenting what we were telling them over the phone, sending it back to us and then in some cases we would sign off and say, “yes this is exactly what we are telling you” or say “no, you’ve got to make these changes.” ” Director (IS) at C11: “One thing I learned is when we outsource … there has to be a tremendous amount of importance placed on oral communication and keeping that up to find out what is going on. But in addition, written communication that kind of tracks what is happening, what has been decided, what has been promised. When I look back at some of the documentation that went through the project, when we looked at “well, was this guy supposed to do this?” it was difficult for us in some cases to say, “yes, and we talked about it on this date.” … There needs to be a lot of diligence paid towards the scope and keeping very good project documentation as the project moves along so you understand where you are and who is responsible for what.” 4.2. Factors affecting coordination Table 5 summarizes the factors that influenced coordination mechanisms. The changes in these factors during each project are indicated in Appendix C. As may be seen from Table 5, the four project attributes expected to affect coordination— uncertainty, efficiency, equity, and relational quality—did play an important role. In addition, two attributes of the system—complexity and criticality—also affected coordination. The effects of the four project attributes are examined first, followed by the effects of the two system attributes. Uncertainty was a key factor influencing coordination mechanisms in both studies. It seemed to play a role in all the projects, except P9. Uncertainty arose from four several reasons. One major cause of uncertainty was the lack of prior IT knowledge (P2, P3, P4, P5) or poor understanding of the system (P5, P6). In contrast, prior experience with a similar system provided valuable knowledge and reduced uncertainty in P9. Another factor causing uncertainty was non-involvement of key groups early in the project. The vendor was not involved from the beginning of project P8. It was asked to work with requirements developed by the client, and subsequently had inadequate understanding of the client’s business. In P10, the client’s IS department was not involved during requirements specifications, which later caused ambiguity in specifications. Third, unclear specifications (P6, P10, P11) and poor documentation (P2, P5, P6) caused uncertainty in several projects. Finally, uncertainty was increased when responsibilities were divided (P4) or several intermediaries were involved (P7). The following quote illustrates the effect of uncertainty due to poor specifications on project coordination:


171

Table 5 Factors influencing coordination mechanism Client’s perspective Factors increasing coordination

Factors reducing coordination

Project attributes Uncertainty Vendor’s nonVendor had involvement in developed similar requirements analysis software earlier (P9) (P8) Non-involvement of IS (P10) Unclear specifications (P10, P11)

Efficiency

Equity

Relational quality

Problems with software delivered (P8, P9) Delays (P8) Unilateral changes in vendor personnel (P8, P11) Perceived lack of software testing by vendor (P11) Change in vendor’s local project manager (P11) Disagreement regarding specifications (P10, P11)

Fixed-price contract (P11)

Vendor’s perspective Factors increasing coordination

Low IT knowledge (P2, P3, P4, P5)

Lack of understanding of system needs (P5, P6) Unclear specifications (P6) Poor documentation (P2, P5, P6) On-site coordinators not seeing off-site code (P1) Divided responsibility (P4) Several intermediaries (P7) Implementation problems (P1) Project delays (P5, P7) Changes in client personnel required rework (P4)

Confidence in vendor Pressure by client to (P8) place vendor personnel at client (P7) Strong commitment Disagreement regarding by both sides (P10) responsibilities (P2, P4)

Pilot project by vendor builds credibility (P11) Long-term relationship (P8, P9)

Confidence in vendor (P1) Pilot project by vendor builds credibility (P2) Prior projects involving them (P4, P5)

System attributes Complexity Complex system (P8) Simple system (P9)

Complex system (P6)

Criticality

Critical modules (P1)

Non-critical system (P9, P11)

Factors reducing coordination

Critical systems (P4, P6)

Simple system (P5)

172


Senior Consultant, V—C, who was the Project Leader for P6: “… the specifications were not very clearly laid out. So during the development process we found that specification of a number of things were evolving. They also felt that maybe a face-to-face meeting would help in clearing all the specification-related issues. They spent some time here …” The level of uncertainty changed during the course of the project in several cases. This was partly due to the involvement of new individuals in the project; for example, in P1 and P5, uncertainty was enhanced during development where on-site coordinators, who had not seen the code developed by the off-site programmers, were involved. The Project Manager at V—C, who was involved in P5, remarked: “People who do the requirements analysis study are there [at client site]. They are fine. Other people who don’t get involved, what is their understanding?” Another reason for change in uncertainty during the project relates to learning during the course of the project. In P11, project coordination improved as learning during the project reduced uncertainty. After discussing an example of difference between vendor and client, the client’s project manager remarked: “That example is typical of the kind of problem we have where not a disagreement but a change or a new understanding took place. We designed it one way after talking to the top VP’s and their understanding of the visions but in real life when you talk to their secretaries this is what it’s really like, and it is not that the vendor was wrong, they did what we asked them to do, but as we learned more we had to go back and request that we add some flexibility because life is not perfect and there are always exceptions.” Efficiency considerations influenced coordination as well, playing a role in six of the projects, including three in Study 1 (P1, P5, P7), and three in Study 2 (P8, P9, P10). Moreover, efficiency considerations changed during the course of the project in response to high or low levels of interim project performance. When the client perceived the quality of software delivered by the vendor to be poor (P8, P9), coordination was increased. The response was similar when delays were encountered (delays by the client in P5, and by the vendor in P7 and P8) or when implementation ran into difficulties (P1, P10). Group Leader for V—D (project P7) described one such increase in coordination: “When we did our Software Requirement Study, the project got delayed, and suddenly the customer forced us to do the development there. He came up with his own reason of security and such things. Whereas … there was no security required there. We said we don’t require your test data also. But he forced us to do the development there. So the whole thing was there. We were forced to send six more people from India to finish the development.”


173

Equity considerations had much less effect on coordination than the other three project attributes. Study 1 revealed no instance of project coordination being affected due to the belief that the other party had not contributed equitably to the project. This might be due to potential overlap between perceptions of equity (i.e., perceived lack of effort) and efficiency (i.e., perceived low output), and the vendor personnel attributing the client’s desire for greater coordination to efficiency rather than equity considerations. However, Study 2 indicated two instances of equity considerations playing a role (P8, P11). These were due to opportunistic behavior by the vendor. One such perceived opportunism was the vendor unilaterally changing project personnel in P8. This happened despite the client having initially evaluated the quality of the people expected to work on the project. Project Manager, P8: “During the development process we had a few problems with personnel in that some of the people that ended up working on the project were not he people that we originally expected to have work on the project. And usually they were of a lower caliber than what we expected… overall in the selection process of the people who are working with this, we are a little disappointed at the attitude that V—B had taken in that they were going to just change the persons or the people involved and we essentially had no say so in terms of who this was or why or when the date was.” In P11, equity was perceived to be high due to a fixed-price contract with the vendor, which assured the client that it would receive the expected system at an agreed cost. However, later events in the project reduced equity somewhat. C11’s project manager believed that the vendor personnel shirked their responsibilities for software testing, especially when they realized that he was quite thorough in testing. He felt that “their programmers developed the sense of “let’s program it and give it to him to test”.” In this project, the vendor was also perceived to have behaved opportunistically by assigning junior personnel to the project: “It is possible that some of the code was written by fairly junior programmers which means that when you do an outsourcing job like this where you pretty much black-boxed it, you rely on the outsourcing firm to have confident people, you are really leaving that control to the outsourcing company versus if you use an outsourcer and bring him in and have him on site at your view, you have much more control over understanding. In a black-box type of scenario, you don’t know, and it seemed like some of the code was amateur, which may have led to some inefficiencies in code sizing and some of the programming and logic, now that we see where we had problems.” Thus, equity considerations also changed during the course of the project, becoming more important in requiring greater coordination following perceived opportunistic behavior. Relational quality also affected the perceived need for coordination. Greater coordination was observed in cases where the relational quality was poor due to lack of

174


prior relationship between vendor and client (P1, P3, P6, P7, P10), and disagreements between them regarding required tasks and specifications (P10, P11) or expected responsibilities (P2, P4). Relational quality also suffered in response to serious concerns about efficiency (P7) or equity (P8, P11), as indicated above. In contrast, coordination was reduced when the client and the vendor perceived their relationship to be strategic or long term (P8, P9), or when prior (or pilot) projects enabled the two sides to develop a relationship (P2, P4, P5, P11). In P10 also, after the disagreement during development, relational quality improved once both parties recognized the other’s high level of commitment to project success. The Development Director attributed the project’s success to both parties being “committed to getting this done almost to no matter what it takes.” The client Project Manager agreed: “The vendor has been very supportive and very understanding as I think we have also been. It has been a win-win type of scenario. We both are committed to getting this done almost to no matter what it takes we will get it done, so there has been no animosity or no problems in that respect. They have been very friendly conversations.” Thus, relational quality changed during the course of the project, with improvements in relational quality through the two parties getting better acquainted with each other, or deterioration in relational quality due to efficiency or equity concerns. In addition to the above project attributes, two attributes of the system (or its modules)—complexity and criticality—also seemed to influence coordination. Complexity6 apparently enhanced coordination, and especially informal mutual adjustment. Several interviewees mentioned the greater need for coordination for complex systems. In the case of one such project (P6), two executives from the client visited the vendor for a period of four weeks during the middle of the project. This visit addressed the problems arising from project complexity. In another complex project (P8), a variety of mechanisms supporting informal mutual adjustment, including the use of e-mail follow-ups for FAXes, regular conference calls, a liaison person from the vendor being at client site, and an executive from client visiting the vendor early in the project, facilitated coordination. Project Manager, C8: “During the development the programmers had a range to talk to any of the other staff members. We thought this was necessary due to complexity of the system, that not one person knew every component so when questions need to be asked we didn’t want to feel that we were going to inhibit the process by saying well, you must ask this person, and then risk any communication errors, etc.” System criticality also led to need for greater coordination in some cases. Projects that were expected to significantly impact organizational performance increased the

6

Complexity and criticality emerged from the interviewee comments as distinct contingency factors.


175

client’s feeling of dependence on the vendor. This was mainly due to the inherent importance of the system, but also to some extent because these projects attracted close attention from the client’s top managers. Vendors also perceived greater dependence on inputs from the client, due to the greater pressure to develop the system and the belief that the successful development of such an important system would help them in obtaining future contracts with the same client as well as other clients. In P4, the project was relatively simple but so important that its announcement caused the client’s share prices to go up. Consequently, there was continuous pressure on timely software development; personnel from the client and the vendor visited each other frequently, and one interview felt that the programmers sometimes found the pressure to be too much. In contrast, in P9, the system was not very critical, and so the client did not pay much attention to coordination, although the vendor did use several coordination mechanisms. Manager, C9: “I also think we were flexible because it wasn’t a time critical project. If we slipped a month or two, nothing really happened. In a critical project I would be much more formal and tie the vendor to their dates more. In this case, it slipped many times.” Whereas the four project attributes were found to undergo changes during the course of the project, as indicated above, system attributes did not seem to change in response to project events. However, these attributes could change across modules within a system, as was the case in P1, where the more critical modules of the system were developed at client site to achieve greater coordination. Vendor and Client Perspectives: Whereas significant differences were observed across the two perspectives in terms of the coordination mechanisms, there was considerable agreement with respect to the factors affecting coordination. As may be seen from both Table 5 and Appendix C, uncertainty and relational quality seemed to be the two key factors affecting coordination mechanisms according to clients as well as vendors. Uncertainty affected coordination in all 11 projects across the two studies, whereas relational quality played a role in five of the seven projects from the vendor perspective (all except P3 and P6), and all four projects from the client perspective. Furthermore, clients and vendors both perceived these two factors to be influenced by circumstances at the start of the project (e.g., prior knowledge and a long-term relationship between the two sides) as well as events during the project (e.g., unclear specifications and disagreements). Efficiency and equity both seemed to play a less important role, with efficiency affecting coordination in three cases studied from the vendor perspective (P1, P5, P7) and two cases studied from the client perspective (P8, P9), and equity affecting coordination in one case studied from the vendor perspective (P4) and two cases studied from the client perspective (P8, P11). Moreover, both efficiency and equity changed considerably as a result of actions and outcomes during the project; interim performance (with respect to quality, schedule, budget) would affect efficiency perceptions whereas perceived opportunism would affect equity perceptions. From both perspectives, the two system attributes—complexity and criticality—

176


has less influence on coordination than the above four project attributes. Moreover, there was little change in the perceived nature of these system attributes, as the system did not become more or less critical or complex over time. System complexity seemed to directly affect coordination in two projects studied from client perspective, with system simplicity reducing coordination in one case (P9), and system complexity increasing it in the other (P9). Complexity also increased coordination in one of the projects examined from vendor perspective (P6), while simplicity reduced coordination in another project (P5). Two possible reasons can be offered for complexity not affecting coordination in the other projects studied from the vendor perspective: (a) most of these projects were moderate in complexity; (b) vendors might have perceived the effect of complexity to be less due to the more apparent effects of other factors (especially uncertainty). System criticality affected coordination in two projects studied from client perspective (P9, P11), with coordination mechanisms being reduced due to the systems’ non-critical nature. The other two systems were also not highly critical to the clients, which might partly explain why the four projects were outsourced. However, the vendors considered criticality to increase coordination in three of the seven projects in Study 1. In one of these projects (P1), this effect was only for some modules, whereas in the other two cases (P4, 6) it was for the entire system. 4.3. The evolution of coordination mechanisms Fig. 2 summarizes the emergent model of evolution of coordination mechanisms. As may be seen from this model, coordination mechanisms (including standards, plans, formal mutual adjustment, and informal mutual adjustment) depend on system attributes (complexity and criticality) and project attributes (uncertainty, efficiency, equity, and relational quality). The coordination mechanisms govern the interaction between client and vendor during the IS development project. The two sides work together through these mechanisms. They also observe each other using these mechanisms. This information gathering is continuous and begins early (Doz, 1996). It can lead to changes in the level of uncertainty (through learning) and periodic reassessments of efficiency, equity, and relational quality. These changes in project attributes are in turn followed by changes in coordination mechanisms. Thus, the emergent model is a dynamic contingency model, in that the coordination mechanisms depend on certain contingency factors (project attributes and system attributes), some of which (project attributes) change during the course of the project, causing changes in coordination mechanisms. As may be seen in Appendix B, in some projects there was little change in coordination mechanisms over time. Some of these projects started with very little coordination and continued in that fashion, while some others made considerable use of coordination mechanisms throughout. These two scenarios can be labeled as ‘noncoordination’ and ‘consistent coordination’, respectively. In some other cases, the coordination mechanisms underwent changes during the course of the project. In all these cases, the projects started without much coordination, but coordination mechanisms were then added later in the project. This scenario can be labeled as ‘late


177

coordination’. Other possible scenarios, e.g., coordination early in the project but not later one, were not observed. The three scenarios that I did observe—in both Study 1 and Study 2—are briefly discussed below. Scenario 1 (Non-Coordination) involves little initial attention to coordination and minor change in coordination later in the project. No formal coordination mechanisms were established in P5, a simple project for a client with whom the vendor had a prior relationship. Few coordination mechanisms were seen in this project, which encountered some problems related to delays in receiving specifications from the client. However, the problems were rather minor and did not cause conflict. Consequently, the project continued without increased coordination mechanisms. A similar ‘non-coordination’ was observed in projects P9 and P11 in Study 2. In these cases, both of which involved V—E, little effort was devoted to establishing formal coordination mechanisms early in the project, and even later there was no increase in coordination mechanisms. This was understandable at P9 as the project was straightforward (simple and non-critical) and the vendor anticipated several longterm benefits from its relationship with C9. The continued non-coordination at P11 was more difficult to understand, especially since both the vendor and the client’s project manager (the sub-contractor) perceived each other as behaving opportunistically. That C11’s top management continued to pay little direct attention to project coordination, leaving it entirely to an individual who was hired for the duration of the project (and, as the vendor’s CEO pointed out, would benefit from the project taking more time!) may be attributed to the system’s non-critical nature and the fixed-price contract. These cases indicate that some initial conditions, most notably a simple and non-critical system, and high levels of equity (e.g., a fixed-price contract) and relational quality (e.g., a long-term relationship), affect coordination mechanisms throughout the project. In the absence of these factors, coordination in P11 might have been increased when opportunistic behavior by V—E was encountered in the client. Scenario 2 (Consistent Coordination) was characterized by early attention to coordination mechanisms with little or no change in them later on. In Study 1, V— A and V—B spent considerable effort early in the project in establishing formal coordination mechanisms (e.g., project management plan, client involvement plan, and parallel hierarchical structures), with V—A being the most extensive of all vendors. They were also sensitive to the client’s potential feeling of vulnerability. They tried hard to address these concerns early on by building personal relationships and inviting client executives to examine their infrastructure and capabilities. By improving relational quality and clients’ perceptions of efficiency and equity, these actions complemented coordination. The early attention to coordination through standards and plans, and to efficiency, equity, and relational quality, might have prevented a later increase in informal mutual adjustment. Projects P1, P2, P3, exhibited this scenario. In Study 2, project P8 involved similar ‘consistent coordination’. Despite the prior relationship between C8 and V—B, a C8 executive visited V—B early in the project. The project began with a combination of plans and informal mutual adjustment, although standards and formal mutual adjustment mechanisms were not set up. This

178


reflected V—B’s approach of using informal mutual adjustment to complement the formal mechanisms. The project continued with the same coordination later in the project despite some problems, including unilateral personnel changes by V—B. That the client did not seek greater informal mutual adjustment may have been due to prior excellent relationship between the two sides. Like scenario 1, Scenario 3 (Late Coordination) involves little early attention to coordination mechanisms. However, unlike scenario 1, here the project encounters significant problems and coordination mechanisms are therefore readjusted later in the project. The evolution of coordination mechanisms in the only project studied at V—D (P7) clearly followed this path. V—D and C7, as well as the intermediaries between them, ignored coordination initially in the project. Consequently, the project quickly ran into trouble, and the client took charge. Making V—D send its programmers to its site, it demanded coordination through informal mutual adjustment. In addition, projects P4 and P6 followed this path, especially in the late incorporation of some coordination mechanisms by the clients. However, projects P4 and P6 differed from project P7; late in the project, there was a high level of conflict in P7 but not in P4, or P6. Similar ‘late coordination’ was observed in project P10 in Study 2. This project began with a loose contract and few formal coordination mechanisms. Other mechanisms (including liaison roles, requirements specifications, and follow-up standards) were later introduced. However, the changes did not result from reassessments caused by performance problems, as in the other instances of this scenario. Instead, the coordination mechanisms changed when the client’s IS group got involved in the project. The emergent model of evolution of coordination (Fig. 2) includes the possibility of the project coordination being affected by changes in project responsibilities, which was also observed to a lesser extent in some other cases (see Table 5). Vendor and Client Perspectives: The two perspectives differed with respect to the evolution of coordination mechanisms. The clients did not focus on setting up the coordination mechanisms early in the project, but they seemed more likely to increase coordination later in the project, in response to performance problems, changes in project responsibilities, and unilateral actions or perceived opportunism by the vendor. Unable to observe the vendor as closely as they would observe the internal IS staff, or even a local vendor, they seemed wary of opportunism by the vendor, especially when problems arose. The clients, particularly those lacking experience in outsourcing, demanded considerable informal mutual adjustment to deal with the problems. The vendors were not much concerned about opportunism by clients. They apparently preferred the project to be managed such that coordination costs would be minimized. Most vendors took great care to establish formal, impersonal mechanisms early in the project. They used formal mechanisms and internal quality control procedures to convince the client about their capabilities. They used informal interpersonal interactions early in the project (to improve relational quality) or in response to client requests. These vendors emphasized the need to anticipate, and plan for, the problems rather than addressing them after they arise. Some other vendors (e.g., V—D), who also wished to minimize coordination costs, neglected coordination


179

mechanisms early in the project. If the project did not encounter problems and delays (as in P9 and P11), there was little change in coordination later in the project. However, if problems arose (as in P7), the client became more sensitive about its vulnerability, and demanded greater informal mutual adjustment.

5. Discussion This paper began with two sets of questions: (1) What kind of coordination mechanisms are used in these projects, and why? (2) How do these mechanisms evolve during a project, and why? These questions were addressed using 11 cases, including four and seven from client and vendor perspectives, respectively. This section revisits these questions, still drawing on the cases, but keeping some distance from their specific details. 5.1. The coordination mechanisms A variety of mechanisms belonging to four broad types of mechanisms—standards, plans, formal mutual adjustment, and informal mutual adjustment—which were adapted from Thompson (1967), Kumar and van Dissel (1996), and Kraut and Streeter (1995), have been identified. The mechanisms observed in the 11 cases are summarized in Table 4 and Appendix C. Comparison of the coordination mechanisms used in the two studies revealed greater use of informal mutual adjustment in the four cases viewed from the client perspective but relatively greater use of standards, plans, and formal mutual adjustment in the seven cases studied from the vendor perspective. During the interviews, client executives seemed less concerned about these more formal mechanisms while vendor executives showed a marked reluctance to rely mainly on informal mutual adjustment. Interviews at vendors (e.g., in P3) as well as clients (e.g., in P8 and P9) revealed that the vendors desired greater formalization of expectations regarding the system and the project management, whereas the clients preferred things to be left somewhat flexible. Consequently, client and vendor had different expectations regarding the details to be provided in requirements specification7. These differences between client and vendor perspectives seem consistent with outsourcing arrangements being sold to the clients as ‘partnerships’, causing them to consider formal mechanisms as unnecessary. However, such arrangements should not be viewed as partnerships, as Lacity and Hirschheim (1993) point out: “The term ‘strategic partner’ is unsuitable to characterize the relationship between an outsourcing vendor and their customer because the profit motive is not shared.

7

In some cases (e.g., P7, P8), this difference between the perceptions of vendors and clients was exacerbated by cultural differences. Language differences also necessitated greater coordination, especially in P7.

180


Account managers at outsourcing providers are rewarded for maximizing profits, primarily by charging customers additional fees for services that extend beyond the contract… When a customer’s costs increase, so do the vendor’s profits. How, then can an outsourcing vendor be conceived of as a partner?” (p. 8). As described in the preceding section and summarized in Table 5, six factors influenced the coordination mechanisms used in the 11 cases. Two of these are system attributes, i.e., complexity and criticality. The other four are attributes of the project. These include uncertainty, efficiency, equity, and relational quality. Overall, two project attributes—uncertainty and relational quality—most commonly influenced coordination mechanisms. Each of these factors was commonly encountered in two ways: uncertainty arose from lack of knowledge (about IT or system needs) or unclear specifications, whereas relational quality was facilitated by prior relations between the client and the vendor but inhibited by disagreement concerning responsibilities or specifications. However, each of the other four factors also affected coordination in some of the cases. There was considerable agreement across client and vendor perspectives with respect to the factors affecting coordination. The only significant differences were with respect to equity. One difference here was that the client was concerned about unilateral actions or opportunism by the vendor whereas the vendor was concerned about rework caused by unexpected changes made by the client. Thus, even in this respect, there was agreement at one level, as each party was concerned about whether the other party made an equitable contribution to the project. Another difference related to equity was that the vendors seemed less concerned about equity (one of seven projects) than clients (two of four projects). This difference is consistent with the agency theory argument the principal would more vulnerable to opportunism by the agent than the other way around (Chakravarthy & Zajac, 1984; Jensen & Meckling, 1976; Pratt & Zeckhauser, 1985). 5.2. The evolution of coordination mechanisms The paper has also developed a dynamic contingency model of evolution of coordination (Fig. 2). Based on the 11 cases of outsourced IS development, this model is consistent with prior research on evolution of interorganizational relationships in other contexts (Arino & de la Torre, 1998; Doz, 1996; Ring & van de Ven, 1994). The model indicates that a set of contingency factors (including project attributes and system attributes) affect the coordination mechanisms, and some of these contingency factors (i.e., the four project attributes) change during the course of the project, causing changes in coordination mechanisms. Specific reasons for the changes in each of the four project attributes were identified from the cases. These reasons are listed below: 1. Uncertainty increased following decisions regarding project management, including non-involvement of key groups, allocation of responsibilities, and inclusion of several intermediaries. Uncertainty also increased as a result of efficiency prob-


181

lems earlier in the project, leading to unclear specifications or poor documentation. However, uncertainty reduced as a result of learning by the project participants. 2. Efficiency considerations changed during the project in response to high or low levels of interim project performance (e.g., delays, poor-quality software). 3. Equity considerations changed following what one party perceives as opportunistic behavior or unilateral actions by the other party. 4. Relational quality changed during the course of the project, with improvements in relational quality through the two parties getting better acquainted with each other, or deterioration in relational quality due to efficiency or equity concerns. Changes in uncertainty, efficiency, equity, and relational quality were observed in several cases. Interestingly, all the factors influencing changes in coordination mechanisms seemed to increase coordination. The changes in project attributes and consequent changes in coordination mechanisms differed across the three observed scenarios. As may be expected, factors increasing coordination were most commonly encountered in cases in which the ‘late coordination’ scenario was observed (P4, P6, P7, P10). Limited change in coordination was also observed in cases (P1, P2, P3, P8) where coordination mechanisms were established early in the project (’consistent coordination’ ), as well as two other cases where simple (P5, P9) or non-critical (P11) systems were developed using a process following the ‘non-coordination’ scenario. Client and vendor perspectives differed with respect to the evolution of coordination mechanisms. The vendors, who are obviously more experienced with outsourcing, do not feel vulnerable to opportunism by clients, but, and possibly because, they prefer to go into the projects with greater preparation, as reflected in their greater emphasis on more formal mechanisms (standards, plans, and formal mutual adjustment) early in the project. Vendors use some informal mutual adjustment mechanisms during analysis and design and later during implementation but prefer to have minimal informal mutual adjustment during the intervening development phase. In contrast, the clients, who have less experience with these projects, enter the project without emphasizing either formal or informal coordination mechanisms. This, as indicated above, might reflect the project being sold to them as a “partnership” (Lacity & Hirschheim, 1993). Later in the project, they seek increased informal mutual adjustment when they develop a better recognition of their vulnerability or when the project runs into problems.

6. Conclusions When interpreting the findings several limitations of the research should be recognized. First, most projects were examined from either client or vendor perspective. The vendors and clients were distributed in a large number of countries (Colombia, India, Netherlands, Oman, Thailand, UK, and US), which contributed to the diversity of cases, but made it difficult to interview key participants from both sides of the relationship. Second, there was a preponderance of Indian vendors and American clients in the

182


cases studied. It is possible that these characteristics of the sample, the use of only 11 cases, and the selection of cases based partly on the ability to access major participants, truncated the range of coordination mechanisms or masked some other patterns of evolution of coordination. Third, the cases were studied retrospectively. This may have inhibited the ability to identify changes in coordination mechanisms and detect events that influence negotiation and commitment processes, reassessments of efficiency, equity, and relational quality, and coordination mechanisms. Fourth, the findings may have been limited by some subjectivity as only one individual interpreted and analyzed all the interview transcripts. All efforts were made to conduct the analysis in a careful and systematic fashion to minimize the effects of subjectivity. Nevertheless, it is possible that other researchers may have focused on some other issues and developed other explanations for the evolution of coordination. Finally, this research focused on one aspect of IS outsourcing, namely outsourced IS development projects, which are specific in nature and also have a clear taskbased culmination point. The findings may therefore not apply to broader and more long-term situations such as the outsourcing of the entire IS function or outsourcing the operation and maintenance of all existing systems. Despite these limitations, this paper has several implications for future research. Further research is needed to identify other coordination mechanisms, other ways in which coordination mechanisms might evolve, and other factors that influence coordination. For example, the stage of the project itself seemed to influence coordination, although its effect was not examined in detail here. Several of the cases (e.g., P1, P2, P3, P5) showed informal mutual adjustment (especially through personal visits) to be greater during the early (analysis and design) and late (testing and implementation) phases, but less during the middle (development) phase. Such further research may benefit from additional case studies of outsourced IS development projects, especially those involving clients and vendors in countries other then the US and India, respectively. Further research is also needed to examine the extent to which of this paper’s findings, including the types of coordination mechanisms used as well as their evolution during the project, can be generalized to other situations. These include other outsourced IS development projects, other kinds of IS outsourcing situations (e.g., total outsourcing of the IS function), and outsourcing of other areas (e.g., accounting). Future research may also compare the coordination mechanisms used in outsourced IS development with those used in internal IS development projects, which do not involve another organization, and considerations of equity and relational quality may be considered less important. Another potentially useful area of future research is empirical testing of the differences observed between vendor and client perspectives. Questionnaires using quantitative measures of the various constructs, as well as additional case studies comparing client and vendor perspectives on the same project would provide further insights into these differences. The concepts of uncertainty, efficiency, equity, and relational quality also need


183

further investigation in the context of outsourced IS development projects. Future research may develop measures of these constructs and then use questionnaire surveys at multiple points in time to examine changes in these three aspects as well as the coordination mechanisms. Finally, future research should examine the complex organizational processes through which the coordination mechanisms are adopted or discarded. This research has provided a preliminary model of the evolution of coordination mechanisms (Fig. 2) and presented three potential scenarios. Future exploration of the evolution of coordination would benefit from such processual perspectives as organizational learning and interorganizational dialectics, and from focusing on cognitive, symbolic, and political factors that influence the evolution. Longitudinal cases would be most appropriate for examining such dynamics of coordination. The paper also has several implications for practice. Client and vendor executives involved in other outsourced IS projects might benefit from the insights it provides into the perspective of the other party in the relationship. Client executives may consider giving greater attention to coordination mechanisms, and especially to the more formal mechanisms, early in the project, so that the more costly informal mutual adjustment does not become essential later. Clients should also seek the benefits of expertise with outsourced IS development early in the project; if the IS group has prior outsourcing experience, it should be actively involved in the initial negotiation process and if the IS group is not so experienced with outsourcing it would a good idea to seek the assistance of external consultants. Vendor executives, on the other hand, should seek ways of preventing the increase in uncertainty and the perceived drop in efficiency, equity, or relational quality, which apparently motivates clients’ demand for increased informal mutual adjustment. Investing in relational quality, avoiding actions that may be perceived by the client as unilateral or opportunistic, and managing expectations so that performance problems do not come as a complete surprise, were some of the tactics that seemed effective in the cases examined here. The paper also provides insights into the coordination mechanisms used in outsourced IS projects. Client and vendor executives managing other outsourced IS development projects would find it useful to consider the broad categories of mechanism (standards, plans, etc.) as well as the different types of mechanisms in each category (problem/issue query form, change control mechanisms, etc.) discussed in this paper. Although the numerous specific coordination mechanisms shown in Table 4 are not exhaustive, they represent a potential starting point for identifying the ways in which a particular outsourced IS project might be coordinated. Client and vendor executives should also be prepared for changes in coordination mechanisms later in the project. The paper presents a model (see Fig. 2) of the way in which coordination mechanisms might evolve. This model, along with Table 5 showing the factors affecting coordination mechanisms, suggests that events during the project may cause changes in perceived uncertainty, efficiency, equity, and relational quality, and those changes might, in turn, cause changes in coordination mechanisms. Uncertainty and efficiency seemed important throughout the project, although the nature of their impact seemed to change. Early in the project, greater efficiency (e.g., large benefits from the system) seemed to increase coordination, but

184


later in the project, coordination increased from perceived reduction in efficiency (e.g., problems with software delivered). Uncertainty also changed during the project due to several reasons, including learning by participants or poor specifications developed earlier. Equity considerations seemed not to influence coordination initially, but they became important later, usually following unilateral actions or perceived opportunism. Relational quality seemed very important throughout, and its effect on coordination seemed consistent over time; initial investments in relational quality reduced coordination, while a later decrease in relational quality (which may result from changes in project responsibilities) led to greater coordination. Finally, the cases suggest that initial actions during the project have major longterm consequences. As client and vendor enter the outsourcing relationship, they start observing each other through the mechanisms they have created. They watch each other for clues about reassessment, such as unexplained divergence between expected and actual behavior, which might cause concerns about the other party’s competence or fairness, or affect the quality of the relationship. Unless the two sides have worked with each other frequently in the past or their motives are above suspicion, early events in the relationship might have a disproportionate effect on later stages of the project. Overall, the paper suggests that the client pulls the relationship toward a hierarchy structure, wherein problems are addressed through mutual adjustments. The vendor, in contrast, pulls the relationship toward a market structure, dictated by a priori coordination structures and contracts. Both parties thus try to pull the relationship into the world they feel most comfortable, and the end-result seems to be somewhere in between—a relationship in which there is greater use of formal coordination than the client might desire and greater interpersonal interaction than the vendor might desire. Acknowledgements I am grateful to Richard Boland, Vivek Choudhury, Tim Goles, Rudy Hirschheim, Ram Nidumolu, and two anonymous reviewers at Information and Organization for their insightful comments on earlier drafts of the paper. I also thank the participants in seminars at the University of Pittsburgh, the University of Houston, and the University of North Carolina, Chapel Hill, for several useful suggestions. The research was funded in part by grants from the Lattanze Center, Baltimore, Maryland, and the Office of International Executive Education, Florida International University. Finally, I am grateful to the numerous managers at the organizations studied for graciously providing the ‘stories’ and invaluable insights. Appendix A. Some details about the data collection Interviews in Study 1, focusing on the vendor perspective, were semi-structured, using a guide containing the following broad areas:


185

1. Your role in the organization? 2. Why do off-shore software development? Disadvantages of on-site development? Advantages of off-shore development? 3. How to go about doing off-shore software development? Infrastructure needed? Acquisition/set-up of the infrastructure? Skills/manpower needed and their acquisition? Other resources needed and their acquisition? 4. When did you (or when do you plan to) start off-shore software development? Key recent projects? Schedules? #5 and #6 below were then pursued for each project. 5. Problems encountered during off-shore software development? During initial stages (project start-up)? During requirements analysis? During software development? In software evaluation/testing? In software installation? 6. Specific tactics and coordination mechanisms used to address the problems identified in #5 above. Steps taken by you and by the client? 7. Organization: Structure/Chart? People? Major business areas? Locations? Annual sales? For Study 2, the structured guide was somewhat different due to the focus on client perspective. It included the following questions: 1. Your role in the organization? 2. The system. Please briefly describe the nature of the IS developed through remote outsourcing in terms of: (a) functionality and size (no. of users); (b) technical specs; (c) budget and project duration; How innovative was the information system? How complex was the system? 3. The vendor. Who was the external vendor involved in the system development? Where was the vendor located? And where were the majority of users located? Was there a time-zone difference? Did your organization have any prior experience with this vendor? 4. The process. How was the outsourcing decision made? I.e., how did you decide to go for an external vendor, and why this particular vendor? Who participated in the decision process? Describe the negotiation process with the vendor. What were your expectations, and vendor’s? Who participated from each side? Was a formal legal contract prepared? Who prepared it? How detailed was it (please give examples)? Did you and your organization have certain expectations other than those included in the contract? Did you feel the vendor did? Please describe the requirement analysis process. How did your organization and the vendor interact during this phase? What coordination mechanisms, such as committees, task forces, liaison roles were used? The preceding question was then repeated for IS development process and then for IS implementation process. 5. Success. How successful was the system? 5=Highly successful; to 1=Highly unsuccessful. How successful was the project in terms of being (a) within budget vs. overbudget and (b) within schedule vs. behind schedule? 6. The client and vendor organization. How much prior experience has your organization had with outsourcing? This particular group? How much experience

186


has your organization had with information systems? This particular group? How large is your organization? This particular unit? How large is the vendor?How much experience does the vendor have, i.e., how long has it been around?

Appendix B. Case summaries Study 1: Seven projects studied from the vendor perspective Vendor V—A has a large share of India’s software export to the UK. Two projects (P1, P2) were studied in some detail at V—A. Project P1 was for a utility company, C1. It involved the development of a works management system for entering incoming work orders and tracking and reporting the progress relative to each order. C1 asked four vendors to do a pilot project on-site, and then selected V—A for this project. V—A split the system into 13 modules, of which five critical modules were done entirely at the client. Before the project began, the vendor developed a detailed project management plan, indicating project scope and duration, contact persons, communication procedures, frequencies of reports and meetings, and specific signoffs. Some standards were also used, including categorization of issues (technical versus functional; critical versus non-critical), numbering of FAXes, and a standard query form for changes. To facilitate formal mutual adjustment, the vendor used a hierarchical structure that was consistent with its other projects. It included, in descending order, the managing director, the development director, two development managers, together responsible for all the projects, either one (in India) or two (in India and at the client) project managers, project leaders (one for each module), team leaders (for sub-modules), and programmers. V—A insisted that the client also establish, for this project, a parallel structure. Coordination was then done at the same level. Formal mutual adjustment was also facilitated by using a separate liaison person for each type of query and submitting weekly progress reports and daily employee timesheets to the client. Informal mutual adjustment was facilitated by the vendor personnel who developed five modules at the client. They helped the vendor’s remote personnel by seeking clarifications for the other modules as well. However, these on-site facilitators were somewhat constrained by their not having seen the code for those other modules. The system was implemented on-site at the client by a team from the vendor. There was little need for other informal mutual adjustment; there was only one visit by a client executive to the vendor, during analysis, and phone calls were also used infrequently. Project P2 involved the reengineering of a stocks and bonds system, adding new functionality to the existing system while converting it from COBOL to an objectoriented system. The client C2, a large software vendor in the UK, asked the vendor to develop a pilot system before awarding it the project. V—A’s analysts did the requirements analysis at the client. FAX numbering scheme and standard query forms helped in coordinating the project. V—A gave considerable attention to the project management plan, which was discussed during two 3-day visits to the client by the vendor’s project manager. However, the project management plan did not include


187

change control mechanisms. Consequently, unexpected changes in client needs, due to changes in the software industry, led to discussions of “is it included in the original specifications?” The development manager indicated that several programs had to be rewritten due to changes made by the client, and the budget was therefore considerably exceeded. The vendor also found the client to lack experience with objectoriented programming. There was some formal mutual adjustment, primarily through fortnightly progress reports from the vendor’s project manager to the client’s project manager, but much greater use of informal mutual adjustment. The mutually agreed project management plan indicated that the client would place one of its designers at the vendor for an eight-month period during development. This individual helped in the informal mutual adjustment. However, unlike P1, where the vendor employees who were developing other modules at the client facilitated coordination, no vendor personnel were positioned at the client in this case. Phone calls and personal visits by the vendor executives (development director, development manager, project manager) were more frequent, especially during development. When V—A was last visited, its on-site team was finishing implementation at the client. However, the client was apparently satisfied with the project and had contracted V—A for another project. Two projects (P3, P4) were studied at vendor V—B, which differed considerably from V—A in project coordination. It had a project management hierarchy similar to V—A but did not insist on the client having a parallel hierarchy for the project. It set up project management plans, but they were not as detailed as those at V—A; they did not include standards for reports, communication frequencies, or numbering schemes for FAXes and queries. Instead, V—B used greater informal mutual adjustment. Project P3 was a 150 man-month project to develop a system for a client (C3) in the Netherlands. The system was intended to allow subscribing customers to order software electronically via home computers. It was developed in a language-independent fashion in English and implemented in Dutch. The initial requirements analysis was done at the client. A project plan was prepared, specifying the requirements and the pricing mechanisms for changes. The expected involvement of the client was specified through a document called the client-involvement plan, which identified the client personnel who would need to be at V—B to provide necessary clarifications, and for how long. The external (or high-level) design, was then done at the vendor. Following the approval of the high-level design by the client, the vendor did the low-level design. During this process, clarifications from the client were frequently sought by phone. Two executives from the client visited the vendor twice for a few days during the low-level design. They approved the low-level design in their second visit, following which the software was developed independently at the vendor by its programmers. Toward the end of software development, there was a three-month period during which the client tested the software and the vendor’s client-site personnel fixed the problems identified. V—B’s team at the client then installed the system. V—B’s project leader visited C3 to lead this process. No use of formal mutual adjustment, through either reports or formal meetings, was found in this project.

188


Project P4 was a strategic project for a U.K.-based client, C4, involving the conversion of a successful distribution and logistics system from AS/400 to UNIX platform. The conversions were divided into five groups, with one group being implemented in parallel with the programming for the next. The project manager, who joined the project a few months after it began, told me that the project management had been initially ignored, possibly because the vendor had done several previous projects for the client. For example, unlike P3, no “client involvement plan” was prepared in P4. The client paid the vendor based on the time spent by its personnel based on mutually agreed programmer productivity standards. Five to seven people from the client were located at the vendor throughout the project. They facilitated project management, provided frequent inputs to the vendor’s programmers, and developed test plans on the vendor’s AS/400 while the conversion was going on. They communicated with their head office through frequent (need-based and not periodic) conference calls and FAX. One person from the client stayed at the vendor for most of the project, but there was a high turnover of the other people, with most individuals visiting the vendor for three weeks. Some of them lacked a UNIX background, which posed additional problems. The priorities were frequently adjusted based on inputs from the client’s head office. V—B had to occasionally rework on some programs. It maintained a record of such situations and later negotiated additional payment from the client. No plans or standards were initially established for such additional payments. V—B’s project manager visited the client during analysis and design, and again during development. P4 was nearing completion at the time of the case study. V—B interviews indicated that C4 was satisfied with the project and a long-term alliance between the two sides was being discussed. Vendor V—C is a combination of two sister companies, which often jointly do IS projects, although they are both among the 20 largest IT vendors in India and focus on different aspects of IT. Two projects (P5, P6) were studied at V—C in some detail. Project P5 involved the development of a taxation system for a client in Thailand, with whom V—C had a prior relationship. C5 designed the system in four months by reverse engineering an existing system and adding some new functionality. The client provided the vendor the specifications and a detailed schedule of deliverables, emphasizing the need for timely progress. V—C quickly ramped up the personnel on this project, adding 20 people to the project in a week. The vendor’s personnel then developed the system in another programming language. The development was nearing completion, and a team of six people was located at the client to implement the software. Except for this, no other site visits were needed in this project. Since V—C had done some previous projects for the client, the people from the two sides knew each other well. Moreover, the vendor was able to seek help in coordination from a few of its people who were at the client for another project. The project did encounter a few problems related to delays in receiving specifications from the client, but these problems were rather minor and caused little conflict. Project P6 involved the development of a word-processing software for a USbased client, C6, with whom V—C had no prior experience. C6, a software vendor itself, wanted a new word-processing software to be developed based on an existing product. However, this software was not in keeping with the company’s stated stra-


189

tegic thrusts, and it therefore outsourced its development. No design documentation was available for the existing product. Therefore, as in P5, V—C was expected to develop the specifications for the new system by reverse engineering the existing software. The lack of clear design specifications caused some problems. One interviewee attributed the problems to different interpretations by the two organizations; unlike V—C, the client had several years of experience with the word processing software and had a clear understanding of what it wanted. The project went through design, approval of design, development, unit testing, integration, system testing, and software release. Four individuals from the vendor visited the client for a month during design, and later, three individuals visited the client for three weeks during implementation. Two individuals from the client visited the vendor for four weeks during development and then another two individuals, who had been supporting the previous software, visited the vendor for two weeks during initial software testing. Informal mutual adjustment was thus achieved through co-location and personal visits. Standards and formal mutual adjustment were used as well. The vendor established change control mechanisms, acceptance criteria, standard forms, and FAX numbering schemes. It designated its project manager as the contact person for the client, and tried to persuade the client also to identify one point of contact. However, it took the client some time to recognize the value of having an individual who would consider contrasting internal views and provide a single input to the vendor. One project, P7, was studied at vendor V—D, a large and experienced software development company. This project involved the development of a human resource management system for C7, a government organization in Oman. A total of four organizations—V—D, C7, and two intermediaries, including a local vendor who received the contract from C7 and another organization that was V—D’s local contractor—were involved, but none of them paid much attention to the coordination mechanisms in the initial stages of the project. There was no planning for the nature and frequency of reports, timing of the vendor personnel visits to the client, and sign-off points. V—D was in sharp contrast to V—A, V—B, and V—C; it did not structure the relationship so as to understand client needs, lacked a formal structure for interacting with the intermediaries, and did not plan for the language differences with the client. The vendor communicated with its local contractor but did not know what was eventually committed to the client. The project quickly ran into trouble, and was delayed by eight months. Feeling concerned, the client took charge, forcing the vendor to send its programmers to do the development at the client’s site. Study 2: Four cases studied from the client perspective Project P8 was a $0.5 million project involving enhancements to a customer service system that supported over 200 worldwide markets of C8, a Fortune 500 financial services company. C8 did the requirement analysis internally before contacting the vendor, V—B. V—B had a good reputation at the client, for which it had developed some other systems. An executive from C8 went to India to meet V— B’s people and examine its facilities before awarding the project to it. Later, the

190


client prepared a detailed project plan and negotiated schedules with V—B. However, the client and V—B had different expectations about how detailed the requirements specification would be. C8 expected V—B personnel to interpret, understand, seek clarifications, but they followed things literally. C8’s project manager acknowledged that an executive from another group at C8, which had used V—B before, had warned him about the need to provide detailed specifications. A liaison person from V—B was at the client after the requirement analysis. FAX, e-mail, and need-based conference calls played important roles in coordination. The conference calls were more frequent initially but only once or twice each week later. FAX messages were not numbered, but they were usually followed by e-mail messages seeking confirmation. The project encountered some problems during development. V—B unilaterally replaced some of the personnel working on this project with less skilled and experienced individuals, and the quality of some of the later software did not meet the client’s expectations. C8’s executives expressed these concerns to V—B, but did not increase informal mutual adjustment. Overall, they expressed satisfaction with the project, and indicated that the client would continue outsourcing to V—B. C9 is another Fortune 500 company and one of the five largest software development firms in the US Project P9 involved the development of an executive information system monitoring C9’s sales. The vendor, V—E, had its head-office in Colombia, but it also had a local office in the same city as C9’s office involved in this project. The requirement analysis took a month, and was based on V—E’s previous executive information system, to which C9 suggested changes based on its specific needs. The software was developed in Colombia. Programs were electronically downloaded to C9 every fortnight. C9 designated one individual, with the title of Manager to manage the project. He communicated regularly with the vendor’s local project manager and the vendor’s development manager at Colombia through phone and e-mail. The vendor’s development manager at Colombia visited C9 twice, for a week on each occasion. C9’s executives believed that the vendor would include some additional features within the original price. The Manager indicated that he would be much more formal if the project was more critical, and if there was not a “special, strategic relationship” between the two sides. The relationship was strategic to V—E because it would enable it to: (a) mention C9 as a reference, and (b) have access to C9’s latest technologies. The informants agreed that the vendor was more formal than C9; e.g., V—E kept a record of its communications with C9. Despite some delays and problems (for example, the volumes of actual data were much greater than what the vendor assumed), the project was viewed as successful. C10 is a large county in South East US, with over 25,000 employees. It outsourced project P10, the development of a legislature tracking system to a vendor, V—F, in another city in the U.S. A contract was prepared based on the county’s standard contract. C10’s IS manager was happy with the vendor, and reluctant to mention the contract to it, but believed that the contract should have been more stringent, with specific penalty clauses. The project was divided into four phases, but the requirements and the specific sign-offs for each phase were not indicated. The client’s IS executives attributed this to their not being involved in the early parts of the project. Several “must have” requirements were identified late in the project. C10


191

negotiated these as additional requirements for later phases. The project was coordinated through a combination of mechanisms. The vendor identified the expected role of the client personnel and specific contact persons for each participant, and all FAX messages were numbered. E-mail messages were followed by phone calls, and the client followed some phone calls with FAX messages to better document the conversation. Software was download weekly during implementation. The project also benefited from several visits by V—F personnel to the client. The visits during development and implementation were not originally planned but based on requests by the client. During the middle of the project, most communication with the vendor was through the Division Director (Development), but his involvement became more “need-based” later on. The vendor also set up a help desk for the client’s queries regarding the software during testing and implementation. The client’s executives remained concerned about outsourcing, but the project progressed smoothly and they were satisfied with the eventual system. C11 is among the ten largest food products firms in the US Project P11 involved the development of a $0.5 million executive information system, to be used on the laptops of field salespersons to track sales and account receivables. The project was based on a fixed-price contract with V—E, the Colombia-based vendor that developed the system for C9. C11 hired a Spanish-speaking subcontractor as the project manager, and then left the project management almost entirely to him. C11 initially gave V—E a small contract. Both this initial contract and the later, larger, contract, were rather loose. C11’s Vice President (IS) attributed this to the company’s approach of using a series of prototypes and the desire to give both sides considerable flexibility. The vendor’s project leader and a few other individuals visited the client for a few days to do the requirements analysis. Later, a few people visited the client to install each new release of the software. The entire development was done remotely. Few formal mechanisms were established. Along with the absence of a detailed contract, this caused some problems. The relationship was “occasionally tricky,” especially on whether a request was something new or something that changed a requirement previously included in the contract. Some problems were caused by the departure of the vendor’s local project manager during development; the vendor had no local project manager for the next four months. The client was concerned that it did not know how many, and how experienced, people were assigned to the project. The client’s project manager also believed that the vendor’s executives shirked their responsibilities for software testing. User training was based on a plan developed by the vendor. V—E trained 20 people at the client, who trained the rest. The system was generally considered a success, despite delays and some modifications needed later.

192


Appendix C. Coordination mechanisms and influencing factors in each case

Project P1 Standards

Plans

Analysis and Design

Development

Implementation

Standard query form Categorization of issues FAX numbering scheme Development schedule

Standard query form Categorization of issues FAX numbering scheme Development schedule and sign-offs Project management plan Design specifications Weekly reports

Standard query form Categorization of issues FAX numbering scheme Development schedule and sign-offs Project management plan Project management plan Weekly reports

Parallel structures

Parallel structures

Daily employee timesheets Liaison roles for queries Client-site coordinators from V—A

Daily employee timesheets Liaison roles for queries Co-location (V— A implementation team at C1)

Project management plan Sign-offs


Weekly reports

Parallel structures at V— A and C1 Daily employee timesheets Liaison roles for queries Informal mutual Client-site adjustment coordinators from V—A

Uncertainty

Criticality

Co-location Selective use of (analysis done at phone calls C1) One visit by C1 project director On-site coordinators were constrained as they had not seen the code 5 (of 13) critical


193

modules done at C1 Efficiency Relational quality

Project P2 Standards

Several problems C1 selected V— A from a group of vendors asked to do a pilot project Initial visit by C1’s project director built confidence in V—A FAX numbering scheme Standard problem/issue query form Project management plan Development schedule

FAX numbering scheme Standard problem/issue query form Plans Project management plan Development schedule Client involvement plan Formal mutual Parallel Parallel adjustment structures at V— structures A and C2 Fortnightly reports Informal mutual Co-location Co-location adjustment (Analysis done (designer from at C2) C2 at V—A)

Uncertainty

Relational

FAX numbering scheme Standard problem/issue query form Project management plan Development schedule

Parallel structures

Fortnightly reports Co-locations (V—A personnel at C2 to do implementation) Two visits to C2 Several visits to Frequent phone by V—A’s C2 by V—A calls project manager executives Frequent phone calls C2 lacked object-oriented program-ming experience and documentation V—A first asked Changes in

194


quality

Project P3 Plans

to develop a pilot system remotely Project management plan Requirements specifications Client sign-offs on design documents Client involvement plan

Informal mutual Co-location adjustment (Analysis done at C3) Two C3 executives visited V—B twice Uncertainty

software industry caused conflict on project scope Project management plan Requirements specifications Client involvement plan

Project management plan Requirements specifications Client involvement plan

Pricing Pricing mechanisms for mechanisms for changes changes Co-location (V— B personnel at C3)

C3’s lack of IS knowledge Project P4 Standards Programmer Programmer productivity productivity expectations expectations Plans Test plans Informal mutual Co-location (C4 Co-location (C4 adjustment personnel at V— personnel at V— B) B) Phone calls and Phone calls and FAXes FAXes Personal visits Conference calls (by V—B personnel) Visits by V—B personnel V—B kept records of changes needed Uncertainty V—B was doing Frequent change part of the in C4 people at project, another V—B vendor doing the rest

Programmer productivity expectations Test plans Co-location (V— B personnel at C4) Phone calls and FAXes Conference calls


Criticality Relational quality

195

“High stakes project” for C4

V—B’s partial responsibility caused conflict (“whose responsibility?”) Project 5 Plans Delivery Delivery schedule schedule Design specifications Formal M.A. Periodic reports Informal mutual Personal visit On-site adjustment (by V—C coordinators(V— executives) C personnel at C6 for other projects) Phone calls and Phone calls and FAXes FAXes Uncertainty C5 and V—C lacked detailed knowledge of the new programming language Efficiency Problems due to client’s delays in providing specifications Relational C5 and V—C quality had prior positive experiences with each other Project P6 Standards Change control Change control mechanisms mechanisms Standard forms Standard forms FAX numbering FAX numbering scheme scheme Plans Acceptance Acceptance criteria criteria Client sign-offs Design on design specifications documents Formal mutual One point of One point of

C4 satisfied with the progress, contemplating long-term alliance Delivery schedule

Periodic reports Co-location (V— C’s implementation team at C6) Phone calls and FAXes

Change control mechanisms Standard forms FAX numbering scheme Acceptance criteria Design specifications One point of

196


adjustment

contact at V—C contact at C6 One point of contact at V—C Informal mutual Phone calls and Phone calls and adjustment FAXes FAXes Co-location (V— Co-location (C6 C analysts at people at V—C) C6) Uncertainty Prior software Unclear design package had specifications poor documentation, constraining design Complexity The desired packaged software was very complicated Criticality Since C6 would sell the software, quality expectations were high Project P7 Plans Development Development schedule schedule Project budget Project budget Informal mutual Four individuals Co-location adjustment from V—D (development at visited C7 C7) Phone calls Phone calls Efficiency 8-month delay in analysis and design Relational V—D “forced” quality to do development at C7 Project P8 Standards E-mail followups of FAXes

Plans

Development schedule

Development schedule Requirements specifications

contact at C6 One point of contact at V—C Phone calls and FAXes Co-location (V— C analysts at C6)

Development schedule Project budget Co-location (V— D team at C7) Phone calls

Categorization of problems E-mail followups of FAXes Development schedule Requirements specifications


Formal mutual adjustment Informal mutual A visit to V—B adjustment by one C8 executive Frequent conference calls, e-mail, and FAX Co-location (one V—B person at C8) Uncertainty Vendor not involved in requirements analysis (done in-house by C8) Efficiency

Equity

Relational quality

Project P9 Plans


Periodic reports Periodic reports Occasional Occasional conference calls conference calls Co-location (one V—B individual at C8) Frequent use of e-mail and FAX

Co-location (one V—B individual at C8) Frequent use of e-mail and FAX

Concerns about quality of software developed late in the project Implementation delayed by 6 months V—B replaced personnel assigned to project with less skilled personnel

Another group at C8, for which V—B had earlier developed software, recommended it Design specifications Development schedule

197

Design specifications Development schedule Liaison role

Design specifications Development schedule Liaison role

Fortnightly electronic download of software

Fortnightly electronic download of software

198


Informal mutual A one-week visit adjustment by vendor’s President and development manager Phone calls, FAX, e-mail

Efficiency Project P10

Standards

Plans


Interaction through two people at V— E’s local office

Phone calls, FAX, e-mail V—E’s headoffice sent its local unit copies of all the document it sent to C9 Frequent bugs in software FAX numbering FAX numbering scheme scheme V—F’s Followed e-mail documentation with phone call procedures V—F’s documentation procedures

One week visit by V—E’s development manager and V—E’s local project manager Phone calls, FAX, e-mail

FAX numbering scheme Followed e-mail with phone call C10 followed phone calls with FAX V—F’s documentation procedures Contract

Contract Contract Client Requirements involvement plan specifications (including need for a project manager from C10) Client involvement plan Liaison roles Liaison roles Liaison roles

Weekly electronic release of software by V—F Informal mutual 10-day visit to Two visits by Visits by V—F adjustment C10 by V—F V—F personnel personnel upon project manager upon C10’s C10’s request


Uncertainty

request Phone calls, FAX, e-mail Phone calls, Help desk at FAX, e-mail V—F Non-involvement Poor of client’s IS requirements group specifications

Efficiency

Relational quality

Project P11

Standards

Plans


Some conflict regarding specifications

199

Phone calls, FAX, e-mail Help desk at V—F

Problems because vendor could not simulate the client environment Recognition of both parties’ strong commitment

Recognition of both parties’ strong commitment FAX numbering FAX numbering FAX numbering scheme scheme scheme Classified needed Classified changes into needed changes three types (“show stoppers,” “important,” “can wait”) A checklist for the training process Development Development Development schedule schedule schedule Training plan C11 hired Project manager Project manager project manager as liaison with as liaison with as liaison with V—E V—E V—E Weekly electronic download of software

200


Informal mutual Visits by V—E’s Two visits by On-site adjustment President and V—E’s President coordinator (V— remote project and project E’s local project manager manager manager) V—E’s local On-site Phone calls, project manager coordinator (V— FAX, e-mail as on-site E’s local project coordinator manager) Phone calls, Phone calls, FAX, e-mail FAX, e-mail Uncertainty Initial specifications/contract not specific Equity Fixed-price Fixed-price As the contract contract consultant tested software well, V—E reduced its own testing Junior personnel Fixed-price assigned to contract project Relational C11 asked V—E Some conflict quality to develop a regarding prototype first specifications

References Adler, P. S. (1995). Interdepartmental interdependence and coordination: the case of the design/manufacturing interface. Organization Science, 6(2), 147–167. Ang, S., & Straub, D. W. (1998). Production and transaction economies in IS outsourcing: a study of the US banking industry. MIS Quarterly, 22(4), 535–552. Arino, A., & de la Torre, J. (1998). Learning from failure: towards an evolutionary model of collaborative ventures. Organization Science, 9(3), 306–325. Bensaou, M., & Venkatraman, N. (1995). Configurations of interorganizational relationships: a comparison between US and Japanese automakers. Management Science, 41(9), 1471–1492. Blau, P. M. (1964). Exchange and power in social life. New York: Wiley. Chakravarthy, B. S., & Zajac, E. J. (1984). Tailoring incentive systems to a strategic context. Planning Review, 12(6), 30–35. Clark, T., Zmud, R. W., & McCray, G. (1998). The outsourcing of information services: transforming the nature of business in the information industry. In L. P. Willcocks, & M. C. Lacity (Eds.), Strategic Sourcing of Information Systems. New York: Wiley. Cross, J. (1995). IT outsourcing: British Petroleum’s competitive approach. Harvard Business Review, 73(May-June), 94–102. Crowston, K. (1997). A coordination theory approach to organizational process design. Organization Science, 8(2), 157–175.


201

Daft, R. L., & Lengel, R. H. (1986). Organization information requirements, media richness and structural design. Management Science, 32(5), 554–571. DeSanctis, G., & Jackson, B. M. (1994). Coordination of information technology management: teambased structures and computer-based communication system. Journal of MIS, 10(4), 85–110. Doz, Y. L. (1996). The evolution of cooperation in strategic alliances: initial conditions or learning processes. Strategic Management Journal, 17, 55–83. Egelhoff, W. G. (1991). Information processing theory and the multinational enterprise. Journal of International Business Studies, Third Quarter, 341–368. Galbraith, J. R. (1974). Organization design: an information processing view. Interfaces, 4(3), 28–36. Galbraith, J. R. (1977). Organization design. Reading, MA: Addison-Wesley. Heiskanen, A., Newman, M., Simila, J. (1996). Software contracting: a process modeling approach. Proceedings of the International Conference on Information Systems. Henderson, J. C., & Lee, S. (1992). Managing I/S design teams: a control theories perspective. Management Science, 38(6), 757–777. Huber, R. L. (1993). How continental bank outsourced its crown jewels. Harvard Business Review, 71, 121–129. Jensen, M. C., & Meckling, W. H. (1976). Theory of the firm: managerial behavior, agency costs and ownership structures. Journal of Financial Economics, 3(October), 305–360. Kirsch, L. J. (1996). The management of complex tasks in organizations: controlling the systems development process. Organization Science, 7(1), 1–21. Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81. Kumar, K., & van Dissel, H. G. (1996). Sustainable collaboration: managing conflict and cooperation in interorganizational systems. MIS Quarterly, 20(3), 279–300. Lacity, M. C., & Hirschheim, R. (1993). Information systems outsourcing. Chichester, UK: John Wiley. Lacity, M. C., & Willcocks, L. P. (1998). An empirical investigation of information technology sourcing practices: lessons from experience. MIS Quarterly, 22(3), 363–408. Mantei, M. (1981). The effects of programming team structures on programming tasks. Communications of the ACM, 24(3), 106–113. Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87–119. March, J. G., & Simon, H. A. (1958). Organizations. New York: Wiley. McFarlan, F. W., & Nolan, R. L. (1995). How to manage an outsourcing alliance. Sloan Management Review, Winter, 9–23. Nidumolu, S. (1995). The effect of coordination and uncertainty on software project performance: residual performance risk as an intervening variable. Information Systems Research, 6(3), 191–219. Nidumolu, S. (1996). A comparison of the structural contingency and risk-based perspectives on coordination in software-development projects. Journal of MIS, 13(2), 77–113. Olson, E. M., Walker, G., & Ruekert, R. W. (1995). Organizing for effective new product development: the moderating role of product innovativeness. Journal of Marketing, 59, 48–62. Pratt, J. W., & Zeckhauser, R. J. (1985). Principals and agents: the structure of business. Boston, MA: Harvard Business School Publications. Ring, P., & van de Ven, A. (1994). Developmental processes of cooperative interorganizational relationships. Academy of Management Review, 19(1), 90–118. Sabherwal, R., & Elam, J. (1995). Overcoming the problems in information systems development by building and sustaining commitment. Accounting, Management, and Information Technologies, 5(3/4), 283–309. Tesch, R. (1990). Qualitative research: analysis types and software tools. New York: The Falmer Press. Thompson, J. D. (1967). Organization in action. Chicago, IL: McGraw Hill. Van de Ven, A. H., Delbecq, A. L., & Koening, R. (1976). Determinants of coordination modes within organizations. American Sociological Review, 41(2), 322–338. Zaheer, A., & Venkatraman, N. (1995). Relational governance as an interorganizational strategy: an empirical test of the role of trust in economic exchange. Strategic Management Journal, 16(5), 373–392.

202


Dr Rajiv Sabherwal is the Emery C. Turner Professor of Information Systems at University of Missouri, St. Louis. Dr. Sabherwal’s research focuses on knowledge management, strategic management of the information systems function, and social aspects of systems development. He has published extensively on these topics, in journals including Information Systems Research, MIS Quarterly, Organization Science, California Management Review, Decision Sciences, Communications of the ACM, European Journal of Information Systems, Journal of MIS, and Accounting, Management, and Information Technology (now Information and Organization). He is an Associate Editor for MIS Quarterly, Journal of AIS, and the IEEE Transactions on Engineering Management.