The Impact of Group Context on Patterns of Groupware Use:
A Study of Computer Conferencing as a Medium of Work Group Communication and Coordination

Abstract

This paper describes a study of the use of computer conferencing for work group communication and coordination. The goal of the study was to examine the relationship between group context and technology utilization, i.e. the social factors which influence a group's use of groupware. This paper describes three work groups, identifies patterns of computer conferencing use for each group, and examines the relationship between use patterns and group context. The findings provide considerations for groupware introduction.

Table of Contents

CASES
Research Group

Senior Management Team

Product Development Group

PATTERNS OF USE
Research Group Conference Use

Senior Management Team Conference Use

Product Development Group Conference Use

ANALYSIS
Leadership

Task Fit

Process Fit

Group Learning

SUMMARY
Findings and further research

Groupware Introduction

References

Figures

This study examines the use of computer conferencing by three work groups in order to examine the group factors which influence the use of groupware technology. The paper first presents three work groups, describing group task, structure and process. Four modes of use observed are then briefly outlined, followed by a detailed account about each groups' use of computer conferencing and the common themes identified by team members. The next section analyzes the use patterns across the teams using a framework developed in the study. This framework draws on the small group theory of Hackman (1975), Gladstein (1984) and (Schein, 1987). The summary section presents a set of considerations, based on the findings, for introducing similar groupware technology.

The study was conducted in a software engineering organization of a computer company. The three groups studied-- a research group, a senior management team, and a product development group-- represent a variety of tasks and goals. The study examined the first year of conference use by the three groups. It focused on the use of computer conferences limited to group members rather than 'open' computer conferences that are used for communication beyond a work group. Electronic mail was a common means of communication in the software engineering environment and most engineering project teams also used computer conferencing. Both electronic mail and computer conferencing systems had been available in this software engineering organization for over ten years.

Data collection involved individual interviews, observation of the members' interactions,

___________________________________________________________________________

Current Address: Lotus Development Corporation, 55 Cambridge Parkway, Cambridge, Ma.

and analysis of computer messages. Typically interviews involved an examination of the

computer conference with the individual group member at his or her desk. The case study approach attempts to uncover use patterns and common themes rather than test specific hypotheses (Yin, 1984).

The findings of this study support previous research on groupware implementation (Bullen, 1988, Orlikowski, 1992) yet distinguishes itself from the early work on conferencing (Hiltz, 1984, Johanson, 1979) by the focus on use by existing work groups and the relationship between group context and patterns of use. The fundamental assumption underlying this study is what Markus and Robey (1988) label 'emergent', that is, social and technical factors interact to create patterns of technology use, and technology use is best understood in light of its social context.

CASES

Research Group: The research group was composed of eight people: a manager, a program manager, four engineers and a secretary. The group was co-located, sitting in adjoining cubicles along an aisle, with the exception of one engineer who was located in another facility thirty miles away. The work of the group was to identify, prototype and transfer new technology to product development groups within the same software engineering organization. The work was divided into one to three person projects pursuing different technologies. The projects were planned and implemented independently with the exception of two technologies which were interdependent. The cycle of an average project ranged from one to two years. A project commonly included engineers or product managers from the product development groups as well as people from university laboratories or small technology companies. The process were non-routine and highly specific to the project and people involved.

The primary means of communication between group members was through ad hoc, face-to-face meetings. The group had a regular, weekly staff meeting for several hours, but the meeting was frequently canceled. Individuals within the group met on a as-needed basis. Often, first thing in the morning the manager would "meet" with group members in the aisle by his cubicle, filling them in on something or finding out about the process on a project. The made frequent use of electronic mail for brief messages regarding ongoing work activities and for exchange of more formal documents. It was common for the manager of the group to send draft versions of "white paper" documents or proposals which he was working on for input. Electronic mail was used for individual communication and for communication to the whole group via a distribution list.

The manager focused his attention primarily on issues external to the group, such as "selling" the work of the group to the larger engineering organization and establishing linkages to other groups or organizations. He tended to leave the operational details and planning to the program manager and project leaders. He was quite involved with the work of the group and knowledgeable about all of the projects, but his style was to talk to group members in an informal, as hoc fashion rather than to have regular meetings or rely on monthly reports. He typically got brief verbal updates from group members when he requested them.

Senior Management Team: The senior management team, composed of a vice president and his staff of fifteen manager's, was responsible for the strategic and operational management of one of the principle software engineering organizations. Half of the staff were located in one building, the remainder were located within 30 miles, and one manager was located on the opposite coast. The staff managed relatively independent product development groups. Several of the product groups were more closely connected, based either on common customers or products that were tested and sold as integrated solutions. At the time of the study, the management team was newly created as a result of a cooperate reorganization, which unified a number of software product groups. The vice president was brought in to develop a market-oriented strategy and establish a common set of business practices and procedures.

Communication for the whole staff occurred in a formal monthly two day staff meeting. The work and communication processes were semi-formal. There were regular budgeting processes and reports, regular product monitoring, processes for capital equipment and for hiring authorization. Staff meetings addressed these standard business processes as well as the less structured processes, such as exceptions or changes to plan, strategy and policy issues common to the whole group. Communication outside of the group was commonly via e-mail, phone or face-to-face meetings between individuals. The vice president did not hold regular individual meetings with his staff, rather he communicated via e-mail and met with individual on an as-needed basis. The degree of interactions between individual staff members was largely based on the degree of interdependency of their products. Staff members periodically worked on task forces together, but it was not uncommon for individuals to have no communication with many of the rest of the group between staff meetings.

Product Development Group: The product development group was composed of 12 members who were all located in adjacent cubicles. There was a project leader, several technical leaders, developers and a technical writer. The task of the group was to revise an existing software product for a new system architecture. The project work was divided into technical component areas, several of which had technical leaders who were more senior engineers. In the planning phase the features of the product were designed and documented as functional specifications and the product schedule was determined. In the implementation phase the developers worked on coding and testing the components, finally integrating them in a series of base levels. The average product cycle for these types of projects was 12-18 months. The tasks were clearly defined, and interdependent with defined procedures and clear milestones. After six months of initial prototyping and feasibility planning was completed by two engineers, the project leader was hired and a project team was assembled. The project leader was technically knowledgeable and focused on daily operations and project deliverables. His orientation to the project team was one of team involvement and decentralized decision making. He had previously worked with several of the engineers on other projects.

Project communication occurred in the brief, weekly project update meeting or in ad hoc, informal meetings of group members. The weekly project meeting, lasting about 1/2 hour, involved reporting of progress to plan for each member. The project leader summarized the members' reports into a project team summary for the week and filed it in one of the conferences the group used. The group also used e-mail for communication of individual issues and general corporate information. Communication was characterized by team members as informal, "over the wall communication", referring to conversations occurring over the cubicle walls. The project leader closely supervised the project, yet expected team members to make the decisions in their own areas and stay informed about the whole project.

PATTERNS OF USE

In studying the three groups, four different modes of conference use emerged: archive, five cabinet, broadcast and discussion. The different modes represent a continuum from passive to active use (see figure 1). Archive use refers to common information that is stored in the conference for access by the whole group, primarily for a historical record. This information is only read on an as-needed basis (e.g. reference material). File cabinet use refers to common information that individuals post, read periodically or used at a later point in the work cycle of a group. Frequency of access distinguishes archive from file cabinet use. Broadcast use refers to communication between one group member and the group, e.g., posting a message for the whole group to see. The communication is to inform the group rather than to have a dialogue. In broadcast the communication is usually one way, and in the cases where two way communication takes place, the exchange is limited. The discussion use is for dialogue, an interaction similar to a conversation between two or more people. In a discussion, the responses from others generally occur within a few days. The discussion is a two-way communication between group members and the interaction is characterized by responses within an expected time period.

Each of the three managers stated that the purpose of using the conference was both to provide another means of communication for the group as well as a mechanism for storing common electronic information, i.e., discussion and archive. The following section describes how each group used the computer conference and presents the common themes raised by team members (see figure 2).

Research Group Conference Use: The research group had one conference which was created for group members to file group-related information, e.g. meeting minutes, general information that may be of interest to the group, such as trip or conference reports, and specific project-related information. The manager had intended the conference to be used as a vehicle for the group to share project information, yet it served minimally as an archive and contributed little to the functioning of the group. Group members reported getting little value from the conference with the exception of one individual who reported regular use of the conference. Two individuals reported reading the conference when they first arrived, but both stopped reading it regularly after a month or two.

Examination of the conference contents demonstrated that the information was not critical to the work of the group. Most the information posted was formal and external to the group rather than information that group members had created. The information was often general technical or administrative and not directly related to projects group members were working on. Information posted included staff meeting minutes, trip reports and technical information received by electronic mail, such as newsletters from specific technology groups and reprints of newspaper articles. The conference was in existence for two months before the first group member posted a personal message that included his thoughts on a specific technical issue. The only other example of a discussion in the first six months of the conference occurred a month later. In this instance one group member posted information that he wanted feedback on. He received one substantial response and second brief response which concurred with the first response.

Group members reported initial interest in the conference, reading and posting messages weekly, but stated that their use declined gradually, dropping to several times a month. Periodically a group member would post a mail message from the manager, but the manager never posted information in the conference. There was uneven use of the conference as some members posted information regularly and others rarely used the conference.

When I asked group members why the conference was not used more actively, a number of key issues surfaced. Group members reports feeling little "social pressure" to post information or read the conference. One person noted, "I didn't put project information in, but I didn't feel guilty because a lot of people weren't". Many group members stated, "the information was routine and low value". Another common theme was captured by one member who said, "the managers communication style is informal and face-face... if something was important it would be discussed face-face or in e-mail". Most people used e-mail as their principle work environment and several people objected to using two different systems to do their work, a mail application and a conferencing application, for example: "I only want one in-box to look for my work" and "I expect e-mail to be read yet I don't know how often the conference is read". Several said that mail came directly to them versus the need to go to an information source as in a computer conference.

In addition several members stated they didn't really know what the purpose of the conference was. They felt it was used principally because it was available, and "it seemed like the right thing to do". One member stated that he was unsure of the protocol for the conference: " I thought it was a semi-formal publication process or for a group record. I wasn't sure what was appropriate for the conferences so I didn't put anything in".

Senior Management Team Conference Use: The Senior management team had three conferences: "SW Staff", "Reports" and "Goals and Objectives". The SW Staff

conference was used for general management team information, including: staff meeting minutes, agendas, action item lists from staff meetings and proposals for review prior to staff meetings. The Reports conference was for monthly reports, and the Goals/Objectives conference was for individual managers to post their group's goal and objective statements for input and discussion with others. The manager expected the conference to improve the productivity of his dispersed management team by providing the ability to share information in the conference prior to staff meetings. He also wanted a central archive of staff -related information for ease of access and for a record. The conferences were used as an archive and file cabinet for administrative information, rather than as a medium for discussion. Most managers posted the minimum required information, such as monthly reports and very few reported reading information posted by other managers. The regular filing of monthly reports eventually deteriorated to a few managers posting monthly reports. Several managers reported using the SW Staff conference for getting administrative information, such as organization charts and e-mail distribution lists, yet most had their secretaries get information they needed from the conference. Most managers reported getting no comments from others on information they posted in the conference. One manager stated, "It didn't work because a lot of people didn't post objectives and only a few people commented on what was posted. There were so few comments that there was no payoff... I got more comments at staff meetings".

Another common theme identified by the managers was that their usual process of e-mail communication was as effective as the conference. Several managers reported, "The stuff posted in the conference seemed optional. If I didn't respond it was OK, yet e-mail was sent to me and probably required my attention. I have more faith if I send e-mail, since I don't know who reads the conference regularly." Several members expressed frustration at the fact the vice president posted meetings minutes and agendas for future meetings in the conference rather that using e-mail, but reported, "typically a staff member would get it from the conference and share it with others, either via e-mail or hard copy".

Several managers preferred to talk directly with others on the staff rather than posting messages in the conference. Another manager pointed out the lack of teamwork, "it was a set of individuals with individual responsibilities, rather than a group". One manager pointed out that the vice president "never discussed the use of the conference at staff meetings, so we never had an opportunity to learn how to use the conference as a group".

Product Development Group Conference Use: The group had two conferences, 'Internal' and 'Bugs'. The 'Internal' conference was used for posting general project information such as: work plans, status reports and project issues. The 'Bugs' conference was used to track product bugs, such as specific work items that were assigned to individual team members. The project leader wanted to use the conferences for members to share relevant project information and as a mechanism to monitor project activities.

The product development group's conferences served as the primary source of project information and were used in all modes: archive, file cabinet, broadcast and discussion. As an archive it was used infrequently. For example just prior to the close of the planning phase, the project leader reviewed all the issues previously posted in the conference to ensure that they were assigned to a group member or accounted for. As a file cabinet it was used as common, reliable storage. One example use involved documentation, any member whose work needed to be put in the final product documentation would post his/her working notes in a conference. The writer later used the notes from the conference as a basis to work on the product documentation. Broadcast usage included such things as the project leader posting the weekly project reports in a status report topic in the conference. Discussion use involved most of the project team members, either generating ideas in a specific area or giving feedback to a proposal. The discussion generally involved simple responses, such as agree/disagree, additional pieces of information, or questions for clarification, but negotiation of differences on more complex issues was done in face-face meetings. Discussions tended to be on specific issues that needed to be addressed and that affected the whole group, for example, the build procedure and the testing system. In one instance, a discussion of the testing procedure, the project leader asked one person to open a topic in the computer conference and asked group members to post messages about their requirements for a test system. After a number of ideas had been generated and responses made to the ideas, one person was assigned to take the ideas and create a formal proposal. The proposal was posted in the conference, responses entered into the conference and the final resolution was achieved in a face-to-face meeting of several group members. The discussion in the conference and process took several months from initial ideas to final decision.

The product development group members consistently reported regular daily use of both conferences. Most members had a daily habit of reading the conference for ten to fifteen minutes first thing in the morning over coffee. "Sort of like an old friend" was the description of the conference by one group member. The 'Internals' conference was used more actively in the planning stage of the project when issues were identified but not always assigned to individuals. The 'Bugs' conference was used throughout the implementation/coding stage of the project and most intensively close to final project deadline.

The project leader moderated the conference and actively encouraged people to use it. One member stated, "In project meetings an issue would come up, like what should I do with release notes, and often the project leader would suggest starting a new topic in the conference". He would also intervene in a conference discussion when he thought the discussion was taking too long or not leading to a conclusion. In those cases he would ask individuals involved to make a final decision about the issue, the often involved a face-to-face meeting. The project leader also included team members in the decisions about the structure and use of the conference.

The product development team was the only group of the three that integrated the computer conference into their work practices and relied on it for their work. In the senior management team and the research group, communication occurred via e-mail, phone and face-to-face meetings despite the introduction of computer conferencing. The following section describes group factors and identifies how they influenced this patterns of use.

ANALYSIS

The following analysis utilizes four group factors (see figure 3) that appear to explain the patterns of computer conference use by the three groups. The four factors include: leadership, task fit, process fit and group learning. These factors emerged in the study from the thematic analysis of the case data. Figure 4 shows a summary of use patterns and analysis of group context.

Leadership as a factor influencing group technology use refer to the degree to which the leader integrates the technology, establishing expectations for use, incentives and /or consequences for use, modeling and reinforcing use. The leader's communication and management style also influence groupware usage. In the three teams studied, the project leader of the product development team was the only leader of the three who performed the leadership tasks necessary for successful groupware adoption. He established and reinforced clear exceptions of use for the conference. He suggested group members start new topics on critical issues and actively moderated the conference, limiting discussions when issues remained unresolved. He modeled its value through his own use. His own use sent a signal to the team that the conference was an important communication tool for the project.

In the senior management team the vice president identified a clear rationale for the use of the conference but did not model or reinforce its use. Initially he posted messages and commented on information his staff posted, thereby creating an incentive for others to use. As he became busier he used the conference less and the incentive for use diminished. His lack of use, as well as the lack of use by his staff, became a negative reinforcement, as when staff members began to expect no responses to their messages. The vice president tried to reinforce use by posting general staff meeting information rather than distributing it via e-mail. However he was inconsistent. Information about staff meetings was in the conference but other information was distributed to staff via e-mail.

In the research group, the manager demonstrated no visible leadership with regards to the conference use. He did not use the technology, post information, and as far as group members knew, did not read the conference. This lack of leadership sent a signal to staff that the conference was not critical to the manager's job, and thereby not critical to the group. The research manager neither established a clear purpose for the conference, nor common expectations for use. This created confusion for group members, who understood that they were expected to use the conference, yet they did not have a clear objective or standards for that use. The heaviest user of the conference created a topic structure that was not used by the group. The group decided it did not need a moderator because of its small size.

The communication style of the leader, in addition to the leader's usage patterns, influence the team's use of groupware. Use of the conference was consistent only with the project leader's approach to management. He wanted to closely monitor the work of the project team and the teams' use of the conference allowed him to do that without spending additional time interacting with each of the team members. The project leader posted his own status reports in the conference in addition to participating in the conference discussions. In the senior management team, the vice president also closely monitored the work of his staff, but he relied primarily on business planning and group financial status reports which were information sources independent of the conference. The communication style of the research group manager was more informal, ad hoc and interpersonal. He did not require regular monthly status reports, rather he had periodic face-to-face updates. His preference was to monitor the work of the group through brief, informal interactions. In the product group the project leader encouraged a lot of direct communication between individual team members, whereas in the senior management team and the research group, the manager was more often the focal point of communication. In both these latter groups work direction and information came from the manager. For the project leader the information in the conference was critical to managing the work group, whereas for the vice president and the research manager, the information in the conference was not essential. In addition, the vice president did not encourage group communication nor did the staff trust each other enough to share critical information in the conference.

Task Fit as a factor influencing group use of technology refers to the degree to which the technology assists individuals and the whole group in accomplishing its work. This includes such things as, does the technology facilitate critical tasks and provide tangible benefits to the group? How and when does the group receive the benefit? Of the three groups studied, the concrete, defined and interdependent tasks of the product development team most clearly benefited from conference use. Individuals often needed real-time information from many other group members. The high level of task interdependency and the resultant high level of communication and information exchange needed was well suited to conferencing. Information could be posted once for the whole group, rather than a series of individual interactions which would be redundant and increase the probability of lost or mis-interpreted information. Group members directly benefited by having access to the same information since work on part of the project had direct impact on work in other parts. Senior management team members and the research group members worked independently and their tasks required more individual rather than group communication. A shared information source, which the conference provided, did not add significant benefit beyond the existing e-mail system. In the research team the work was divided into projects and it was project-level communication which was most critical to the success of the individuals. There was little ongoing dependency among the projects. The conference was restricted to the group and, therefore did not support communication with project members outside the group. The group's internal communication capacity was sufficient for its task, but a conference restricted to the group did not support the more critical communication external to the group. The senior management team and the research group both attempted to use the conference as an archive for the group's work, yet a centralized, electronic record provided no immediate, tangible benefit to the group's success. Establishing and maintaining an accurate record required work on the part of the individuals in both groups and in neither group were there sufficient incentives for individuals to post information to a group repository.

Process Fit as a factor influencing group use of technology involves the degree to which technology matches the work practices and culture of the group. This includes the work flow, i.e. the actual work steps associated with a task, the communication flow, i.e. who talks to whom about what, group values and norms for acceptable behavior, and membership, i.e. who is in the group and what roles do they play. In the product group, the use of the conference was consistent with how the group functioned, i.e. there was a high level of information exchange on a project information. The norm of group-wide communication was already established and so the computer conference was convenient and efficient medium for this. Most of the communication in the senior management team and research group was individual or sub-group communication rather than group-wide communication. Both groups functioned in a way that did not easily incorporate the use of the conferencing into their work practices, and so the conference usage remained marginal. Computer conference supports group-wide communication which was contrary to the dominant interactions and norms of these two groups. Additionally in the management team the lack of trust among team members contributed to a secretive environment where information was often not willingly shared. The conference required behavior which individuals perceived as risky and so, it was often unused. Communication occurred between individuals or between staff members and the vice president, but little communication occurred across the whole group. In the research group there was a higher level of trust and group communication, but the group communication was typically characterized by brainstorming and a quick-paced give and take best done face-to-face. The group valued individual, autonomous work and creativity, rather than tight integration and regular communication. Individuals often interacted with others to spark ideas, to get feedback on some specific issues, or learn about new developments in technology rather than to coordinate work. The communication style of the group evolved in response to the manager who preferred informal communication rather than planned staff meetings or regular one-one meetings. The communication needs and style of the senior management team and the research group were consistent with the one-to-one model of e-mail. E-mail provided a known and comfortable means of communication which fit the existing norms for interaction, consequently conference usage never became an established norm.

The quality of information communicated among the teams differed also and affected usage. The product development team's work dictated information that was often more structured, concrete and repetitive that the abstract, impressionistic information of the research and management teams. The more unstructured, less predictable information was more difficult to capture and exchange in a conference without risk misinterpretation and ambiguity.

Group Learning refers to the degree which the group is able to adapt the technology to its work context, or adapt its behavior to the technology. This includes how accurately and consistently the group understands the purpose of the technology, the strength and weakness of the technology, the opportunities created through technology use as well as risks. Group learning also refers to way the group manages the introduction of the technology. The product development team established an explicit learning process that involved team members in identifying the ways in which the technology could be used in their specific group context. Group members in the product development team had similar prior experience with conferencing which minimized the learning required. Neither the senior management nor research teams discussed the use of the computer conference as a group. In both the research and senior management teams the use of computer conferencing for group communication was new for individuals. Individuals from both groups had knowledge or first hand experience with computer conferences as information management tools, i.e. a means for individuals to access common information, yet not as a medium for internal communication. Use of conferencing for internal group communication required explicit learning and discussion that failed to occur.

The early experiences of the research and senior management team created negative expectations for future use which contributed to deterioration of conference use. A negative spiral was established in which little valuable information led to diminished individual expectations and eventually to less use. Individuals learned to expect little valuable information and/or communication in the conference. In the product team the project leader involved group members in determining the conference's structure and subsequently modified both its structure process. The group learning and adaptation was effective in the product team. The research and management team neither monitored or evaluated the use of theconference. The absence of effective learning prevented these groups from establishing new work practices consistent with conferencing technology.

SUMMARY

Findings and further research: The findings of this study illustrates how group context influences the use patterns of computer conferencing technology for three groups. The study does not indicate which of the four factors (leadership, task fit, process fit and group learning) has the greatest impact on technology utilization and what other social or technical factors influence a group's use of computer conferencing. The comparison across the three cases suggests that it is the interaction of the four group factors which determines use patterns. The study begins to suggest an effective group context for use of conferencing technology specifically for internal communication and coordination. Further investigation of these factors is an important next step.

Groupware Introduction: The findings and group factors discussed in this study provide a framework and set of considerations for introducing groupware technology. The manager must have a clear purpose for the use of technology and establish expectations for individual use and a process for group use. The leader's reinforcement of technology use by modeling its use and establishing incentives that support use is also critical.

The likelihood of groupware being used is closely linked to the degree to which the technology supports the successful completion of critical tasks. It is insufficient for the technology to primarily benefit the manager, with little benefit to the individuals in the group. Groupware technology is also not likely to be used when the goal is to enable group behavior or interactions, hoped for by the manager, but not in the group's repertoire or to the benefit of the individual group members.

Use of the specific groupware technology is most successful when it is consistent with the group's work practices, norms and communication patterns rather than requiring behavior in the group that does not exist or contradicts existing norms of interaction. Groups are less likely to use groupware technology if it requires learning significantly different ways of interacting. New groupware technology such as conferencing, must present tangible benefits over existing communication medium, such as e-mail, in order for groups to overcome the barriers to change. Introduction of group communication technology must take into consideration individual needs and preferences in addition to the need of the group. Finding ways to incorporate a variety of personal communication styles is critical if the technology intends to support communication for the entire group.

Groupware technology provides opportunities for new group interactions, yet when new group behavior is the goal of the manager, he or she must address the changes required. Learning is a fundamental component of successful change, and establishing the conditions for learning and for change will be critical for many groups to gain the benefits from new groupware technologies. Individuals have little experience to draw upon as models for how to interact in shared, electronic work spaces. An on-going learning strategy integrated with work is more effective than a strategy that emphasizes up-front learning. Working within group's natural work rhythms, and trial/error learning processes allows individuals an opportunity to understand a new technology and learn about its application in an actual work environment. Our capacity to learn and adjust to the demands of this new work environment represent the major challenge for users, managers and system designers.

Bullen, C.V. and Bennett, J.L. (1990). Groupware in Practice: An Interpretation of Work Experience. Center for Information Systems Research, MIT, ( Working Paper No,205)

Bullen, C.V. and Johansen, R.R. (1988). Groupware: A Key to Managing Business Teams, Center for Information Systems Research, MIT, (Working Paper No,169)

Gladestein, D.L. "Groups in Context: A Model of Task Group Effectiveness", Administrative Science Quarterly, 29 (1994) : 499-517

Hackman, J.R. and Morris, C.G. 1975. "Group Tasks Group Interaction Process and Group Performance Effectiveness: Review and Proposed Integration" In Berkowitz, (Ed.) Advances in Experimental Social Psychology, 8. New York: Academic Press.

Hiltz, S.R., (1984) Online Communities: A Case Study of the Office of the Future. Norwood, New Jersey: Ablex

Johansen, R. (1988) Groupware: Computer Support for Business Teams. New York: The Free Press

Markus, M.L. and Robey, D. "Information Technology and Organizational Change: Causal Structure in Theory and Research", Management Sciences. May 1988, Vol. 34, No.5.

Orlikowski, W.J. (1992). Learning From Notes: Organizational Issues in Groupware Implementation. In J. Turner and R. Kraut (Ed.) Conference On Computer-Supported Cooperative Work, (pp. 362-369). Toronto, Canada: Association for Computing Machinery.

Schein, E. (1987) Organizational Culture and Leadership. San Francisco, Jossey-Bass