Collaborative Infrastructure Formation in Virtual Projects - CiteSeerX

Collaborative Infrastructure Formation in Virtual Projects J. Roberto Evaristo University of Illinois at Chicago 601 S. Morgan Street, MC 294 Chicago, IL 60607 [email protected]

Bjørn Erik Munkvold

Department of Information Systems Agder University College Serviceboks 422 4604 Kristiansand, Norway [email protected] forthcoming in the Journal of Global Information Technology Management March 15, 2002 An earlier version was accepted for publication at AMCIS 2000, Long Beach, California.

Collaborative Infrastructure Formation in Virtual Projects Abstract In this paper, we discuss the concept of collaborative IT infrastructure. Based on data from our own research plus case studies from the literature we propose a framework for the implementation of such infrastructure at the level of hardware, software, and protocols or guidelines on how to manage such projects. This framework is applied to a typology of projects including four dimensions: number of sites, number of projects, locus of project (intra versus interorganizational), and level of cultural homogeneity versus heterogeneity. The resulting insights allow us to present considerations on the successful implementation of a collaborative IT infrastructure for different types of virtual projects. A summary of insights obtained and future research suggestions are also offered.

I.

INTRODUCTION

Throughout the nineties, different forms of virtual projects have become more widespread, as a result of the increasing focus on globalization and organizational flexibility. Although the concept of 'virtualness' is still fraught with different meanings, a virtual project is commonly defined as involving collaboration between project members at different geographical sites, where the sites can be internationally distributed and also include different organizations (Adams and Adams, 1997). The key distinguishing factor of virtual projects from distributed projects is the time frame: a virtual project is more ad hoc and and of a temporary nature. Virtual projects can also be seen as closely linked to the concept of virtual organizations (Davidow and Malone, 1992). However, these two concepts should not be regarded as indistinguishable, as virtual projects can also be conducted in the context of 'traditional' organizational structures. Further, although this often is the case, not all virtual organizations are of a project-based nature (Mowshowitz, 1997). As argued by Marshall et al. (1999), at the heart of both virtual projects and virtual organizations are "the webs of networked microcomputers and telecommunications technologies, which facilitate realtime interactivity in ways unknown more than a few years ago" (p. 484). This explicates the reliance of all virtual structures upon an IT infrastructure supporting communication, coordination and collaboration among the organizational units participating in the virtual collaboration. This infrastructure should provide universal access (Markus, 1987) to the different participants in the form of synchronous and/or asynchronous communication media, necessary IT applications for working on shared information objects (e.g. documents and drawings), as well as tools for scheduling and coordination. In several cases, the formation of a virtual project will imply a need to establish such a common IT infrastructure, as this type of organizational arrangement often involves collaboration among several different organizational units in different locations, that may also comprise different organizations. However, in the literature discussing virtual projects and organizations the existence of this infrastructure is usually taken for granted, and surprisingly few have addressed the process of establishing this infrastructure. For example, Marshall et al. (1999) list the following as the 'Critical Success Factors for the virtual organization': Shared purpose, shared risk, trust, mutual benefit. We will here argue that a supporting collaborative IT infrastructure also should be regarded as a critical success factor. The focus of this paper is on the aspects concerned with managing the implementation of a collaborative IT infrastructure for supporting virtual projects. Little research has been identified that deals with this issue, both in the project management and the IT implementation literature. The paper borrows from data that we have collected in the course of our long-term research studies on virtual and distributed projects to develop a general framework for the implementation of collaborative infrastructures, and applies this as a basis for discussing characteristics of this formation process in different types of virtual projects. In general, this discussion illustrates a need for applying project management techniques to deal with the complexity of this type of implementation. The paper is structured as follows. First we will define the key concepts of collaborative infrastructure and IT implementation to be used in the rest of the paper. This is followed by a brief review on previous research on virtual projects, including a description of several mini-cases of issues related to the formation of collaborative infrastructure in virtual projects. These mini-cases are drawn from multi-cultural situations, and will help provide insights on that aspect of project management as well. Based on the common experiences described, we then propose a framework for collaborative IT infrastructure implementation. Some consequences for globalized IT infrastructure implementation are also discussed. This framework is then combined with a typology of project forms, resulting in infrastructure implementation considerations for different types of projects. Finally, we provide conclusions for this work as well as future research directions. II.

DEFINITION OF KEY CONCEPTS

Collaborative infrastructure The term IT infrastructure is most commonly seen as composed of hardware, software, data and telecommunications & networks, i.e. the 'physical infrastructure' (Martin, et al., 1999; Palmer, 1998). However, there are several examples of how this definition is expanded to also include other elements. Saga and Zmud (1994) apply the term 'administrative infrastructure development', defined as "policies or formal rules associated with an application's use and the establishment of personnel positions or budgetary lines directly linked to the application, its training, its support, or its use" (p. 76). Building on actor-network theory, Monteiro and Hanseth (1996) introduce the term 'information infrastructure' to put focus on the standardization processes that take place in the

formation of institutional arrangements and new work practices evolving around the introduction of new information technologies and their alignment with the organization. And in a study on the increasing adoption of meeting schedulers in two large software organizations, Grudin and Palen (1995) partly ascribe this to the "pervasive supporting infrastructures" evolving in these organizations, including both technical (network, software and support) and behavioral infrastructure. The last here refers to the fact that people have become more used to incorporating technology in their work, such as e-mail. In this paper we will apply the term 'collaborative infrastructure' to denote the various elements comprised in the infrastructure needed to support a virtual project. According to this, a collaborative infrastructure comprises hardware, telecommunication networks, software (e.g. different forms of collaboration technology, such as conferencing tools, application sharing, workflow, etc.), organizational routines for using the technology including allocation of roles and responsibilities, and finally some support apparatus offering both technical and procedural support in the application of the technology. IT implementation The term IT implementation may have different meaning in different areas of research and practice. In environments concerned with developing IT systems, implementation will often refer to the actual coding of the specified system, i.e. the activities concerned with making the technology work according to the specifications (Grudin, 1991). In MIS research and among IT consultants, implementation will usually be understood as “an organizational effort directed towards diffusing appropriate information technology within a user community“ (Cooper and Zmud, 1990). To distinguish between these two understandings, Walsham (1993) uses the term 'organizational implementation' when referring to the last meaning of the term. Kwon and Zmud (1987) define IT implementation as including six phases: initiation, adoption, adaptation, acceptance, use and incorporation, thus comprising the complete cycle from needs analysis to full utilisation of the technology. The focus in this paper on the implementation of a collaborative IT infrastructure, can be seen as related to the adaptation stage in the Kwon and Zmud phase model. According to Cooper and Zmud (1990), the adaptation stage involves the development, installation and maintenance of the IT application, and the revision and development of organizational procedures. Further, this stage also includes the training of the organizational members in the new procedures and in the IT application. Although often used as a unified concept, the possible contextual variations create a multitude of different forms of IT implementation projects. Some of the possible different contextual dimensions that can be used for distinguishing between different types of IT implementation projects are intraorganizational vs. interorganizational, single location vs. distributed, in-house vs. vendor based systems, and differences in technological scope (Fichman, 1992; Prescott and Conger, 1995). Fichman and Kemerer (1994) argue that the many fundamental differences among the types of IT and the implementation contexts make it unrealistic to develop a unifying theory on IT adoption and diffusion. Instead they argue for focusing on the distinctive characteristics of the implementation context, and develop local theories for these. In this manuscript we will focus our attention on the following four dimensions, because they are at the crux of the definition of virtual projects and virtual organizations: single versus multiple locations, single versus multiple projects, intra versus interorganizational locus, and homogeneous vs. heterogeneous culture. The majority of the IT implementation literature deals with intraorganizational implementation of in-house systems in a single location. It is interesting to note here that few of the studies on IT implementation have applied a project management perspective. Instead, most of this research is using a diffusion of innovation perspective (Prescott and Conger, 1995). In comparison, project management has a much stronger hold in areas related to software development, such as software engineering and software quality management. III.

EXAMPLES OF INFRASTRUCTURE IMPLEMENTATION IN VIRTUAL PROJECTS

As virtual projects and virtual teamwork become increasingly widespread, empirical studies of such practices are starting to appear. For example, a study of the adaptation of collaboration technology in an interorganizational virtual team in Boeing-Rocketdyne illustrates how this process involved continuous alignment between organizational environment, group structures and technology (Majchrzak, et al., 2000; Malhotra, et al., 2001). Part of the conclusions involve a clearer understanding of the need for flexible technology, strategy and work processes geared to a better fit between needs and tasks. Recent studies on global virtual teams also illustrate how these teams face additional challenges compared to more 'localized' virtual teams - challenges related both to people issues (cultural diversity, language barriers and discrepancies in technological proficiency) and technology issues (hardware and software accessibility, reliability and compatibility) (Dube and Pare, 2001). As a set, these findings

clearly point out the need to understand the different issues surrounding virtual projects, and that several of these issues are related to infrastructure implementation. This realization is part of the motivation for our study. In this section, we complement these findings by discussing several examples – or mini-cases – of infrastructure implementation in virtual projects, based on our own research. These examples were chosen to discuss issues related to infrastructure implementation in virtual environments: (A) establishing a technical infrastructure, (B) scheduling and coordinating different software versions, (C) dealing with cultural diversity and geographical distance, and (D) communication issues related to the structuring of software development efforts. Based on the combined insights afforded by this set of mini-cases, we will derive a framework for collaborative infrastructure implementation. A. Establishing a Technical Infrastructure Munkvold (1999) studied the organizational network NNB (North-Norwegian Building Group), formed by four independent Norwegian companies in the building industry to compete for the contract of building the media village for the 1994 Winter Olympic Games at Lillehammer. Further expressed goals of the network were to exploit common resources and to compete on new, international markets. The process of developing tenders in this network was very resource demanding, and Telenor R&D was therefore asked to provide communication services that could support this work. They established a communication network among the different organizations in NNB, using ISDN with TCP/IP functioning as a virtual LAN. Based on this communication network, they developed a communication package offering integrated e-mail, computer-supported telephony, file sharing and fax. The system was initially planned to be ready early in 1994, so that installation and training could take place after the first phase of the Lillehammer project was completed. However, the project ran into different technical problems, causing a delay in the implementation of nearly six months. The main reason for this problem was delays in the implementation of the ISDN services in Norway. There were also problems with limited availability of ISDN-solutions for PC, and incompatibility between the NNB virtual LAN and the existing LANs in the member organizations. By the time the technology was ready for use, the Lillehammer project was in its second peak period, involving the dismantling of the media village. The NNB organizations did not have time to introduce the technology during this period, and the installation and training therefore had to be postponed until after the completion of the Lillehammer project. At this stage, joint activity in NNB was low. The two largest companies became engaged in new projects on their own, and without new collaborative projects there were no incentives for using the technology. The implementation in NNB exemplifies how the process of establishing the technical infrastructure in a virtual project may not be trivial. Interoperability problems due to heterogeneous technological platforms combined with an immature stage of ISDN technology created several obstacles that had a crucial impact of the entire implementation project. The example also illustrates that before the technical infrastructure is in place, the project can not advance to the further levels of implementing collaborative software applications and developing routines for effective utilization of these applications. B. Scheduling and coordination Bell Core used to be the MIS Department of the pre-breakup AT&T (Evaristo and Scudder, 2000). It had created all the billing, invoicing and operation systems for what became the Baby Bells. Therefore, they were a natural choice for Baby Bells when any update on their systems was needed. However, a feature that may have been required and paid by, say, Pacific Bell, should not be made available to the others. The problem was then how to generate a new version of the software that could be shipped to all Baby Bells without giving away features not paid for or which could infringe copyrights. The solution encountered was to create a matrix structure, where project managers were assigned specific “Bells,” and therefore took ownership of the development of certain features, or enhancements to the software. At the same time, there was a higher level project manager who was aware of all different features being worked on by the group as a whole. This manager avoided the likelihood of duplicate development. Ultimately, the situation here included several projects being performed in several locations – with strong interdependencies both across sites and projects. The key insight afforded by this case is that although all the technical infrastructure was in place, the teams did struggle on how to coordinate their own actions with the other teams. In other words, the actual protocols and procedures for coordinating the highly related work across different teams and projects, although working relatively well, were the result of trial and error, and not exactly similar across locations and projects.

C. Cultural Diversity and Geographical Distance Issues Time Warner, Toshiba, and US West formed a joint venture with the objective of implementing fiber in several Japanese cities (Evaristo and Scudder, 2000). The process consisted of American designers using a GIS to come up with a rough install plan for cable in certain Japanese neighborhoods. These maps were then shipped to Japan, where construction managers would survey the actual physical location and check for consistencies or problems. At that point, they would fix the map, send it back to Denver, where local designers would use the corrected map as a base to order the materials and equipment needed to install fiber in that Japanese neighborhood. Orders were placed to several suppliers, and then later shipped to Japan. The containers would then eventually arrive in Japan, and installation proceeded. Some of the problems included items shipped to Japan without extensive testing, and then used in situations where they failed to perform. Japanese technicians strongly felt that Americans had not used appropriate effort in making sure that everything was working, and blamed them for the problems. Japanese technicians also made mistakes in map corrections, and the final result was distrust from both sides, besides strong blaming. One of the solutions encountered was to enable the whole team from both sides of the Pacific to meet face-to-face to iron out these problems. Although these meetings were not enough to solve all problems, what we saw was a resulting willingness to work more on how to solve them. Moreover, once the structure and strong routine of design map – send to Japan – correct map – send back to US – final details worked out – was established, then the amount of actual interaction decreased a bit, and the whole project started working as a well-oiled machine. Three strong conclusions can be derived in this situation. First, that trust on a virtual environment is totally critical for the success of the project (Carmel, 1999) (Jarvenpaa and Leidner, 1998). Second, that one of the best ways to create this trust is face-to-face encounters, although alternatives exist. Third, that even the existence of the best collaborative IT infrastructure is not sufficient in highly unstructured jobs. Conversely, as the structure increases, the availability of collaborative infrastructure improves the effectiveness of the interaction. D. Communication Issues Suleiman et al. (2000) describe a situation where “analysts” (graduate students at a Rocky Mountain area university) had the opportunity to interview “users” from another university sixty miles away, with the objective of describing the user’s registration system. One distribution list was set up including “analysts” – about 25 – and the “users”, roughly the same number. The analysts never met the users in a face-to-face environment. Most of the interaction problems were related to poor use of the medium, such as too many questions in the same email, or questions which required too much effort on one single email (for instance “please list all input and outputs of your system”). A follow up study had “analysts”, who were students at a Norwegian university, interviewing users from a university in the East Coast of the U.S. to develop program specifications which were eventually shipped to student developers in another Rocky Mountain area university. This time the availability of software was different in the interaction of users-analysts and developers-analysts. The combined results of these two studies suggest that there may be a clear need for a set of guidelines on how to use IT to support a virtual development project. In particular, there were strong cultural differences between the direct communication style of the Norwegians students who were perceived as almost rude by their American counterparts. Some of these and other differences could in fact also be due to specific group characteristics more than to national culture, but the overriding lesson is that one should be very aware of potential culture differences and its implications. In the next section we will present a framework for IT infrastructure formation to support virtual projects. IV.

A FRAMEWORK FOR COLLABORATIVE INFRASTRUCTURE FORMATION IN VIRTUAL PROJECTS

Three Levels of Collaborate Infrastructure Implementation Based on the experience data provided in the previous section, we now propose a framework comprising three levels of collaborative infrastructure and challenges and key concerns related to the formation of this infrastructure. The situation described in the North Norwegian Building Group suggests that the first concern is to have the technical infrastructure totally implemented and tested before any project, virtual or otherwise, is attempted. We will call that the first level, and propose that most issues are related to the hardware and network infrastructure. The second level of collaborative infrastructure formation, as chronicled in several of the other mini cases, is related to software readiness, as evidenced by installation, testing, and final availability to users. The problems we have found at this level mostly relate to the fact that many times people tend to appropriate different uses to the

software than originally intended by designers (Poole and DeSanctis, 1990). Therefore, the outcomes might not be exactly those planned. Also, when users try to use a particular feature that was “advertised” by the analysts and find out that this particular feature is not available or works in a different way than intended, they may not want to come back to try it again. This was the case with the Norwegian/US systems analysis experiment, where some of the features originally claimed to be present in the software were not operational to the extent promised, resulting in a large difference on the outcome as well as on the type of interaction. Finally, the third level relates to available guidelines. Quite possibly, this may be where most of the differences between traditional and virtual projects are. For instance, let us assume that beginners in virtual projects may tackle something like a distributed text-writing project. Relatively simple decisions such as who is holding the “editable” version and who can use it as read-only (basically, concurrent update issues) need to be made explicit. Such problems disappear when people start using software with versioning control to work on their distributed project, but this typically only happens when a decision is made to move toward that type of environment. In fact, it is interesting how many basic issues are missed because people are trying a virtual environment for the first time. For instance, Suleiman et al. (2000) suggest that a well-defined task and deadline description may increase the chances people may have a good rapport across locations. Similarly, they suggest that some of these simple rules may include: only one question per email, absence of open-ended questions, at least at the beginning of the exchanges, and that the existence of a project manager or facilitator is also relevant (Evaristo and Katzy, 2000). A general complicating issue in these projects is time frame. The traditional concern in distributed projects relates to non-concurrency of work and the resulting issues with difficulties of synchronous communication across time zones. For virtual projects, the temporary nature implies additional considerations related to connecting and dismantling the collaborative infrastructure. However, although a particular virtual project is finite in duration, there are likely to be others to take its place. And even if some of the physical infrastructure may need to be dismantled as in the Lillehammer example, in many others the only discontinuity will refer on the task and team composition. Therefore, the development of hardware, software and policy guidelines will help not only current specific collaborative projects but also future ones. The key challenge thus becomes to capture 'best practices' from a current virtual project, as a basis for further development of the various levels of infrastructure. Another critical factor is effective training of team members previously inexperienced in virtual project work. The challenges and concerns related to each level in our framework will clearly be influenced by the type of virtual project we are describing. In the next section, we will discuss a typology of projects, and will then base our argument for the different types of implementation on it. A Typology of Collaborative Projects Figure 1 presents a general typology of projects (Evaristo and Fenema, 1999), with number of geographical locations and number of projects as the key dimensions. A simple view of Figure 1 suggests that as many as 7 different types of projects exist. The inclusion of the locus dimension (intra versus interorganizational projects) expands the typology to 14 project types. In practice, some of these combinations are unlikely, for instance, the single project, single location, which is not that likely to be interorganizational. But the fact remains nonetheless that there are many possible combinations.

Single Location

Single Project

Program (Multiple Projects)

Traditional Project

Co-located Program

Multiple Traditional Projects

Multiple Co-located Programs

Multiple Virtual Projects: Discrete Locations

Multiple Virtual Projects: Shared Locations

Multiple Virtual Project

Locations

Fig. 1. Project Typology (Adapted from Evaristo (1999)) where: = Project = Location

Since we are acutely aware of the importance of culture, we need to add a fourth dimension to this typology: homogeneous or heterogeneous cultures. For the purposes of this argument, we are borrowing Hofstede's (1980) definition of culture as “the collective programming of the mind which distinguishes the members of one human group from another” (p. 260). A homogeneous project culture, therefore, would be a project where all members originate in the same national culture, whereas a project with heterogeneous culture will have a sizable proportion of the team originating in different national cultures. The cultural make-up of the team, although potentially related to geography and number of projects, is something that needs to be observed instead of inferred. In this vein, a single traditional project could have a very large number of culturally heterogeneous teammates, where a multiple distributed project could have childhood friends still working together, and therefore fairly culturally homogenous, even if working in a distributed fashion. The argument presented by Evaristo (2000) is that in heterogeneous cultural situations the misunderstandings and potential lack of trust are likely to be higher, hampering further satisfactory project management. The conclusion is that the more heterogeneous the team make-up, the more it is necessary to surface assumptions as well as behavioral expectations. Our attention to organizational locus and culture thus adds two extra dimensions to the project typology in Figure 1. For simplicity of display, we do not present a graphical representation including these other two dimensions. One can perhaps better abstract that for each one of the cells in Figure 1, there would be a two by two set of possibilities: culturally heterogeneous versus homogenous, and intra vs. interorganizational project. Theoretically, in each of these 4 cells (times the 7 cells in Figure 1) there would be different considerations in terms of collaborative infrastructure implementation. We will apply the extended typology as a basis for our discussion of collaborative infrastructure formation in different types of virtual projects. A complete analysis of all 28 project forms is beyond the scope of this paper. Further, as mentioned earlier, some of these cells either represent unlikely situations or merely simplifications of more complex project forms. Therefore, we restrict the discussion to the more generic situations from which we can assume that all others could be folded in. This includes the following situations: traditional projects (single project, single location,), single virtual project (single project, multiple locations), and multiple virtual projects (multiple projects, multiple locations). The first of these represents the most simple project form in Figure 1. Most of the empirical research on IT implementation actually focuses on this type of project. Thus, the traditional project is included here to enable comparison with other more complex project forms. The single virtual project represents the most common form of virtual projects, i.e. that which includes a single project in different locations. Examples A, C and D in the previous section all fall into this category. The third type of project, i.e. multiple virtual projects represents the most complex form. Example B represents an instance of this type of project. It is interesting to note that all these types of projects, be they in homogeneous or heterogeneous cultural contexts, need to comprise all three levels of infrastructure formation as defined in our framework. However, the key issue is the extent to which this happens, which is different in each type of project. In the following section, specific characteristics of each of these three types of projects will be discussed and related to the three levels of collaborative infrastructure implementation defined earlier. Collaborative infrastructure implementation in traditional projects It can be argued that the traditional project category in Figure 1 does not apply to virtual projects, as the collaboration takes place in a single location. Single location is defined as involving a distance between project stakeholders that is considered by them as having the project co-located (Evaristo and Fenema, 1999). In fact, studies have shown that distance between offices in the same building may actually represent a barrier to face-toface collaboration (Kraut, et al., 1990), thus resulting in the preference of other communications media such as phone or e-mail. However, even co-located projects may benefit from collaborative technologies, as it is the case in decision support rooms. It is also common that much of the project work in a single organization may take place in an asynchronous mode, using e-mail and other types of communication tools. Further, technologies for supporting coordination (e.g. workflow management and calendaring and scheduling) and information sharing (e.g. document management systems and knowledge repositories) are increasingly being implemented for supporting intraorganizational project work conducted in single locations. The three-level model of collaborative infrastructure implementation presented earlier suggests that traditional projects are characterized by the following. Similar to all types of projects, the technical infrastructure needs to be

in place and operational before the following two levels can be realized. The degree of variation in the existing infrastructure in the organization will depend on whether the organization has developed and implemented an IT strategy or whether investments and technical upgrades are made more on an ad hoc basis. In any case, the existing technical infrastructure will normally be more homogeneous than in a distributed project involving multiple organizational sites. Further, the activities related to acquiring and installing new hardware are relatively easy to manage when conducted in a single project in a single organization. The same arguments apply for the second level, or the implementation of collaborative applications in the project. Planning and scheduling of the activities related to installation, testing, integration with existing software, and training of users will normally be of a relatively low complexity. For example, all users can be trained at the same location, and as the users will share much of the same background, culture and experience the need for adapting the training to different users is not great. However, this should not be taken as to imply that the implementation of a collaborative infrastructure in traditional projects is always trivial. For example, political and cultural issues may create important challenges in this type of projects (Walsham, 1993). Level three in the process of collaborative infrastructure formation involves the specification of organizational routines and guidelines for effective use of the technology. Studies of the implementation of different forms of collaboration technology have identified several potential barriers in this process (Bowers, 1994; Ciborra, 1996; Munkvold, 2002; Orlikowski, 1992). The flexible nature of collaboration technologies like Lotus Notes may result in that the users develop different mental models of the technologies, resulting in inefficient use. Further, the implementation of collaborative applications will often result in that tacit organizational practices are made explicit, such as in the case of workflow technologies, and may also require new work practices where people are expected to share information openly even though it is considered incomplete. This implies a transparency in the work processes that may feel uncomfortable to users. All together, these studies show that the need for developing guidelines for effective use of collaboration technology is great, even in a traditional project situation. Although this may be a challenging task, the definition and implementation of these routines will be easier to manage in a traditional project than in a virtual one. For example, a decision to change work procedures and introduce new mandatory guidelines is less problematic in the context of a single organizational structure than in a project possibly comprising several independent decision-structures with varying incentive systems and work cultures. Further, in a traditional project there will at any time be possible to resolve any conflicts or ambiguity through face-to-face communication. This situation changes when there are more locations, projects, organizations, cultures, or a combination of these elements. In the next two sections, we will discuss this more complex situation. Collaborative infrastructure implementation in a single virtual project The single virtual project form comprises a single project conducted in multiple geographical locations. According to the definition of virtual projects, the sites can be internationally distributed and also include different organizations (Adams and Adams, 1997). Thus, compared to infrastructure implementation in traditional projects the management of this type of project requires inter-site coordination or boundary spanning across the multiple sites (Evaristo and Fenema, 1999). The organization of the implementation project will typically involve representatives from the IT units of the different sites, where these exist. However, there will usually be established a core IT implementation team that has the overall responsibility and mandate to conduct the different project activities (Munkvold, 1999). The staffing of this team may be subject of negotiation among the participating units. Another dimension that distinguishes IT implementation in virtual projects from traditional IT implementation is the time frame for this organizational arrangement. By definition, a virtual project is temporary in nature, being established to exploit a specific business opportunity and then being dissolved when the project is completed (Palmer, 1998). Based on this general description of IT implementation in virtual projects, some further characteristics related to the implementation of a collaborative IT infrastructure in virtual projects are discussed. There are key differences from traditional implementation at all three levels. For instance, the technical infrastructure now has to accommodate (a) telecommunications capabilities – typically internet connection, but maybe other alternatives as well, and (b) appropriate translation mechanisms across potentially different platforms across different organizations. As exemplified in the NNB project, heterogeneous technological platforms in the different locations may create problems with interoperability. This may imply a need for conducting extensive tests of different combinations of hardware and network technologies prior to installation and use. Moreover, in a globalized environment one has also to be concerned with differences in local infrastructure sophistication and availability.

At the second level, collaborative software to help the stakeholders work in geographically distributed locations should be made available. Also related to this level, testing is more complex compared to in traditional projects, because many possibilities and combinations have to be anticipated and checked. For example, in cases where new collaborative applications need to be implemented, it is important that these also can be integrated with the application portfolio currently in use at each site. For instance, Loftin (2001) suggests a tool for design engineering in virtual environments. Even more general is the Collaborative Virtual Workspace tool described in Maybury (2001). In general, the geographical dispersion in these projects creates logistical challenges related to installation, testing, training and support at each site. Training here also needs to be adapted to the background and former experience of the users at each site. The functionality of such software needs to be adapted to support not only different work styles but also support for different languages and other preferences. The third level is now particularly crucial. Guidelines on how the projects should be conducted need to exist, as well as appropriate tools to help manage these projects. Training in effective, integrated use of these tools becomes an important issue (Munkvold and Line, 2001; Qureshi and Zigurs, 2001). This also involves the allocation of roles and responsibilities related to the information handling in the project. In cases where the virtual project involves interorganizational collaboration, effective use of the technology will be dependent on that a level of trust is established among the participants (Malhotra, et al., 2001). The development and negotiation of organizational routines can also be further complicated by cultural differences among the different sites, as illustrated in example C. Members of different organizational cultures may often have different norms, values and policies, that may lead to misunderstandings, hidden agendas, uncertainty and conflict (Evaristo, 2001). In the case of multinational projects, national cultural differences also come to play, e.g. related to management behavior (Dube and Pare, 2001). However, interorganizational differences are often found to be stronger than national differences, at least among western companies (Doz, 1988). Cultural distance may be a problem when trying to establish a common understanding of the possibilities and limitations of using IT to support collaboration. At the same time, this technology can be regarded as a means for supporting the communication between the partner firms, thus contributing to reducing the cultural distance. The use of a common IT infrastructure can also serve as an integrating factor between the collaborating partners (Ragusa and Bochenek, 2001). Collaborative implementation in multiple distributed projects Our most complex collaborative project involves (a) many projects, (b) each of which can be worked from many locations, (c) and the stakeholders can belong to different organizations. We also have interdependencies and resources shared across these projects and locations. Actually, the other project forms in Figure 1 can be adapted from this one by relaxing one or more constraints. The crucial difference of interdependencies (as compared to previous virtual forms) creates special needs for the collaborative infrastructure. Knowledge sharing involves making available selected information across different projects to appropriate stakeholders. It should, in addition, involve prioritization schemes, cross-site and crossproject calendaring and other project management tools such as Gantt charts. In the Bell Core example, the different project managers had to be informed on the status of the projects which interacted with theirs on a need to know basis. The higher level project managers, on the other hand, were involved in several projects located in different cities. It was extremely important for them to be able to prioritize their efforts across those commitments. Globalized, multiple virtual projects are more complex than those in a single country in the same lines as discussed previously.

V.

CONCLUSION AND IMPLICATIONS

In this manuscript, we have presented a framework for collaborative infrastructure implementation and then applied this to a categorization of virtual project types. The result of this exercise generated a set of insights. First, it pointed out critical differences in the implementation of collaborative infrastructure between traditional projects, single virtual projects and multiple virtual projects. Although they all can be related to the three different levels of collaborative infrastructure implementation (hardware, software, guidelines), we also found that they will differ considerably in the degree of sophistication needed across these levels. In summary, we found that (1) all types of collaborative projects need hardware solutions which become somewhat more complex as the 'virtualness' increases; however, (2) the software solutions in virtual projects are an order of magnitude more complex, involving completely different sets of features than those needed in traditional projects. Also, guidelines become an important issue, since this paradigm of team working is relatively new and fraught with uncertainties. Finally, (3) in multiple virtual projects the software needed is at least as complex as the set of products used under single virtual projects, but the protocols or guidelines become an order of magnitude more complex. This situation is still not widespread.

We have also noted that there are strong implications for the implementation of collaborative infrastructure for global virtual projects. Most of these refer to technical aspects, but one should not underestimate the importance of cultural issues in potential usage patterns, potentially affecting the eventual success or failure of the overall project. Future research may develop more fully the nature of how our framework interacts with the different cells in the extended project typology. An important contribution related to this will be the development of suggested guidelines for the conduct of the implementation of collaborative infrastructure for different types of virtual projects. From a practitioner’s perspective, we know that most of the project management techniques existing today stem from the traditional single project, single location situation. The current manuscript extends this situation and proposes that in complex collaborative projects more guidelines for stakeholder interaction need to be developed. In addition, it suggests that project management tools appropriate for these types of projects need to be developed and implemented. REFERENCES

Adams, J.R. and Adams, L.L. "The Virtual Project: Managing Tomorrow's Team Today," PM Network (11:1), 1997, pp. 37-42. Bowers, J. "The Work to Make a Network Work: Studying CSCW in Action," Proceedings of the Proceedings of CSCW 94, Chapel Hill, NC, 1994, pp. 287-299. Carmel, E. Global Software Teams: Collaborating Across Borders and Time Zones, Prentice Hall PTR, Upper Saddle River, New Jersey, 1999. Ciborra, C. Groupware and Teamwork: Invisible Aid or Technical Hindrance?, John Wiley and Sons, Inc., Chichester, 1996. Cooper, R.B. and Zmud, R.W. "Information Technology Implementation Research: A Technological Diffusion Approach," Management Science (36:2), 1990, pp. 123-139. Davidow, W.H. and Malone, M.S. The Virtual Corporation. Harper-Collins, New York, 1992. Doz, Y.L. "Technology Partnerships between Larger and Smaller Firms: Some Critical Issues," In Cooperative Strategies in International Business, C. F. J. and P. Lorange (Eds.), Lexington Books, Massachussetts, 1988, pp. 317-338. Dube, L. and Pare, G. "Global Virtual Teams," Communications of the ACM (44:12), 2001, pp. 71-73. Evaristo, J.R. "The Management of Distributed Projects Across Cultures," Proceedings of the BITWORLD, Cairo, Egypt, 2000 Evaristo, J.R. "Non-consensual Negotiation in Distributed Collaboration," Communications of the ACM (44:12), 2001, pp. 89. Evaristo, J.R. and Fenema, P.C.V. "A Typology of Project Management: Emergence and Evolution of New Forms," International Journal of Project Management (17:5), 1999, pp. 275-281. Evaristo, J.R. and Katzy, B. "Anatomy of a Distributed Proposal Writing Process," Chicago, IL, 2000. Evaristo, J.R. and Scudder, R. "Geographically Distributed Teams: A Dimensional Analysis," Proceedings of the Thirty-third Hawaii International Conference on Systems Sciences, Maui, Hawaii, 2000 Fichman, R.G. "Information Technology Diffusion: A Review of Empirical Research," Proceedings of the Thirteenth International Conference on Information Systems, Dallas, 1992, pp. 195-206.

Fichman, R.G. and Kemerer, C.F. "Toward a Theory of the Adoption and Diffusion of Software Process Innovations," In Diffusion, Transfer and Implementation of Information, L. Levine (Ed.), Elsevier Science, B.V. North-Holland, 1994, pp. 23-30. Grudin, J. "Interactive Systems: Bridging the Gaps Between Developers and Users," IEEE Computer (24:9), 1991, pp. 59-69. Grudin, J. and Palen, L. "Why Groupware Succeeds: Discretion or Mandate?," Proceedings of the Fourth European Conference on Computer-Supported Work, Stockholm, Sweden, 1995, pp. 263-278. Hofstede, G. Culture's Consequences: International Differences in Work Related Values, Sage, Newbury Park, CA, 1980. Jarvenpaa, S.L. and Leidner, D.E. "Communication and Trust in Global Virtual Terms," Journal of Computer mediated Communication (3:4), 1998. Kraut, R.E., Egido, C. and Galegher, J. "Patterns of Contact and Communication in Scientific Research Collaboration," In Intellectual Teamwork: Social and Technological Foundations of Cooperative Work, J. Gallegher and R. E. Kraut (Eds.), Lawrence Erlbaum, New Jersey, 1990, pp. 149-172. Kwon, T.H. and Zmud, R.W. "Unifying the Fragmented Models of Information Systems Implementation," In Critical Issues in Information Systems Research, R. J. Boland and R. A. Hirscheim (Eds.), Wiley and Sons, Chichester, 1987, pp. 227-251. Loftin, R.B. "Design Engineering in Virtual Environments," Communications of the ACM (44:12), 2001, pp. 4950. Majchrzak, A., Rice, R.E., Malhotra, A., King, N. and Ba, S. "Technology Adaptation: The Case of a Computer Supported Inter-Organizational Virtual Team," MIS Quarterly (24:4), 2000, pp. 569-600. Malhotra, A., Majchrzak, A. and Carman, R. "Radical Innovation without collocation: A Case Study at BoeingRocketdyne," MIS Quarterly (25:2), 2001, pp. 229-249. Markus, M.L. "Toward a "Critical Mass" Theory of Interactive Media, Universal Access Interdependence and Diffusion," Communication Research (14:5), 1987, pp. 491-511. Marshall, P., Burn, J., Wild, M. and McKay, J. "Virtual Organisations: Structure and Strategic Positioning," Proceedings of the 7th European Conference in Information Systems, Copenhagen, 1999, pp. 482-495. Martin, E.W., Brown, C.V., D.W., D., Hoffer, J.A. and Perkins, W.C. Managing Information Technology, Prentice Hall, Upper Saddle River, NJ, 1999. Maybury, M. "Collaborative Virtual Environments for Analysis and Decision Support," Communications of the ACM (44:12), 2001, pp. 51-54. Monteiro, E. and Hanseth, O. "Social shaping of information infrastructure: on beingspecific about the technology," In Information Technology and Changes in Organizational Work, W.J. Orlikowski, G. Walsham, M. R. Jones and J.I. DeGross (Eds.), Chapman and Hall, London, 1996, pp. 325-343. Mowshowitz, A. "Virtual Organization," Communications of the ACM (40:9), 1997, pp. 30-37. Munkvold, B.E. Implementing Collaboration Technologies in Industry: Case Examples and Lessons Learned. Springer-Verlag, London, 2002. Munkvold, B.E. "Challenges of IT implementation for supporting collaboration in distributed organizations," European Journal of Information Systems (8:4), 1999, pp. 260-272.

Munkvold, B.E. and Line, L. "Training Students in Distributed Collaboration: Experiences from Two Pilot Projects," Journal of Informatics Education and Research (4:1), 2001, pp. 1-14. Orlikowski, W. "Learning from Notes: Organizational Issues in Groupware Implementation," Proceedings of CSCW '92, Toronto, 1992, pp. 362-369. Palmer, J.W. "The Use of Information Technology in Virtual Organizations," In The Virtual Workplace, M. Igbaria and M. Tan (Eds.), Idea Group Publishing, Hershey, 1998, pp. 71-85. Poole, M.S. and DeSanctis, G. "Understanding the use of Group Decision Support Systems: The Theory of Adaptive Structuration," In Organizations and Communications Technology, J. Fulk and C. Steinfield (Eds.), Sage, Newbury Park, CA, 1990, pp. 173-193. Prescott, M.N. and Conger, S. "Information Technology Innovations: A Classification by IT Locus of Impact and Research Approach," The Data Base for Advances in Information Systems (26:2), 1995, pp. 20-41. Qureshi, S. and Zigurs, I. "Paradoxes and Prerogatives in Global Virtual Collaboration," Communications of the ACM (44:12), 2001, pp. 85-88. Ragusa, J.M. and Bochenek, G.M. "Collaborative Virtual Design Environments," Communications of the ACM (44:12), 2001, pp. 40-44. Saga, V.L. and Zmud, R.W. "The Nature and Determinants of IT Acceptance, Routinization, and Infusion," In Diffusion, Transfer and Implementation of Information Technology, L. Levine (Ed.), IFIP Transactions, Elsevier Science, North Holland, 1994, pp. 67-86. Suleiman, J., Evaristo, R. and Kelly, G. "Facilitating and Coordinating Distributed Joint Applications Development," Informatica (24:2), 2000, pp. 159-166. Walsham, G. Interpreting Information Systems in Organizations, John Wiley and Sons, Chichester, 1993.