Abstract

This ethnographic study investigates how a project group deals with the contradiction between distributed knowledge in boundary-spanning collaborative processes and the expectation that software systems will provide unified, codified knowledge. Group and individual activities were observed over a period of 18 months, to examine the ways knowledge was presented, recognized, shared, or otherwise managed during joint design of business process and IT systems change. The study explores how knowledge and expertise were translated across organizational boundaries, and identifies four stages in the development of group understanding of how to manage sensemaking and expertise across knowledge boundaries: focus on defining shared goals; acknowledging and sharing tacit knowledge about organizational practice; identifying external influences; and explicit knowledge generation.

Introduction

The most commonly-held view in the organizational knowledge management (KM) literature is that there is a hierarchy in which data, information, and knowledge incrementally build on each other, to construct the basis for human action (Alavi & Leidner, 2001). In a search for how an understanding of how practice-based knowledge can be shared and understood, authors have focused on the differences between tacit and explicit knowledge, comparing "know-how" (tacit knowledge) with "know-what" (explicit, fact-based knowledge) (Garud, 1997; Prusak, 2001). But organizational knowledge management is especially problematic because of the difficulty in combining knowledge of business processes that are largely tacit and embedded in local norms and practice with information systems that require the formalization and codification of explicit rules by which to process and present data (Brown & Duguid, 2000; Johnson, Lorenz, & Lundvall, 2002; Zack, 1999). It is therefore difficult to codify a body of knowledge without losing some of its original characteristics. Most forms of relevant knowledge combine elements that are simple to codify with elements that are embedded in human action or thought processes—extraction of the codifiable parts of this knowledge does not always represent progress, as it may remove the capacity for effective decision-making or exception-handling (Johnson et al., 2002). This is especially difficult when collaboration is required for the completion of work tasks across organizational group boundaries (Boland, Tenkasi , & Te'eni, 1994; Brown & Duguid, 1994; Carlile, 2002). While many studies focus on cooperation in computer-mediated work groups, these studies often focus on the role of technology in supporting some unexplored construct of collaboration.

This article attempts to flesh out that construct, by providing rich insights into how members of a group that spans various professional communities of practice collaborate in jointly constructing a socio-technical artifact—a knowledge management system—within its context of application. The study presented here follows a diverse group of managers engaged in the high-level co-design of business process and IT systems to support the process of responding to customer invitations to bid for new business contracts. The analysis examines the problems the group faced in determining what knowledge was appropriate for the process and how this would be supported by information and knowledge sources, when existing knowledge of the process was distributed across a wide number of people and work-domains.

Conceptual Background

Contradictions in Boundary-Spanning Knowledge Management

The IS literature reflects a fundamental contradiction between two views of "knowledge management." To manage organizational practice effectively, we need to understand how knowledge processes produce, and are in turn produced by, a localized context of work (Brown & Duguid, 2000; Nonaka & Konno, 1998). Work-related knowledge is embedded within the social and cultural rules of behavior that pertain to a specific group, performing specific work, in a specific place (a community of practice) (Alavi & Leidner, 2001; Lave & Wenger, 1991; Suchman, 1987, 1996). But the successful use of information and computer technologies to communicate knowledge among and across distributed workgroups depends on knowledge being captured, codified, and transferred among people performing related-but-different work, located in different places and belonging to different communities of professional practice (Boland et al., 1994; Leibowitz, 2001; Zack, 1999). Thus, the utilization and transfer of organizational knowledge lies at the intersection between two modes of analysis: 1) reflective involvement in those local systems of social interaction, practice, and sensemaking that constitute organizational work, and 2) engagement in that detached sensemaking and analysis, by which situated knowledge is externalized, reified, and made explicit (Buckland, 1991; Johnson et al., 2002; Nonaka & Konno, 1998; Weick, 1995).

This is a complex process when engaged in by a boundary-spanning group. It involves the negotiation of multiple domains of knowledge, by actors who possess at best a partial understanding of domains other than that pertaining to their own community of professional practice, and who may only be able to articulate knowledge partially within their own domain (Hutchins, 1991; Johnson et al., 2002; Lave & Wenger, 1991). It also involves the negotiation of expertise within a political context involving a diverse set of interest groups (Boland & Tenkasi, 1995; Brown & Duguid, 2000; Gioia, Thomas, Clark, & Chittipeddi, 1994). Expertise—the ability to act knowledgeably within a specific domain of application—is inextricably linked to the mobilization of organizational knowledge. As a result, organizations need to manage knowledge both as information-object and as process—the design of IT-based knowledge systems cannot be separated from the design of related business processes and the consideration of how expertise will be supported (Blackler, 1995; Zack, 1999). These elements were explored through the research question that guided this study:

How does a participative boundary-spanning group, that is engaged in the design of a knowledge-management information system, balance sensemaking as reflective involvement in their various communities of practice with sensemaking as joint engagement in the "detached" analysis of business processes and IT support requirements within a political context?

Forms of Knowledge and Ways of Knowing

At the core of the tension between situated involvement and detached analysis is a distinction between explicit and tacit knowledge (Polanyi, 1958; Ryle, 1949/1984). Tacit knowledge is equated with know-how: knowledge that we acquire through our experience of acting in the world. This presents problems for computer-mediated communication, especially when this mediation involves knowledge management systems. Much tacit knowledge is embedded in the actor's understanding of the situation in which it is produced. It is difficult to reify and "transfer" this knowledge without social interaction and apprenticeship-type learning (Buckland, 1991; Lave & Wenger, 1991). As Schmidt (1997) observes, formal organizational procedures, plans, and structures cannot fully reflect the complex organization of work. All knowledge about what to do, and how, depends upon a complex set of assumptions and contingencies that lie outside of the formal prescriptions of action that are presented as legitimate in specific circumstances (Schmidt, 1997; Suchman, 1987).

The transfer of organizational knowledge requires joint sensemaking—a mutually-negotiated understanding of how to make sense of the local, organizational "world" of work and interaction (Weick, 1995). This is enacted through the combined use of tacit and explicit knowledge—and of individual and shared knowledge (Cook & Brown, 1999). In providing the sensemaking that guides organizational action, each type of knowledge performs a role that the others cannot. Cook and Brown (1999) argue that four distinct "ways of knowing" thus underlie the various forms of knowledge that must be shared for effective organizational collaboration. This model was adapted by considering the forms of expertise required to influence the negotiation of boundary-spanning knowledge across communities of practice, as shown in Figure 1 and explained below.

Concepts represent things an individual can know learn and express explicitly—these form the easiest form of knowledge to recognize and to codify for transfer by computerized information systems (Cook & Brown, 1999). When an individual's knowledge of the problem situation is only partial (as is the case in a boundary-spanning group), conceptual knowledge such as technical expertise may be manipulated by others, to shape stakeholder expectations of information technology (Markus & Bjorn-Andersen, 1987). The ability to define relevant knowledge-domains is essential for collaborative sensemaking. Influence may thus be exerted by claims to expertise that affect the legitimacy (or otherwise) of various knowledge domains.

Stories are typically used as a way for socio-cultural communities of practice to express collective memory of success or failure (Cook & Brown, 1999). Influence may be exerted through the "management of meaning" (Smircich & Morgan, 1982), where events and phenomena are interpreted in specific ways through stories and "myths" that reflect specific cultural behaviors that are valued. Definition of a relevant boundary of action defines relevant actors for these stories and thus provides a focus for explicit group knowledge.

Skills are tacit knowledge that represent individual know-how (Cook & Brown, 1999). Influence may be exerted by constraining the application of skills by specifying methods of investigation and analysis, as these emphasize the use of some skills while excluding others (Adams & Avison, 2003; Carlile, 2002; Markus & Bjorn-Andersen, 1987).

Genres represent a collective form of "know-how," inscribed into organizational conventions through the use of a specific language, form, or medium of communication (Cook & Brown, 1999). Genres provide a "script" for determining what to do in certain, recurrent situations and communicate legitimacy, as this signals membership of the same community of practice and thus a shared worldview. When genres collide, there is a conflict of influence, as actors from various communities attempt to represent the interests of their group by employing their own local genres of problem-representation (Yates & Orlikowski, 2002). The imposition of standard forms and procedures for knowledge-representation provides an exercise of influence that constrains and legitimizes specific community interests by imposing a common "language" for collaboration (Carlile, 2002; Star, 1989).

Ways of Knowing in Distributed Collaboration

Cook and Brown (1999) argue that these four forms of knowing bridge the various epistemologies of distributed organizational knowledge. But is the distinction between tacit and explicit knowledge sufficient to explain how a boundary-spanning group engages in collaborative sensemaking? Johnson et al. (2002) argue that the codification process tends to reduce knowledge to a distinction between know-what and know-how, but that know-why and know-who (or who-knows-what) are equally important in real-world knowledge identification and use. Know-why supplements and explains know-what and know-how (Garud, 1997). Know-why represents a knowledge of rationale that is accumulative and situationally-dependent (Blackler, 1995).

To make tacit knowledge both explicit and transferable, there must be a precise naming and explication of the constructs and meanings used by a community of practice to understand what they do. Know-why permits a limited articulation of historical and situated rationale (Boland & Tenkasi, 1995; Johnson et al., 2002). To produce a synthesis of knowledge that is transferable to other contexts, know-how must be operationalized through shared language constructs, common work-practices, genres, and the use of shared artifacts in collaborative work. The rationale of know-how is made meaningful through relating it to wider organizational practices and common cultural interpretations of events, for example, by explaining or demonstrating how a process exemplar used in one situation may be adapted to another situation (Boland & Tenkasi, 1995; Weick, 1995). Making know-how meaningful in this way relies on an understanding of know-why.

The fourth type of knowledge, who-knows-what, is critical for collaboration when knowledge is distributed across multiple communities of practice (Cannon-Bowers & Salas, 2001; Moreland, 1999). Knowledge of who-knows-what allows a collaborating group to predict each other's perspectives, to locate sources of information, and to allocate tasks based on the distribution of expertise. Faraj and Sproull (2000), in a survey of software team effectiveness, found that knowledge of who-knows-what was more important to success than the possession of specific domain expertise. Knowledge is processual—knowing is situated, mediated, pragmatic, and contested (Blackler, 1995). Thus, domain expertise-the ability to act knowledgeably-is a fundamental part of knowledge management. While the traditional view of expertise is that it drives from know-how that is acquired through a progression from novice to mastery within a specific, identifiable knowledge-domain, experts increasingly need to combine and negotiate knowledge from multiple knowledge-domains, to produce hybrid solutions (Engestrom, Engestrom, & Karkkainen,1995). Expert knowledge derives from two sources: membership and perceived mastery within a specific community of practice. But it also derives from perceptions of an ability to synthesize knowledge from multiple communities of practice (Johnson et al., 2002). Because of this, knowledge of who-knows-what is acquired through interactions with other individuals, as well as articulated claims to expertise. As a boundary-spanning group possesses a diverse range of attitudes-and-beliefs, specific individuals may influence what knowledge is considered relevant by framing the group problem in specific ways. For example, the statement "the problem is one of coordinating people so they do their work on time" frames the problem as restricted to project management and legitimizes calling on the expertise and knowledge of those managers experienced in project management.

A taxonomy of knowledge-forms is synthesized from this discussion and shown in Table 1. This extends the framework of Cook and Brown (1999) and was used as the basis for the analysis of system adaptation presented below.

The Use Of Boundary Objects To Mediate Distributed Understanding

The final aspect of boundary-spanning collaboration examines how groups use physical and conceptual artifacts—models, documents, procedures, and IT-based information systems—to manage understandings of joint activities that are distributed among or "stretched over" (Star, 1989) group members. What we refer to as "organizational knowledge" is distributed across multiple communities of professional practice only ever understood in part by individual actors (Hutchins, 1991; Lave & Wenger, 1991). Collaboration is conducted via an overlap, rather than a congruence, of individual knowledge about what to do (Boland et al., 1994; Star, 1989). Thus, the task of a boundary-spanning design group is to devise a small-scale classification scheme to make sense and structure the limited aspects of the problem situation that are shared (Hertzum, 2004; Star, 1989). Once a small-scale classification scheme has been established, the group must convert this into a generic scheme for organizational consumption (Star, 1989; Weick, 1995). This may be achieved through the use of different forms of "boundary-object" that signify a common concept, design, or a state in a distributed task (Star, 1989). For example, IT developers use data-flow diagrams as a way of communicating the internal logic of their design. Another developer does not have to understand the application domain to understand the logic represented by such boundary objects, as they mediate meaning across knowledge domains by employing a common abstraction (Flor & Hutchins, 1991). But this must be converted to a more general representation, such as a set of document templates, if it is to be used to communicate with members of another community of practice, such as accounting system users. So boundary objects act to communicate different forms of knowledge in different ways.

Carlile (2002) develops Star's (1989) classification of boundary objects by suggesting that a group uses different forms of boundary object when it shares specific assumptions (or experience) of the knowledge-sharing problem. This is summarized in Table 2. We can examine the use of boundary-objects to understand how a group perceives its knowledge-sharing problems.

This article uses the knowledge framework shown in Table 1, coupled with an analysis of the modes of boundary object use shown in Table 2, to understand how knowledge was created, externalized, and shared within a high-level design process involving management stakeholders from multiple business divisions. I will examine how a boundary-spanning collaborative group employs their own language, genres, and culture to mediate and give meaning to local "knowledge," and how this is translated across organizational boundaries.

Research Site and Method

Organizational Background

NTEL Ltd.¹ is a mid-sized engineering firm in the U.K., specializing in the design, manufacture, and sale of products for the telecommunications industry. The company felt that they were losing business to competitors because of poor responses to customer invitations to bid for new business. A potential customer invited a number of suppliers to submit a bid for a customer project, detailing how each supplier proposed to fulfill the customer's requirements and at what price. Preparation of this document was performed by a loosely-associated group of people, assembled on an ad hoc basis from the main areas of the business. Delegated staff would work on an individual section of the bid response document for a few days, or weeks, until it was ready to be dispatched. Problems with bid response processes and systems could be classified into four areas:

1. coordination of a bid response team consisting of people who worked for different managers with different priorities;
2. bid response quality: information accuracy and consistency across sections prepared by different people;
3. crisis management, due to the short notice at which invitations to bid were received; and
4. information management: bid response preparation depended upon local knowledge.

The subject of this study was a group of managers engaged in the design of business process change and IT systems support, to improve the customer bid response process. The group was led by the IS Manager and the Process Improvement Manager, who reported to the company Board of Directors. Other group members had personal experience of bid preparation and each represented one of the main corporate divisions: marketing, finance, engineering, operations, and commerce. The design group membership was intended to represent knowledge derived from all areas of organizational work and also to represent the interests of the various political groups involved in the process being redesigned.

The IS Manager led the initiative. He selected design group members on the basis of whether they would have a positive attitude to organizational change, on the extent of their domain knowledge, and on the respect that they commanded within their respective functional areas. The resulting group contained "willing" representatives from all of the main business divisions and interests. Minor differences in seniority were not perceived as significant by members of the group, who respected and valued each other as colleagues. A company organization chart is shown in Figure 2, with participating members of the group shown in bold type.

Research Method

A longitudinal field study was conducted using an interpretive, ethnographic approach to data collection and analysis (Schwandt, 1998). Data collection was performed via three means:

1. Participant observation of a boundary-spanning design group. The author participated in design group meetings as an observer and had no prior relationship with the company or group members. Approximately half of the group's meetings (28 three-hour design meetings and two one-hour design-group meetings with senior management) were observed and tape-recorded, over an 18 month period. Rich field-notes were kept during meetings, to record meeting events, summarize group discussions and interactions, record whiteboard representations, and note other relevant information, e.g., conflict, negotiation, or agreement.
2. Ad hoc interviews were conducted with group members preceding or following group meetings. These explored individual definitions of the design problem, system solution, and design process, and events that had taken place between meetings. Formal, two-hour interviews with all group members were conducted to elicit design perspectives at three points: the start of the project, approximately halfway through, and at the project's end.
3. Group workshops were held halfway through the study and following its completion. These workshops provided validation of research findings and obtained additional insights.

The study used inductive qualitative analysis techniques (Eisenhardt, 1989; Gioia et al., 1994; Strauss & Corbin, 1998). Emergent themes and categories identifying various behaviors related to forms of knowledge were explored through iterative cycles of literature search and data analysis using a qualitative analysis software package, to locate these within a conceptual framework and to compare data across different points in time. An analysis of the different "ways of knowing" suggested by Cook and Brown (1999) resulted in the definition of four stages of design. The second-order observed categories (Gioia et al., 1994) identified at each stage are summarized in Table 3. Differences between stages appeared to reflect distinct modes of knowledge use that were explored through further analysis and review of the data. When the analysis reached the point where repeated reviews of all sources of data provided no new insights, the four stages of knowledge use were categorized according to the elements identified by the analysis, to provide the conceptual categories summarized in Table 4, in the discussion section.

Case Study Findings

Four stages of sensemaking were identified, each with their own distinct modes of knowledge use. Each stage appeared to be guided by different ways in which knowledge emerged and was shared among group members. These differed from the decomposition (waterfall model) stages of design used to manage project deadlines, as shown in Figure 3.

Table 3 summarizes differences between modes of knowledge use at each stage, under the Cook and Brown (1999) framework categories of: concepts, valued skills, metaphors and stories, and dominant genres of communication.

Each stage appeared to be guided by different ways in which knowledge emerged and was shared among group members. During each stage, different types of skills and knowledge were valued by the group, leading to a different process focus. Transitions between these stages appeared to be guided by a shift in the group's tacit valuation of specific knowledge domains at any point in the design process. A shift in valuing certain types of knowledge appeared to lead to a shift in design focus by the group. The nature of this shift in knowledge valuation is explored further in the discussion section below. In this section, an ethnographic description of knowledge use during design at each stage is provided, followed by a synthesis of the differences between the stages.

Stage A: Defining Design Objectives

At the beginning of the project, group discussions focused mainly on the objectives of the design. Objectives to be achieved by the new information system differed radically for individual group members. Differences in perspective appeared to stem from each individual's work-background, as reflected by one participant's assessments of his fellow group members:

The Customer Solutions Manager comes at it from a reasonably broad experience in industry. How the hell he packs his understanding of the way business ticks in his young head, I have no idea … he has been mind-blowing, and I've constantly underestimated his capacity to contribute, but … I've seen him very much as a pragmatist, speaking from experience and a practical understanding of the way things tick, with a very high degree of vision.
… I expected the Bid Manager to be a lot more open minded and to demonstrate a lot more vision than he has. He has turned out through this exercise to be extremely protective of the status quo … and I think, really, the only conflicts that come out within the group … were because of his protectivism.
-Interview with IS Manager, following an early design meeting in Episode A

Different team members were perceived as possessing specific domain expertise and their ability to influence fellow team members appeared to depend upon whether the group prioritized the knowledge associated with that domain of expertise. In the following design meeting extract, the Bid Manager redefines the set of information that other group members have just determined is required for a bid response by calling upon his expertise in managing the existing process:

Bid Manager: These [information flows] are not part of the process; these are just inputs to the process.

Customer Solutions Manager: Yes, but we need these pieces of information to put the Bid together, so producing them is part of the process.

Bid Manager: No it's not. Mike doesn't produce these costings; Geoff does. It's not part of the estimating process, its part of product engineering process, so this is nothing to do with us.

Customer Solutions Manager: But if we need this information to produce the Bid, then it is part of our process.

Bid Manager: No, I disagree. This is nothing to do with bidding. The output from this is: this is the price we're going to charge the customer. That's the output. There are lots of inputs to make that decision. But the process is still getting the information, doing your juggling with the figures and coming up with the answer.

Initially, using different representations of the design was an explicit project objective. The co-design of business and IT systems was a new initiative for this company and they wished to experiment with appropriate forms that the process should take. Individual group members were encouraged to use a variety of design representations. The early stages saw different individuals produce Pareto charts, organizational charts, information-flow diagrams, "knowledge-component diagrams" (a way of showing the knowledge components that fed into a decision), and many other forms of representation. The type of representation used appeared to depend strongly on their domain background. These representations appeared to be associated with different definitions of what the design (and its associated organizational change) was intended to achieve.

Different group members were aware that they defined design objectives differently, to the extent that managing conflict in dialogues was an explicit part of design meeting interactions—group members often prefaced contributions with comments such as "I know [individual] won't agree with me, but …" or "I understand where you're coming from, but I don't agree with you because …". While these debates appeared generally good-humored and led to richer conceptualizations of the target system, the IS Manager (who was leading the project) saw the existence of multiple design perspectives as problematic:

The big problem is, everyone's got their own ideas about what it should do and how it should work. What we need is to agree on a common vision as early as possible, not to complicate things with even more disagreements. You tell me how you can get seven people around a table to agree on what they're doing, if they're all drawing different pictures of what they want to get out of it.
-Interview with IS Manager, commenting on design progress during Episode A

Because of this concern, the IS Manager suggested that the group use process flowcharts to achieve a "common vision of the design." Other group members deferred to his extensive experience of managing IS design and the group as a whole engaged in a training session to learn how to produce and understand process flowcharts. But different group members interpreted the purpose and content of the process flowcharts very differently, depending upon their work-background (even towards the end of the project, misunderstandings would arise from the way in which these models were interpreted). Even after repeated training sessions, a wide variety of representations continued to be used, as the group appeared to find it helpful to take different views of the design problem domain. The Process Improvement Manager produced an organization chart, connected at the bottom with a decision-process symbol (a diamond). The Project Engineering Manager produced what looked like a circuit diagram, with every process connected the every other process. The Customer Solutions Manager (who had a Marketing background) produced a Pareto chart of issues related to the decision, with a decision-process at its end. The individuals who were most influential in group discussions at this time (determined from an analysis of how disagreements were resolved) were the IS Manager and the Customer Solutions Manager. Other group members appeared to defer to them, because they were perceived as possessing the widest scope of knowledge about how the organization worked and so could bring the most innovative perspectives to the redesign of this core business process.

Stage B: Determining an Appropriate Design Process

Towards the middle of the project, group members appeared to adopt a position that they were there to learn from each other, and so they deferred to other people who understood various areas of process operation. There were still disagreements among group members, but these tended to be about the information required by the system, or the processes by which external information was generated, rather than about the purpose and nature of the system.

The Project Engineering Manager was "intellectually excited by the design process," to the extent that he was prepared to spend a great deal of effort in acquiring the application-domain knowledge and expertise necessary for him to conceptualize the process, in all its complexity. This led him to propose a new approach to design. Each member of the group would take responsibility for defining a sub-process—a paper prototype of the design—that would be presented to the group for critique and modification. This approach soon became known across the group as a whole as the "Aunt Sally" approach: The name derives from a fairground game, where a wooden doll is knocked from a stand using sticks or balls. The new approach allowed each person to present their knowledge of that part of the bid process of which they had prior experience to the others. This gave the group a conceptual starting-point, from which they could add to, or modify, a representation of explicit knowledge, supplementing this with exemplars that communicated tacit knowledge. The group were now able to pool very incomplete knowledge of how the current bid process worked, or could work. The IS Manager commented:

I think everyone was more than happy with the Project Engineering Manager doing the bulk of the work (laughing). … my view is that the quality of the 'Aunt Sally' has been better for stages one and four than it has been for stage two which was done by committee.
-Interview with IS Manager, following an early design meeting in Episode B

The group emphasis then shifted to an investigation of what individual knowledge was required to participate in preparation of a bid response and how the formal information system could capture this so that such knowledge could be shared. So issues of "know-how" now became significant, rather than "know-what." This distinction exerted itself in two ways. First, the know-how that the group most valued was the ability to perform design. Most group members were aware of the need for change to the bid process. But they lacked the skills to define what needed to change. So they relied on those members of the group who had prior experience of design: the IS Manager and the Project Engineering Manager. This resulted in some conflict between the two individuals, as each attempted to guide the process according to their domain-based knowledge of how design should proceed. The IS Manager attempted to standardize the process by insisting that all design representations should use a common format (process flowcharts, accompanied by a formal text specification of the process). The Project Engineering Manager disagreed, attempting to introduce information-flow representations as a core representation, as his experience warned him that existing process tasks and mechanisms were not sufficiently understood for a new process to be defined:

IS Manager: I would feel a lot more comfortable with a little more structure in the text against each box. If, in each box, if it said: owner, input, process, outputs, rather than a more ad hoc, textual, "this is what happens here" then I would feel that it was a bit more usable into the long term.

Project Engineering Manager: you normally work it the other way round. You say 'what am I asked for', 'how am I going to do it', 'who do I need to do it' and 'what [information] do I need in to me to achieve it'? You work backwards but you record forwards.
-Exchange during design meeting, midway through Episode B

The IS Manager won this debate, because he was able to explicitly define the forms of knowledge that were legitimate for the project. In particular, he enforced the genre of recording "what, not how," calling on a formal training in business process redesign methods, to deter decisions concerning organizational responsibility that degenerated into political debates. Avoiding "the specter of organization" became a common metaphor in group design discussions—individuals would catch themselves, halfway through a description of a suggested process, with the words "I'm raising the specter of organization again, aren't I?"

Stage C: Expanding the Design Boundary

The Board of Directors had authorized the project on the promise of "quick wins:" rapid benefits to the company, delivered through the identification of inefficiencies and problems in the existing process that could be amended by work-reorganization or the provision of more targeted information. But, to quote the IS manager: "[T]he outcomes of this project were neither winning nor quick." As the design proceeded and the group began to develop a more extensive shared model of how the process worked and how this fitted into the wider set of organizational and business processes, their vision of change became more systemic. They began to perceive the interrelatedness of the bid process with various other business processes with which the bid process interacted. However, this "systemic" knowledge was not perceived as legitimate, as it conflicted with their politically-constrained agreed boundary for the system design. It was also contentious, as the Marketing division representative on the group—the Customer Solutions Manager—had left the company and had not been replaced, because the Marketing Director was hostile to any changes to his area of responsibility. So not only did the group lack detailed knowledge of areas that they needed to change, but they also lacked a political advocate for this change in the Marketing division. The only access which the group had to Marketing work-processes was to the documents produced as output from those processes. The group spent many hours attempting to understand, at second hand, actual and potential information-flows within the company, based on these documents. They worked in a "gray area" of knowledge that attempted to make sense of processes that were not legitimate targets of the design, but that were tacitly recognized as necessary for the design to be effective, as shown in Figure 4.

The team had representatives from all major corporate divisions, but some informal processes required for bid response—specifically those performed by Senior Management—lay outside the scope of what they could affect with their design. There were also areas of operation (the gray area in Figure 4) that lay outside of their formal system scope definition. The impact of this expanding, implicit system boundary was emergent and slow to be realized. The design group started to define "interfaces" to the formal system boundary. Explicitly these were document or information requirements at the interface to their system, but these were not represented as information-flows. The group created a new process flowchart symbol—a hexagonal box—to represent a tacit meaning of "interface": changes required to an external process. They invited people from outside the group to present on various aspects of organizational processes that interfaced with their own process and which they needed to affect. But as this was not a legitimate scope for the design, external experts were often invited secretly and asked to talk through scenarios for how they performed their work. The group wrestled with many process changes that lay outside of the explicit system boundary, which they could not legitimately define or investigate, as demonstrated by this meeting extract:

Project Engineering Manager: So what we need is a short-form document to hack the MSOR [a document produced by the Marketing division, external to the Bid process].

Process Improvement Manager: If it's product driven, won't it come through the Invitation to Bid document?

Project Engineering Manager: No, it will always come through the MSOR. This filtering process is appropriate to stage 4 as this process will be drawn upon from other routes and other processes.

Bid Manager: So what you want at the top of stage 4 is "strip and allocate MSOR"? [this comment implies a fundamental change to Marketing work procedures].

Process Improvement Manager: I'm not sure that we can do that.
-Exchange during design meeting in Episode C

The IS Manager ended this dispute with the words "the reason we're struggling because we're trying to look at it in process terms whereas it's really information flow that we're trying to reflect round that feedback loop." But it was unrealistic for the group to learn another representational method. The IS Manager eventually came up with a resolution: He redefined the bid process as a component of the wider business and product planning processes in the company. This legitimized the need for formal documentation of business and product lifecycle information and it legitimized the need for the design group to understand strategic business processes (which had formerly been politically unacceptable). In this way, without extending the explicit system boundary, the IS Manager and then the group as a whole made the implicit system boundary explicit to the design group. Soon, the IS Manager was encouraging the Project Engineering Manager to reintroduce his information flow diagrams (similar to data-flow diagrams, but conceived at a higher level of modeling document generation and flows of knowledge between business processes). The group managed the dual nature of the system boundary by inscribing this boundary implicitly in definitions of strategic business document contents. For example, by redefining the Marketing Statement of Requirements template, they were able to redefine the Marketing business process of capturing local knowledge about customer priorities and intentions to request new bids. While the design group could not redefine the processes that produced these documents, they redefined them indirectly through a redefinition of the documents that resulted from these processes.

Stage D: Working Towards Design Closure

The group was under pressure to complete the design. The project had initially been planned to take three to six months. It had lasted for over 15 months at the start of this stage. The Board of Directors were questioning the expected benefits. Pilot studies had been held under the supervision of the Bid Process Manager and other design group members to prototype parts of their newly-defined business processes and to experiment with various forms of the supporting knowledge-management IT system. Managers and more junior employees who had participated in these pilot studies were adopting and promoting the changes in an ad hoc and partial way. The design group needed to deliver benefits and was afraid that the benefits would be perceived as "business as usual" by the time that the project completed, so they adopted a satisficing approach to project completion, focusing on instrumentality rather than perfection. This led them to value expertise that would help them to complete the project rapidly.

Two different types of expertise were identified as most influential in driving group decision-making because of this. The IS Manager and the Project Engineering Manager were each influential because they had prior experience in design project completion. But most influential in this process—to the frequently-expressed chagrin of the IS Manager—was the Bid Manager. The Bid Manager understood how the current process worked. He could therefore define parts of the process that no one understood, or over which there was a lot of disagreement. The Project Engineering Manager was frustrated that so many radical changes were being lost in the rush for closure and the lack of any mechanism to capture individuals' knowledge of process mechanisms that were being delegated to others, but could do nothing in the rush to deliver the design.

It became clear that none of the group understood the bid response process as a whole. Through modeling information-flows, the group had started to derive an extremely complex model of the bid response process. This was difficult for one person to comprehend in its entirety. Group members agreed that they could not possibly define all of the information and knowledge required to support the new process. Thus they started to redefine what should be in a "document repository" to support a set of areas of the bid response process that were not well-defined, such as the provision of accurate cost estimates, the selection of which products should be considered strategic for specific market segments, or the determination of how various combinations of products should be configured for different working environments. In this way, they subsumed the definition of the formal knowledge required to prepare a bid response into the definition of a system that would store company documents—and thus support informal knowledge processes—and a limited set of codified knowledge (such as the basis for historical cost estimates). The group appeared to compromise their objectives, because their detailed design was too complex for them to understand and implement collectively.

Project closure was achieved in a rush of delegation. They identified a set of tasks that needed to be completed for the project to deliver the intended benefits. Individuals who had knowledge or expertise in various areas of the work required were delegated to perform this work. A need to "train the troops" was identified, so the Process Improvement Manager was delegated to take charge of this element. A need to define the detailed information requirements for each part of the new process was identified to ensure that the IT systems contained appropriate documents, so the IS Manager was delegated to take charge of this work. A need to define improved task allocation processes was defined, so the Bid Manager was delegated to take charge of this work. It was noticeable that the group resolved their earlier problems with distributed knowledge by now abdicating responsibility for achieving a common vision of the design. It is also significant that the IT system became invisible to the project group from this point on. Its detailed specification was delegated to the system development group for them to define the detailed information and knowledge to be stored in the document repository.

Discussion

The research question that guided this study asked: How does a participative boundary-spanning group that is engaged in the design of a knowledge-management information system balance sensemaking as reflective involvement in their various communities of practice with sensemaking as joint engagement in the "detached" analysis of business processes and IT support requirements within a political context?

The use of the four categories of knowledge defined by Cook and Brown (1999) to analyze the group design process over time provided insights into the nature of the process that a less guided thematic analysis could not. An analysis of the production of different forms of knowledge over time revealed that there was an evolution in the group's understanding of how best to share knowledge under different contingencies.

Table 4 summarizes the four stages of design in terms of how the group's mode of knowledge-sharing, and their use of boundary objects, changed with the design task-focus and their perceived collaboration problem. This provides a framework for contingent knowledge-sharing across different types of knowledge-domain boundary.

By analyzing the use of specific boundary objects (Star, 1989), it can be seen that new uses of boundary objects signal a change in genre (and thus the implied focus of communication) for the group. The use of various types of boundary-objects communicates how the group perceived its knowledge-sharing problems (Carlile, 2002). When faced with new problems at the boundary between designers, or at the boundary between the design group and the rest of the organization, the group adapted their use of boundary objects, signifying a new focus of concern.

From the four stages summarized in Table 4, it can be seen that there was a constant tension between viewing the design process as pooling existing knowledge, or viewing design as a process of collective learning about how organizational processes functioned. A second dimension arising from this analysis reveals a tension between group knowledge elicitation and sharing, and external (distributed) knowledge elicitation, sharing and dissemination. These dimensions provide the basis for the model shown in Figure 5, reflecting four different modes of knowledge-sharing in a boundary-spanning group faced with a complex, distributed knowledge-management problem. This model shows the knowledge elicitation and sharing mechanisms, the group process emphasis, and the knowledge category focus of each stage.

The group in question here expressed dissatisfaction that they had been unable to shift their focus from Stage D of this process, to revisit the earlier modes of knowledge-sharing. They felt that it would have led to a better design overall if they had been able to achieve an iterative design process more rapidly. If this sequence had been understood at the time, it is possible that by explicitly adopting one of the process/focus modes of Figure 5, or by employing a different mechanism for knowledge elicitation and sharing, this could have been achieved.

This model extends and adds an additional dimension to the framework of Cook and Brown (1999). This is reconciled by integrating the individual/group dimension to provide a two-dimensional framework that focuses on the relationship between a collaborative group and the organization, distinguishing between knowledge that is shared (internal to the group) or distributed (across/between the group and external actors). The two halves of the model echo the two contradictory views of knowledge management explored in the initial literature discussion, with a progression in the direction of the central arrow.

In the first two stages of the design project (the left-hand-side of the model), group members viewed the design process as pooling their collective knowledge about the design across internal (to the group) knowledge-domain boundaries through:

1. sharing and codifying explicit knowledge through the use of exemplars and analogies, then
2. surfacing, negotiating, and codifying their tacit knowledge of business processes through the use of "Aunt Sally" (paper prototype) representations to provide a process exemplar.

As they identified areas where the design was incomplete, the group focus shifted to integrating distributed knowledge across external (to the group) knowledge-boundaries (the right-hand-side of the model). This reflects the human-activity and informal IS focus of the organizational KM literature, where relevant knowledge may be communicated first by co-constructing genres and exemplars, then by generating stories and expertise requirements (management responsibilities and roles) to communicate and manage a distributed understanding of explicit knowledge. They achieved this by:

3. continuing the strategy of surfacing tacit knowledge from external stakeholders through the use of Aunt Sally process prototypes to provide the basis for scenario generation, then by
4. division of labor according to areas of expertise, to integrate their design into the explicit information-flows, procedures, and norms that reflected the wider, distributed set of organizational knowledge.

Conclusions

The research study presented here demonstrates that knowledge resides in a shared, conceptual space that is created through the co-construction of a socially-situated, organizational "knowledge-world" among multiple communities of practice. These findings represent a single field study, albeit over 18 months. But this situation is representative of the complexity of group design and problem-solving in most organizations, and its findings may well be transferable to other contexts. Organizational actors constantly balance the need for meaningful participation in local work-practices to provide deep knowledge of their own community business processes, and a "detached" analysis of others' work-practices to integrate, transfer, or transform their own local knowledge, so that they may collaborate meaningfully with members of other communities of practice. The wider scope and longer duration of the balancing process required for both technical and non-technical stakeholders to participate meaningfully in the design of a collaborative system requires more formal ways of incorporating knowledge across multiple knowledge-domains.

By applying an analysis of how different types of knowledge were accessed to produce collaborative design artifacts, it proved possible to integrate the two views of knowledge management developed in the literature into a single process model, presented in Figure 5. This model develops the ways of knowing suggested by Cook and Brown (1999) by suggesting how dealing with different types of knowledge-domain boundary balances the contradictions between the two knowledge management "worlds:" of codifiable, explicit knowledge and of embedded, tacit knowledge. The process model suggests ways in which progress may be made in distributed design, by manipulating the task and knowledge-sharing focus of the group, or by the use of specific knowledge sharing and elicitation mechanisms.

The framework presented in Table 4 provides an understanding of group learning that is significant for design and for other forms of boundary-spanning group collaboration, such as organizational innovation and problem-solving. Surmounting each of the four knowledge-domain boundaries appears to require a different approach to design inquiry and representation. In particular, the move from managing shared knowledge to accessing and managing distributed knowledge is ill-supported by traditional methods for systems requirements analysis. It may be possible to progress this shift in perspective and to support more effective systems design by employing specific techniques for design inquiry, or by employing specific types of boundary object in specific ways, as discussed above. This requires further investigation.

This study also exposes the variety of knowledge-forms and modes of knowledge-exchange required to collaborate across organizational boundaries. These processes are normally taken for granted, rationalized, or ignored by managers of IT-related organizational change, and tend to be hidden from view in technology-focused studies of collaboration. The interior view presented here demonstrates the problems of providing an effective IT system to support boundary-spanning collaboration. Boundary-spanning collaborative systems need to be defined more flexibly than those provided for a single knowledge-domain, so that they can provide the multiple types of boundary object required for the different modes of knowledge-sharing required to share different types of knowledge.

These findings have significant implications for both research and practice. In most approaches to knowledge management, we assume that there is a shared perception of practice that defines how information is used. From a research perspective, we need to develop new ways of conceptualizing how distributed views of knowledge affect the process and object of collaborative system design. In knowledge management practice, we need new methods for managing the surfacing and the coordination of distributed knowledge across collaborative groups. In IS design practice, we need to understand the designed artifact as serving the need of multiple communities and therefore emergent in nature, as new perspectives are incorporated into the design of the system. The role of representational forms, genres, and other forms of boundary object in mobilizing a move from one mode of knowledge-manipulation to another may be significant in this endeavor.

Note

1. Names of the organization, its departments, members and products have all been disguised.

References

Adams, C., & Avison, D. E. (2003). Dangers inherent in the use of techniques: Identifying framing influences. Information, Technology & People, 16 (2), 203-234.

Alavi, M., & Leidner, D. (2001). Knowledge management and knowledge management systems: Conceptual foundations and research issues. MIS Quarterly, 25 (1), 107-136.

Blackler, F. (1995). Knowledge, knowledge work and organizations: An overview and interpretation. Organization Studies, 16 (6), 1021-1046.

Boland, R. J., & Tenkasi, R. V. (1995). Perspective making and perspective taking in communities of knowing. Organization Science, 6 (4), 350-372.

Boland, R. J., Tenkasi, R. V., & Te'eni, D. (1994). Designing information technology to support distributed cognition. Organization Science, 5 (3), 456-475.

Brown, J. S., & Duguid, P. (1994). Borderline issues: Social and material aspects of design. Human-Computer Interaction, 9 (1), 3-36.

Brown, J. S., & Duguid, P. (2000). Knowledge and organization: A social-practice perspective. Organization Science, 12 (2), 198-213.

Buckland, M. K. (1991). Information as thing. American Society for Information Science, 42 (5), 351-360.

Cannon-Bowers, J. A., & Salas, E. (2001). Reflections on shared cognition. Journal of Organizational Behavior, 22 (2), 195-202.

Carlile, P. R. (2002). A pragmatic view of knowledge and boundaries. Organization Science, 13 (4), 442-455.

Cook, J., & Brown, J. S. (1999). Bridging epistemologies: The generative dance between organizational knowledge and organizational knowing. Organization Science, 10 (4), 381-400.

Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14 (4), 532-550.

Engestrom, Y., Engestrom, R., & Karkkainen, M. (1995). Polycontextuality and boundary crossing in expert cognition: Learning and problem solving in complex work activities. Learning and Instruction, 5 (4), 319-336.

Faraj, S., & Sproull, L. (2000). Coordinating expertise in software development teams. Management Science, 46 (12), 1554-1568.

Flor, N. V., & Hutchins, E. L. (1991). Analyzing distributed cognition in software teams: A case study of team programming during perfective software maintenance. Empirical Studies of Programmers - Fourth Workshop. Norwood NJ: Ablex.

Garud, R. (1997). On the distinction between know-how, know-why and know-what in technological systems. In A. S. Huff & J. P. Walsh (Eds.), Advances in Strategic Management, Vol. 14 (pp. 81-101). Greenwich, CT: JAI Press Inc.

Gioia, D. A., Thomas, J. B., Clark, S. M., & Chittipeddi, K. (1994). Symbolism and strategic change in academia: The dynamics of sensemaking and influence. Organization Science, 5 (3) 363-383.

Hertzum, M. (2004). Small-scale classification schemes: A field study of requirements engineering. Computer Supported Cooperative Work (CSCW), 13 (1), 35-62.

Hutchins, E. (1991). The social organization of distributed cognition. In L. B. Resnick, J. M. Levine, & S. D. Teasley (Eds.), Perspectives on Socially Shared Cognition (pp. 283-307). Washington, DC: American Psychological Association.

Johnson, B., Lorenz, E., & Lundvall, B. A. (2002). Why all this fuss about codified and tacit knowledge? Industrial and Corporate Change, 11 (2), 245-262.

Lave, J., & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge UK: Cambridge University Press.

Leibowitz, J. (2001). Knowledge Management: Learning from Knowledge Engineering. Boca Raton, FL: CRC Press.

Markus, M. L., & Bjorn-Andersen, N. (1987, June). Power over users: Its exercise by system professionals. Communications of the ACM, 30 (6), 498-504.

Moreland, R. L. (1999). Transactive memory: Learning who knows what in work groups and organizations. In L. Thompson, J. M. Levine, & D. M. Messick (Eds.), Shared Cognition in Organizations: The Management of Knowledge (pp. 3-31). Mahwah, NJ: Lawrence Erlbaum Associates.

Nonaka, I., & Konno, N. (1998). The concept of `ba: Building foundation for knowledge creation. California Management Review, 40 (3), 40-54.

Polanyi, M. (1958). Personal Knowledge: Towards a Post-Critical Philosophy. Chicago: University of Chicago Press. (Reprinted in 1974.)

Prusak, L. (2001). Where did knowledge management come from? IBM Systems Journal, 40 (4), 1002-1007.

Ryle, G. (1949/1984). The Concept of Mind. Chicago: University of Chicago Press.

Schmidt, K. (1997). Of maps and scripts. Proceedings of GROUP 97 ACM SIG, Distributed Group Work. Phoenix, Arizona: University of Phoenix.

Schwandt, T. (1998). Constructivist, interpretivist approaches to human inquiry. In N. K. Denzin & Y. S. Lincoln (Eds.), The Landscape of Qualitative research: Theories and Issues (pp. 221-259). Thousand Oaks, CA: Sage Publications.

Smircich, L., & Morgan, G. (1982). Leadership: The management of meaning. Journal of Applied Behavioural Science, 18 (3), 257-273.

Star, S. L. (1989). The structure of ill-structured solutions: Boundary objects and heterogeneous distributed problem solving. In L. Gasser & M. N. Huhns (Eds.), Distributed Artificial Intelligence, Vol. II (pp. 37-54). San Mateo, CA: Morgan Kaufmann Publishers Inc.

Strauss, A. L., & Corbin, J. (1998). Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, 2nd Edition. Newbury Park, CA: Sage Publications.

Suchman, L. (1987). Plans and Situated Action. Cambridge MA: Cambridge University Press.

Suchman, L. (1996). Constituting shared workspaces. In Y. Engestrom & D. Middleton (Eds.), Cognition and Communication at Work (pp. 35-60). New York: Cambridge University Press.

Weick, K. E. (1995). Sensemaking in Organizations. Thousand Oaks CA: Sage Publications.

Yates, J., & Orlikowski, W. (2002). Genre systems: Structuring interaction through communicative norms. The Journal of Business Communication, 39 (1), 13-35.

Zack, M. H. (1999). Managing codified knowledge. Sloan Management Review, 40 (4), 45-58.

About the Author

Susan Gasson is Assistant Professor in the College of Information Systems and Technology at Drexel University, following a career in systems design, management and information systems consultancy. Her research focuses on social cognition in collaborative group processes, and distributed knowledge management in the co-design of business and information technology systems. She is the author of articles published in JITTA, The Data Base for Advances In Information Systems, and the Journal of End User Computing.
Address: College of Information Science and Technology, Drexel University, 3141 Chestnut Street, Philadelphia PA 19104-2875 USA