Contested collaboration: A descriptive model of intergroup communication in information system...

Pergamon Information Processing & Management, Vol. 31, No. 6, pp. 859-877, 1995

Elsevier Science Ltd. Printed in Great Britain

0306-4573(95)00002-X

CONTESTED COLLABORATION: A DESCRIPTIVE MODEL OF INTERGROUP COMMUNICATION IN INFORMATION SYSTEM

DESIGN

DIANE H. SONNENWALD* Rise National Laboratory, P.O. Box 49, DK-4000 Roskilde, Denmark

(Received for publication January 1995)

Abstract--Many information system design situations today include users, designers, and developers who, with their own unique group and individual perspectives, need to interact so that they can come to a working understanding of how the information system being developed will coexist with and ideally support patterns of work activities, social groups, and personal beliefs. In these situations, design is fundamentally an interactive process that requires communication among users, designers, and developers. However, communication among these groups is often difficult although of paramount importance to design outcomes. Through a qualitative analysis of a house, expert system, and telecommunications network architecture and management system design situations, a descriptive model of design that characterizes communication among users, designers, and developers as they create an artifact was developed. The model describes design phases, roles, themes, and intergroup communication networks as they evolve throughout the design process and characterizes design as a process of "contested collaboration." It is a first step towards a predictive design model that suggests strategies which may help participants interact more effectively and ultimately improve the quality of design outcomes and the design process.

1. INTRODUCTION

In the past, information systems, including interactive information retrieval systems, management decision support systems, and accounting applications, were usually designed as islands of automation with neither the system's and accounting applications, were usually designed as islands of automation with neither the system's functions nor its human-computer interfaces intergrated to span the needs of a given multi-task function. This problem was further exacerbated by changing business and technical environments in which job functions frequently changed. As a result, users often discovered that systems were not easy to use and often did not help increase their productivity or solve their problems.

More recently, designers and developers have recognized that many information systems are customized cognitive tools that help users do tasks, make decisions, or solve problems within social contexts; therefore, it is essential to consider the users' characteristics and problem- solving context in order to design a successful system. Increasingly, design situations include users, designers, and developers who, with their own unique group and individual perspectives, need to interact so that they can come to a working understanding of how the information system being developed will coexist with, and ideally support patterns of work activities, social groups, and mental models or personal beliefs. In these situations, design is fundamentally an interactive process that requires communication among users, designers, and developers.

Bekker and Vermeeren (1992) observed during interviews and focus group discussions that designers and developers reported their most serious problem in design was communication with team members. While studying a design situation Long et al. (1983) discovered that users

* Permanent address: School of Information and Library Science, 100 Manning Hall, CB#3360, University of North Carolina at Chapel Hill, Chapel Hill, NC 27599-3360, U,S.A.

859

860 Diane H. Sonnenwald

were also dissatisfied with communication during the design process. A user explained:

we come in contact with computer people a great many of whom talk in a very alien language, and you have a constant difficulty in trying to sort out this kind of mid-Atlantic jargon-what it is they're really trying to get a t . . . to an outsider who is suddenly confronted with having to be involved in this, then that's a constant and on-going problem (Long et al., 1983, p. 59).

Brooks (1982) suggested that design projects failed when "[participants] were unable to talk to each other" (Brooks, 1982, p. 74) and suggested that teams should communicate with one another in "as many ways as possible" (Brooks, 1982, p. 75). Kraut and Streeter (1995) surveyed 65 information system design situations within a corporation to discover the relationship between communication among designers and developers and project performance. The main findings of their survey indicated that extensive interpersonal networks improved design outcomes (especially in uncertain projects), projects with denser cross-boundary networks were better informed and coordinated, and the use of formal procedures did not improve intergroup coordination. These findings illustrate that communication among design participants is often difficult although of paramount importance to design outcomes.

The goal of this research was to develop a descriptive model of design that characterizes communication among users, designers, and developers as they create an information system. Communication is defined as "human behavior that facilitates the sharing of meaning and which takes place in a particular social context" (Lievrouw & Finn, 1990, p. 49). To develop a descriptive model of communication in design, the following questions were examined:

(1) How does communication among users, designers, and developers evolve during the design process?

(2) Does the design process have an overall structure that influences communication? (3) Are there communication roles that emerge during the design process? (4) What is the nature of intergroup communication during the design process? In

particular, what are the intergroup communication themes and networks?

Although primarily focusing on information system design, this research also investigated design situations in other fields, such as architecture, when those situations involve users, designers, and developers. These situations provided a basis for comparison and facilitate the creation of a model applicable to a range of design situations in which users, designers, and developers participate.

The descriptive model of communication in design was developed through a qualitative analysis of a single-family house, an expert system, and a telecommunications network architecture and network management system design situations. This model consists of several interrelated components which describe design phases, roles, and the evolution of intergroup networks and themes in design phases. It integrates these components, proposing a concept of "contested collaboration" that suggests why communication in design is difficult although important to design outcomes. This research is a first step towards a prescriptive model that suggests strategies which may help design participants interact more effectively and which may ultimately improve the quality of design outcomes and the design process.

2. PREVIOUS RESEARCH

Historically, research on communication in information system design group began in the 1980s focusing on user-designer interaction in the early phases of the design process. User-designer interaction was analyzed to discover user-designer interaction patterns and designers' communication and cognitive styles and their impact on performance. Carroll e t al .

(1980) analyzed interviews between a designer and user (in laboratory settings) to formulate requirements. They hypothesized that the interview followed a cyclical pattern in which the requirement problem is decomposed into smaller subproblems.

Guinan (I 986) investigated communication during requirement interviews between designers and users and its relationship to designer performance. That is, she observed pairs of designers and users in a laboratory setting as each designer interviewed a user in order to develop system

Intergroup communication in IS design 861

requirements and compared designers' communication styles during the interviews to designer performance as evaluated by their supervisor and the confederate user. As a result, Guinan proposed that interpersonal communication techniques such as meta-communication, reframing, and backtracking are positively related to designer performance.

Using similar methods, Dorsey (1988) investigated the relationship between designer communication-as observed in an initial requirement interview between a designer and user in a laboratory setting--and cognitive styles as measured by psychological tests. He proposed that people-oriented, outgoing designers are the least effective in discovering users' needs, and task- oriented designers are most effective.

In the late 1980s, research on communication in design was expanded to include research on intragroup interaction among designers. For example, Walz (1988) focused on intragroup communication among designers in the early phases of the design process. She did a conversation analysis of 17 meetings attended primarily by designers over 4 months during the early planning phase (software requirement specification stage) of an object-oriented database management system. Walz observed conflict and uncertainty in these meetings and suggested that conflict is "not solely the result of incompatible goals and/or opinions, but also represent[s] a natural dialectic process of knowledge exchange" (Walz, 1988, p. vi). Behavior roles that she identified during these meetings included the role of expert, translator, manager, and asker (seeking information which is lacking in his or her own mental model) (Walz, 1988, p. 49). She attributed 68% of the interaction to the expert role, 18% to the asker role, 9% to translator, and 6% to manager. Walz also observed that conflict among designers was high as they attempted to determine design requirements, decreased when they communicated the determined requirements to users, and increased as they discussed how to fulfill the requirements.

Curtis et al. (1988) conducted 1-h-long structured interviews with 97 designers and developers from 9 corporations involved in 19 projects in stages ranging from early planning through maintenance. They reported the three most salient problems in design for the designers and developers were the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication and coordination breakdowns (Curtis et al., 1988). Factors influencing communication breakdowns included communication skills of individuals, existing incentive systems, different representational formats, rapid change, local jargon, breakdown of information capture (i.e. overwhelming amounts of information), and cultural mores and norms for individual behavior (Krasner et al., 1987). They also observed that "boundary spanners" helped avoid, or reduce, communication breakdowns. The authors also reported that technical themes included application design, system diagnosis or evaluation, software reuse, software technology, and feature and attribute negotiation.

B ucciarelli (1984, 1988) conducted an ethnographic study of design in two engineering firms. Although his study investigated the engineering design process, it is included here because his study was similar in scope and method to the work presented in this paper. In his study Bucciarelli concluded that design is a social process, and through discourse constraints, decisions, and solutions are socially constructed. This discourse occurs across different object worlds, each a "world of technical specialization with its own dialect, system of symbols, metaphors and models, instruments and craft sensitivities" (Bucciarelli, 1988, p. 163).

A recent study that focused on communication surveyed 65 design situations within a corporation to discover how designers and developers communicated and coordinated software development (Kraut & Streeter, 1995). Kraut and Streeter found that extensive interpersonal networks appeared to improve design outcomes, especially in uncertain projects. Design situations with denser cross-boundary networks were better informed and coordinated, and the use of formal procedures did not seem to improve intergroup coordination. This study continued the tradition of relating communication and project performance and the findings further emphasize the importance of intra- and intergroup communication in design.

The research reported in this paper extends these studies by investigating the longitudinal and evolutionary nature of communication throughout the design process as it occurs in "real life," i.e. settings outside the laboratory. It identifies news communication roles and discusses how these roles interact in different phases of the design process. It introduces the concept of "contested collaboration" to explain why these roles and networks emerge.


1. MODEL DEVELOPMENT 2. MODEL EXPANSION~VALIDATION

CASE HISTORY, - - ~ [ ~ PRELIMINARY ANALYSIS j - MODEL

J CASE HISTORY2 - -

l 3. MODEL SYNTHESIS

DESIGN SITUATION

)1 STUDY I

EXPANDED MODEL

SYNTHESIS OTHER ~ &

MODELS COMPARISON

$ P R O P O S E D M O D E L

Fig. 1. Research approach.

3. RESEARCH APPROACH

Because no previous studies explored communication among users, designers, and developers during the information system design process, three actual design situations were analyzed to discover how communication evolved during the design process. As illustrated in Fig. 1, these studies were conducted and analyzed in three main stages: model development, model validation/expansion, and model synthesis. These stages utilized multiple qualitative and ethnographic methods that included participants' and observers' retrospective accounts of design situations, and observations, interviews, surveys, and reports from an ongoing design situation. This multi-perspective data allowed me to look at design from multiple vantage points to discover how participants interacted to facilitate the sharing of meaning and mutually create design knowledge as they do cooperative and disjunctive, complex tasks that require specialized knowledge over a period of time (from several months to several years) in social settings.

3.1. Model development

In the model development stage, two case histories of design situations were analyzed in order to develop a provisional model. Because design situations typically last from many months to several years, case histories provided the opportunity to analyze multiple, diverse design situations and perhaps discover general patterns that may be constant across a variety of design situations.

3.1.1. Case histories. The design situation in the first case history focused on the construction of a single-family house over a 10-month period in 1984. Participants in this design situation included the users (a family of two adults, two children, and the wife's mother and father), developers (a construction firm with four owner-employers who had worked together for approx. 4 years), and designers (an architect establishing a private practice and his assistant). Membership within each group was stable (i.e. it did not change during the design process). The designer group was located in Boston, Mass., U.S.A., several hours away from the construction site and users' current homes and work sites near Amherst, Mass. Throughout the design process, a fast-track, "design-as-you-go" approach was used. In the fast-track approach, designers create plans for artifact components as construction tasks proceed.

The design situation in the second case history focused on the development of an expert system, called XSEL (the eXpert SELling assistant), that was intended to assist sales people in


configuring computer systems which satisfy customer needs. Users were sales people and their managers at Digital Equipment Corporation (DEC) offices throughout the U.S.A., designers were researchers at Carnegie Mellon University, and developers were employees at DEC. New group members joined each group during the design process which occurred over a 5-year period, from 1981 to 1985. Design methods used to create the expert system included the ETHICS (Effective Technical and Human Implementation of Computer-based Systems) participatory design method (Mumford, 1985) which prescribes activities that facilitate user involvement in the design process and an interactive/prototype design approach which prescribes a succession of development and evaluation tasks until a system contains a sufficient number of features to be labeled "completed."

3.1.2. Data sources. Data for the first case history came from the book House (Kidder, 1985). It was selected for analysis because it contains a wealth of data about design tasks, interaction among the architect, builders, and owners, and participants' expectations and interpretations of those interactions throughout the design process.

Data for the second case history included the book XSEL's Progress: The Continuing Journey of an Expert System (Mumford & McDonald, 1989), which provides a history of the design situation from the perspective of a group manager, a business case study of the design situation (Leonard-Barton, 1987), published and unpublished papers by designers and developers (Kukich, 1984, 1985a; Kukich et al., 1985; McDermott, 1981, 1982b, 1984; McDermott & Steele, 1981; O'Connor, 1984), an article on the culture of the corporation during that period (Rifkin, 1986), an interview with a participant, and several documents that describe predecessor design situations (Kukich, 1983, 1985b; McDermott, 1982a). These data from participants documented the knowledge and meanings that people created and attempted to share during the design process.

3.1.3. Data analysis. Both case histories represented diverse situations yet they seemed to share characteristics that might prove common across design projects. A careful review and analysis of the case history data demonstrated that in fact each situation possessed certain definitive event sequences, communication themes, roles, and networks, which evolved in characteristic ways.

To analyze the data, event sequences were first constructed for each design situation. Sequencing was necessary because participants and observers seldom reported events in chronological order to using the same descriptions or organizing schemes. An example of a time line of event sequences is provided in Appendix A. Event sequences served as a basis for categorizing participants' interactions, in particular, who participants talked with, what they talked about, and how they talked about it throughout the design process. Patterns emerged from this coding procedure and were incorporated into the provisional model described elsewhere (Sonnenwald, 1992). The provisional model provided a foundation for data analysis in the subsequent model validation/expansion stage.

3.2. Model validation~expansion

The goal of this stage was to determine the descriptive adequacy of the provisional model by validating it in a new, "real-world" design situation, and modifying it as necessary to create a more general, descriptive model of communication in information system, design. Data was gathered on interactions among users, designers, and developers involved in an ongoing design project. The content and context of their interactions as well as their perceptions and expectations of the project as it unfolded over time were examined.

3.2.1. Research setting and participants. The design situation investigated took place in engineering organizations of a research and development (R&D) corporation that employs several thousand technical employees in the U.S.A., and in its parent corporations that employ thousands of employees throughout the U.S.A. The superordinate goal in this design situation was to create a telecommunications network architecture and management system that would support data, voice, and video communications. The design participants included approximately eight designers, five developers, and 45 users. They had bachelors, masters, and doctorate degrees in disciplines such as electrical engineering, operations research, and business

IPM 31-6-f


administration, and their on-the-job experience ranged from 3 to 37 years. The designers and developers worked in separate office buildings, located up to 50 miles apart, and users worked in locations throughout the U.S.A. Most participants did not work full time on the artifact, others worked full time for intermittent time spans.

3.2.2. Data collection and analysis. Multiple, coordinated research methods, including unstructured interviews, participant observation, document collection, sociometric surveys, and critical incident interviews, were used to gather data about communication. Using multiple methods provided flexibility for gathering data from a range of data sources, including design participants, others in the corporation, technical paper, meeting minutes, viewgraphs, and memoranda. Data from 41 unstructured interviews, 19 participant observation periods, 125 documents, 2 sociometric surveys, and 14 critical incident interviews were collected over a 14 month period. A disadvantage to this approach is that it yielded a large amount of data that was challenging and time-consuming to analyze. To manage this, data collection was interspersed with data analysis.

Similar to the model development stage, these data were analyzed to discover who talked to whom, what they talked about, and how they talked about it. The results of this analysis were summarized in tables and topic memos that included statistics, descriptions and evidence of concepts, or patterns, in the answers to these questions. For example, a table providing statistics on document interaction between developers and users, and excerpts from a topic memo describing developers' perceptions about interaction with users are provided in Appendix B. The results from the analysis were combined in a triangulated strategy to explore the design process from multiple vantage points. For example, one explanation why developers sent users twice as many documents (see Appendix B) could be that developers or users preferred written communication over other types of communication, such as face-to-face interaction. However, data from interviews (see Appendix B) revealed developers felt an urgent need to communication, in particular, to educate users. Thus using multiple types of data helped clarify design participants' behavior.

3.3. Model synthesis

In the model synthesis stage, the results of the model development and model validation/ expansion stages, i.e. results from the house, expert system, and telecommunications studies, were integrated or synthesized in order to create a more general, descriptive model, i.e. patterns that emerged in all three design situations were merged to form a more general model that may be applicable across a range of design situations. The resulting model of design, presented in this paper, characterizes communication among users, designers, and developers as they create an information system by describing design phases and the evolution of roles and intergroup networks and themes during design phases. It proposes the concept of "contested collaboration" as a way to understand these phenomena.

This research approach appears to reflect the multi-perspective nature of design involving diverse groups more than any single-study or single-method approach can. Because the design process is multi-dimensional, it appears appropriate to try to learn about design in the same way, using methods that gather multi-dimensional, multi-perspective data from a range of design situations. By looking at design from multiple vantage points, as provided through histories, interviews, documents, observations, and surveys, a model that incorporates the shared experiences and perceptions of design participants is more likely to be created. Furthermore, utilizing multiple research methods and data sources facilities a triangulation strategy to increase the reliability and validity of the results.

The research methods selected and their implementation impose several limitations for this research. As in most case history research, the availability of data sources constrain the analysis. In the first case history, all data came from one source (i.e. Kidder 1985). This source is informative, however, there is a potential for bias to emerge when only using one source. To control for bias, a second case history was used. In the second case history, multiple data sources helped to incorporate multiple perspectives. Not all perspectives were available, however,


because the design situation occurred in the past and participants and some documents were not accessible.

To increase the number of perspectives incorporated in the model, an empirical investigation, or field study, of a design situation was conducted. As in all qualitative and ethnographic research, unstructured interviews, participant observation, document collection, sociometric surveys, and critical incident interviews impose limits on objectivity, validity, and reliability. Using multiple methods helped to overcome these limits through data triangulation (i.e. using multiple sources such as interview, observation and document data) to confirm observations and interpretations.

There were several limits which emerged, however, when implementing these methods. One limitation was that the telecommunications design project did not go to completion, i.e. the artifact was not finished as was done in the other two studies. A second limitation is that all design situations took place in the U.S.A. and this may introduce a cultural bias in the research. Although this is not uncommon, it implies that some aspects of the results may change as additional types of design situations are investigated. Despite these limitations, however, this research has laid the foundation for a deeper understanding of communication in design and how strategies could be formulated to support communication in design.

4. RESEARCH RESULTS

The descriptive model of communication in design developed in this research consists of several inter-related components which describe design phases, roles, and intergroup communication networks and themes and their evolution during the design process.

4.1. Design phases

A model of design phases, or task activities, partition, or segment, the design process and provide a way to organize and discuss communication behavior and its evolutionary nature during the design process. Previous models of design phases such as the waterfall and spiral life- cycle models (Boehm, 1976, 1988) are prescriptive models that are useful in teaching novices design techniques (Rasmussen, 1990) but they do not reflect what is done in practice (e.g. see Norbjerg, 1992). Thus these models are not adequate frameworks to describe the evolutionary nature of communication in design. Other problem-solving and decision-making models such as the linear group problem-solving model (Fischer, 1970), the spiral model (Crowell & Scheidel, 1961), the functional task model (McGrath, 1984), and the contingency model (Poole & Roth, 1989a, b) have "centred on narrow ranges of task-oriented interactions in primarily self- contained groups" (Putman & Stohl, 1990, p. 261) and their applicability to design situations that consist of multiple, concurrent and sequential complex tasks shared among diverse and dynamic groups over months and years in work settings has not been illustrated. Thus a new model that provides a framework to discuss actual design practice is required.

The model of design phases developed in this research is a generalization based on the design task structure participants and observers presented orally and in text. For example, Mumford and MacDonald (1989) presented their history of the expert system design situation (in the U.S.A.) in five chapters (Chap. 4-8) and analysis of the chapters' contents supported the conceptualiza- tLon of five phases. These phases are: history, planning, framing, finishing, and conclusion, as illustrated in Fig. 2.

The history phase includes past and concurrent events that may have an impact on design situations, including selection of design participants and expectations about communication during the design process. History is represented as a phase and not just a factor because of its universal importance in design situations; it is created by participants and influences them throughout the design process.

After a superordinate goal to create an artifact, or information system, was established and funded, design participants in the three design situations began planning tasks. Plans created in


I HISTORY HISTORY Influential past and ~ c o n c u r r e n t events I PLANNING

PLANNING ~ ~ / i FRAMING I Creati°n °f plans J / / I FINISHING

FRAMING .. . / / , / I CONCLUSION , Initial development / /

CONCLUSION Evaluation

Fig. 2. Proposed design phases.

the house design situation included blueprints that specified how the house should be constructed and a construction contract that specified construction materials, construction prices, and completion dates. Data illustrated that participants discussed plans throughout the design process suggesting that, like the history phase, the planning phase continues throughout the design process.

The next pattern of activities and interaction that emerged from the data appeared to focus on initial development, or implementation, of the artifact or artifact component. This phase is called the framing phase. In the telecommunications design situation, interaction among users and developers in the flaming phase focused on the analysis and integration of technical components, i.e. telecommunications transmission hardware and software intended for use in the artifact. Similar to the history and planning phases, data suggest that the framing phase continues throughout the design process.

Subsequent to framing activities, design participants focused on finishing work, or the addition of details to the artifact or artifact component. In this phase, called the finishing phase, participants in the expert system design situation discussed topics such as user training, system accuracy, and help facilities (e.g. see Mumford & MacDonald, 1989, pp. 123-124). In the house design situation, interaction focused on artifact components such as the main staircase, floors, closets, trim, and other fixtures. After the users moved into the house and paid the developers in full, a developer continued to work on the house doing finishing tasks (Kidder, 1985, p. 327), illustrating that the finishing phase may continue throughout the design process.

The final pattern of activities and interaction, referred to as the conclusion phase, appeared to focus on evaluation of the artifact or artifact component, including user acceptance of the artifact. Some participants also began to plan their next design situation in the conclusion phase. As participants in the telecommunications design situation evaluated the results of their efforts, they began to plan new technical and organizational approaches for another telecommunications network architecture and management system.

As mentioned, analysis of the three design situations suggests that design phases may begin sequentially and continue in parallel. A participant in the telecommunications design situation remarked:

The work is continuously in all phases ... we're always creating proposals, prototypes, and implementing [systems] in parallel.

Furthermore, the overall structure appeared to be recursive, i.e. each phase consisted of a set of events, or tasks, and each event consisted of phases. For example, a planning task for the expert system was the creation of a natural language prototype. Creation of the prototype included a planning task (specification of the prototype's functions), framing task (code construction), finishing task (testing and debugging code), and conclusion task (evaluation of the prototype).

Intergroup communication in IS design

Table 1. Observed communication roles that span group boundaries

867

Role Definition

Agent External star Intergroup star

Gatekeeper

Boundary translator

Facilitates interaction, and arbitrates conflict, among participants Interacts with people external to the design situation Interacts with other participants in the desig," situation and represents their group in these interactions Filters/blocks information that originates outside a group to/from group members Translates group information for others who are not members of the group

Design participants did not necessarily traverse the phases in unison or sequentially. Data suggested that the design phases occurred at different or overlapping points in time for participants. For example, in the telecommunications design situation, there was no single event that marked the establishment of the superordinate goal; participants, largely on a one-by-one basis, began (and stopped) doing design tasks at different points in time. Backtracking and omission of phases also occurred.

4.2. Design roles

Roles do not define an individual but describe relationships to design. Goffman (1981) defined the concept, role, as "the activity the incumbent would engage in were he to act solely in terms of the normative demands upon someone in his position" (Goffman, 1961, p. 85). An individual may perform one or more roles and may change roles. Role performance, or role enactment, is the actual conduct of an individual while assuming a role. Role performance occurs primarily through interaction with others. Others have expectations with respect to role performance and these expectations help shape an individual 's behavior. The individual 's performance, in particular their communication behavior, is the elementary unit of analysis.

Through conceptualization of underlying patterns of communication behavior reported in the unstructured interviews, sociometric surveys, case history data, document distribution patterns, and participant observation, role concepts emerged. Roles that spanned group boundaries and assisted intergroup communication included the agent, external star, intergroup star, intragroup star, gatekeeper, and boundary translator as illustrated in Table 1.

The purpose of the agent role is to arbitrate, or negotiate, differences and facilitate interaction among design participants to ensure that the artifact is created. Bruce, an agent in the expert system design situation, described his role as

A Convener]Facilitator. I will fill this role and act in a manner similar to that of an outside consultant. I will help define agenda items, keep the group focused on its task; ask critical questions; mediate conflict, and ensure that the group meet its work objectives and time targets (Mumford & MacDonald, 1989, p. 87).

Another role which emerged is called a boundary translator role. When assuming a bount~ary translator role, a design participant appeared to explain this or her group perspective for design participants in other groups to increase their knowledge and understanding about the group. For example,

The meeting ended with one of the development team describing bow properties for XSEL were decided. She showed how certain things affected others in XSEL and these dependencies influenced the order in which the development team approached problems. Priorities were also greatly influenced by the needs and goals of Manufacturing Engineering, Sales Management, and the User Design Group itself (Mumford & MacDonald, 1989, p. 124).

A participant who assumed the role of external star interacted with people outside the design situation. The purpose for this interaction appeared to be to get ideas and to validate, or receive recognition for, their expertise. A gatekeeper role also emerged in the two design situations analyzed. This role has been discussed in small group communication literature (e.g. see Tushman & Katz, 1980) and its function is to filter (i.e. discover, interpret, and retransmit) information that originates outside the group to group members. A gatekeeper may also


withhold information from group members. Some group members prepare to assume an intergroup star role, i.e. they interacted frequently with members from other goups and represented their group during those interactions. The intergroup star role is similar to the external star role discussed in small group communication literature (e.g. see Tushman & Scanlan, 1981). However, in design situations, the intergroup star role included the concept of group representation in addition to interaction with other groups.

4.3. Intergroup communication in design phases

In the house, expert system, and telecommunications design situations, general patterns of intergroup communication behavior among roles emerged in each design phase. Role emergence in each phase is described in the following sections and summarized in Table 2.

4.3.1, History. Interactions that occurred before the establishment of the superordinate goal to create an artifact, or information system, appeared to foretell who would and would not participate in the design situation. In all three design situations, an intergroup star from the designer group and an intergroup star from either the user developer group had a personal and/or professional relationship with each other before the superordinate goal to create the artifact was established. When the user group provided funding for the design project, the relationship was between the designer and user intergroup stars; when the developer group provided funding the relationship was between the developer and designer intergroup stars. For example, in the house design situation, the owners who financed the project and the architect had been friends for many years; in the expert system and telecommunications design situations, the developer intergroup stars who provided initial funding for the project and the designer intergroup stars had worked together previously.

The history that is created during the design process appeared to have an impact on subsequent events during the design process; previous decisions were referred to by participants at later points in time to justify their perspective. For example, the users in the house situation insisted that the developers reduce the construction contract price by $660.00, approx. 0.4% (Kidder, 1985, pp. 38-47). Months later, when negotiating changes a developer rejected a compromise offered by a user saying,

I'm uncomfortable on this .... The fact that you already knocked the price down $660.000 makes me reluctant [to compromise] (Kidder, 1985, p. 210).

Furthermore, the history that is created during the design process appeared to have an impact on communication in subsequent design situations. Developers in the house design situation left notes carved in beams and etched in concrete to future builders telling the story of their work. They also talked about notes they found from past builders on houses they renovated. This is

Table 2. Role emergence among groups during design phases

PHASES

Role History Planning Framing Finishing Conclusion

Agent User or User or User or User or Developer Developer Developer Developer

Intergroup Designer and Designer Designer Designer Designer star (User or User User User User

Developer) Developer Developer Developer Developer

Boundary Designer Designer Designer Designer translator Developer

Gatekeeper Developer Developer Developer Developer Designer Designer Designer Designer

External User User User User star Developer Developer Developer Developer

Designer Designer Designer Designer


USER INTERGROUP STAR

, / ",,

J \ DEVELOPER ~, ~ DESIGNER

INTERGROUP STAR INTERGROUP STAR

Fig. 3. Observed intergroup communication in the planning phase.

similar to the software programming practice of leaving notes describing the software in program code which only future programmers will see.

4.3.2. Planning. As illustrated in Fig. 3, intergroup communication in the planning phase appeared to occur primarily one-on-one among intergroup stars from user, developer, and designer groups. When design methods and/or corporate policies required one-to-many or many-to-many face-to-face interaction among participants, communication appeared to be less effective. For example, during focus group meetings attended by two designers and 7-10 users when users appeared to question proposed artifact features, designers appeared to negate users' comments, responding to users with phrases such as:

We're not here tonight to address those issues. We'd like to focus on another issue.

Themes communicated among intergroup stars appeared to be more dependent on the message originator, or originator's group, than the audience. That is, each group appeared to have a main topic they communicated regardless of the role or group membership of the audience. Themes common to developer, designer, and user groups in all three design situations were, respectively: (a) development methods (including next steps in the design process) and practices; (b) artifact aesthetics and artifact details; and (c) users' needs, artifact functionality, and constraints. For example, in the expert system design situation, the developer's theme focused on the ETHICS method (e.g. Mumford & MacDonald, 1989, pp. 86-89), the designer's theme focused on algorithms to do ad hoc constraint processing and natural language explanation (e.g., McDermott & Steele, 1981; McDermott, 1981), and the user's theme focused on ease of use requirements (e.g. Mumford and MacDonald, 1989, pp. 80-81).

Conflicts among groups during the planning stage seemed to arise from the following: (a) Theme incompatibility. For example, a user intergroup star in the house design situation

asked the developer how much the lumber was going to cost to build the house. The developer answered by explaining standard pricing methods in construction. This was not what the user wanted to hear, yet, it was the best answer the developer could provide from the developer's perspective.

(b) Language differences. Design participants with their own specialized knowledge and work tasks, had language differences that caused misunderstanding among participants. For example, a developer reported:

Language is a weird thing, man. I don't understand Jim's language a lot of the time even though it's the same language (Kidder, 1985, p. 163).

(C) Incomplete, specialized knowledge. All three groups had specialized knowledge that contributed to the design process. However, during the planning phase, that knowledge was incomplete; participants were formulating and refining plans throughout the planning phase. Participants' incomplete knowledge often caused conflict when other groups or group members expected completeness.


USERS

7", DEVELOPERS DESIGNERS

Fig. 4. Observed intergroup network in the finishing phase.

(d) Power relationships. For example, in the telecommunications design situation, the designer group was granted more power than the developer group by the corporate culture. This contributed to developers' perception of being powerless with respect to some planning decisions and to designers' perception of having permission to ignore comments from others.

4.3.3. Framing. During the framing phase, additional roles and themes emerged. The agent role emerged and facilitated communication among all participants irrespective of their group membership. In particular, the agent fostered goodwill among participants by providing opportunities for communication among participants, reinforcing the superordinate goal, and helping participants negotiate differences. Additional intergroup stars also emerged; they assisted their group's original intergroup star by interacting with other design participants and representing their group during those interactions. Intergroup stars also introduced interpersonal themes and expanded their interactions to include most design participants. The purpose of these roles appeared to be to help reduce intergroup conflict and encourage participants to complete design tasks. Sometimes these strategies did not appear to be successful as participants misunderstood one another's intentions and languages.

Judith [a user] . . . [made] her merry laugh. "Jonathon [another user] was here this morning. He said, 'They must be Jewish builders. I thought Protestant builders were always at work by seven."' Jim [a developer] smiles faintly, but after she leaves, he says, "Protestant carpenters. Is that what you call being razzed? . . . I 'm not going to tell them I 'm half-Jewish. I may need to use that someday" (Kidder, 1985, p. 142).

The agent role, additional intergroup stars, and interpersonal themes did not emerge in the telecommunications design situation. In this situation, communication appeared to be equated with control. Corporate communication rules appeared to be perjorative in nature, including such rules as:

Your manager tells you who you talk to. Women cannot initiate technical or project-related talk.

Because communication appeared to be equated with control, it was not surprising that roles and themes to facilitate intergroup communication did not emerge.

4.3.4. Finishing. A dominant intergroup communication theme in the finishing phase appeared to be the negotiation of design details, or artifact features. Most design details had to be decided (or resolved) in this phase or would never be resolved. As the artifact nears completion, it may be more difficult to resolve artifact details due to the large number of unresolved details, constraints on choices imposed by previous solutions, limited resources, and possible negative interactions with other features.

As illustrated in Fig. 4, the agent continued to perform a vital role in negotiating differences among the designer, developer, and user groups. However, intergroup interaction among designers and developers appeared to greatly diminish during this phase; in the expert system


design situation, developers reported no interaction with designers (e.g. see Mumford & MacDonald, 1989, p. 116). Past stressful interactions and the anticipation of future stressful interaction as well as practical considerations, such as designers working on other design situations and not being available for interaction, may cause interaction to decrease. Whatever the cause, participants appeared to implement strategies to successfully complete tasks with minimal interaction between designers and developers. For example, developers made design decisions independent of the designers.

Jim [a house developer] thought of calling Bill [the designer]. There were many reasons why, and one of them, Jim knew, was that the thought of calling Bill made him feel less than fully competent. Besides, Jim would have to wait for Bill to come . . . Jim made the choice, and eagerly began to build (Kidder, 1985, p. 272).

Developers also enlisted the aid of users who had taken on developers ' tasks and worked side- by-side with developers. They consulted with these users, who were in close physical proximity and who had begun to learn developers ' language and task domain, and asked them to make design decisions that otherwise designers would have had to make.

4.3.5. Conclusion. There appeared to be a gradual reduction in intergroup communication in the conclusion phase as group members completed their task and began to work in other design situations.

The primary intergroup theme that appeared to emerge in the conclusion phase focused on evaluation. Due to the recursive nature of the design process, evaluation occurred throughout the design process (i.e. as participants concluded tasks they often evaluated their own and each other 's task results). In the house design situation, developers evaluated designers ' plans for attributes such as completeness, timeliness, and aesthetics; designers evaluated how accurately developers implemented their plans; users evaluated the quality, cost, and progress of developers ' construction. At the completion of the design process, participants appeared to do a "future-oriented" evaluation, i.e. they did not evaluate the artifact or design situation in order to modify it but rather to reflect how their experiences will shape their future. Users appeared to evaluate how they will be able to use the artifact in the future. Developers appeared to evaluate how they will be able to use what they learned during the design process in future design situations. Designers appeared to evaluate artifact features to determine which should be used in future artifacts. In the house situation, the designer actually lived in the house for several days, evaluating how he and the users interacted with house features.

In general, users appeared to perceive design as successful when they saw their requirements and requests synthesized and transformed into an artifact and that artifact was useful in their context, perhaps in ways they had not originally envisioned. Designers appeared to perceive success as the fruition of their ideas into an completed artifact, utilization of the artifact, and peer recognition such as design awards and invitations to write and/or speak about the artifact. Developers appeared to perceive design as successful when they experienced personal and/or professional growth, users accepted the artifact, good will was established with users, and a technically superior artifact was constructed. For example, a developer proudly reported:

Good will at the end is worth some money. We are horrible business people. But by God, we can build a house! (Kidder, 1985, p. 327).

As a result of participants' diverse evaluation criteria, conflict occurred and the agent often helped participants resolve their conflicts.

In the house and expert system design situations (in which an artifact was built), participants also praised one another for jobs well done. Although conflicts and tension existed throughout the phases, participants appeared to respect and value each other 's contributions at the end of the design process. But even when praising others, there still was misunderstanding. For example, the users invited the developers to a party to thank them for their work.

The Souweines [users] have proposed [a party] . . . for the middle of a weekday .... The next few days, Jim [a developer] canvasses everyone .. . . Finally, Jim has to tell Judith [a user] that she's chosen the wrong time of day for the party. In a busy season like this one, no one wants to take hours off from work. Perhaps another time they say to each other, but Jim feels sure there won't be a party. There almost never is (Kidder, 1985, pp. 298-299).

In the telecommunications design situation (in which the artifact was not completed),


Specialization ~ PARTICIPANT I

CONTESTED CONTESTED COLLABORATION COLLABORATION

~Exploration Expl°rati°n~ PARTICIPANT- , .~ and'integration and integration~,, . . . . . . . . . . ,L,' L ) . . . . . . ) CONTESTED .- - (..,) - , r=-vvw~Lu ~ COLLABORATION

Specialization

PARTICIPANT a LIFE-WORLD

Specialization

Fig. 5. "Contested collaboration" in the design process.

participants criticized one another 's behavior and reported negative feelings towards one another and the design process:

[Others] tried to sell their own interests --look good through any means--not solve real problems.

I have come to disown [the project.]

I'm worn out.

There's no positive thinking any more .. I'm disgusted. I don't care who knows. You can tell anyone you want.

4.4. Contested collaboration

Through conceptualization of roles, and intergroup networks and themes across design phases, a general model of communication in design emerged that suggests why communication is difficult for users, designers, and developers although of paramount importance to design outcomes. The model, illustrated in Fig. 5, suggests that communication in design may be characterized as "contested collaboration." Users, developers, and designers come to design situations with pre-existing individual and group patterns of work activities, social groups, and personal beliefs. That is, they have unique life-worlds,* or domains and perspectives. This uniqueness makes their participation in design situations meaningful. Designers contribute specialized knowledge about how an artifact could be constructed, developers contribute specialized knowledge about how to construct an artifact, and users contribute specialized knowledge about the intended domain of the artifact. Participants must collaborate and mutually explore one another 's life-world and specialized knowledge so that they can come to a working understanding of how the artifact will co-exist with and, ideally, support patterns of work activities, social groups, and personal beliefs. For example, to create an information system, designers may need to collaborate with users to learn about their work domain(s). Similarly, users may need to collaborate with designers to discover the possible implications of emerging technology in their work domain. Designers and developers may need to collaborate to refine the designers' plans in order to facilitate construction of the system, and users and developers may need to collaborate to determine how the system, can be implemented, or installed, satisfying developers ' and users' constraints. This is similar to Bucciarel lrs (1984, 1988) model of engineering design in which constraints, decisions, and solutions are socially constructed through discourse among design participants.

*Life-world is a term introduced by Schutz and Luckman (1973) to mean "the quintessence of a reality that is lived, experienced, endured . . . a reality that is mastered by action and the reality in which--and on which -----our action fails" (Schutz & Luckman, 1973, p. 1).


However, it is often difficult for participants to collaborate and mutually explore one another's life-world due to the uniqueness of each life-world. This uniqueness separates participants through differences in language, expectations, motivation, and perceptions of quality and success, as illustrated in the following conversation between users and developers during a meeting:

Userl: We need a Consumer's Report of [the technology] with circles indicating how well equipment does with each function.

Developer1: We can't make judgments, recommendations. We give technical details about technology. Developer2: There are legal problems with comparing more than one vendor on a piece of paper. User2: Put it on separate pieces of paper. Developer~: Have you seen our reports? We send them to [person's name] in your organization. User2: He's asleep.

These differences can cause misunderstandings, conflict, and uncertainty as observed not only in the three studies reported in this paper but in other studies of information system design as well (e.g. Curtis et al., 1988; Walz, 1988). Participants appear to contest, or challenge, each other's contributions as illustrated by the following comments by design participants.

I was treated as a non-professional who doesn't know anything; [others] complained about my [written analysis], it's style, language, content . . . . They didn't like the s tory . . , but I had a different story to tell. I listened to the user.

Dissatisfaction is continuous.. , for two years trying to find the right language to draw [others] in.

People try to sell their own interest, push their own point of view, what's best for them.

We were soldiers in the knowledge wars.

This is further exacerbated because participants must also delve deeper into their unique life- worlds, searching for additional specialized knowledge and increasing their unique expertise, to complete required design or domain-related tasks. That is, to complete tasks, participants often need to apply and further develop their unique specialized language, domain knowledge, and life constructs. As one participant explained.

One person we don't generally interact with are actual designers. This is not good, it's best to get the information first-hand... I suspect this is because they have too much investment in doing designs to spend time talking with us.

Thus, it may be difficult for design participants to negotiate differences or come to an understanding during the design process because there appears to be opposing forces separating developers, designers, and users. The need to collaborate with other groups requires participants to gain an understanding of one another's life-world, including one another's language, expectations, and normative behavior. Yet, at the same time, the need to solve other design tasks may require participants to delve deeper into their own life-world, focusing on their specialized language, knowledge, and normative behavior.

Data from intragroup communication (see Sonnenwald, 1993) further suggest that the concept of "contested collaboration" may also explain communication among group members. That is, the concept appears to be recursive, applying to intragroup communication as well. Within groups, members often specialize and this specialization may impose a unique language, expectations, and beliefs and may make negotiation of differences and mutual creation of knowledge difficult.

There appears to be communication strategies which may help participants collaborate and negotiate differences. Intergroup communication strategies which emerged in the house and expert system, design situations included the agent role, sharing similar types of tasks between groups, and interpersonal themes.

Individual, organizational, or cultural norms may prohibit these strategies from emerging. When communication was equated with control in the telecommunications design situation, strategies to help participants overcome the differences implicit among their unique life-worlds and successfully negotiate differences, mutually create knowledge, or reach a consensus did not appear to emerge. Instead, participants attempted to force others to accept their life-world. Equating communication with control and similar norms may have a negative impact on the quality of the design process and design outcomes. They appear to allow conflicts to remain


unresolved, causing anger or animosity among participants and unwillingness to work with together in future design situations.

5. IMPLICATIONS

Through the use of multiple qualitative and ethnographic methods, this research explored the evolutionary and multi-dimensional nature of communication in design. It extends previous research by discovering communication roles and networks that evolve during the information system design process and by proposing the concept of "contested collaboration" as a way to understand why communication in design is difficult for participants although paramount to design outcomes.

The description and explanation of interaction among design participants may help developers, designers, and users involved in actual design situations to better understand each other 's perspectives and help them to create realistic expectations for others' behavior and resolve conflicts more effectively, leading to improved outcomes.

The model also implies that multi-disciplinary courses drawing on communication, psychological, organizational, and information theories should be incorporated into design curriculums. These theories could augment traditional, rational design methodologies by introducing students to the multiple complexities of design contexts and offering them theories to help manage and explore those complexities when they encounter them as practitioners and researchers.

The results, in particular the concept of "contested collaboration", may also increase our understanding about communication in collaborative contexts similar to design where people with diverse knowledge need to interact over a period of time to achieve a goal. For example, in the pharmaceutical industry (Algon, 1994), market economists and epidemiologists (users), chemical researchers and process engineers (designers), and statisticians (developers) need to collaborate to create the documentation and processes required to bring a new drug to market. Further research is necessary to determine if the model is applicable to these types of situations, but it represents a step towards increasing our understanding of group interaction in complex and dynamic collaborative contexts.

This research is a first step towards a predictive model that suggests strategies which help design participants interact more effectively and which may ultimately improve the quality of design outcomes and the design process. Studies such as the one presented in this paper are necessary in order to create general models that explain the design process, and suggest how design participants from different life-worlds can more effectively communicate throughout the design process.

Acknowledgement--This paper is dedicated to the memory of Marjorie E. Courain. I wish to thank Nick Belkin, as well as Carol Kulhthau, Leah Lievrouw, Valerie Manusov, and Scott Robertson, for their valuable advice throughout this research. I also wish to thank the participants in the field studies, and Annelise Mark Pejtersen, Jens Rasmussen, and the anonymous reviewers for their comments on this paper. This work was supported by the Bellcore Support for Doctoral Education Program, and, in part, by the ASIS ISI Dissertation Scholarship.

REFERENCES

Algon, J. (1994). The effect of task on information-seeking behaviors of individuals in the work-group environment. Unpublished dissertation proposal, Rutgers University, New Brunswick, N.J.

Allen, T. J., Lee, D. M., & Tushman, M. L. (1980). R&D performance as a function of internal communication, project management, and the nature of the work. IEEE Transactions on Engineering Management, EM-27, 2-13.

Bekker, M. M., & Vermeeren, A. P. (1992). Developing design methods: Task analyses in user interface design. Poster presentation at CH1'92 ACM Conference on Human Factors in Computing Systems, Monterey, Calif.

Boehm, B. W. (1976). Software engineering. IEEE Transactions on Computers, 25(12), 1226-1241. Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21,

61-73.


Brooks, E P. (1982). The mythical man month. Reading, Mass.: Addison-Wesley. Bucciarelli, L. L. (1984). Reflective practice in engineering design. Design Studies, 5, 185-190. Bucciarelli, L. L. (1988). An ethnographic perspective on engineering design. Design Studies, 9, 159-168. Carroll, J. M., Thomas, J. C., & Malhotra, A. (1980). Presentation and representation in design problem solving. British

Journal of Psychology, 71, 143-154. Crowell, L. & Scheidel, T. M. (1961). Categories for analysis of idea development in discussion groups. Journal of

Social Psychology, 54, 155-168. Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems.

Communications of the ACM, 31, 1268-1287. Dorsey, E R. (1988). An investigation of the effectiveness of communication between systems analysis and end users in

the design of large computer systems. Unpublished doctoral dissertation, The University of Utah. Fisher, B. A. (1970). Decision emergence: Phases in group decision making. Speech Monographs, 37,

149-190. Goffman, E. (196 l). Encounters. New York: Bobbs-Merrill. Guinan, E J. 0986). Specialist-generalist communication competence: A field experiment investigating the

communication behavior of information systems developers. Unpublished doctoral dissertation, Indiana University, Bloomington, Ind.

Kidder, T. (1985). House. Boston: Houghton Mifflin. Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM. 38(3),

69-8 I. Krasner, H., Curtis, B., & Iscoe, N. (1987). Communication breakdowns and boundary spanning activities on large

programming projects. In G. M. Olson, S. Shepard, & E, Soloway (Eds), Empirical studies of programmers: Second Workshop (pp. 47-64). Norwood, N.J.: Ablex.

Kukich, K. (1983). Design of a knowledge-based report generator. In Proceedings of the 21st Annual Meeting of the Association for Computational Linguistics. Cambridge, Mass. Association for Computational Linguistics.

Kukich, K. (1984). Knowledge-based explanation generation. In Proceedings of the Second Annual Language Generation Workshop. Stanford, Calif.: Stanford University.

Kukich, K. (1985a). Explanation structures in XSEL. In Proceedings of the 23rd Annual Meeting of the Association for Computational Linguistics (pp. 228-237). Morristown, N.J.: Association for Computational Linguistics.

Kukich, K. (1985b). The feasibility of automatic natural language report generation. In Proceedings of the 18th Annual Hawaii International Conference on System Sciences. Honolulu, Hi: IEEE Computer Society Press.

Kukich, K., McDermott, J., & Wang, T. (1985). Explaining XSEL's reasoning. Unpublished manuscript. Pittsburgh, Pa: Carnegie Mellon University.

Leonard-Barton, D. (1987). The case for integrative innovation: an expert system at Digital. Sloan Management Review, Fall, 7-19.

Lievrouw, L. A., & Finn, T. A. (1990). Identifying the common dimensions of communication: The communication systems model. In B. D. Ruben & L. A. Lievrouw (Eds), Mediation, information, and communication: Information and behavior (Vol. 3, pp. 37-65), New Brunswick, N.J.: Transaction.

Long, J., Hammond, N., Barnard, E, Morton, J., & Clark, I. (1983). Introducing the interactive computer at work. The users' views. Behaviour and Information Technology, 2(1), 39-106.

McDermott, J. (1981). Domain knowledge and the design process. In Proceedings of the 18th Design Automation Conference (pp. 580-588). Piscataway, N.J.: IEEE.

McDermott, J. (1982a). Rl: A rule-based configurer of computer systems. Artificial Intelligence, 19(1), 39-88.

McDermott, J. (1982b). XSEL: A computer sales person's assistant. In J.E. Hayes, D. Michie, & Y-H Pan (Eds), Machine Intelligence 10 (pp. 325-337). New York: Wiley.

McDermott, J. (1984). Building expert systems. In W. Reitman (Ed.), Artificial intelligence applications for business: Proceedings of the NYU Symposium (pp. I 1-22). Norwood, N.J.: Ablex.

McDermott, J., & Steele, B. (1981). Extending a knowledge-based system to deal with ad hoc constraints. In Proceedings of the Seventh International Joint Conference on Artificial Intelligence (pp. 824-829). Los Altos, Calif.: Morgan Kaufman.

McGrath, J. E. (1984). Groups: Interaction and performance. Englewood Cliffs, N.J.: Prentice-Hall. Mumford, E. (1985). Defining system requirements to meet business needs: A case study example. Computer Journal,

28(2), 97-104. Mumford, E., & MacDonald, W. B. (1989). XSEL's progress: The continuing journey of an expert system. New York:

Wiley. Nerbjerg, J. (1992). Skill and cooperation in systems development. In G. Bjerknes, T. Bratteteig, & K. Kautz (Eds),

Proceedings of the 15th information systems research seminar in Scandinavia (IRIS) (pp. 271-285), Oslo, Norway: Department of Informatics, University of Olso.

()'Conner, D. E. (1984). Using expert systems to manage change and complexity in manufacturing. In W. Reitman (Ed.), Artificial intelligence applications for business: Proceedings of the NYU Symposium (pp. 149-158). Norwood, N.J.: Ablex.

Poole, M. S., & Roth, J. (1989a). Decision development in small groups: IV. A typology of decision paths. Human Communication Research, 15, 323-356.

Poole, M. S., & Roth, J. (1989b). Decision development in small groups: V. Test of a contingency model. Human Communication Research, 15, 549-589.

Putnam, L. L., & Stohl, C. (1990). Bona fide groups: A reconceptualization of groups in context. Communication Studies. 4•(3), 248-265.

Rasmussen, J. (1990). Models for design of computer integrated manufacturing systems: Information requirements of decision makers. International Journal of Industrial Ergonomics, 5(1), 5-16.

Rifkin, G. (1986). A whole new DEC. Computer World, 20(38A), 14-23. Schutz, A., & Luckman, T. (1973). In R. M. Zaner, & H. T. Engelhardt, Jr, Trans., The structures of the life-world.

Evanston, Ill.: Northwestern Univerity Press.


Sonnenwald, D. H. (1992). Intergroup communication in design: A pilot study. Proceedings of the 55th American Society for Information Science Meeting (Vol. 29, pp. 86-93).

Tushman, M. L., & Katz, R. (1980). External communication and project performance: An investigation into the role of gatekeepers. Management Science, 26( 11 ), 1071-1085.

Tushman, M. L., & Scanlan, T. J. (1981). Boundary spanning individuals: Their role in information transfer and their antecedents. Academy of Management Review, 24, 289-305.

Walz, D. B. (1988). A longitudinal study of the group design process. Unpublished doctoral dissertation, The University of Texas at Austin.

APPENDIX A

Example of Event Sequences

Timeframe Event(s)

Source (Kidder, 1985)

Page No.

Summer, Fall 1982

January 1983 Late January 1983 February 1983

1 March 1983

March-Mid-April 1983 Mid April 1983 Monday in April 1983

Late April 1983

Several days later Early May 1983 17 May 1983

Jonathon and Judith (owners) bicycle to look at houses 14 in the area Bill (architect) starts own business 22 Jonathon & Judith called architect 1, 52 ff. Bill still working at his old finn 59 Bill visited Jonathon & Judith to discuss ideas for the 52 ff. house Bill created plans for bids 31-33 Jim, Ned, and Richard (developers) reviewed Bill's plan, 23-24, 31 developed bid Meetings to discuss house plans 32-37 Ground breaking 6 Jim proposed final price to Judith and Jonathon (1 week 38 after ground breaking) Meeting between Jim, Judith & Jonathon to discuss 40-47 contract price & dates Construction contract signed 46 Concrete foundation poured 84 Apple Corps began building 103

Event sequences were used as a basis to categorize participants' interactions, and identify design phases and communication networks within these phases.

APPENDIX B

Excerpts from document distribution tables

No. of Network path occurrences

Developer to user 18 User to developer 9


Excerpts from a topic memo

Developers' Perceptions of Interaction with Users

Developers reported their role was to educate users about technology, and business and market directions; users were perceived as not knowing a lot about these topics. In describing their interactions with users, developers used words that indicated their perspective/knowledge was superior to the users'. The developers felt their role was not to listen to users or mutually exchange knowledge but to 'educate' and 'enlighten' users, to 'tell ' and 'sell ' their perspective to users. Words such as 'discuss,' 'learn,' or 'explore' were not used by developers as they described their interaction with users. Evidence of this includes the following:

6.28.91, p. 7: X stated that a user' solution "is a fast train hitting a brick wall."

9.20.91, p. 13: V reported that users "do little planning which they need to do." He also reported that he does not get the information he needs from the users (p. 12).

9.24.91, p. 2: Y reported he did a "selling job [to users] to make them aware." On p. 3, he reported "I enl ightened. . . [users] of it's [the technology's] potential."

10.3.91, p. 3: X described "going out [to users] to bring focus and informed information about technology and applications." P. 4: they pay me to tell them what they don't know in such a way that they won't be upset." P. 16: X reported giving users a "tutorial on technology."

10.24.91, p. 6: Z reported that the purpose of a meeting with users was "to figure out how our work plan meets their needs." Note, the meeting's purpose, as reported, was not to determine whether the work plan met or could meet the users' needs; Z assumed it did, he just needed to figure out how to convince them it did.

11.25.91, Memo: X reported that users are dissatisfied with their interaction with developers and that the cause of the dissatisfaction is timing; users want more of the same type of interaction but in a more timely fashion.

11.25.91, p. 1: X reported "users don't know what they want . . . they don't have a complete perspective." P. 5: Users are "just people who work on day to day problems." p. 7: They "react to the market place. Very dangerous."

12.4.91, P. 2: X reported that he has done "lots of social work with our users about what [the project is.]"

Analysis of different types of data were combined in a triangulation strategy to discover explanations of design participants' behavior.

Contested collaboration: A descriptive model of intergroup communication in information system...

Documents

Transcript of Contested collaboration: A descriptive model of intergroup communication in information system...