We talk about organizational design and change problems as if they were given — as if there is only one problem that could be defined for any situation and only one best way to design a solution. This is far from true. Design is like completing a jigsaw puzzle without the picture on the box. We find a bit of sky and then realize it is, in fact, part of a swimming pool.
Organizational change, design, and problem-solving depend on pattern recognition. When organizations assemble a team of managers or designers to represent different business groups, each person brings the assumptions of their group culture and “best practices” with them. They are expected to collaborate as if they totally understand every single part of every business practice involved. But there are multiple, interrelated problems involved in any situation and different stakeholders will perceive different problems depending on their background and experience. The key skill is to recognize those problems and tease them apart, dealing with each one separately.
Organizational problems – whether operational or strategic – typically span organizational boundaries, so the design of business processes and enterprise systems is complicated. Boundary-spanning systems of work need systemic methods and solutions. The point is to understand how collaboration works when people lack a shared context or understanding — and to use design approaches that support collaborative problem investigation, to increase the degree of shared understanding as the basis for consensus and action in organizational change. To enable collaborative visions, people need some point of intersection. In typical collaborations – for example a design group working on change requirements – the “shared vision” looks something like Figure 1.
Figure 1. Differences Between Individual, Shared, and Distributed Understanding In Boundary-Spanning Groups
The only really shared part of the group vision is the shaded area in the center. The rest is a mixture of partly-understood agreements and consensus that mean different things to different people, depending on their work background, their life experience, education, and the language they have learned to use. For example, accountants use the word “process” totally different to engineers. Psychologists use it to define a different concept from either group. When group members perceive that others are not buying in to the “obvious” consequences of a shared agreement, they think this is political behavior — when in fact, it most likely results from differences in how the situation and group agreements are interpreted.
Boundary-spanning collaboration is about maximizing the intersections of understanding using techniques such as developing shared representations and prototypes, to test and explore what group members mean by the requirements they suggested. It involves developing group relationships to allow group members to delegate areas of the design to someone they deem knowledgeable and trustworthy. It uses methods to “surface” assumptions and to expose differences in framing, in non-confrontational ways. But most of all, it involves processes to explore group definitions of the change problem, in tandem with emerging solutions. We have understood this for a long time: Enid Mumford, writing in the 1970s and 80s, discussed the importance of design approaches that involved those who worked in the situation, and the need to balance job design and satisfaction with the “bottom line interests” of IT system design (Mumford and Weir 1979; Mumford 2003) – also see Porra & Hirchheim (2007). This theme has been echoed by a succession of design process researchers: Horst Rittell (Rittel 1972; Rittel and Webber 1973), Peter Checkland (1999), and Stanford’s Design Thinking initiative (although “design thinking” tends to be co-opted to focus on “creativity” in interface design, rather than the integrative design approach that may have been envisioned).
The problem is that most collaboration methods for design of organizational and IT-related change, whether focused on enterprise systems design, business process redesign, cross-functional problem-solving, or IT support for business innovation, employ a decompositional approach. Decomposition fails dramatically because of distributed sensemaking. Group members cannot just share what they know about the problem, because each of them is sensitized by their background and experience to see a different problem (or at least, different aspects of the problem), based on where they are in the organization. Goals for change evolve, as stakeholders piece together what they collectively know about the problem-situation — a process akin to assembling a jigsaw-puzzle. (Productive) conflict and explicit boundary negotiation are avoided because group-members lack a common language for collaboration so misunderstandings are ascribed to political game-playing. We need design and problem-solving approaches that support the distributed knowledge processes underpinning creativity and innovation — approaches that recognize and embrace problem emergence, boundary-negotiation, and the development of shared understanding. This is the core of my work on improvising design.
Checkland, P. 1999. Systems Thinking Systems Practice: Includes a 30 Year Retrospective, (2nd. Edition ed.). Chichester UK: John Wiley & Sons. [Original edition of this book published in 1981].
Mumford, E. 2003. Redesigning Human Systems. Hershey, PA: Idea Group. Mumford, E. and Weir, M. 1979. Computer Systems in Work Design: The Ethics Method. New York NY: John Wiley.
Porra, J., & Hirschheim, R. 2007. A lifetime of theory and action on the ethical use of computers: A dialogue with Enid Mumford. Journal of the Association for Information Systems, 8(9), 3.
Roumani, Nadia 2022. Integrative Design: A Practice to Tackle Complex Challenges, Stanford d.school on Medium, Accessed 8-15-2023.
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.
Rittel, H.W.J. and Webber, M.M. 1973. “Dilemmas in a General Theory of Planning,” Policy Sciences (4), pp. 155-169.
Modern organizations are complex, and the sorts of problems that remain to be resolved using process redesign, IT systems design, or the combination of both that we call the co-design of business & IT systems can’t be defined around a simple set of issues. There are multiple managers and groups of stakeholders, with competing goals for change. Some of these overlap, some complement each other, and some are in conflict with those of other stakeholders. Even a group of people who work together will have differing requirements and goals, depending on their experience, their professional background, and their position in the organization. People understand the parts of the organization they have experience of. Those who have worked in multiple groups will have a much wider – and more complex – view of what needs to change than those who have worked in the same role for years.
There’s a management consultancy joke that says if you get five stakeholders around a table, you’ll have at least fifteen different goals.
The co-design of business & IT systems is like piecing together a jigsaw puzzle without the picture. You get an edge here and there, part of a building outline, or a connecting feature, but mainly you are assembling bits and pieces that are tacked together in whatever way makes sense at the time. Most IT analysts fudge this by merging stakeholder requirements for change under a single, vague business goal. But this doesn’t prevent the shift in focus between multiple objectives that stakeholders prioritize, as these become salient to the current area of design. Change analysts have to understand multiple business domains, as stakeholders’ requirements indicate different types of solution and the analyst attempts to integrate these around a coherent business vision. Even business managers don’t really understand their processes – and know very little of the processes with which their area of responsibility interfaces. Conflicts, priorities, and omissions in change objectives are seldom realized as the logical analysis methods used for IT requirements don’t provide ways to map out the full scope of change – the big picture.
We lack ways to represent the big picture of how the organization “works” in ways that would allow business managers to understand the implications of changing things. Business analysts, change managers, and IT systems analysts are in a no-win situation. They are expected to understand myriad interpretations of the business strategy, reconcile conflicting viewpoints on how business processes work, and somehow define a coherent set of change objectives that pleases everyone. All while the stakeholders they need to satisfy each understand only a fraction of what the business does.
The co-design of complex organizational processes & IT systems
In today’s complex organizations, very few design goals are understood to the point that they can just be stated and agreed across stakeholders. Design-goals are constantly changing between iterations, as shown in Figure 1. The designer starts by designing for the subset of goals they understand. As they explore and test the design with users, they become aware of new requirements and so modify the subset of goals they are designing for. As part of this process, they also discard any requirements that are no longer associated with perceived user needs.
Figure 1. Goal-emergence in design
Goal-based design is a myth
Organizational change requires repeated cycles of appreciation, enculturation, inquiry, learning, change, and evaluation – until the design is good enough. Not perfect – and certainly not optimal – good enough is good enough [2]. We talk about design as if it were fixed: as if there were one best way to design everything. We celebrate designers who produce especially elegant or usable artifacts as if they were possessed of supernatural powers. Yet design should be easy. It is the application of “best practice” principles to a specific situation. We can observe how the users of a designed artifact or system work, then design the artifact or system accordingly.
I was musing about the differences between these three concepts. They are not explained clearly in any resource I could find (although many people take a stab at this), so I thought I’d try bending my brain around the problem. The three types of collectivity appear goal-oriented (as in, sharing a common purpose), but there are big differences between the ways in which group members interact – and the reasons for these types of interaction.
Cooperation is when people share ideas about how to work, or share effort to complete the work towards a shared goal, which is understood in common. People work together to complete a task that would be much more difficult to complete individually. Cooperation often involves deciding how to divide the work between individuals in a group for an optimal outcome – for example, in software or organizational change projects. Work may be divided laterally (each person takes a separate slice of the work towards a deliverable), vertically (each person takes a separate deliverable), or performed collectively, where people share the effort required to achieve a goal (for example, analyzing a business process that is too diverse – involving too many stakeholders – for one person to explore in a reasonable amount of time).
Coordination is the organization of work-tasks across individuals to achieve a complex goal that requires analysis (breakdown into subtasks) before it can be addressed. People work together towards a common goal within an agreed timeframe, even if they don’t understand all the tasks required at the start. They organize their activities around a schema, which provides a model of the parts of the work to be done. They divide their labor on the basis of this schema, with individuals or sub-groups completing each part, which is assembled into a whole once all relevant parts have been completed. They may collaborate to perform shared subtasks.
A Work Breakdown Schema (WBS) Used For Coordination of Work
Coordination may be organized around interim deliverables, which are completed individually from subsets of the work-schema, then assembled once all the parts are complete. The underpinning concept to coordinated work activity is that of a plan – a plan of work, or a plan of how the parts of the whole are organized. This is used to guide the coordination of work, across individuals and across groups. For example, in traditional software project management, work is coordinated around a work breakdown structure (WBS).
Collaboration is the pooling of effort, to achieve a joint goal, which everyone in the group of coordinated workers may not understand in the same way (so this is not a shared goal – subgoals may emerge through the processes of discussion and experimentation over how to perform the work). People work together, taking different parts of a task, to achieve a goal that, if not understood in common at the start of the process, will probably be understood in the same way by the end. Collaboration requires trust (that other people will work towards a common goal), but it is more adaptive than coordinated work – instead of agreeing a model of the task in advance, collaborators develop a shared model of the task deliverables as they collaborate on the task. Working together increases the amount of shared understanding between people, which allows them to improvise and adapt the plan of work to contingencies that arise. So both goals and work-practices evolve as shared practice increases shared understanding between collaborators. Software developers, working on agile software projects, collaborate in analyzing how to coordinate their team’s work around a feature-breakdown then coordinate team work around each person implementing the next feature in the backlog. Finally, they collaborate around integrating the feature components into a coherent prototype system.
Collaboration schema, where sub-goals are explored and defined independently, then merged to achieve an integrated outcome
Collaboration is organized around sub-components (or sub-goals) of the planned outcome that are defined separately. Each sub-component emerges through discussion and experimentation, so the parts are managed autonomously by delegating them to different people. It is only at the integration stage that the shape of the whole solution can be understood.
The way in which problems are defined is critical to producing a good enough solution. Most people don’t stop to think about the constraints they introduce to problem-solving by defining problems in a certain way.
If you ask how something is done (IT requirements analysis), you get a focus on how a solution can support EXISTING processes. This defines the solution only in the vaguest terms.
If you ask what is done, you get a focus on how existing processes could be performed, which allows you to examine alternative ways of working and alternative ways of solving the problem. This approach provides more detail, to define the elements and purpose of the solution.
In the examples that follow, I use an IT system solution, as this illustrates how solution requirements are missed or constrained by ways of defining the problem.
Example 1 – Focusing On How (A Typical Mistake)
Element
Description
The problem of …
Order processing is too slow and prone to human error because this is done manually.
Affects …
Customers, order processing staff, order fulfillment staff, complaints staff and managers.
And results in …
Orders are not processed in a timely manner, some orders are never dispatched, and some customers receive the wrong items.
Benefits of a solution …
A system to automate order-processing would eliminate errors, provide more time for order processing staff and order fulfillment staff to get on with their work, and increase customer satisfaction, resulting in more business.
What the system will actually do (its functional purpose) is not defined here – you now need a lot of investigation (and negotiation) to agree what should be involved in automating order processing.
Example 2 – Focusing On What (Better)
Element
Description
The problem of …
Order processing is too slow and prone to human error because there is no way of recording what has been done, to process an order, and no way of tracking the status of an order.
Affects …
Customers, order processing staff, order fulfillment staff, complaints staff and managers.
And results in …
Orders are not processed in a timely manner, some orders are never dispatched, and some customers receive the wrong items.
Benefits of a solution …
A system to record and track order-processing activities would eliminate errors, provide more time for order processing staff and order fulfillment staff to get on with their work, and increase customer satisfaction, resulting in more business.
This problem definition hinges on what is not being done properly. The functional purpose of the system is defined by the problem definition – all that remains is to determine how this should be performed by people using an information system.
Example 3a – Focusing On Parts of “What” (Best) – Part 1
The best way is to define problems around what people need to do, rather than what the IT system does not do, in supporting them. Then you can think really laterally about whether solving this problem requires work-process changes, IT system changes, or both.
Element
Description
The problem of …
Order processing is too slow and prone to human error because staff are not trained in effective work procedures and lack any formal coordination mechanisms to ensure that they understand and follow best practice.
Affects …
Customers, order processing staff, order fulfillment staff, complaints staff and managers.
And results in …
Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
Benefits of a solution …
A system to manage and track order-processing activities would ensure that staff process orders effectively, increasing customer satisfaction and resulting in more repeat business.
Example 3b – Focusing On Parts of “What” (Best) – Part 2
Element
Description
The problem of …
Order processing is too slow and prone to human error because there is no way of recording what has been done, to process an order, and no way of tracking the status of an order.
Affects …
Customers, order processing staff, order fulfillment staff, complaints staff and managers.
And results in …
Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
Benefits of a solution …
A system to record and track customer orders would flag errors and communicate order priority and progress, allowing problems to be detected before they affect customers.
Example 3c – Focusing On Parts of “What” (Best) – Part 3
Element
Description
The problem of …
Order processing is too slow and prone to human error because work is poorly coordinated, between departments, and between individual staff.
Affects …
Customers, order processing staff, order fulfillment staff, complaints staff and managers.
And results in …
Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
Benefits of a solution …
A system to record and target delivery of the information required to process each step of order processing would eliminate errors and communicate work priorities.
These three problem definitions allow us to specify the (IT system) solution purpose:
The new system will support order processing and fulfillment activities. Specifically, it will fulfill the following high-level purposes (functions):
1.The system will coordinate order information between the order processing system and the order fulfillment system, so that orders are scheduled for fulfillment by the expected date of delivery. This is determined by the combination of (i) date of placing order, and (ii) order priority (1-day, 3-day or 4-5 days). Order processing staff will be able to determine and to change the status of an order in case of customer queries.
2.The system will manage and track order fulfillment processing. The system will signal, through a daily management report and on-screen tracking reports, how many and which orders have not been processed to meet their scheduled delivery date. The main stages of order processing tracked will be: (i) order placement, (ii) order verification against inventory, (iii) customer confirmation of order, (iv) inventory delivery to packing station, (v) order packed, (vi) order delivery to shipping station, (vii) order shipped, (viii) delivery confirmation received.
3.The system will communicate the information required to process orders effectively. It will provide daily management reports, that summarize the percentage of orders processed on time for expected delivery and that list outstanding orders for immediate action. This report will also be available on request, reflecting real-time order processing and fulfillment status. The system will communicate order processing information to each work-station, on the basis of priority and staff availability.
Because of their depth, they also allow us to specify the (IT system) solution features:
The new system will support order processing and fulfillment activities. Specifically, it will provide the following user features:
1.An order processing staff member can determine the status of an order from customer or order identifying information. A list of recent orders will be presented for selection, if order ID code is not available.
2.An order processing staff member can change the status of an order (cancel or change priority) in case of customer queries.
3.A manager can print or view a dynamic order-tracking report. A daily management report will summarize the percentage of orders processed on time for expected delivery and list outstanding orders for immediate action. On-demand reports will summarize real-time order processing and fulfillment status. The user can drill down to locate and see the progress of an individual order.
4.A manager can view or print the status of work at each stage of order-processing, for each employee work-station. The main stages tracked will be: (i) order placement, (ii) order verification against inventory, (iii) customer confirmation of order, (iv) inventory delivery to packing station, (v) order packed, (vi) order delivery to shipping station, (vii) order shipped, (viii) delivery confirmation received.
5.Order processing and order-fulfillment staff will receive work-scheduling information at their work-station, that provides them with the information that they need to process the next order, on the basis of priority and staff availability. The information provided will depend on the stage of order processing (see feature 4).
Validating The System Purpose and Features
The system purposes can be validated fairly easily – ask people if this is what they need a new system to do!
System features are more difficult — how do you know if you’ve missed anything?
You can use scenarios (paper walkthroughs) to validate sequence of events
You can use swimlane diagrams to determine sequence of interactions with system
You can use use-case models, to understand detailed system interactions required for each purpose
You can use event-lists, to determine if you have included all the processes that you need
Any of these methods is useless unless validated by people who will work with the system (and their managers).
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.
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:
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.
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.
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.
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.
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.
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.
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].
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.
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.
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. 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
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.
In the last few years, the terms human-centered and user-centered have become synonymous in HCI and IT design, with a focus on disciplines such as “user experience” and “interaction design.” Here I will argue that neither discipline really deals with the core issues of human-centered design.
Human-centeredness in design involves designing technology artifacts, applications, and platforms that provide a “support system” to people performing specific work or play activities as individuals, or collaborating around a set of (more or less) well-defined aims – often messily and exploratively. Asking people to describe their requirements for technology to support them in their activity doesn’t work because no-body really stops top think about how they work, or what they do to achieve a goal. When they are forced to do so, they will describe how work should be done – the formal system of procedures and rules – rather than how it is done – the informal, socially-situated system that makes work activities fit with their environment and the objectives that people have.
People are seldom alone in what they do, even when engaging in individual activity. They socialize with other people and exchange ideas, they seek advice on how to proceed, and they collaborate to achieve shared – or similar – goals. When confronted with a novel problem, most people turn to a “small world” network of trusted social contacts for input – people who share their values and perspectives – rather than conducting a wider search that includes subject experts and knowledge resources (Chatman, 1991). Even when working alone, we are never truly alone. We are thrown into a working environment that existed before we joined – a self-contained world of work and social activity that we can only understand through participation (Weick, 2004). Professionalism and practice in one organization are completely different to the practices and standards applied in another.
When we try to understand the “user” of a software application or system, we often fail miserably because we only see the formal work activities that they perform. We miss the web of activities that their formal activity is a part of – the multiple other human-activity systems they interact with, to get things done. User-experience design is reductionist in its focus on interaction design. It takes a human being, rich in purpose and understanding, and reduces them to the role of artifact user. Not only that, but by implication, the user of a pre-defined artifact, whose purpose is understood, but whose mechanisms of interaction remain to be fully defined. By focusing on conceptual models of use, user scripts, and activity/task frameworks for work-analysis e.g. Sharp, Preece, and Rogers (2019), it isolates the user from the social context of work, describing activities in terms of fixed procedures and embedding assumptions about how and why the artifact will be used. It loses the joyful multivocality of the human-centered approach to design. Instead of understanding that thrownness is a temporary state, where there is a choice between reaction or being proactive, user-centered design embeds reaction as a paradigm. It separates tasks from workflows, making each interaction an end in itself and enforcing the approach to design that led Lucy Suchman to write her famous treatise on situated design (Suchman, 1987, 2007). There is no linked flow of work processes, where the human being knows that (for example) they have already photocopied the report covers (onto special cardstock) and the early chapters, so now have only to copy later chapters. There is the dumb lack-of-saved-status machine, which jams halfway, then asks the user to reload the report pages in their original order, starting with the covers which need the user to load special cardstock into the paper feeder. Which they already did.
We can support this world by understanding the various purposes of human activity and designing technology to assist in those purposes (Checkland and Winter, 2000). Human-centered design differs from user-centeredness by being systemic and multi-vocal: it is aware of the multiple networks of activity in which a human technology user engages, simultaneously. Unlike user-centered design, which focuses on a single, definable work-goal, human-centered design appreciates the multiple goals that people pursue simultaneously, for different purposes. Human-centered design appreciates the social and organizational context of work, employing analytical approaches and methods that explore the complexity of the activities that we do – and the social networks we inhabit to do them.
Designing for humans rather than users is a choice:
Human-centered design explores the multiple, purposeful systems of human-activity that are required to achieve even simple work (or play) goals.
It treats the participants in a human activity system as autonomous individuals, not agents to be modeled, controlled, and curtailed. Human-centered design respects and supports the local knowledge required to act skillfully, using local knowledge and various forms of tacit or implicit knowledge to perform work that is often not recognized as knowledge work.
It recognizes that a social system of information exchange exists, of which the designed technology artifact or software is only a part, and that humans need to exercise a deliberative choice about what to record and why. Any computer-based system of data is part of a wider, human-network-based system of information.
Because it appreciates work as part of a wider social system, human-centered design involves a conscious decision to support the informal communications and activities that keep the system of work connected and informed – for example, water-cooler conversations or phone calls. These informal channels produce more knowledgeable participants in the system of work, rather than resulting in recorded data records or written resources. They are often omitted from – or worse, designed out of – the formal system of “user experience design.”
Above all, it acknowledges that knowledge, understanding, and the meanings that we ascribe to work are emergent. We understand how to do things by doing them, then reflecting on what we did and how – after which we have a better understanding of how to do them next time. Designing any particular set of procedures into a computer-based system is not only a waste of time, but may be counterproductive, as we constantly improvise and improve on how we did things previously (learning-by-doing). Human-centered systems design allows the human to be in control of their work, rather than the IT system.
So no – “user experience design” and “interaction design” do not support human-centeredness in work (or play). They seek to humanize the artificial processes imposed by transaction-based systems by associating these with perspectives that acknowledge the psychology of human activity, learning, and interactions with technology. But they don’t even scratch the surface of understanding situated, systemic activity. For that, you need to employ methods that complicate your perspective, such as Soft Systems Analysis (Checkland, 2000; Checkland and Poulter, 2006) – and to take human-centeredness seriously.
To conclude, user-centered design – as the term is employed in HCI and UX – is not the same as human-centered design. User-centered design is aimed at mitigating and improving the experience of using a system of technology that was designed for another purpose than those the user prioritizes – to make money, to “engage” users on the website so they return (and spend more money), and to publicize the firm’s products and services. In contrast, human-centered design is an approach that starts with user values, priorities, and purposes. It seeks to afford uses of the system that fulfill how the user would like to access the features that they value and expect. It designs the flow of use-interactions around the expected user flow of work (or play), allowing the user to configure this flow how they want. It does not make you do illogical or stupid things, like reloading all the sheets in a photocopier feed in their original order, even when the copy failed on the last-page-but one. It does not make you enter the same information repeatedly, because the designer was too unimaginative to anticipate that a user might want to change some of the options they had selected earlier (e.g. when booking an airline ticket). And it doesn’t make you go through seven layers of a menu to reach the one page you need.
Human-centered design is performed by people who talk to users, learn to think like users, and walk alongside them in their work. These designers not only prototype and evaluate their designs, but also listen to the feedback they are given. They value user input and see it an critical to their portfolio of design experience. In the design literature of the 1980s there was a lot of discussion of how user representatives would “go native,” when participating in design projects, learning to think like designers and subsuming the interests of their fellow users in the process. In the 2020s, we need to see more IT designers going native, learning to think like users, reworking IT system designs to support how users work, and valuing the aspects of system design that users value. That is human-centered design.
References
Chatman, E.A. 1991 “Life in a Small World: Applicability of Gratification Theory to Information-Seeking Behavior,” Journal of the American Society for Information Science (42:6), pp. 438–449.
Checkland, P. 2000 “Soft systems methodology: a thirty year retrospective,” Systems Research and Behavioral Science (17), pp. S11-S58.
Checkland, P., and Poulter, J. 2006. Learning For Action: A Short Definitive Account of Soft Systems Methodology, and its use Practitioners, Teachers and Students Chichester: John Wiley and Sons Ltd, 2006.
Checkland, P., and Winter, M.C. 2000 “The relevance of soft systems thinking,” Human Resource Development International (3:3), pp. 411-417.
Sharp, H., Preece, J., and Rogers, Y. 2019. Interaction Design: Beyond Human-Computer Interaction, 5th EditionWiley, UK, 2019.
Suchman, L. 1987. Plans And Situated Action Cambridge MA: Cambridge University Press, 1987.
Suchman, L. 2007. Human–machine reconfigurations: Plans and situated actions Cambridge, UK: Cambridge University Press, 2007.
Weick, K.E. 2004. “Designing For Throwness,” in: Managing as Designing, R. Boland, J and F. Collopy (eds.), Stanford CA: Stanford Uniersity Press, pp. 74-78.
Selected Papers:
Gasson, S. (2008) ‘A Framework For The Co-Design of Business and IT Systems,’ Proceedings of Hawaii Intl. Conference on System Sciences (HICSS-41), 7-10 Jan. 2008. Knowledge Management for Creativity and Innovation minitrack, p348. http://doi.ieeecomputersociety.org/10.1109/HICSS.2008.20.
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.
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/
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.
When collaborative innovation groups span knowledge domain boundaries, we have the additional complexity of distributed sensemaking. Boundary-spanning groups find it difficult to develop a common language for collaboration — often because they use similar terms to mean different things, or because they frame salient aspects of the problem-situation in different ways. We cannot, therefore, use the typical, goal-directed methods that we would use with a homogeneous design group (for example, IT professionals engaged in software design). We need methods that represent and permit reconciliation of the multiple frames of meaning encompassed by boundary-spanning collaborators.
I have explored the processes underlying the co-design of business processes and information systems in boundary-spannning groups across multiple studies. We are faced with a wicked problem: one that can only be resolved through stakeholder argumentation, rather than analysis. Choices in the design of technology and the effects of alternative forms of technology on work are formed by definitions of organizational problems and, in turn, affect how organizational problems are defined. So design choices are emergent. Technology and process design, organizational innovation, problem-solving, and management decision-making are inextricably intertwined. The critical issue for organizational problem-solving and design groups is how we manage distributed sensemaking in collaborative knowledge processes. In groups with little shared experience or background – such as the typical enterprise systems design group, which is constituted of managers from different business groups and knowledge domains, understanding is stretched across group-members rather than shared between them. This concept is shown in Figure 1.
Figure 1. Venn Diagram Illustrating Different Categories of “Shared” Understanding
Most collaboration methods, whether focused on enterprise systems design, business process redesign, cross-functional problem-solving, or IT support for business innovation, employ a decompositional approach, which fails dramatically because of distributed sensemaking. Group members cannot just share what they know about the problem, because each of them is sensitized by their background and experience to see a different problem (or at least, different aspects of the problem). Goals for change evolve, as stakeholders piece together what they collectively know about the problem-situation — a process akin to assembling a jigsaw-puzzle. (Productive) conflict and explicit boundary negotiation are avoided because group-members lack a common language for collaboration so misunderstandings are ascribed to political game-playing. We need design and problem-solving approaches that support the distributed knowledge processes underpinning creativity and innovation — approaches that recognize and embrace problem emergence, boundary-negotiation, and the development of shared understanding.
Selected Papers:
Gasson, S. (2013) Framing Wicked Problems In Enterprise-System Design Groups, Ch. 4 in Boundary-Spanning in Organizations: Network, Influence, and Conflict, Janice Langan-Fox and Cary L. Cooper (Eds.), Routledge, Taylor and Francis, New York.
An information system (IS) is not simply an assemblage of hardware and software. As organizations increasingly deploy computer-mediated technology,we see tech-objects displacing people as relationship partners. This provides challenges for technology users, especially in work that requires decision-making across business groups and domains of expertise. My work explores how groups that span multiple knowledge domains collaborate, how we can manage group memory and knowledge in virtual communities and project groups, and the implications for how we design the socio-technical assemblage of processes, knowledge-sharing, and decision-making/management roles that is provided by a digital information system.
Figure 1. Core Elements of Designing Platforms for Digitally-Mediated Collaboration
Wicked Problems and Boundary-Spanning Collaboration: I have explored the processes underlying the co-design of business processes and information systems in boundary-spannning groups across multiple studies. We are faced with a wicked problem: one that can only be resolved through stakeholder argumentation, rather than analysis. Choices in the design of technology and the effects of alternative forms of technology on work are formed by definitions of organizational problems and, in turn, affect how organizational problems are defined.
Design Emergence in Complex Organizations: As multiple stakeholders negotiate the goals and boundaries of change initiatives, these naturally evolve to incorporate the organizational learning that results from the collaborative processes of problem and work/business process representation and debate. Real-world design is much more protracted and complex than envisaged in the planning stage. Design choices are emergent. Technology and process design, organizational innovation, problem-solving, and management decision-making are inextricably intertwined.
Managing Organizational Knowledge: An additional complication is introduced when groups collaborate using digital technologies. The tension between local, context-specific knowledge & practices, and the global, generic knowledge & practices formalized at the organization level present major challenges when managers attempt to define requirements for enterprise-spanning systems, or to investigate organizational problems. This exacerbates the distributed understanding found in problem-solving or online learning groups. This research thread investigates how virtual groups and communities construct and manage various forms of group memory to support collaboration.
Systems Thinking and SSM: Systemic thinking is critical for the organizational sensemaking required for change management in the real world. On this site, I have included my overview of Soft Systems Methodology, the approach to organizational and IT change created by Peter Checkland. It adopts a divide-and-conquer approach, where a complex situation is broken down into relevant subsystems of human activity, each of which is explored from the perspectives of those involved in that activity. This approach is increasingly influential in guiding change management, as it embodies the key distinction between user-centered design and human-centered design. I have found it immensely useful in surfacing perspectives from subjects in research studies, as well as an approach to early requirements analysis in change management projects.
Human-Centered Design Methods: Human-centered design ensures that information system design and configuration choices support, rather than constrain, the exercise of human skills, knowledge and capabilities. The objectification of human attributes, such as knowledge, expertise, and the capability for informed decision-making has led to design choices that severely constrain the ability of humans to recover from machine-instigated problems. We need design approaches and representations that model salient aspects of the system of human activity, not just the mechanistic operations to be automated or codified into the system.
To produce a truly human-centered design, we need to integrate these elements, exploring the design implications and integrating the threads to produce a coherent account of how to approach human-centered design in practice.
This website provides a tour of how to enable IT-related change in complex business organizations (nonprofit and for-profit). It is focused around improvisational design, as improvisation is the result of dealing with wicked problems.
Wicked problems are the type of interrelated, subjective problems that we encounter in organizational change. We can never resolve (or even agree) such complex problems in one go – each stakeholder has a different perspective on what the problems are. As Rittel & Webber (1973) observed, there is no single problem definition – and no stopping point by which to judge if you are finished.
Goal-based design is a myth. Instead, we face emergent design, comprising cycles of inquiry, systemic analysis, organizational & IT change, and evaluation. The best we can do is to agree a scope for action, analyze the problems within that scope and take action, then evaluate whether we made the situation better or worse. Design is emergent because we constantly need to change our scope and goals, depending on that evaluation – and on changes to organizational goals in response to a changing business environment.
IT and change management fail when they are managed as if each project is self-contained. Instead, we need to manage these processes as a single cycle in an ongoing process of managing organizational fit with an evolving business environment.
