Creating Heterogeneity â Evolving Use of Groupware in a ... - CiteSeerX

Computer Supported Cooperative Work 12: 381–409, 2003. © 2003 Kluwer Academic Publishers. Printed in the Netherlands.

381

Creating Heterogeneity – Evolving Use of Groupware in a Network of Freelancers BETTINA TÖRPEL1, VOLKMAR PIPEK2 & MARKUS RITTENBRUCH3

1 IT University of Copenhagen, Glentevej 67, DK-2400 Copenhagen, NV, Denmark (E-mail: [email protected]); 2 Research Group HCI and CSCW (ProSEC), Institute for Computer Science III, University of Bonn, Römerstr. 164, D-53117 Bonn, Germany (E-mail: [email protected]); 3 CRC for Enterprise Distributed Systems Technology (DSTC), Level 7, General Purpose South, The University of Queensland, QLD 4072 Australia (E-mail: [email protected])

Abstract. This contribution is a long-term study of the evolving use of the organization-wide groupware in a service network. We are describing the practices related to organization-wide groupware in conjunction with local groupware-related practices and how they have proceeded since the organization was established. In the discussion of these practices we are focussing on issues such as: 1. tendencies for proliferation and integration, 2. local appropriations of a variety of systems, 3. creative appropriations, including the creation of a unique heterogeneous groupware fabric, 4. the design strategy of multiple parallel experimental use and 5. the relation between disparate local meanings and successful computer supported cooperative practice. As an overarching theme we are exploring the explanatory value of the concepts of objectification and appropriation as compared to the concepts of design vs. use. Key words: evolving use, freelancers, groupware fabric, multiple approaches of groupware use, multiple parallel experimental use, objectification and appropriation, organization-wide groupware, Participatory Design, service network

1. Introduction When we first discovered that a research field of “Evolving Use of Groupware” had formed, we immediately had an idea of what it was about: At some point in time, a groupware system is introduced in an organization, then the members of this organization use the groupware system over a period of time. The situation before the introduction may then be compared to the situation afterwards; phases of use may be constructed and compared with each other; the use might be described in a differentiated manner, for example in terms of group-related use issues or in terms of the interplay between technological and organizational changes. While working through our empirical records from the introduction and use of groupware in a network organization, we realized that we would have to revise our assumptions on the groupware, the organization and the use. We have perceived some assumptions as seriously limiting the understanding of real-life phenomena of evolving use of groupware. Some critical examples are:

382

BETTINA TÖRPEL ET AL.

• When ‘the’ groupware is expected, it is easy to miss the fact that usually the groupware system is only one element of an infrastructure. • When ‘the’ organization is the social unit of the analysis, important issues related to the multiplicity of approaches on the individual or subgroup level easily escape the analytical focus. Groupware-mediated collaboration with customers or in inter-organizational projects also transcend the organizational boundaries and are beyond a view focused on ‘the’ organization. • Sometimes under the label of “organization” only a certain type of organization is regarded, such as organizations of a certain size, with a special division of labor or with institutionalized structures of negotiation between capital/management and labor. With expectations only justified for certain organizations, issues in other organizations cannot be addressed. (For Participatory Design and organizational specificity Törpel et al. (2002) contains a compilation of issues.) Many of the organizations which served as cases for the observation of long-term groupware use in the literature seem to be ‘traditional’, for example in terms of horizontal (departments) and vertical division (hierarchy) of labor (cf. Orlikowski, 1996; Pipek and Wulf, 1999; for an early overview cf. Bullen and Bennett, 1990). • When ‘use’ is assumed to mean that a group of persons avails an artifact to itself in exactly the manner its creators had in mind when they created the artifact, then issues such as creative use or creation in use are difficult to take into account. Furthermore, in a perspective of ‘use vs. design’, issues that cannot clearly be attributed to either ‘use’ or ‘design’ easily become neglected. To a certain extent, it has already been acknowledged that, when groupware is introduced into an organization the individual and organizational appropriations often differ from the expectations of designers, managers and other actors (cf. Rogers, 1994; Orlikowski, 1996; Ciborra, 1996; Karsten and Jones, 1998). In this contribution we are presenting the case of a network of freelancers. We found that an appropriate description and analysis of evolving use of groupware in this setting would have to capture issues such as: • Even though ‘the’ organization has existed as a legal entity, the assumptions of homogeneity and stability proved inappropriate for the organization as well as for the units and projects under its umbrella. • Even though organization-wide groupware has been introduced, other groupware systems have had local and organization-wide impact. • Even though ‘the’ introduction took place, the infrastructures into which the groupware had to be integrated were diverse and thus required diverse processes of adoption. • Even though ‘the’ groupware has been in use, the concept of ‘use’ as different from (opposed or complementary to) ‘design’ would not grasp the creativity that has been part of mastering the challenges of computer supported collaboration and coordination.

CREATING HETEROGENEITY

383

Based on the information we gathered, we are telling the story of groupware use in a network organization. Systems with groupware functionality have been locally adapted, interpreted and appropriated into contexts of specific practices, purposes and infrastructures at any time. We are depicting a whole range of practices and systems employed for the diverse purposes of collaborative work in local settings of the described organization. The emergence of specific appropriations will be exemplified by a number of accounts of appropriations of the organization-wide groupware and other groupware systems. The text and its line of argument are structured as follows. We are first introducing the concepts of objectification and appropriation as a potential alternative to the concepts of design vs. use (section 2). This is followed by a description of the empirical procedures performed for obtaining the information drawn upon (section 3). The next section is devoted to a characterization of the studied organization, a service network (section 4). This description provides the background for understanding the section on working with organization-wide groupware in conjunction with other groupware throughout the history of this network organization (section 5). Since an isolated account based solely on the organization-wide groupware would not give much insight, we are describing use issues of the organization-wide groupware in relation to local practices and infrastructures, including the utilization of other groupware functionality. The observed practices are to be discussed in relation to existing research concepts (section 6). We will, for example, recur to the concepts of objectification and appropriation for appreciating the potentials of the described groupware related practices. Many have questioned the appropriateness of the concepts of design vs. use and call for the deconstruction or replacement of these concepts. For our case we are asking whether the concepts of design vs. use could help to capture interesting issues relevant for setting up, maintaining, refining and utilizing collaborative infrastructures. We are also discussing observed practices in the context of concepts from Participatory Design and Computer Supported Cooperative Work.

2. Objectification and appropriation In our view, the notion of ‘evolving use’ has seemed problematic as long as the ‘use’ part of it denotes something outside the realm of creativity (often referred to as ‘design’). An ‘uncreative’ understanding of ‘use’ would limit our appreciation of what practitioners achieve in use. The concepts of ‘design vs. use’ emerged from and are closely related to a view of the division of labor and cooperation that is ignorant of issues such as: • the diversity of the possible contributions to artifact-mediated practice, • the blurred boundaries between these possible contributions, • the creative aspects of forming new practices related to technologies and • the dynamic and interactive aspects involved.1

384


Following authors like Suchman (1994), we suspect that the concepts of design vs. use should be deconstructed and replaced by more suitable concepts: To move beyond simple dichotomies in our understanding of who and where we are within the divided terrain of technology production and use, we need to begin by deconstructing the terms ‘designer’ and ‘user,’ and reconstructing relevant social relations that cross the boundaries between them. (p. 25) In this contribution we are rather exploring the analytical, explanatory and practical value of the concepts of objectification and appropriation. Artifacts are normally created to serve a certain purpose. In the process of creating the artifacts, these purposes become inscribed in the artifacts; once the artifacts exist, the purposes are materialized in them. The creators of artifacts inscribe – current, future and desired – aspects of reality, as they subjectively experience them, into the artifacts. This means that accounts of reality, as subjectively experienced by creators, become frozen in artifacts. This process and result has been referred to as “objectification” (Leont’ev, 1978; Leontyev, 1981). In the case of computer applications, practical necessities as well as anticipations of reality and subjective experiences become materialized in hardware and software components which provide functionality. Usually some portions of the provided functionality are not explicitly created and provided; other portions are not even intentionally created by the developers. Sometimes, for example, hierarchy or gender is objectified in groupware, but nobody explicitly mentions these hidden properties; sometimes objectifying hierarchy or gender in groupware does not even occur consciously. Once an artifact is available in a certain setting, it may be used according to the purposes for which it is suited. Users discover and make the possibilities of the artifact available to themselves for their specific purposes, resulting in an artifact-mediated practice specific for the artifact and for their setting, situation and practices. This process and outcome has been referred to as “appropriation” (Leont’ev, 1978; Leontyev, 1981). The adoption of artifacts is constructive in itself (Hales 1994 convincingly describes this for CSCW). The purposes ‘read out’ of the artifact by its potential users may differ from the purposes anticipated by the creators of the artifact. Appropriation hence is a constructive and creative process in various respects. For example: • The purposes of the artifacts have to be re-invented (re-constructed, realized) by the users. • In reinventing the purposes, purposes not anticipated (at least not consciously) by the creators may be discovered. • As part of appropriating the artifact, users might create new artifacts, thus objectifying new purposes. • In appropriating the purposes of the artifact, users somehow modify their own practice and their environments (e.g. organizational structures), thus gradually creating a new reality.


385

The interpretation of artifacts and the resulting purposes and practices may not only differ from those anticipated by the artifacts’ original creators but also evolve over time, e.g. become increasingly differentiated or restricted. Numerous accounts of what we subsume under the concepts of objectification and appropriation can be found in the literature. To illustrate the way we are availing to ourselves these concepts in this contribution we are referring the reader to a selection of articles which exemplify some of the issues we have in mind, activities that are involved, possible outcomes in terms of artifacts and social facts, and constructions involved in mediating the generation of these outcomes. In the research on technical collaboration support in hospitals carried out by the group around Ina Wagner, problems related to choices necessary for building collaborative systems were elaborated. Wagner (1993), drawing on the objective of electronically supporting a hospital’s operating room schedule, points at how each design choice rests on partial assumptions so that any design outcome would favor certain groups at the expense of others. The article also contains reflections on how the respective computer applications contain assumptions in a ‘petrified’ state that are perpetuated through the application’s very existence and potentially conveyed by being integrated into existing infrastructure and practices. A study of 19 software projects already conducted in the 1980s (Curtis et al., 1988) draws attention to specific objectification activities. The authors describe what the people involved in large software projects exactly do to give the computer applications their particular shape. Hofmann (1999) illustrates the implications of design decisions for the creation and adoption of a number of early word processing systems. Key persons for the design of these word processing systems had different preconceptions of the target group and their work. These preconceptions heavily influenced the functionality of each system. Once in use, each system contributed in shaping the work it was employed for. Shaping the work also meant shaping the identities of and attributions toward the groups of persons who did the work. The author argues that since what is perceived to be typically ‘male’ and ‘female’ and what is perceived to be typical work for men and women occurs in a dynamic historical process of mutual ascription (see also Törpel, 2000). Hofmann (1999) shows that design decisions do not inevitably establish particular practices and images. She rather stresses that the historical dynamic involves appropriations where the outcomes cannot be predicted. She concludes that design decisions and the meaning of gender are dynamically interrelated. Bowker and Star (1998) focus on classifications and standards as potentially mediating processes of artifact creation. According to the authors, creating and putting classifications and standards into effect rests on subjective perceptions of the relevant features of the objective in question, historically grown work practices and vocabularies used, and power to create and enforce classifications and standards. Built into artifacts, such as community systems and computer applica-

386


tions, the classifications and their underlying assumptions, experiences and power structures potentially become reified and hence spread further. 3. Empirical approach The cooperation between the service network SIGMA2 and researchers mainly of the Research Group on HCI and CSCW (ProSEC) at the University of Bonn was initiated in 1996. (The researchers have worked in the fields of Computer Supported Cooperative Work and Participatory Design. Their educational backgrounds are in the fields of computer science, social sciences, mathematics and psychology.) The managing directors and a few IT interested members of SIGMA had just started the process of decision making on an organization-wide groupware. The researchers perceived the situation in SIGMA as a challenge for applying and extending their knowledge of groupware development, introduction and use in network organizations. The researchers, a managing director of SIGMA and a few other SIGMA members agreed to cooperate as part of a research and development effort where the two sides expected to learn from each others’ fields of expertise. Over a period of more than five years, a multitude of empirical data has been collected based on a multifaceted empirical approach. In the remainder of this section we are only mentioning those relevant for this study. As part of getting an overview of SIGMA in terms of its members, practices, services, means, structures etc., 16 semi-structured interviews were conducted in the fall of 1997. The informants included managing directors, freelancers in the areas of IT and HR, providers of infrastructure-related services, a promoter and an honorary internal consultant. Since 1997, the researchers have attended a variety of working groups and task forces on a regular basis. Frequently, the researchers contributed to these meetings. Minutes and notes have been taken and archived by the researchers. The circles the researchers have attended are • the working group on information technology and knowledge management (1997–spring 2000), • a working group of researchers and SIGMA individuals who sporadically gathered, supposedly with the aim of initiating a participatory process for the development of a future organization-wide groupware system replacing the one then installed (1998–2000), • the taskforce for the decision making on the future organization-wide groupware replacing the first organization-wide groupware system (spring–winter 2000), • the taskforce for the introduction of this new groupware system (since 2001) and • the working group on SIGMA’s organizational culture (since 1998). The researchers have read and analyzed the contents communicated via the organization-wide groupware systems as far as they were accessible to all users. (Many emails and project-related electronic bulletin boards, for example, have not


387

been accessible.) Other documents, such as the letters of the managing directors to the shareholders, the shareholders’ contract (and its updates) and the annual business report, have been read and analyzed. Since 1999, researchers have attended the annual shareholders’ meeting; since 1998, researchers have participated in the fair of SIGMA’s areas of service provision held in conjunction with the annual shareholders’ meeting. This fair provides the opportunity to present services and approaches to colleagues and actual and potential customers. During summer 2000, a group of researchers, including two of the authors of this contribution, conducted interviews with 12 trainers and consultants. The topic of these interviews was work practices – with and without tool support, with and without collaboration. The authors of this paper draw on their own research and the research done before they joined the ProSEC research group. For acquiring their current knowledge on SIGMA, they have read existing minutes, transcripts, memos and notes, as well as previous research papers (e.g. Rittenbruch et al., 1998). Collegial discussions have also contributed to the authors’ current knowledge. Our version of those events that occurred before 1996 is based on reports of informants. 4. SIGMA – a service network In this section we are depicting the organization we studied. We are first describing the organization itself (section 4.1) and then important organizational changes (section 4.2). Section 5 is devoted to groupware practices in the organization. 4.1. ORGANIZATION OF SIGMA SIGMA is a network of about 200 freelancers who offer services, mainly training and consulting. About another 300 people occasionally work under the umbrella of SIGMA or otherwise belong to SIGMA’s wider spectrum. The members of the network live and work in locations throughout Germany. Working with SIGMA means providing one’s own workplace, typically a home office with telephone, fax, personal computer, internet access, a variety of software programs and other technical equipment. The founders who established the enterprise in 1992 have been the managing directors. Since then, they have envisioned the organization as a network organization. The enterprise and its services are basically structured along the lines of projects. Each project is unique in terms of its objective, time limit and composition of team members. Only a few projects are long-term projects that last for a few months or longer; typically projects last from a few days to a few months. After finishing a training or consulting project, SIGMA’s members turn to new tasks. SIGMA has responded to the market by continuously changing its spectrum of products and services. Most SIGMA members continuously extend their service

388


portfolios and offer their skills and potentials to a twofold (labor) market: the market within SIGMA and the ‘global’ market outside. Both markets constantly change, and hence the service portfolios of the SIGMA members. Except for a few employees whose work contributes to the infrastructure of the network (for example administration and office work), the network does not employ members on the basis of contracts. Instead, the individual members are freelancers. They pay 10 percent of their incomes from their training and consulting activities to the network. Another 20–25 percent is paid to the person who established a project. (Sometimes this is the only person who is involved in the project). In return for the network fee, SIGMA’s members can use the network-internal services which help address situations freelancing trainers and consultants typically face. The network-internal ‘Financial Services’, for example, offer cheap shortterm loans in cases when members otherwise are unable to pay their invoices, and they financially bridge the time between sending an invoice until the customer pays. Other internal services are related to financial and tax issues, marketing support etc. For the purposes of administration the network has formed several regional branches. The only office space rented by the company itself (and not by individuals or regional groups) is located in a city in the western part of Germany. In a few cities members of SIGMA have rented shared office space, usually for representation and meetings and not as a workplace. Only one of these regional offices has a secretary. Members with similar business interests have formed “business area groups” to coordinate their activities. Some of these associations have recently transformed into private liability companies; some of these spin-offs have become part of a network of private liability companies headed by SIGMA (see below). Communication within and beyond the network has been a crucial factor for the work within SIGMA. Meetings of various levels of exclusivity and dedication frequently take place; member groups from a certain area or with overlapping interests typically meet in bars or restaurants. These meetings serve purposes such as establishing relationships, exchanging experiences and ideas and developing new business objectives. Power has been concentrated in the group of the four managing directors. The ordinary organization members have not been grouped by a formal organizational hierarchy. In most projects the positions of project manager(s) and regular project member(s) are assigned. A member’s project position can vary from project to project. The organizational culture rests on a self-image of a self-organizing network. Despite SIGMA’s official ideology of self-organization, informal power structures have developed. Relations of power, dependence and subordination are omnipresent and strongly structure the organization and the activities of its members. These relations exist along lines such as business success, position in the flow of information and communication, skills related to the commissioning of projects and promotion from the side of the managing directors. How far the issue of informal power relations reaches is may be illustrated by the fact that the criteria


389

of who belongs to, successfully works with and remains working with SIGMA or groups within SIGMA are as vague as they are effective: they regulate the inclusion or exclusion of individuals. The four managing directors have politically and officially represented SIGMA. They have had the ownership of many of SIGMA’s most important customers. Because of their experience and their familiarity with the network and its structures, members and customers, they have also had an information monopoly. Their work has been formally approved and their status confirmed by the shareholders in their annual meetings. About 40 network members have had the informal status of ‘managers’. Members have become eligible for this status when the annual turnover of their projects reached a certain level and when they had the approval of the managing directors. The ‘manager forum’ meets four times a year to discuss and make decisions concerning strategic issues. For the network members, the described flexibility often means working conditions in accordance with their individual preferences and constraints (e.g. time budgets), more responsibility than ‘ordinary employees’ for the projects in which they work, work based on motivation and self-determination and an income about as high as in other organizations where comparable services are provided. However, they trade this off for disadvantages such as less security concerning their future incomes, for example in cases of work disability. They work in a hybrid situation between being employed and being autonomous freelancers. Many SIGMA members have experienced enormous economic pressure. This has enhanced a tendency toward decisions for immediate individual gains at the expense of investing work in the organization’s infrastructure. SIGMA has had the legal form of a private liability company. There are about 200 shareholders: freelancers within SIGMA or associated individuals. They influence major organizational decisions according to the number of their shares and participate in the business successes. SIGMA’s turnover increased from about $2.1 million in 1994 to about $10 million in 2000 (even though former units have established their own companies). The number of shares in the hands of the managing directors provides part of their income (as long as the organization operates successfully) and also provides major influence in decisions. The composition of the group of SIGMA’s customers is not different from the composition of the group of customers in ‘traditional’ small or medium-size enterprises: Most customers – more than 90% – provide less than $25.000 (each) of the annual turnover. Business activity with only about 30 customers has yielded significantly higher results; these are the customers with whom SIGMA has been able to maintain long-term business relationships.

390


4.2. IMPORTANT ORGANIZATIONAL CHANGES IN SIGMA When SIGMA was established in 1992, its founders intended to prove the viability of an organizational approach based on a self-organization management strategy allowing for a pleasurable and profitable work life for everyone. From their previous leading positions in large organizations the founders had business contacts to a variety of potential customers. They considered it to be their task to initiate and maintain business contacts and to solicit commissions. In turn for their engagement and a financial contribution to the network, the network was supposed to provide interested freelancers with advice, business contacts, entrepreneurial experience, possibilities for mutual exchange, a minimal administrative infrastructure and a good social climate. Initially, the network had about 50 members. Their work was strongly based on personal relationships, among each other as well as between SIGMA members and their customers. Personal relationships were established and maintained in either regional or project meetings. At the end of 1996, SIGMA had about 100 members. Eventually, work could not be as strongly based on personal relationships as before; many individuals within SIGMA no longer got to know each other. Even though the managing directors still played a key role in terms of access to information and importance in communication, they lost their information and communication monopoly. Instead, information, contacts, knowledge and influence became distributed. Initiating and maintaining business relationships, formerly the responsibility of the managing directors, has gradually also become the responsibility of experienced project managers, trainers and consultants. The managing directors reacted to the situation by installing two forms of subdivisions, one according to business objectives and one according to location. Within the new divisions work has continued to be structured according to personal relationships. Newcomers and even long-term SIGMA members have found it difficult to understand the existing division of work, structures, policies and practices. Conflicts pertaining to the distribution of revenues, the placing of orders and the participation in projects emerged among the regional branches. Since 1999, regional subgroups, teams with common business objectives and providers of internal services have founded private liability companies (such as ‘SIGMA-South’ and ‘Financial Services’3 ). In 2000, SIGMA and seven ‘partner enterprises’, who have closely collaborated with each other, formed a network of private liability companies. Some of the newly founded private liability companies which were formed on the basis of local subdivisions, groups with common business objectives and functional units have been members of this network of organizations. Through this, services that were previously only provided for SIGMA internally by a team of SIGMA members have now become professionalized services provided by independent enterprises. At the end of 1999, for example, a private liability company was founded for the administration of SIGMA’s finances and for


391

handling turnover by means of factoring (‘Financial Services’). This company also offers its services to third parties external from SIGMA. The main reason for this reorganization was the managing directors’ fear that the diversity of offered services endangered SIGMA’s position in specialized markets. For these specialized markets sub-companies have been encouraged to create brands which signify a part of the spectrum of services formerly offered by SIGMA (e.g. IT-Consulting). A second important reason was that the risk of project failure could be better dealt with than when the whole network would formally take the risk. Current efforts to restructure SIGMA refer to the number of the ‘managers’, who finally proved out to be the most important group for SIGMA’s selfmanagement. The managing directors consider this group of 40 members as too big to be able to manage things properly. It will be downsized to 18 members, with a new hierarchy level below them. 4.3. THE SIGNIFICANCE OF THE CASE OF SIGMA SIGMA has been an interesting organization because of its heterogeneity and the autonomy of the freelancers. Heterogeneity has been present for example in terms of skills, personal backgrounds, business objectives, work cultures, ideas and work means. Units in SIGMA have had idiosyncratic approaches to basically everything. Some of these approaches have either coexisted or influenced each other, sometimes at a fast pace. As a whole, hence, SIGMA is a highly dynamic organization. Autonomy of SIGMA’s members has been present for example in terms of individual work organization, technological infrastructure, use of work means and involvement into the network. 5. Organization-wide groupware – local infrastructures and practices We are now describing the evolution of the use of the organization-wide software solution(s) introduced in SIGMA for supporting organization-wide information flows and cooperation. We are arranging this report around the three versions of the organization-wide groupware solution: SigSys I, SigSys I Online and SigSys II.4 Besides describing these versions and related decision processes we are including examples of local purchase, development, introduction and use of collaboration technologies.5 5.1. GROUPWARE PREDECESSORS When SIGMA was established in 1992, the members were already distributed throughout Germany. In the first years, a high frequency of personal communications guaranteed a good flow of information. Telephone (also mobile phones as

392


soon as they became available) and fax were the most often used communication technologies. Most SIGMA members had personal computers for their individual use, especially with installations of standard office applications. 5.1.1. Computers connected via modem In 1993, a few members of a subdivision in an area of western Germany (SIGMAWest) started using a shareware tool with which one of the members had experimented. In this member’s home office, a server was installed which could be accessed via 2400-Baud modems to send documents to other members. The documents were stored on the server until the receiver called and exchanged his or her documents. Since the data transfer rates were too low for transferring large documents such as presentations, the system was used as a messaging system with only occasional transfers of larger documents. 5.1.2. Computers connected via ISDN In 1994, when ISDN adapters became affordable, the modem-based shareware system was replaced by a similar software delivered with the ISDN adapter itself. It allowed peer-to-peer exchange of data and was also used to transfer larger documents. Since the computers did not run constantly, the recipients of a data transfer had to be called to turn on their computer. Since the software came with the hardware required for ISDN communication, the system was open to all members of SIGMA. Its use was encouraged. Two members of SIGMA used the system to exchange presentations for training courses they offered. Although the system was installed by many members of SIGMA, only the SIGMA-West group developed a pattern of frequent use for the exchange of documents. 5.2. AFTER THE INTRODUCTION OF SIGSYS I SigSys I was introduced at the beginning of 1996. Before the introduction the functionality was discussed and defined for purposes such as: • warranting communication among members of SIGMA and its projects, • exchanging documents among members of geographically distributed projects, • cooperatively assembling and changing documents, • coordination (appointments, meetings, schedules) and • creating and maintaining important documents – such as a list of SIGMA members, the portfolio of SIGMA’s activities, the SIGMA logo – and providing access to them for all SIGMA members. The decision for the system was largely made by the managing directors. Most SIGMA members, including most of SIGMA’s ‘stakeholders’, were not involved. SysHouse,6 a partner company of SIGMA, had developed SigSys I with the help of a student whose father was a member of SIGMA. It was configured for SIGMA


393

based on the document sharing experiences within SIGMA-West, but without direct user participation. 5.2.1. New functionality offered by SigSys I SigSys I was basically a proprietary Bulletin Board System (BBS) with slightly enhanced functionality. The system allowed for (asynchronous) messaging to other BBS users as well as to the Internet and using ‘Binary Pools’ for sharing documents, and it made it possible to set up discussion forums. To use the system, the users dialed into a computer via ISDN at SysHouse, exchanged new messages, disconnected and then continued working off-line. The system was based on common BBS standards, so it was easy to work with standard BBS client programs developed for other BBS applications of that time. The complete client software was delivered on a floppy disk from which the files could automatically be installed by starting an installation program. Soon after the introduction, an area for data shared by the whole organization – such as address lists, logos and contract templates – was defined. Among the discussion forums set up were the ‘Zentralforum’, a general discussion forum relevant for all members of SIGMA, and several forums for local groups within SIGMA. 5.2.2. Introduction and use of SigSys I For most of its users SigSys I provided the first opportunity to work with networked computers. Some had to buy and install the required hardware. New users found downloading the shared documents particularly difficult. SysHouse rarely provided training. A low-response hotline was immediately overwhelmed by the incoming queries. These might be the reasons why it took about a year before most members of SIGMA were using SigSys I. Problems regarding the reliability of the Email-system of the software were present from the beginning. Internet emails had delays of up to a week, and sometimes attachments were not delivered correctly. Both problems were never completely solved. This was a major drawback for system’s acceptance. Several discussion forums were successful, especially the ‘Zentralforum’ – the organization-wide main newsgroup – with up to 20 messages per day. The file sharing and the calendar options were not often used. Instead, files necessary for collaboration were emailed, and the use of paper-based calendars was preferred. One reason was that fine-grained access rights were not available; there was no option to restrict access to a smaller group of users without the assistance of SysHouse. In general, the members of SIGMA felt that the benefits of the more elaborated functions of SigSys I did not justify their efforts to learn about them.

394


5.2.3. Other use options while SigSys I was available in SIGMA Eventually, inexpensive applications including groupware applications became easily available. Locally, individuals and groups introduced a whole range of them and formed their own use practices. Some of the – individual, group-specific and SIGMA-wide – expectations that had not been met by SigSys I as an unreliable system with limited functionality were now met by other systems. As the only channel for internal computer-based communication, SigSys I was complemented – and even partly replaced – by a multitude of computer-based communication media. Correspondingly, SigSys I was no longer expected to meet tough and differentiated requirements. For many SIGMA members, SigSys I became one means among many, and only for the objective of organization-wide communication. 5.2.3.1. Additional forums: ‘Job market’ and ‘private’ After the users had gained experience in using discussion forums, the idea that a forum could be used as an open job market within SIGMA emerged. Soon after the forum was created members began to post job/project offers and requests. However, this method of matching projects and people only represented a small section of the job market within SIGMA. Most offers were handled informally by asking someone to join a project or by asking others for recommendations. People posting job requests in the SigSys I job forum were considered not to be well integrated into the network. In 1999, the open internal job market caused a conflict. A regional group of members had invested much time in introducing new members into SIGMA. They became annoyed when another group ‘poached’ those members instead of recruiting and introducing new members themselves. Eventually, this resulted in the current practice of having two forums, one for the ‘stakeholders’ and one for the rest of the members. (This practice materialized by means of the division into SigSys II Business and SigSys II Basic, see below.) Open positions are visible to only the ‘stakeholders’ until they agree to make them available to all SIGMA members. Some frequent users of SigSys I found messages with personal content, e.g. vacation notifications and baby- and pet-sitting requests, in the ‘Zentralforum’ annoying and hence requested an additional forum for private issues. This was created in late 1996. 5.2.3.2. Experimenting with RAS/ISDN solutions In 1996, two members of SIGMA-Central began to use the Remote Access Service (RAS) of their operating system to collaboratively prepare documents and presentations for planning a large project. The service enabled them to use remote directory structures of a computer connected via a temporary on-demand ISDN connection. The directory structures appeared as if they were local. They structured their work accordingly and established a collaborative editing process of the documents necessary for the projects in which they both worked.


395

5.2.3.3. Local groupware installations: Experiences with notes One group in a northeastern city of Germany (‘SIGMA-Northeast’) had conducted a large project with the German railway company. In this project they supported customer processes with a groupware solution based on ‘Lotus Notes’ combined with the ‘Oracle database management system’. During the project they eventually began to use the basic functionality of these tools for their internal cooperation as well. Since then, most members of this group have used Notes functionality such as the messaging system, the group calendar and document workspaces for local purposes and projects. Two other members of SIGMA-West had gained experiences with Lotus Notes from the company they worked with before they joined SIGMA. They continued to use Notes, although they did not use most of the available functionality. They mainly used the database replication service of Notes for their address databases and other databases necessary for their work. 5.2.3.4. Discovering the Internet Users had to buy modems and communication software in order to use SigSys I. For most users, it was the first time they had used groupware technology. When the rates of Internet service providers in Germany dropped to a reasonable level, the users found it easy to experiment with other new technological possibilities. Most of them used the Internet for obtaining information on products and markets. Many also used email via the internet for cooperation because sending attachments this way was more secure and reliable than in SigSys I. Some members of SIGMA also discovered the marketing possibilities of the Internet, thus providing their own homepages and using domains such as “legaladvice.org” to advertise their services. One user mentioned that this practice was ambivalent. On the one hand, he believed that he had achieved a better presentation using new domain names. On the other hand, he and his co-partners found it confusing to use up to five email addresses per person simultaneously. Customers were confused or even became suspicious when one message came from one account and the next from another. This counteracted the benefit. Beyond this, co-partners and customers were annoyed when they sent an email to an address not always used. Forwarding emails was not a viable alternative, since mailbox quotas would be exceeded and download times would increase enormously.

5.3. AFTER THE INTRODUCTION OF SIGSYS I ONLINE Two major reasons led to the introduction of SigSys I Online. First, with a growing use of the Internet as a source of information, users felt uncomfortable with having to dial two different telephone numbers (the SysHouse server and the Internet Service Provider) in order to keep up to date. Second, and more important, users wanted to use the organization-wide groupware system from any Internet access point, especially from customers’ computers. SigSys I Online was introduced at

396


the end of 1998. After the introduction of SigSys I Online, SigSys I and SigSys I Online were both available. 5.3.1. New functionality available in SigSys I Online SigSys I Online, as an improved version of SigSys I, provided access to the groupware via a World Wide Web interface. Most of the functionality remained unchanged; a few changes, such as a new security system for the web, were invisible for the users. While the output quality was comparable to the one provided by the SigSys I client, input now relied on data using HTML forms. The system was not ‘web-embedded’, i.e. it was not possible to treat any of the data in SigSys I Online as web links. Some functionality could not be fully represented by the web interface. 5.3.2. Introduction and use of SigSys I Online There was no special introduction process for the new system version. The use patterns did not change much with regard to the groupware but to the Internet. It was now easier to switch between the SIGMA-wide groupware and external sources of information. Some users reported that they had decided to use only the Internet version of the system. Others reported that they had not used the new option at all, since they wanted to have all the messages stored on their PC for offline browsing. This was not possible with the new interface. 5.3.3. Other use options while SigSys I Online was available in SIGMA 5.3.3.1. Local installations of web-based groupware After the idea of fundamentally redesigning the organization-wide groupware had emerged, several platforms were discussed as potential bases for solutions. Members interested in the alternatives on the market experimented with several groupware products, among them the BSCW7 system. In this process, SIGMACentral decided to use the BSCW system as a platform for a weak form of project management. They have established a use practice they have perceived superior to any other groupware use option including the new SigSys II options (see below). Therefore, they have used the BSCW server system as their primary collaborative system. 5.3.3.2. Developing one’s own groupware solutions: ViOffice Driven by a series of projects, one regional group (SIGMA-Southwest) developed its own groupware product called “ViOffice”.8 The group members have used it for their coordination (calendar management, communication channels, etc.), even though the available functionality does not go far beyond the functionality of SigSys I. The web-based system has offered an additional hold-file functionality and support for Internet telephony. Additionally, links to interesting and relevant


397

websites (railway/flight schedules, etc.) have been incorporated in the system. In later versions, a chat tool was integrated, but never used within SIGMA. 5.3.3.3. Adopting file structures by laptop exchange One member who joined SIGMA in 1999, reported on how he learned to structure his work in SIGMA. From a colleague he bought a used laptop computer with all data still on its disk. While working with this computer, he learned about the possibilities of his colleague’s file structure and the stored documents. He reported that adopting the file structure eased communication as well as cooperation with his colleagues in the projects he joined. The file structure also gave him valuable hints on how to structure his individual and collaborative project work in SIGMA. 5.3.3.4. Example of groupware use of a ‘peripheral’ member One of our informants had worked for a variety of clients and organizations. In a long-term project administered by SIGMA he worked as a trainer. Beyond providing part of his income, SIGMA was meaningless for him. In general, he was strongly opposed to computer technology. He also avoided any form of mediated communication if possible. Nevertheless he used SigSys I, mainly for participating in the coordination with his project fellows which was about every three days. Since he basically did not like information technology at all, he neither had any critique of the system’s features nor wishes for its improvement. He said that expressing criticism depended on liking something in principle. The system and its use had not posed serious problems for him. His explanation was that he did not like SigSys I and considered it irrelevant for him. For communicating within the project in which he was involved, he sometimes used the SigSys I email functionality. He did not mention anything about delays or defective attachments. He had an alternative email access via a commercial provider. For getting current project information and coordinating the project work he used to read the project bulletin board. The most important part of this was to fill in work schedules. He usually printed out important information and tacked the printouts to his wall until the information became outdated. Since he did not rely on orders via SIGMA he did not read bulletin boards except the project bulletin board. He did not mention the document pool at all.

5.4. AFTER THE INTRODUCTION OF SIGSYS II The growth of the organization itself and the diversity of its technical infrastructures were assessed as problematic by some members who operate both locally and organization-wide. Another challenge to the existing organization-wide groupware system SigSys I (and SigSys I Online) had been posed by the local groupware solutions as they grew mature and provided for good practice. This was expected to benefit the organization as a whole. A system based on ‘Lotus Domino 5’, with

398


accessibility via ISDN and Internet, was discussed from the very beginning. Due to the restricted financial resources for organization-wide groupware, several other groupware products were considered: internal ones such as ViOffice as well as external ones such as Groupwise and BSCW. The discussion itself was characterized by political and economic interests. At first, SysHouse began to develop a new proprietary system from scratch. Based on the experiences with SigSys I, SIGMA’s managing directors intervened, and soon afterwards SysHouse stopped its development effort. SIGMA-Southwest had a strong interest in promoting ViOffice. Other individuals and groups were in favor of other solutions. After a while, SysHouse preferred the choice of Lotus Notes – adapted and administered by SysHouse – as an opportunity to improve their own market position. A Lotus based SigSys II was finally chosen for establishing a long-term solution for cooperation support in SIGMA. SysHouse has been responsible for the configuration and introduction of the new system. SysHouse had a subcontractor add SIGMA-specific functionality. SigSys II was made available for pilot users by October 2000 and then for all SIGMA members in December 2000. The access to the system has three levels of extension: • SigSys II Basic provides any SIGMA member with a range of basic groupware functionality, such as messaging/email, mailing lists and discussion forums, shared workspaces, a weak form of task/project management and team calendar management. Additional features include an interface to a bookkeeping software and to mobile devices (Palmtops). • SigSys II Business was designed as an add-on for those members who usually conduct longer projects; they have been provided with tools for project documentation and quality assurance. SigSys II Business also incorporates address and skill databases of SIGMA and of – real or potential – customers and cooperation partners, and a key account management solution. • SigSys II Sales is an even further extension; its functionality supports marketing and order management. In contrast to the other components, it does not have a web interface. The differentiation between the “Sales” and the “Business” levels disappeared during the introduction; all current functionality is available in the “Business” version. SigSys II Basic has been available for every member of SIGMA without costs beyond the network contribution, and has offered functionality comparable to the functionality of SigSys I. SigSys II Business has been available at an extra charge. Only a limited group of SIGMA’s members – the ‘stakeholders’ who have been approved by the managing directors – have had the possibility to use SigSys II Business. 5.4.1. New functionality offered by SigSys II With SigSys II SIGMA switched from a BBS-based organization-wide infrastructure to a ‘Lotus Notes’-based infrastructure. The new groupware framework


399

has been much more complex for individually organizing work (e.g. planning tasks, using the hold-file functionality, contact management) and for cooperating (e.g. meeting scheduler, group calendar, task manager with delegation support). Additional modules have been bought in order to extend existing functions (e.g. specialized forums, templates for address databases, etc.), to support typical business processes (order processing, billing, etc.) and to connect to a standard accounting software. The latter two function classes are only available in the “Business” version of SigSys II. Although it is possible, desired and planned to embed the system into the Web, this functionality has not yet been implemented. But users have the choice to download the server data to their client via the Internet. 5.4.2. Introduction and use of SigSys II SysHouse was aware of the fact that the new functionality offered by SigSys II posed a challenge to almost all users. The introduction was prepared by a “road show” where the new features were presented to the different user groups. For the introduction itself, users were not provided special training, but the introduction proceeded along the lines of the local informal support structures which were informally established when SigSys I was introduced in 1996. Additionally, a central hotline has been provided. Overwhelmed by the new functionality of SigSys II, even power users of information technology have needed a while until they have mastered the system. None of the “introduction deadlines” (end of 2000, end of March 2001) have been met. By August 2001, eight months after the introduction, about two thirds of SIGMA’s members ordered the installation CD, more than half of the members installed the client software and connected it to the server and less than one third of the members began to actually use the software. 5.4.2.1. Software versions as information barrier Initially the different SigSys II versions were supposed to meet the needs of different target groups within SIGMA. It has turned out that the versions objectify already existing differences regarding the access to business information. The ‘stakeholders’ who have the approval of the managing directors – for example the ‘managers’ – have had access to the Business version while the ‘ordinary members’ are only granted access to the Basic version. A discussion forum for job and project-related issues has been accessible only for users of the Business version. The messages in this forum contain contents formerly communicated in the SigSys I ‘Job Market’ forum and contents formerly communicated outside SigSys I, i.e. in discussions of the ‘stakeholders’. Job offers are publicized to ‘ordinary’ SIGMA members only after all ‘stakeholders’ have agreed. This policy contradicts the official network ideology of equal access to resources within SIGMA.

400


5.4.3. Other use options while SigSys II has been available in SIGMA 5.4.3.1. Mobility and calendar Use Although many groupware products used in SIGMA have included some kind of calendar functionality, it was in most cases only used for events of general interest, such as important conferences or SIGMA’s annual shareholders’ meeting. For cooperative purposes, calendar functionality has been used only in a few groups. Many SIGMA members have used mobile phones and paper calendars for coordination. This habit has been due to the fact that these tools can be used for coordination purposes while driving a car, e.g. to or from a customer. This has been considered a valuable time gain. Coordination work while driving was not supported by SigSys I and SigSys I Online, and hence the groupware calendar functionality of SigSys I and SigSys I Online were not used. 5.4.3.2. Innovative mobile devices Currently, a group of SIGMA-West members has experimented with mobile devices such as smartphones and personal digital assistants (PDAs). The tools for synchronizing PDA data with the SigSys II system have been available but not yet integrated into the versions available in SIGMA. Up to now, SIGMA members who have used these tools have only used them for their individual work organization. Potential collaborative use options have now been discussed and may become pivotal for the design of future organization-wide groupware systems in SIGMA. 5.4.3.3. Opening the platform for collaboration with customers In many projects of the SIGMA-Northeast group, service providers have closely cooperated with customers. They recently began to experiment with options for enabling customers to get restricted access to SigSys II for the projects, denying them access to internal structures and data. This can only be realized with a web access to SigSys II. Currently, the group has been in a negotiation process with SysHouse in which options for web access versions of SigSys II have been discussed.

6. Discussion In SIGMA, we found a heterogeneous variety of groupware applications in use. These systems have been used parallelly or in conjunction with each other. Many systems have been appropriated in various ways, by different individuals or groups, in different situations and in different constellations of work means. We provided a variety of examples. The business approach in SIGMA encourages and reinforces idiosyncratic approaches to basically everything that matters. Assessing all individual and group-specific groupware-related practices co-existing within SIGMA would have been impossible, especially since they underlie continuous development.


401

Trying to describe and analyze ‘the’ use of ‘the’ groupware in SIGMA would be an inappropriate endeavor. The ‘bird’s eye view’ of ‘the’ organization with ‘its’ groupware practice is of little help for understanding groupware-mediated work practice in SIGMA. Multiple ‘worm’s eye views’ of and from the perspective of local work environments are necessary to appreciate SIGMA’s specific groupwarerelated practices. The resulting picture must be a dynamically changing collage. Nevertheless, the complex and dynamic picture can be structured. For the following discussion, we are choosing the structuring topics of • the complementary tendencies for proliferation and integration, • the creative and objectifying aspects of appropriating groupware, including the creation of a heterogeneous fabric of systems and practices, • the ‘practical’ design activities potentially bringing about an ever more refined groupware fabric, • the tension between disparate approaches and successful cooperation and • the analytic, explanatory and practical value of the concepts of objectification and appropriation. 6.1. PROLIFERATION VS . INTEGRATION ? From a perspective of appropriation and objectification, our observations of the groupware practice in SIGMA can be structured in terms of two complementary tendencies. The first tendency reflects that groupware has to be appropriated to serve special purposes. The diversity of purposes as well as the diversity within the individual and social processes of appropriation brings about a heterogeneous landscape of use modes; a process which can be characterized by two terms: • Proliferation: For the same purpose, different technologies are appropriated. An example for this is the negotiation of meeting dates in SIGMA. Most members of SIGMA still use a paper-based calendar and a (mobile) phone to handle the task. Some use PDAs synchronized with a digital personal calendar in SigSys II and mobile phones; some use email instead. Some subgroups have agreed to use the group calendar of SigSys II and the associated messaging component to negotiate meetings. • Differentiation: One technology is appropriated in many different ways for many different purposes. Although the technology itself may be capable to also serve similar or different purposes, it is sometimes specialized for only a one or a few purposes (see the ‘peripheral member’ example in section 5.3.3). On the other hand, there is a tendency for having a shared understanding of technology use for enabling organizational communication and cooperation. In SIGMA, this has been objectified in the different versions of the organization-wide groupware. We are aware that objectification has happened on many levels, from the individual to the organization-wide. Our examples here are referring to the organization-wide groupware. This tendency can be further described by means of three categories:

402


• Integration: One systems provides for multiple existing use modes formerly realized by multiple systems. An example here is the development of SigSys I Online for integrating the use possibilities of the organization-wide groupware with the different use possibilities of the Internet. • Standardization: One or more specific ways of use are objectified in one artifact. SigSys II is an example here, since its workflow functionality has been advertised as the future way of managing the billing process in SIGMA. Another example was the promotion of the use of SigSys I as the only platform for internal messages. • Initiation: Anticipated but still imaginary new use options are objectified for purposes assumed relevant. This is usually done when new use possibilities are objectified in an artifact and when this artifact becomes available to people who have not yet been acquainted with the options it provides for. An example here is the creation, installation and propagation of SigSys I in SIGMA. The description of these tendencies from a perspective of appropriation and objectification makes it easier to acknowledge the diversity and richness of groupware practice than from the ‘classical perspective’ of (re-)design, introduction, and intertwined tailoring and use: it reflects the active part practitioners play in that process in any case, not only when participation is an issue in the ‘design process’. 6.2. APPROPRIATION VS . OBJECTIFICATION ? In the previous chapter we provided examples of creative and objectifying appropriations in the use of SIGMA’s organization-wide groupware as well as in the utilization of individual and group-specific systems with groupware functionality. When organization-wide groupware was introduced not ‘the’ groupware but one more groupware system was introduced: a system to be used by all organization members for organization-related purposes. For other purposes, members have used their individual and group-specific infrastructures. In many cases, this included the use of other groupware systems such as the BSCW shared workspace system, other web-based repository systems, diverse installations of Lotus Notes and groupware solutions developed by SIGMA members as part of research or consulting projects. The status of the organization-wide groupware could neither be anticipated nor predefined in advance. It rather has to be negotiated, largely in incessant dynamic – parallel or intertwined – local processes. Each local setting has utilized its specific infrastructure, typically including the organization-wide groupware; each setting has availed certain systems for its specific purposes and in its specific manner. Each groupware system was locally appropriated in a specific way, according to the local infrastructures and practices. In a sense, in each setting each groupware system displayed a specific range of functionality according to the diverse meanings associated with it. Use of groupware and appropriation in use has not only comprised individual and group-specific aspects but also creative aspects. As long as parallel experi-


403

mental practice with groupware systems in SIGMA, for example, is understood only in terms of using predefined functionality, important creative dimensions are ignored: • In individually and group-specifically appropriating the organization-wide groupware solutions within the organization, SIGMA’s members derived a variety of purposes/functionality out of this groupware: they (re-)shaped their infrastructures and work practices integrating the possibilities of the provided system. • By individually and collectively introducing multiple individual and groupspecific groupware, SIGMA’s members have created a heterogeneous multifaceted and dynamic fabric of applications, experiences and practices. The introduction of SigSys II, in this view, is one more effort to integrate a piece of groupware into a common information space (Schmidt and Bannon, 1992, see also below) formed within heterogeneous infrastructures and practices. • An ongoing process of multiple parallel experimental prototyping has been maintained. This process can be interpreted as an integral part of an ongoing design process. (We are explaining this idea in the following subsection.) 6.3. OUTCOME VS . PROCESS ? In the Scandinavian tradition of Participatory Design (PD), the approach of cooperative prototyping has extensively been used (cf. e.g. Grønbæk, 1991; Bødker and Grønbæk, 1996). Future users get the opportunity to explore and experiment with preliminary ‘quick-and-dirty’ ‘throwaway’ systems; the practical value of functionality can be explored, and, on the basis of the experiences, the functionality can be changed. The feedback loops are supposed to be small. The cooperative prototyping approach aims to establish a design process where both users and designers are participating actively and creatively, drawing on their different qualifications. To facilitate such a process, the designers must somehow let the users experience a fluent work-like situation with a future computer application; that is, users’ current skills must be brought into contact with new technological possibilities. This can be done in a simulated future work situation or, even better, in a real use situation. (Bødker and Grønbæk, 1991, p. 200) Many approaches in the Scandinavian PD tradition assume organizations with characteristics such as a certain size and institutionalized co-determination (cf. Törpel et al., 2002). These conditions are not always present, as Robertson (1998) shows for small companies: Small companies are outside the organised labour/management divide because they are not unionised and the relationship between employer and employee is differently defined. They rarely have the resources to employ a specialist system designer in their company, so the same people act both as user and designer. (Robertson, 1998, p. 210).

404


The same is true for the freelancers in SIGMA who can be considered as microenterprises. According to Robertson (1998), the main chances for small companies to engage in participatory design lie in “shopping decisions, and the fitting of purchased technology to the local work situation” (ibid., p. 205). For the designers of systems within small companies, the challenge is selecting the best fit technology from what is available in the marketplace and adapting it to the local conditions. User participation in this process is crucial to the quality of purchasing decisions and the effectiveness of the adaptations.” (ibid., p. 218) [S]mall companies are purchasers of off-the-shelf technology and lack the infrastructure, and the economic means and justification, to design their own systems from scratch. They must make do with what is available within the marketplace and within their invariably tight budgets. (ibid., p. 209) The freelancers in SIGMA probably have even less degrees of freedom in terms of financial resources, infrastructure and man-power. The parallel purchase, adaptation, adoption, use and evaluation of groupware in SIGMA can be interpreted as a special sort of experimental prototyping within a continued collective design process: a design effort of multiple parallel experimental prototyping. Over time SIGMA’s members have built and extended knowledge of and criteria for the systems they have used and of appropriate computer-supported practice. Especially when the use experiences are exchanged and analyzed and when practical consequences are drawn and communicated, this kind of practice is part of an ongoing design process. This, to a large extent, happened in SIGMA. In part, this belonged to the decision process resulting in the decision for SigSys II: local solutions had at least a certain chance to be regarded as possible candidates for the organization-wide groupware (see section 5.4). ‘The designers’ though, understood as design professionals whose primary task is to design someone else’s technological infrastructure, have been absent in this process. They have been replaced by the collective design experiences of the network members: some of the involved persons are IT professionals; many non-IT professionals are power users and some of them have acquired design knowledge even in the sense of the traditional division of labor. This has been the case, for example, in the SIGMA-Northeast group where Lotus Notes knowledge has been accumulated (see section 5.2.3). The conceptualization, realization and introduction of SigSys II, in this view, is one more design attempt paralleling the design activities emerging as part of the work activities of various units. The already existing groupware-related practice of parallel use could in principle be extended in the direction of a systematic approach to the development and ongoing refinement of an organizational groupware fabric. This process would fit into SIGMA’s culture of self-organization, local autonomy and synergetic effects between local units. The experiences and results gained at the local level could be collected and evaluated, for example by delegates from the local units. The delegates could also derive suggestions as to where and how to generalize the


405

experiences and results. These suggestions could be fed back to the local units. (This idea is elaborated in Törpel et al., 2002.) 6.4. DISPARATE APPROACHES VS . SUCCESSFUL COOPERATION ? On the one hand, we discovered appropriations of groupware specific for individuals, constellations and situations. On the other hand, SIGMA’s members have the need for cooperation and its support via suitable computer applications. In fact, they have already established a practice of cooperation that has at least in some respects and constellations proved to be viable beyond disparate meanings, practices and appropriations. A satisfactory computer supported cooperation rests on constituents as diverse as • the peculiarities of the organization and its members, • existing practices and interpretations and • an infrastructure consisting of groupware applications and other artifacts relevant for the performed work tasks. The tension between disparity and – the need for and reality of – cooperative practice is an inherent quality of attempts to create and inhabit common information spaces. This tension was for, example, manifest when the use of the Internet and individual groupware solutions had become widespread in SIGMA. At this point, a standard channel for information of organization-wide relevance had to be warranted. According to Schmidt and Bannon (1992) “a common information space encompasses the artifacts that are accessible to a cooperative ensemble as well as the meaning attributed to these artifacts by the actors” (ibid., p. 28). The tension between diversity and successful cooperation cannot be overcome in principle. A common information space can emerge, evolve and keep up with the requirements and desires of its participants to the degree in which these participants engage in articulating disparate assumptions: “The common information space is negotiated and established by the actors involved” (ibid., p. 28). It is “ ‘articulation work’ that people must engage in in order to make the cooperative mechanisms developed to support different aspects of work in complex environments fit together and fit to local circumstances” (ibid., p. 22). SIGMA provides a good case for demonstrating that the creation, maintenance and improvement of a common information space largely takes place beyond the official division of work into design/development vs. use. Accomplishing this has involved articulation and negotiation, especially on the level of the micro-settings. SIGMA’s culture of negotiation has probably been conducive in this respect. 6.5. OBJECTIFICATION AND APPROPRIATION VS . DESIGN AND USE ? At this point, we would like to return to the concepts of objectification and appropriation as a potential alternative to the concepts of design vs. use. In our view, an important criterion for the suitedness of concepts in this context is

406


their capability to highlight and utilize the potentials of diverse contributions to groupware supported practice. If technologies are to be made useful, practitioners of other forms of work must effectively take up the work of design, as those activities currently glossed under the notion of technology adoption; that is, appropriating the technology so as to incorporate it into an existing technology environment and set of practices. Integration, local configuration, customization, maintenance and redesign on this view represent not discrete phases in some ‘system life cycle,’ but complex, densely structured courses of articulation work without clearly distinguishable boundaries between. (Suchman, 1994, p. 24) The creative dimensions of appropriating artifacts easily escape our perception as long as we expect them not to occur in the realm of “use” but only in the realm of “design”. Thinking in terms of the categories of design vs. use, one tends to assume that one group of people, the users, does exactly those things with an artifact for which another group of people, the designers, created this artifact. The case of SIGMA underlines how inappropriate it is to restrict the quality of design relevance only to the activities of those whose official professional responsibility includes “design”. Issues relevant for the organizational cooperation and hence for the business success in SIGMA as part of a practice utilizing the functionality of groupware systems would not be visible. These are phenomena we found in our case, for example: (1) By creating a multitude use options, SIGMA’s members often also created functionality usable in specific contexts. In the interplay between SigSys I use and Internet use, for example, an interesting dynamic unfolded: After the introduction of SigSys I, the practitioners became familiar with modem technology (hardware, software and use knowledge). This familiarity lowered the threshold for installing an Internet access via an Internet service provider. Use patterns concerning the Internet as well as the groupware emerged. The perceived discrepancy between the options generally available in the Internet but not present in SigSys eventually resulted in the desire for an online version of SigSys I. The appropriations of both technologies provided contributions to SigSys I Online. This example would be difficult to conceptualize from the perspective of ‘design’ and ‘use’ (and a system life cycle perspective). (2) As an ongoing process, an organizational groupware fabric was created and adapted. (3) As part of an ongoing organizational process, SIGMA’s groupware infrastructure has been developed and improved. 7. Conclusion In this contribution on evolving use of an organization-wide groupware, we have drawn on research on an interesting and unusual organization: a network of freelancing trainers and consultants with its cultural creed of self-organization, individual/local autonomy and the expected emergence of synergetic effects. We described relevant groupware related practices which have occurred since the


407

establishment of this organization. In these practices we found indicators for the tendencies for proliferation as well as for integration. The multiplicity of practices has included manifold specific individual and local appropriations of systems: individuals and groups have worked with different systems, and the way work has been done by aid of each system has been context specific. Acknowledging that diversity has been present here would not be enough. The diversity of the local appropriations corresponds with creativity: SIGMA’s members have created, maintained and refined a unique heterogeneous groupware fabric; the activities involved can be interpreted as a design strategy of multiple parallel experimental use; this design strategy is a path toward a groupware infrastructure appropriate for the organization. We discussed the tension between disparate local meanings and appropriations on the one hand and (the necessity and reality of) computer supported cooperative practice on the other hand. For doing this, we referred to the concept of the common information space. The concepts of design vs. use would most likely not have engendered sensitivity for the findings reported. Heterogeneous work-related practices, contents and means have been an integral part of SIGMA’s business approach and have had interesting ramifications for its groupware practice. The specific case of evolving use of organizationwide groupware in SIGMA has drastically underlined the importance of issues such as multiple groupware systems, infrastructures of work means with intertwined functionalities, subgroups with differing work practices and hence multiple appropriations of any single application. Provided there is a sensitivity for finding them, these issues might also be visible in other organizations. The consequences might be different in other environments. We are curious to reading other cases of evolving use of groupware. Acknowledgement We are indebted to a number of individuals and institutions. We could certainly not have written this paper without the participation of Helge Kahler, Meik Poschen, Birgit Lemken and others in our research. We are grateful to our cooperation partners and informants at SIGMA for granting us access to various sites of their individual and cooperative work and for providing us with valuable insights into their practice. Most of the research on which this study is based was part of the Virto (“Design of Multimedia Systems for Virtual Organizations”), InKoNetz (“Integrated Cooperation Management in Network Organizations”) and OLViO (“Organizational Learning in Virtual Organizations”) projects. Virto was funded by the German State of North-Rhine Westfalia (from 1996 to 1998, grant No. IV A3-107 041 96), InKoNetz was funded by the European Commission and MAGS NRW (from 1998 to 2000, grant No. 93/V52A/0083), OLViO was funded by the German Ministry of Research and Education (from 2000 to 2002, grant No. 01H69984).

408


Steffen Budweg, Hans-Jörg Burtschick, Helge Kahler, Patricia Pawlyk, Meik Poschen, Markus Rohde and three anonymous reviewers of this special issue helped improve this contribution by commenting on earlier versions. Notes 1. Our diagnosis has been that in reality many phenomena are difficult to capture with the concepts of ‘design’ and ‘use’. These phenomena have even been research objectives (e.g. the creation of web applications, tailorability, end-user programming). Yet, the ‘design-use’ terminology has widely remained unchallenged. 2. The name has been changed. 3. The names have been changed. 4. Thenames of the groupware systems have been changed. 5. We are referring to subgroups in SIGMA by fictitious names such as SIGMA-West, SIGMANortheast, SIGMA-South and SIGMA-Central. 6. The name has been changed. 7. Cf. http://bscw.gmd.de/ and http://www.bscw.de 8. The name has been changed.

References Bødker, S. and K. Grønbæk (1991): Design in Action: From Prototyping by Demonstration to Cooperative Prototyping. In J. Greenbaum and M. Kyng (eds.): Design at Work: Cooperative Design of Computer Systems. Hillsdale, NJ: Lawrence Erlbaum Associates, pp. 197–218. Bødker, S. and K. Grønbæk (1996): Users and Designers in Mutual Activity: An Analysis of Cooperative Activities in Systems Design. In Y. Engeström and D. Middleton (eds.): Cognition and Communication at Work. Cambridge, UK: Cambridge University Press, pp. 130–158. Bowker, G.and S.L. Star (1998): Building Information Infrastructures for social Worlds – The Role of Classification and Standards. In T. Ishida (ed.): Community Computing and Support Systems, LNCS 1519. Heidelberg: Springer Verlag, pp. 231–248. Bullen, C.V. and J.L. Bennett (1990): Groupware in Practice: An Interpretation of Work Experience. In Proceedings of the Conference on Computer Supported Cooperative Work, October, Los Angeles, CA. New York: ACM SIGCHI, pp. 291–302. Ciborra, C.U. (1996): Foreword: What Does Groupware Mean for the Organizations Hosting it? In C.U. Ciborra (ed.): Groupware and Teamwork – Invisible Aid or Technical Hindrance? Chichester, UK: John Wiley and Sons, pp. 1–19. Curtis, B., H. Krasner and N. Iscoe (1988): A Field Study of the Software Design Process for Large Systems. Communications of the ACM, vol. 31, no. 11, pp. 1268–1287. Hales, M. (1994): Where are Designers? Styles of Design Practice, Objects of Design and Views of Users in CSCW. In D. Rosenberg and C. Hutchison (eds.): Design Issues in CSCW. Springer Verlag, pp. 151–177. Hofmann, J. (1999): Writers, Texts and Writing Acts: Gendered User Images in Word Processing Software. In D. MacKenzie and J. Wajcman (eds.): The Social Shaping of Technology. Buckingham: Open University Press, pp. 222–243. Karsten, H. and M. Jones (1998): The Long and Winding Road: Collaborative IT and Organisational Change. In Proceedings of the Conference on Computer Supported Cooperative Work, October, Seattle, WA. New York: ACM SIGCHI, pp. 29–38. Leont’ev, A.N. (1978): Activity. Consciousness. Personality. Englewood Cliffs, NJ: Prentice-Hall. Leontyev, A.N. (1981): Problems of the Development of Mind. Moscow: Progress.


409

Orlikowski, W.J. (1996): Evolving with Notes: Organizational Change Around Groupware Technology. In C.U. Ciborra (ed.): Groupware and Teamwork – Invisible Aid or Technical Hindrance? Chichester, UK: John Wiley and Sons, pp. 23–59. Pipek, V. and V. Wulf (1999): A Groupware’s Life. In S. Bødker, M. Kyng and K. Schmidt (eds.): Proceedings of the Sixth European Conference on Computer Supported Cooperative Work, 12–16 September, Copenhagen, Denmark. Dordrecht, NL: Kluwer, pp. 199–218. Rittenbruch, M., H. Kahler and A. Cremers (1998): Supporting Cooperation in a Virtual Organization. In Proceedings of the International Conference on Information Systems, 13–18 December. Stockholm, pp. 30–38. Robertson, T. (1998): Shoppers and Tailors: Participative Practices in Small Australian Design Companies. Computer Supported Cooperative Work, vol. 7, nos. 3–4, pp. 205–221. Rogers, Y. (1994): Exploring Obstacles. Integrating CSCW in Evolving Organisations. In Proceedings of the Conference on Computer Supported Cooperative Work, Held 1994 in Chapel Hill, NC, USA. New York: ACM Press. Schmidt, K. and L. Bannon (1992): Taking CSCW Seriously – Supporting Articulation Work. In Computer Supported Cooperative Work, vol. 1, pp. 7–40. Suchman, L. (1994): Working Relations of Technology Production and Use. Computer Supported Cooperative Work, vol. 2, pp. 21–39. Törpel, B. (2000): Do Computers Transform People into Women and Men? In E. Balka and R. Smith (eds.): Charting a Course to the Future. Proceedings of the IFIP conference on Women, Work and Computerization, Vancouver June 7–11, 2000. Boston: Kluwer, pp. 17–25. Törpel, B., V. Wulf and H. Kahler (2002): Participatory Organizational and Technological Innovation in Fragmented Work Environments. To appear in Y. Dittrich, C. Floyd and R. Klischewski (eds.): Social Thinking. Software Practice. Cambridge: MIT Press, pp. 331–356. Wagner, I. (1993). A Web of Fuzzy Problems: Confronting the Ethical Issues. Communications of the ACM, vol. 36, no. 4, pp. 94–101.

Creating Heterogeneity â Evolving Use of Groupware in a ... - CiteSeerX

Creating Heterogeneity â Evolving Use of Groupware in a ... - CiteSeerX

Suggest Documents

Heterogeneity and Specialization in Evolving Teams - CiteSeerX

Dynamics of groupware use in a collaborative telelearning ... - CiteSeerX

Internet Groupware Use in A Policy-Oriented Computer ... - CiteSeerX

Evolving concepts of tumor heterogeneity - COREwww.researchgate.net › publication › fulltext › Evolving-

Reducing Conflicts in Groupware - CiteSeerX

Supporting Awareness of Others in Groupware - CiteSeerX

Evolving concepts of tumor heterogeneity - Semantic Scholar

Internet Groupware Use in A Policy-Oriented Computer Security Course

Use of habitat heterogeneity in salmonid spawning habitat ... - CiteSeerX

Temporal Heterogeneity in the Study of African Land Use - CiteSeerX

The Use of Asynchronous Discussion: Creating a Text of ... - CiteSeerX

Groupware for Collaborative Learning: A Research ... - CiteSeerX

Groupware: Experience in New Zealand - CiteSeerX

Using Groupware in Quality Management Programs - CiteSeerX

Workspace Awareness for Groupware - CiteSeerX

Workspace Awareness for Groupware - CiteSeerX

Groupware Support for Requirements Management in ... - CiteSeerX

Architectures for Synchronous Groupware - CiteSeerX

Investigating Preference Heterogeneity in a Repeated ... - CiteSeerX

Multicasting in Groupware?

Evolving a photosynthetic organelle - CiteSeerX

Creating heterogeneity from homogeneity: the ...

Exploiting Heterogeneity in Sensor Networks - Creating Web Pages in

A Formalisation of Evolving Algebras - CiteSeerX

Creating Heterogeneity â Evolving Use of Groupware in a ... - CiteSeerX