Coordination of Outsourced Information System Development in ...

Proceedings of the 38th Hawaii International Conference on System Sciences - 2005

Coordination of Outsourced Information System Development in Multiple Customer Environment – A Case Study of a Joint Information System Development Project Antti Nurmi, Petri Hallikainen, Matti Rossi Helsinki School of Economics, Information Systems Science [email protected], [email protected], [email protected] Abstract In large software development projects, coordination is considered critical for the success of system development. Generally, coordination focuses on managing interdependencies among different organizational units within one organization. However, in IS outsourcing the interdependencies reach beyond organizational boundaries into coordination of development between a software vendor and a client company. Our research focuses on coordination of development in a setting where several vendors and client organizations develop a common information system. In this study we investigate the characteristic features of system development in a multiple customer environment. Especially we look at the coordination mechanisms and their evolution over time and phases of system development. Our analysis shows that the coordination mechanisms become more formal and control-oriented as the jointly developed system becomes more and more functional. Subsequently changes to the system become harder to get through the coordination mechanisms.

1. Introduction As software industry matures, less and less software is developed in-house [1]. The tighter IT-budgets force organizations to outsource their IT functions and system development as it is not their “core competence”. As an inevitable result some control over the development process is lost. Therefore, management of coordination between different parties involved in the information system development (ISD) project becomes vital for the success of the project [2, 3, 4]. We studied a consortium of Finnish Universities developing a common student record system. The common system development has been going on for about ten years. In the beginning of the project the consortium consisted of five universities, but over the years the consortium has expanded to 13 universities. The universities in Finland are funded by the government.

Decreased funding from the government in mid 1990’s and scarcity of the resources has led the universities to cooperate. Sabherwal [4] conducted multiple case studies and studied coordination mechanisms, factors affecting coordination mechanisms and evolution of coordination mechanisms in outsourced ISD projects. In addition, his analysis covers both client and vendor perspectives in outsourced system development projects. We applied Sabherwal’s [4] analysis and extended it to a setting of multiple customers and studied the different coordination mechanisms applied. Furthermore, we examined how the coordination mechanisms evolved during the system development process. We sought to find out what are the primary coordination mechanisms between the different universities, and also between the customers and the vendor(s). As this system development project has a relatively long history we have had a good opportunity to study the evolution of the coordination mechanisms over time as well. The structure of the paper is as follows. In the next section (Section 2) we shortly review the existing theories on coordination in IS projects. After that the case subject and research method are presented (Section 3). In section four we introduce the case setting. The following section describes the coordination mechanisms and their evolution in the case. In the last section (section 6) the results are discussed and finally the conclusions are drawn and the future research directions are outlined.

2. Coordination Theories Coordination problems have been studied in different scientific disciplines [5]. In information economics the research has focused on coordination costs [6, 7]. Coordination as a phenomenon has been studied also in organizational studies [8, 9, 10] and in computer science. Each discipline has a different focus, but the basic phenomenon is the same: process of managing dependencies among activities [5]. There are many

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

1


different ways to categorize different coordination mechanisms. McCann and Galbraith [11] proposed that coordination between organizational units can vary along three dimensions: cooperativeness, formality and localization. According to these three dimensions the endpoints of the organizational coordination mode continuum would be organic coordination (cooperative, informal, and decentralized) and mechanistic control (controlling, formal, and centralized). DeSanctis and Jackson [12] proposed that major mechanisms for facilitating inter-unit coordination of IT management are: structural design approaches, functional coordination modes, and computer-based communication systems. Adler [3] found five different coordination mechanisms (noncoordination, standards, schedules and plans, mutual adjustment and teams) in electrical and mechanical engineering product development. Nidumolu [13] saw coordination mechanisms as horizontal or vertical. Grant [14] categorized coordination within a firm as: rules and directives, sequencing, routines, and group problem solving and decision making. Crowston’s [15] categorization is based on dependencies between task vs. task, task vs. resource and resource vs. resource. Kim [16] modeled inter- and intra-organizational coordination by three major components: object, actor and process. In Kim’s [16] model all the relations between organizational units can be modeled with these three components. Van de Ven et al. [17] defined coordination as a mode of linking together different parts of an organization to accomplish a set of collective tasks. Malone & Crowston [5] saw coordination as process of managing dependencies among activities. However, these definitions are quite close to the concept of control and in general, coordination and control can be seen as different sides of the same coin. While coordination focuses on managing interdependencies among multiple individuals or activities involved in the overall task, control focuses on improving performance relative to certain overall goal when the goals of individual stakeholders differ from those of the larger overall entity [4]. It is also worth noting that if there is no dependency, then there is no control and therefore both concepts are used in situations where there are dependencies among different intra- or interorganizational units. Sabherwal [4] studied coordination in outsourced system development projects and categorized coordination mechanisms as • standards, • plans, • formal mutual adjustment, and • informal mutual adjustment His categorization of coordination mechanisms in outsourced information system development projects is a synthesis of prior literature on coordination theories. He argues further that “coordination mechanisms have not

been examined for either internal or outsourced IS development projects” [4]. Therefore his categorization matches our purposes. Sabherwal [4] also presents and emergent model of evolution of coordination mechanism. According to the model the coordination mechanisms are affected by, projects attributes (uncertainty, efficiency, equity, relational quality),, system attributes (complexity, criticality) and project events (learning, interim performance, unilateral actions or opportunism, and changes in project. We applied Sabherwal’s approach to our case project and sought for events or encounters that have affected coordination mechanisms.

3. Research Subject and Method Software development in university context has been studied to some degree in IS research [18, 19, 20, 21, 22]. University environment is considered to be a very challenging environment for system development. Weick [23] described universities as loosely coupled systems, where each unit preserves their own identity and separateness. Academics are individualists that can and will act according to their own desires. This ‘academic way’ is often reflected by support staff as well [23]. In our study we study co-operation between several universities and a number of vendors. Considering the different organizational environments and climates of the institutions the systems development process is even more challenging. Hence, coordinating would be a describing word for this kind of environment, where only little control is possible. Therefore our research questions are: RQ 1: What are the coordination mechanisms used in multiple customer environment? RQ 2: How coordination evolves over different phases of system development in multiple customer environment and what issues have effect on used coordination mechanisms?

3.1. Research method Given the small number of prior research on such joint system development, qualitative research approach seems appropriate. So, we use in-depth case study [24] for this outsourced system development project. A single case study is an appropriate research design under several circumstances [25]. The first rationale for using single case study design is the criticality of the case, which can legitimate the use of a single case. In our study criticality refers to a complex organizational environment, which can capture the essence of the studied phenomenon i.e. coordination in a deep level. The second rationale for

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

2


single case study is the uniqueness of the case. Having done a thorough literature review we have not found any studies of this kind of research setting studying coordination. However, the themes that we study are not idiosyncratic but rather usual in system development projects. Hence, our case is an example of outsourced system development in a complex and demanding organizational setting. The third rationale for a single case study is the revelatory power of the case. According to Yin [25] single case is revealing, when the phenomenon has previously been inaccessible to scientific investigation. In practice, these kind of revealing cases are rather scarce, but given our research setting there are some revealing aspects as well. ‘Revealing’ in our case refers to organizational setting (i.e. a group of organizations developing common information system), which can extend the current coordination theories. The single case design can further be divided to holistic or embedded case studies [25]. Holistic focuses on the global nature of the phenomenon, whereas in embedded case study design multiple units of analysis are selected. Our research setting could support both approaches, but given the nature of our research question the holistic case study seems more interesting. Nevertheless, the coordination challenges are studied through subunits of the joint information system project, (i.e. universities, consortium, vendors), but our primary interest is in the coordination between these subunits and thus coordination is studied in a holistic fashion.

3.2. Data collection Our objective is to understand the characteristic features of system development in multiple customer environments. So, there are several opinions and interpretations on [26] same issues depending from which organization we asked. Also, there are many differing views inside each organization. Taking these issues into account we interviewed people from several organizations and more than one person from each studied organization. Altogether we conducted eight semi-structured interviews and one email interview for background information. The interviews lasted from one hour to two hours. All the interviews were recorded for later analysis. The total number of interviewees was 11. Six out of eleven interviewees have been involved in this system development project from the beginning, so we have information from all the stages of system development.

We conducted three interviews in one university that has been involved in the system development project from the beginning. In contrast, we collected data from two universities that have recently joined the consortium in order to compare their views with universities that have been longer in this consortium. We interviewed two persons from the consortium, because it has a key role in this kind of organizational structure. In addition to that we interviewed two persons from one vendor company to capture the view of the vendor. Given the special nature of universities as organizations we interviewed at least two persons from each organization. From universities we interviewed IT managers and student administration personnel. A summary of the conducted interviews can be seen in Table 1.

3.3 Data analysis The interviews produced over 150 pages of transcripts and dozens of pages of field notes. In addition to that we had access to a lot of written material (theses, documents, manuals) and internal documentation (records, budget documentation, contracts. etc.) . After the interviews were conducted the interviewees had a chance to comment our transcripts. Also, we contacted interviewees for further information in case we missed some details. A one page summary was made out of all interviews to capture the key points in each interview. The data was analyzed iteratively in order to find out what actually has happened during over ten years of system development. The large number of stakeholders makes it difficult to be able to piece together an overall picture. Therefore, we divided the system development process in stages (i.e. negotiation stage (including feasibility study), requirement analysis, detailed design, coding, first implementations, maintenance and the expansion of the consortium). This followed the phases of the actual system development process, which followed a waterfall life-cycle. The division of system development to stages helps us to better identify and analyze the coordination mechanisms.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

3


Table 1 The conducted interviews Organization

Interviews

Interviewees

CIO

Project manager

Systems designer

Student administration

Administration

University 1 (early adopter)

3

2

1

-

1

-

-

university 2 (late adopter)

1

3

1

-

1

1

-

Useruniversity 3 (late adopter)

1

2

1

-

1

-

-

Consortium

2

2

-

-

-

-

2

Vendor

1

2

-

1

1

-

-

Total

8

11

3

1

4

1

2

4. Case Description Our case is a joint system development project, where 13 Finnish Universities develop a common student record system. The actual system development is outsourced. The number of vendors has changed over the years, but all the time there has been more than one vendor. The coordination between different universities and vendors is primarily done by a mediating organization i.e. consortium that has the primary responsibility of system development. Different interest groups from the universities participate in the system development process. IT staff and people from student administrative office define the specifications in co-operation with staff from the other universities and people from the consortium. After that the agreed features are frozen and then the vendor(s) will develop that feature. The organizational structure of the university co-operation has changed over the years, but a “high-level” illustration of the multiple customer system development is shown in Figure 1. The Consortium described in the middle acts as an intermediary between the universities and the vendors. In Figure 1 one university is placed in the center of the university “network”. This is for a reason, since one big university is in very central role in this development project. Firstly, this university has been involved in the project from the beginning and it is the biggest university in Finland. Secondly, this university gives premises to the consortium organization. Thirdly, this university runs a service center that provides outsourcing services to other universities in terms of IT infrastructure i.e. hardware, ITsupport, and user training. The development of the new student record system was started in 1995 by five universities. There were different reasons for these five different universities to join the

consortium. In one university the old system was too “person-centric”, and in another the old system was “out of date”, but basically, all the universities were in need of a new system. As a consequence, these five universities

Figure 1 System development in a multiple customer environment made an agreement to develop the system jointly in order to cut costs and be able to develop a better and more functional system. Another factor that pushed universities to co-operate was the decreased funding from the government. The first step of the joint development process was the foundation of the consortium, which is the coordinating organ between the universities and vendors. The first “consortium agreement” was made between five universities in 1995. In 1996 a feasibility study and risk analysis were made in order to analyze the central risks and possibilities of joint system development. The system development in outsourced multiple customer environment was considered challenging but under the

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

4


circumstances, it was found to be the most feasible solution. After the decision to proceed requirements analysis was performed in co-operation with the vendors. At this point the coordination among different organizations seemed to work well. This is due to the fact that the specifications were made in so high abstraction level that it was easy for every party to agree. However, in hindsight the university consortium did not document the requirements accurately enough, which caused difficulties in the later stages of the system development. However, this was not that extraordinary, given the different organizational and technological contexts of five different universities. The actual coding started somewhat late after the requirements analysis stage. Also, there were some delays in the first releases of the software. There were some difficulties with the application development environment as well as with the work of the vendors’. Over the years other Finnish universities have joined the university co-operation and now in 2004, there are 13 member universities. As a consequence, the original consortium universities and the late adopters are in different position in terms of learning the organizational Negotiations

1995

1996 1997

and technological environment of the system. The original members of the consortium have been involved in the system development from the scratch i.e. the system is tailored to their needs. From the late adopters’ point of view the student record system is more or less a software package that can be tailored by parameters and they can procure extra components. The major stages in system development are illustrated in Figure 2.

5. Evolution of Coordination over the System Development Life Cycle In this section we analyze the evolution of coordination mechanisms in different phases of system development and issues that have affected the used coordination mechanisms. We explain events in each phase by looking at the used coordination mechanisms and issues that were encountered during the phase. The nature of this particular system development effort leads into a development process with six distinct stages.

1998 1999

2000 2001 2002 2003

2004

Establishment of the Consortium Feasibility Study Requirements Analysis Choice of Development Tool Detailed Design Sixth University joins the Consortium Coding / Fixing Implementations Maintenance / Expansion of the Consortium

Figure 2 The system development process deal that they are exploring to undertake jointly [10]. In our case study the early stages of the system development were very informal. The idea to start to develop new In the negotiation stage, the parties develop joint (not student record system jointly emerged through informal individual) expectations about their motivations, possible relations among staff in different universities. Also, the investments, and perceived uncertainties of a business

5.1. The negotiation stage

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

5


coordination mechanisms used during the feasibility study were very informal. However, general agreement i.e. the consortium agreement was needed in order to give frames to the forthcoming co-operation. Hence, the used coordination mechanisms in the negotiation phase were informal meetings and the consortium agreement. In Sabherwal’s [4] terms these mechanisms would be informal mutual adjustments (i.e. informal meetings) and formal mutual adjustment (i.e. consortium agreement).

Additionally, it is worth noting that if this one university had joined the consortium at the later stages of the development process, it would have been very unlikely for these requirements to have had any weight in the decision. In Sabherwal’s [4] coordination categorization the most influential mechanisms in detailed design phase were informal mutual adjustments (i.e. project group) and formal mutual adjustment (i.e. consortium agreement).

5.4. Coding 5.2. Requirements analysis The requirements analysis was the responsibility of a 10 member project team. This group had participants from all five member universities, from consortium organizations as well as vendors’ representatives. The main coordination mechanism in this system development phase was the 10 member project team, which held weekly meetings, where the requirements were designed. A general agreement specifying co-operation mechanisms preceded the requirements analysis phase. In this phase there were no major coordination problems, because all the universities worked towards a common goal and were dependent on each other to be able to build the new system. However, institutional complexity (i.e. different organizational climates in different organizations) made requirements analysis difficult. The specifications were made, but they were in too general level to be useful when implementing the system. The used coordination mechanisms in this phase were informal mutual adjustments (i.e. project group) and formal mutual adjustment (i.e. consortium agreement). It might be argued that the project group could be categorized as formal mutual adjustment, but we interpret that the project group mostly worked informally.

5.3. Detailed design The most characteristic event in the detailed design phase was the choice of development tools that was made in 1997. There were some differences in the technological architectures of the universities, and therefore, the development tool was chosen to support data independence in the databases level. In fact, there was only one university that had different database technology, forcing the choice of development tools supporting several databases. Of course, there were some other influencing factors as well, but without this detail the development tool might have been different. This is a characteristic feature of system development in a multiple customer environment, where compromises will always exist. Heterogeneous organizational and technological environments bring features to system development that are absent in system within one organization.

The coding was done according to the documents made in the detailed design phase. There were some difficulties in coding phase, because there was a delay in the first release of the software. The client was under the impression that the vendors would ask for further information about the system features, but the vendor coded the system according to the documentation despite the fact that the documents were vague, and the requirements were in a too general level. This was due to the different requirements of different client organizations. In this system development phase the most influential coordination mechanisms [4] were coordination by plans (i.e. requirements documentation) and formal mutual adjustment (i.e. consortium agreement).

5.5. First implementations One university joined the consortium after the coding had started (in the beginning of 1998), because they thought they had a millennium problem. This further complicated the development process. The detailed design was already finished, so the sixth university was in different situation compared to the five original universities – it would buy more of a software package, than a tailored information system. Also, the coding phase lasted a year longer than it was supposed to, due to the insufficient documentation and communication between the vendor and the client. In spite of this the first implementation was made before the millennium. The system was at this stage somewhat unfinished. The five other universities implemented the system one by one in 2000 and 2001. In this phase several different, and somewhat incompatible coordination mechanisms were used. However, as we see it there were three primary mechanisms. The consortium agreement was there to coordinate cooperation in general level and requirements documentation and required code inspections [2] were to guide the actual system development. Therefore the used coordination mechanisms [4] were formal mutual adjustment (i.e. consortium agreement and code inspections) and plans (i.e. requirements documentation).

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

6


5.6. Maintenance and the expansion of the consortium After the first implementations the system development continued in order to improve its functionality. Between

2001 and 2004 seven more universities have joined the consortium. The information on implementations accumulated gradually, as more implementations were made. As the system became more

Table 3 The evolution of coordination mechanism System development phase

Negotiation

Requirements analysis

Detailed design

Coding

First Implementations

Maintenance and the Expansion of the Consortium

The most influential coordination mechanisms used

•Personal contacts • Informal feasibility studies •Consortium agreement

•Consortium agreement •10 member project team

•Consortium agreement •10 member project team

•Consortium agreement •Requirements documentation

•Consortium agreement •Requirements documentation •Code Inspections

•Consortium Agreement •Yearly plans •Strategy for further development •User groups (about 4) •Development Bank

Issues affecting coordination mechanisms

•Decreased funding from the government •Need for new student record system

•Institutional complexity

•Compromising

•Delayed schedule •Remote communication

•Unfinished system

•Compromising •Number of participants •Need for more precise rules

Some evidence from the material

•”There was a need for a new system in many universities. Then we discussed the possibility to develop new student record system jointly with colleagues from the other universities”.

•”The requirements analysis was generally ok, but it was made in too general level”.

•”The development tool might have been different, if one university would not have needed database independent development tool”

•“The customer thought that the vendor would ask for more precise specifications, but the system was coded according to the original documents”

•“The first implementations were several months late from the original plan and system was not even ready”.

•“There is an endless need for compromising” •“When you have 13 universities together, it is quite a jungle… And to find mutual understanding is sometimes really difficult.”

and more functional more universities joined the cooperation, which, on the other hand, made coordination more difficult. The more complex the system, and more parties involved, more coordination is needed [2, 27]. As the system development process has matured the coordination mechanisms have become more formal and the number of coordination mechanisms has increased. In the maintenance phase the used coordination mechanisms [4] are formal mutual adjustment (i.e. consortium agreement), standards (i.e. development bank), plans (i.e. strategy for further development, yearly plans), and informal mutual adjustments (i.e. user groups). Here a clear tendency could be observed: as the system became more functional the dependence on each other between the member universities has diminished. As a result the goals of the universities are not necessarily that mutual any more. So, coordination mechanisms are also becoming more and more formal and close to control. The consortium has managed to stay together, but there is an added characteristic feature in this stage: the need for constant compromising and negotiation on the most mundane details. This is because all the universities have to agree on the coming system specifications. So, some universities have started to develop the system by themselves without having to negotiate with other

consortium universities. Most of the interviewees commented that the biggest challenges of multiple customer system development are the organizational i.e. coordination issues. Clearly, the economic constraints have forced universities to cooperate. But, at the same time, the coordination of system development was seen as a challenge. Also, there were some differing views on how ready the system is. In some universities the system was seen to be ready and some other interviewees saw the system not to be even close to being ready. All these issues make organizing and coordinating system development even more challenging. The summary of the evolution of coordination mechanisms is presented in Table 3. In Table 3 we summarize the key coordination mechanisms, issues affecting them and quotes from the interviews that highlight the issues and events in each development stage. It can be observed that the number of coordination mechanisms and formality of coordination increase over time. This can be seen as a direct result of the expansion of the consortium and the diverging needs of the consortium members.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

7


6. Discussion and Conclusions In this paper we have discussed coordination in a multiple customer environment. In our research setting the most important coordination mechanisms varied in different phases of system development. In the formal level a co-operation agreement was needed to make the coordination possible. This consortium agreement was a vehicle for setting the common goal and thus the key coordination mechanism. The actual system development decisions were made in the project / user group meetings. The different project / user groups have been the primary forum of the actual system development in the late stages of system development. As the system has become more functional and more universities have joined the co-operation some universities have also started their own system development activities outside the consortium structure. Sabherwal’s [4] coordination mechanisms (standards, plans, formal mutual adjustment, and informal mutual adjustment) were all visible in some form in this student record system development process. The process started with very informal types of coordination mechanisms like informal mutual adjustment. As the system became more functional and more universities joined the consortium the more coordination was needed. As a result consortium’s organization was restructured and rules of the cooperation were more formally defined. Compromising was the most characteristic feature of system development in this multiple customer environment. This was seen as the most challenging aspect of the development process, especially, in the later stages of system life-cycle. Different organizational and technological environments of different organizations made decision making and finding a mutual understanding difficult. As the number of universities in the consortium has increased the more compromising has been needed. Compromising was present in all the system development stages. The choice of development tools was the most visible instance of this phenomenon. In Sabherwal’s [4] model there is no such a system attribute as compromising, but compromising can be seen as sort of complexity. Compromising has affected the used coordination mechanisms in two ways. Firstly, it has made system development more difficult, and therefore, increased coordination needs. Secondly, compromising has forced the consortium to formalize its decision making, which can be seen in the increasing number of used coordination mechanisms. This formality, together with the large current number of members in the consortium has made it nearly impossible for the consortium to reach any consensus agreements on development issues, which has made the evolution of the system quite slow.

Other interesting pattern in the process has been the decrease of the dependence on each other as the system has become more functional, forcing tighter controlling mechanisms. In the beginning of the development project the universities were much more dependent on each other as they all needed the new information system and no-one was able to do it completely alone. In other words the incompleteness of the system made organizations dependent on each other. But, as the system was implemented and it became more functional the dependency on other members decreased. As a consequence, if one university would decide to leave the consortium it might be able to survive on its own. This is something that would not have been possible in the early stages of the joint system development. On the other hand as coordination is by definition work of dependent parts towards common goal, control is something that is needed when the goals of the different parts are mutually shared. Altogether as dependence on each other decreases and goals of different stakeholders spread coordination mechanisms become more formal and more controloriented (see Table 3[M.R.1]). Table 3 Control vs. coordination

Dependency

Control

Coordination

Yes

Yes Malone & Crowston (1994)

Mutual Goal

No

Yes

Sabherwal (2003)

Van de Ven et. Al (1976)

Given the organizational context that is a consortium of universities the study has its limitations. First of all we studied only one case, which limits our possibility for broad generalizations. Secondly, the university environment is rather different from the business environment, although large consortium market places, such as Covisint, exhibit similar patterns and problems. And thirdly, given the large number of different stakeholders there are a lot of different views that cannot be captured by limited number of interviews and formal

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

8


documentation. However, we believe that the overall picture of this kind of situation is quite well captured even by the limited number of interviews. In the future we are interested in studying the differences of coordination and control mechanisms in a multiple customer environment. Questions like how and when control should be practiced are of great importance in all system development projects and we will study this issue in the multiple customer setting. Consortium as an organizational form has its own implications to system development. What are these advantages and challenges is also part of future research. As we have case example that have a relatively long history, we can study more deeply the evolution of coordination in terms of how and why coordination of development goes to some direction (e.g. control ÅÆ coordination ÅÆ chaos). Concepts like ‘compromising’ and dependency need more clarification and justification of what is their role in multiple customer system development. Furthermore, the political and social aspects of system development in such a setting are of great interest to us. The most interesting aspect that we will study in the future is the maintenance of the balance between control, coordination, and chaos in development in a manner that allows for agile development of new features, but maintains control and consensus among consortium participants.

7. References [1] F.W. McFarlan and R.L. Nolan, "How to Manage an It Outsourcing Alliance," Sloan Management Review, vol. 36, no. 2, 1995, pp. 9. [2] R.E. Kraut and L.A. Streeter, "Coordination in Software Development," Comminications of the ACM, vol. 38, no. 3, 1995, pp. 69-81. [3] P.S. Adler, "Interdepartmental Interdependence and Coordination: The Case of the Design/Manufacturing Interface," Organization Science, vol. 6, no. 2, 1995, pp. 147-167. [4] R. Sabherwal, "The Evolution of Coordination in Outsourced Software Development Projects: A Comparison of Client and Vendor Perspectives," Information and Organization, vol. 13, no. 3, 2003, pp. 153-202. [5] T.W. Malone and K. Crowston, "The Interdisciplinary Study of Coordination," Acm Computing Surveys, vol. 26, no. 1, 1994, pp. 87-119. [6] V. Gurbaxani and S. Whang, "The Impact of Information Systems on Organizations and Markets," Communications of the ACM, vol. 34, no. 1, 1991, pp. 59-73.

[7] J.Y. Bakos and E. Brynjolfsson, "Information Technology, Incentives, and the Optimal Number of Suppliers," Journal of Management Information Systems, vol. 10, no. 2, 1993, pp. 37. [8] J.R. Galbraith, Designing Complex Organizations, Reading, MA: Addison Wesley, 1973. [9] P.S. Ring and A.H. Van De Ven, "Structuring Cooperative Relationships between Organizations," Strategic Management Journal, vol. 13, no. 7, 1992, pp. 483. [10] P.S. Ring and A.H. Van de Ven, "Developmental Processes of Cooperative Interorganizational Relationships," Academy of Management. The Academy of Management Review, vol. 19, no. 1, 1994, pp. 90. [11] J.E. McCann and J.R. Galbraith, "Interdepartmental Relations," in P. Nystrom and Starbuck W., ed., Handbook of Organization Design, New Jersey: Oxford University Press, 1981, pp. 60-84. [12] G. DeSanctis and B.M. Jackson, "Coordination of Information Technology Management: Team-Based Structures and Computer-Based Communication Systems," Journal of Management Information Systems, vol. 10, no. 4, 1994, pp. 85. [13] S.R. Nidumolu, "A Comparison of the Structural Contingency and Risk-Based Perspectives on Coordination in Software-Development Projects," Journal of Management Information Systems, vol. 13, no. 2, 1996, pp. 77-113. [14] R.M. Grant, "Toward a Knowledge-Based Theory of the Firm," Strategic Management Journal (1986-1998), vol. 17, no. Winter Special Issue, 1996, pp. 109. [15] K. Crowston, "A Coordination Theory Approach to Organizational Process Design," Organization Science, vol. 8, no. 2, 1997, pp. 157. [16] H.-W. Kim, "Modeling Inter- and Intra-Organizational Coordination in Electronic Commerce Deployments," Information Technology and Management, vol. 2, no. 3, 2001, pp. 335. [17] A.H. Van de Ven, A.L. Dahlbecq, and R. Koenig, "Determinants of Coordination Modes within Organization," American Sosiological Review, vol. 41, no. 2, 1976, pp. 322338. [18] M. Newman and F. Noble, "User Involvement as an Interaction Process: A Case Study," Information Systems Research, vol. 1, no. 1, 1990, pp. 89-113. [19] F. Noble and M. Newman, "Intergrated System, Autonomous Departments; Organizational Invalidity and System Change in a University," Journal of Management Studies, vol. 30, no. 2, 1993, pp. 195-219. [20] M. Newman and D. Robey, "A Social Process Model of User-Analyst Relationships," MIS Quarterly, 1992, pp. 249-266.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

9


[21] A. Heiskanen, M. Newman, and J. Similä, "Software Contracting: A Process Model Approach," in Proceedings of International Conference on Information Systems 1996, 1996, pp. 51-62. [22] A. Heiskanen, M. Newman, and J. Simila, "The Social Dynamics of Software Development," Accounting, Management and Information Technologies, vol. 10, no. 1, 2000, pp. 1-32. [23] K.E. Weick, "Educational Organizations as Loosely Coupled Systems," Administrative Science Quarterly, vol. 21, no. 1, 1976, pp. 1. [24] G. Walsham, Interpreting Information Systems in Organizations, Chichester: Wiley & Sons, 1993. [25] R.K. Yin, "Case Study Research: Design and Methods," Applied Social Research Methods Series, Vol. 5, Newbury Park, CA: Sage Publications, 1984. [26] H.K. Klein and M.D. Myers, "A Set of Principles for Conducting and Evaluating Interpretive Field Studies in Information Systems," MIS Quarterly, vol. 23, no. 1, 1999, pp. 67-93. [27] M.V. Koushik and V.S. Mookerjee, "Modeling Coordination in Software Construction: An Analytical Approach," Information Systems Research, vol. 6, no. 3, 1995, pp. 220.

0-7695-2268-8/05/$20.00 (C) 2005 IEEE

10