Category: groups

  • Knowledge-Sharing In Distributed Groups

    Knowledge-Sharing In In Collaboration Across Organizational Boundaries

    Susan Gasson
    College of Computing & Informatics,
    Drexel University

    Please cite this paper as:
    Gasson, S. (2007) ‘Knowledge-Sharing In Collaboration Across Organizational Boundaries.’  Working Paper.  Available from https://www.improvisingdesign.com/knowledge-sharing/ ‎ Last updated 08/15/23

    Sharing Knowledge in Collaborative Teams

    Knowledge-sharing in collaborative design is problematic, because it involves the merging of a variety of stakeholder perspectives to achieve a collective “vision” of what needs to be changed: the task objectives, the task goals and – even – the problem being addressed. We tend to assume that groups develop a common perspective on collaborative tasks over time, but there is quite a bit of research that demonstrates otherwise.

    The problem of collaboration is exacerbated when the collaboration spans organizational boundaries, such as groups that comprise members from different functions or divisions. People who work in different functional units not only tend to have diverse ways of defining organizational problems, that are related to their disciplinary and professional backgrounds, but also define problems and their solutions according to the local conventions of their department or function. A group of managers and participants in the work processes to be changed may have difficulty in agreeing what needs to change as they find that they have very little shared understanding of organizational problems – or how to resolve them. Each stakeholder defines the problems in a different way, depending on their experience of these problems and of the situation in which they occur (Gasson, 2004).

    Different subgroups of stakeholders may have shared understandings, that encompass a subset of the problem definition. These subsets often form the basis for political alliances, that emphasize specific aspects of the organizational problem-situation (Gasson, 2007). But knowledge about the actual problem, represented in Figure 1 by the union of the various perspectives (the bold outline), is difficult to represent and therefore to debate. Each stakeholder sees a different part of the problem, with different emphases and priorities, that are filtered through a different interpretation, based on their educational and work experience. So sharing knowledge – about how things work and what should or could be done – is difficult.

    Knowledge Convergence

    This is not an issue for simple, well-structured problems, that are easy to define. For example, if a group of stakeholders is designing a solution to the problem of reporting on what hours different employees work on different projects to which they are assigned, the problem is fairly easy to define and the solution follows from this problem definition. While there may be some “softer” aspects of the problem that need clarification (for example, how a “project” is defined, how employees can be expected to record the hours that they work, or cultural constraints of reporting on what various people work on), most aspects of the problem are straightforward and therefore easy to structure into a clear, consensus problem-definition. Over a period of working together, different stakeholders share their knowledge about a well-defined problem, to reach a clearly-defined domain of action. The degree of shared understanding can be increased, as trust between group members increases over time therefore very high.

    Wicked2

    Figure 1: Knowledge Convergence In Collaborative Work

    Not so for problems that are complex and ill-defined. A group of stakeholders who work together over time may be able to define the rationale for change and the context of the problem in a consensual way, but each member of the group will conceive of the problem and appropriate solutions in very different ways. The degree of shared knowledge possessed about the problem to be solved may not increase much from that shown in Figure 1. This is because organizational problems are “wicked” problems (Rittel, 1972). Wicked problems, according to Rittel and Webber (Rittel and Webber, 1973) have ten specific characteristics:

    1. Wicked problems have no definitive formulation. A problem can only be defined by exploring the type of solution required: problem and solution are interdependent. Each attempt at creating a solution changes the stakeholder’s understanding of the problem.
    2. Wicked problems have no stopping rule. Since you can’t define the problem, it’s difficult to tell when it’s resolved. The problem-solving process ends when resources are depleted, stakeholders lose interest or political realities change.
    3. Solutions to wicked problems are not true-or-false, but good-or-bad. Since there are no unambiguous criteria for deciding if the problem is resolved, getting all stakeholders to agree that a resolution is “good enough” can be challenging.
    4. There is no immediate or ultimate test of a solution to a wicked problem. Solutions to such problems generate waves of consequences, and it is impossible to know how these waves will eventually impact the situation. Wicked problems are interrelated (see point 8) and so resolving one problem may make another problem better or worse.
    5. Every implemented solution to a wicked problem has consequences. Once the Web site is published or the new customer service package goes live, you can’t take back what was online or revert to the former customer database, because customers have different expectations. So consequences not only relate to the original problem, but change the nature of the problem that now has to be resolved.
    6. Wicked problems do not have a single, well-defined set of potential solutions. Various stakeholders have differing views of acceptable solutions. It is a matter of judgment as to when enough potential solutions have emerged and which should be pursued. Alternative solutions may be just as good as the solution selected [1]. Alternative solutions may not exist.
    7. Each wicked problem is essentially unique. There are no “classes” of solutions that can be applied to a specific case. As Rittel and Webber wrote in “Dilemmas in a General Theory of Planning,” “Part of the art of dealing with wicked problems is the art of not knowing too early what type of solution to apply.” This moves us a long way away from the generalized ontology of the semantic web, or the pattern language proposed by Alexander (1999) [2].
    8. Each wicked problem can be considered a symptom of another problem. A wicked problem is a set of interlocking issues and constraints that change over time, embedded in a dynamic social context. So organizational problems are highly interrelated and resolving one problem in a particular way will affect other problems in unpredictable ways.
    9. The causes of a wicked problem can be explained in numerous ways. There are many stakeholders who will have various and changing ideas about what might be a problem, what might be causing it and how to resolve it. Problem resolution cannot be achieved through problem analysis, but must be achieved through “argumentation” (Rittel, 1972), where multiple views of the problem are debated and negotiated among stakeholders.
    10. The planner (designer) has no right to be wrong. Scientists are expected to formulate hypotheses, which may or may not be supportable by evidence. Designers don’t have such a luxury—they’re expected to get things right. Rittel (1972) argues that you cannot build a freeway to see how it works. Similarly, you cannot build an information system to see what type of IS you need [3].

    As a consequence, problem-solving and design groups tend to diverge, as much as they converge over time, in defining the problem that they are resolving. Design tends to proceed via a series of “breakdowns”, in which the current group consensus falls apart and a new consensus is formed around a mobilizing vision, that provides a good-enough definition of the problem to mediate negotiation and constructive argumentation (Gasson, Under Review).

    So What?

    We need new methods and approaches to manage IS design and collaborative problem-solving/innovation groups. Most current approaches are based on an individual model of problem-solving, that views problems as ill-structured (Simon, 1973). Ill-structured problems, while being ill-defined are capable of being structured, once a suitable problem-boundary and set of constraints have been agreed. But as I argued above, organizational problems are wicked problems and are therefore not amenable to objective definition or structuring. Approaches to wicked problem resolution [4] require techniques for surfacing people’s implicit assumptions, so that everyone is talking about the same elements of the problem. They require ways of managing multiple perspectives at once: recording constraints and solution requirements at multiple levels of decomposition, so that understanding of the problem is not “lost” when the group changes focus. They require ways for allocating responsibility for different parts of the problem to those familiar with those parts and for building trust so that these different views of a solution can be aligned, even if they are not shared. My research is about how these things can be achieved.

    I explore methods and processes for (a) sharing distributed information and knowledge, and (b) managing collaborative problem-solving and design activities in groups where knowledge-sharing is not feasible because the context and the problem are so diverse and “wicked”. Some of the issues that have arisen from this program of research so far are:

    Is the process goal-driven? Most views of problem-solving see this process as goal-driven, at least at a high-level. In other words, collaborative groups designing IT-related change derive a “common vision”. The findings from my prior research demonstrate that, for complex problems that span organizational groups and/or units, a common vision is highly unlikely to be shared. Group collaboration is impeded by continual revisiting of this vision, in the attempt to derive a common language for the project change goals.

    How do distributed groups assess their progress? In traditional perspectives of collaborative work, progress is judged by how far a group has proceeded towards a set of common goals for a solution. If the group is unable to establish a common set of goals, because group members view “the problem” in multiple ways, how do they assess progress towards achieving a collective solution? My prior studies indicate that groups do manage this satisfactorily and that group members assess a set of subtle change-management elements that are unrelated to the elements that we would normally define as part of a common vision. Further studies will investigate these elements further.

    What types of collaboration tools and techniques might be useful to increase the degree of shared understanding? If boundary-spanning groups really do possess conflicting or diverse perspectives of the problem to be solved and the types of solution that might be appropriate, are there specific techniques or approaches that might aid in increasing the shared element of the group’s understanding of the problem? My experience as an educator, developing methods for collaboration in a classroom context that often involves groups with diverse memberships, leads me to believe that certain types of approach might “displace” individuals’ current understanding sufficiently to allow a shared vision to emerge, at least for a limited scope of action. These techniques are to be developed further, through “action research” studies.

    References

    Alexander, C. 1999. “The origins of pattern theory: The future of the theory and the generation of a living world,” IEEE Software (16:5), Sept-Oct. 1999, pp 71-82.

    Gasson, S. 2004. “A Framework For Behavioral Studies of Social Cognition In Information Systems,” ISOneWorld: Engaging Executive Information Systems Practice, Information Institute, Las Vegas, NV.

    Gasson, S. 2005. ‘The Dynamics Of Sensemaking, Knowledge and Expertise in Collaborative, Boundary-Spanning Design’, Journal of Computer-Mediated Communication (JCMC), 10 (4). http://onlinelibrary.wiley.com/doi/10.1111/j.1083-6101.2005.tb00277.x/abstract

    Gasson, S.  2007. ‘ Progress And Breakdowns In Early Requirements Definition For Boundary-Spanning Information Systems’ in S. Rivard & J. Webster (Eds.) Proc. ICIS ’07, Montréal, Québec, Canada Dec. 9-12, 2007

    Rittel, H.W.J. 1972. “Second Generation Design Methods,” Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327., Interview in: Design Methods Group 5th Anniversary Report, DMG Occasional Paper, 1, pp. 5-10.

    Rittel, H.W.J., and Webber, M.M. 1973. “Dilemmas in a General Theory of Planning,” Policy Sciences (4:155-169).

    Simon, H.A. 1973. “The Structure of Ill-Structured Problems,” Artificial Intelligence (4), pp 145-180.

    Notes

    [1] This is quite distinct from Simon’s perspective, that there is an “optimal” solution, that can be selected from a range of alternatives according to a set of definable criteria. Wicked problems do not possess any clearly-definable definition, so a single set of criteria for a solution cannot be defined.

    [2] Alexander, incidentally, was the initial proponent of hierarchical decomposition – the model that underlies the waterfall model of design and the traditional systems development life-cycle.

    [3] Although actually, the sad truth is that this is exactly what tends to happen … which explains why so many people are disenchanted with their IS development group.

    [4] Note that I do not use the term “problem-solving” here. One can only solve a problem that is amenable to definition. According to Rittel (1972), a wicked problem can only be understood through designing a solution. This is a high-risk activity and should not be treated in the same way as “solving” a well-defined problem.

    Page last updated 05/14/2015 © Susan Gasson (sgasson@drexel.edu) ; Paper last modified: 12/02/2007

  • Managing Organizational Knowledge

    Managing Organizational Knowledge

    This thread of my work explores the forms of knowledge shared across organizational boundaries, the mechanisms for sharing knowledge that are employed, and how human-sensemaking is mediated by processual, technical and informational artifacts. My work draws on theories of distributed cognition, contextual emergence, and sociomateriality. Hayden White observes that human sensemaking relies on subjective forms of narrative for meaning. Much of this work explored how to enable a “conversation with the situation” that introduces reflexive breakdowns into the situated narrativizing and framing in which humans routinely engage. This results in different types of support, focusing on the different forms of knowledge that are required for decision-making — and the degree to which such knowledge can be shared.

    In virtual organizations and distributed project groups, non-human objects increasingly mediate human relationships, as they displace humans as collaboration-partners in distributed knowledge networks. We may be able to identify forms of metaknowledge that work across domain boundaries by identifying mediating object roles – e.g. categorization schemes, instrumentation, databases, and routinized practices that embed frameworks for analysis or participation. My analysis has revealed different forms of group memory management in use, depending on the organizational scope of projects and the locus of control in the global network. Organizational knowledge – about how to work, how to frame organizational goals and outcomes, and how to organize work effectively – is mediated by technical objects, creating assemblages of social and technical systems of work, that guide the emergence of new business practices. The distributed scope of organizational locales creates four categories of knowledge that are acquired in different ways, summarized in Figure 1.

    2 x 2 matrix showing 4 forms of knowledge - these are described in the following text

    Figure 1. Forms of Knowledge (Gasson & Shelfer, 2006)

    Codifiable knowledge is the simplest to define, as this knowledge is routine and programmable. It equates to explicit knowledge, in that we know that we know it – and we can articulate what we know, so it can be stored for others to access and use. Typical examples are organization charts, or the rules, standards, and forms used in business processes.

    Transferable knowledge is articulable, but it is also situational – it is related to the context in which it is applied. For example, an IT systems developer might design software differently for a general-purpose website, whose users are relatively unknown, than for a small local application to be used by 4-5 people working together to perform specific business calculations as part of their shared work. The knowledge of when to apply different design techniques depends on the designers experience of working in various business environments and is generally acquired through some sort of apprenticeship process, where they learn from someone who has more experience of that environment.

    Discoverable knowledge is less straightforward. It combines tacit knowledge (Polanyi, 1961), which is process or skills based, with implicit knowledge that people fail to recollect consciously, or perceive explicitly (Schacter, 1991). As such knowledge is inarticulable, its possessors must recall it inferentially, by relating reported case studies to their own experience, or pattern recognition that can be related to data analysis findings. An effective way of surfacing such knowledge is to discuss historical data or case studies to explore what is known collectively about various situations. This is similar to the argumentation method proposed by Rittel (1972) in his discussion of “second generation design.”

    Hidden knowledge is the most difficult type to surface. It’s not the sort of knowledge that you are going to realize, unless you stop to reflect on what went wrong in your decision-making, or how an action was performed. For example, an IT Manager commented to me that the business process he had selected for a new initiative in organizational change was not as “stand-alone” as he had expected. He stopped to think, then commented that “in fact, I couldn’t have chosen a worse process to start with – it was related to every single business process we have.” Then he paused, and added, “but actually, you could say that about all of our business processes. It seems there is no such thing as a stand-alone process!” This category of knowledge is surfaced through breakdowns (Heidegger, 1962), where the “autopilot” of everyday action is disrupted by the realization that one’s usual recipe-for-success in such circumstances is not working. At that point, the tool or process we were about to use goes from being ready-to-hand, ready for automatic use, to being present-at-hand, needing reflection in order to work out how to use a tool, or how to behave in those circumstances (Winograd & Flores, 1986). During breakdowns, we need to stop and think, revising our mental model of how the world works to come up with a new way of behaving that is a better fit to the situation. Again, Rittel’s (1972) argumentation approach would be helpful here, as people pool and debate what they have learned from a failure, collectively.

    The ways in which we learn, then, are dictated by the scope of access that we have to our colleagues. The more distributed people are, the more that knowledge is mediated across formal technology channels, as distinct from being acquired through face-to-face conversations. This remoteness means that we are more reliant on formal knowledge, that is codifiable, or discoverable from formal sources of information. When people are co-located, they can spend time learning from what others do, or how a mistake or failure happened. They key take-away is that we need multiple ways of configuring and using technology platforms, for all types of knowledge to be supported. We cannot design one-size-fits-all information and communication technology systems.

    Selected Bibliography:

    Khazraee, E.K. & Gasson, S. (2015) ‘Epistemic Objects and Embeddedness: Knowledge Construction and Narratives in Research Networks of Practice’ The Information Society, 31(2), forthcoming, Jan. 2015.

    Gasson, S. (2015) “Knowledge Mediation and Boundary-Spanning In Global IS Change Projects.” Proceedings of Hawaii Intl. Conference on System Sciences (HICSS-48), Jan. 5-8, 2015. Knowledge Flows, Transfer, Sharing and Exchange minitrack, Knowledge Systems.

    Gasson, S. (2012) The Sociomateriality Of Boundary-Spanning Enterprise IS Design, in Joey, F. George (Eds.), Proceedings of the International Conference on Information Systems, ICIS 2012, Orlando, USA, December 16-19, 2012. Association for Information Systems 2012, ISBN 978-0-615-71843-9, http://aisel.aisnet.org/icis2012/proceedings/SocialImpacts/8/

    Gasson, S. (2011) ‘The Role of Negotiation Objects in Managing Meaning Across e-Collaboration Systems.’ OCIS Division, Academy of Management Annual Meeting, San Antonio, August 11-16, 2011.

    Gasson, S. and Elrod, E.M. (2006) ‘Distributed Knowledge Coordination Across Virtual Organization Boundaries’, in Proceedings of ICIS ’06, Milwaukee, WI, paper KM-01. [Winner of ICIS Best paper in track award].

    Gasson, S. and Shelfer, K.M. (2006) ‘IT-Based Knowledge Management To Support Organizational Learning: Visa Application Screening At The INS’, Information, Technology & People, 20 (4), pp. 376-399. Winner of 2008 Emerald Literati outstanding paper award.

    DeLuca, D., Gasson, S., and Kock, N. (2006) ‘Adaptations That Virtual Teams Make So That Complex Tasks Can Be Performed Using Simple e-Collaboration Technologies’ International Journal of e-Collaboration, 2 (3), pp. 65-91

    References

    Heidegger, M. 1962. Being and Time. New York NY.: Harper & Row New York

    Polanyi, M. 1961. “Knowing and Being,” Mind (5:70), pp. 458-470.

    Rittel, H.W.J. 1972. “Second Generation Design Methods,” DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.

    Schacter, D. L. (1992). Implicit knowledge: new perspectives on unconscious processes. Proceedings of the National Academy of Sciences, 89(23), 11113-11117.

    Winograd, T. and Flores, F. 1986. Understanding Computers and Cognition. Norwood New Jersey: Ablex Corporation.

  • Organizational Forms Of Coordination

    I have been working for a while on comparing the results from some very complex research studies of collaborative design in groups that span disciplines or knowledge domains. I was stunned to realize that I had different types of group activity depending on the sort of organization.

    By “organization,” I mean the way in which work is organized, not the sort of business they are in. I noted three types or organization, that seem to respond to collaboration in different ways:

    • Tightly-coupled work organizations rely on well-defined work roles and responsibilities to coordinate tasks across group members. When people in this sort of group have to make decisions, they partition these decisions, based on expertise. Because they all know each others’ capabilities and roles, they don’t have to think about who-knows-what: this is just obvious. This type of organization falls down when people don’t perform their role reliably. For example, if the whole system relies on accurate information coming into the group, someone who misinterprets what they observed can undermine the whole group system.
    • Event-driven organizations rely on external crises and pressures to coordinate group action. People in this sort of group have strongly-defined roles in the wider organization that take precedence over their role in the group — for example in management taskforce groups, business managers tend to prioritize their other work over problems that the group needs to fix. When people in this sort of group make decisions, they partition these decisions according to who-claims-to-know-what, who has time to do the work, and who knows people connected to the problem. They get to know each others’ capabilities over time, but this is a slow process as priorities and decisions are driven by external events, rather than a shared perception of what needs to be done. This type of organization falls down when decisions or actions that were put on a back burner because of another crisis inevitably become a crisis themselves because they were not followed through.
    • Loosely-coupled organizations rely on ad hoc work roles and cooperation among group members. This type of group is commonest in business process change groups, professional work-groups, and community groups, where people are there because they share an interest in the outcome.  When people in this sort of group make decisions, they partition these decisions according to who can leverage external connections to find things out and who has an interest in exploring what is involved. People often share responsibilities in these groups, comparing notes to learn about the situation. This type of organization falls down because it is hard to coordinate. So shared tasks are performed badly because someone knew something vital that they failed to communicate back to the group.

    Wild Horses
    Managing group collaboration can be like taming wild horses

    Why would we care about these different types of organization? Well these structures affect how we approach problem-solving and design. If we (process and IS analysts) need to work with one of the tightly-coupled work-groups, we need to identify who has the decision-making capability for what. It would not occur to a tightly-coupled group member that anyone would not realize who to go to for what. If we need to work with an event-driven group, we have to realize that our work will not be a priority for them — it must be made a priority by gaining an influential sponsor who can kick a$$ within the group(!).  If we work with a loosely-coupled group, we need to engage the interest of the group as a whole. Working with individuals can lead to failure, as this type of group makes decisions collaboratively, not on the basis of knowledge or expertise.

    I have a fair amount of evidence for this line of thought and I am pursuing other factors that make these groups different. More to follow …