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 ‎ 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.


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.


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).

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.


[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 ( ; Paper last modified: 12/02/2007