Author: Susan

Wicked Problems

Organizational Problems are Wicked Problems

A wicked problem is one that is just too complex and messy (comprising multiple problem-elements) to be easily defined. As it can’t be defined, it can’t be resolved using regular analysis methods, such as those used to generate IT system requirements. Different stakeholders will define the problem in different ways, depending on the parts they have encountered in their work. The emergence of multiple problem-definitions as the problem is explored distinguishes “wicked” problems from the “tame” problems that organizational analysts and IT systems developers typically deal with. While tame problems can be defined in terms of goals, rules, and relate to a clear scope of action, wicked problems consist of many, interrelated problems, each with its own organizational scope and goals. As a result, wicked problems have vague, emergent goals and boundaries. Ways of framing wicked problems are negotiated among stakeholders who hold radically different views of the organization (Rittel & Webber, 1973).

“It comes as no particular surprise to discover that a scientist formulates problems in a way which requires for their solution just those techniques in which he himself is especially skilled.”
Kaplan, Abraham (1964) “The Age of the Symbol—A Philosophy of Library Education” The Library Quarterly: Information, Community, Policy, Oct., 1964, Vol. 34, No. 4 (Oct., 1964), pp. 295-304

These types of problem are also known as systemic problems because we use systems thinking (a.k.a. systemic analysis) to resolve them. Systemic analysis methods use a “divide-and-conquer” approach to exploring problems. The sub-problems prioritized by various stakeholders are explored and debated across the wider group of change managers. Goals and potential solutions emerge as “the problem” is framed and re-framed in multiple ways over time, and across stakeholders. This process results in organizational learning, as stakeholders acquire an improved understanding of others’ perspectives across organizational functions and boundaries. Systemic analysis also allows change managers to explore the “knock-on” impacts of change, allowing them to appreciate conflicts and tradeoffs between perspectives and to predict the impact of changes to one area of the organization on other areas and functions.

What are Wicked Problems?

Wicked problems present as tangles of interrelated problems, or “messes” (Ackoff, 1974). Because these problems are so messy, they are defined by various stakeholders in multiple ways, depending on the parts that they perceive — which in turn depends on where they are in the organization, their experience and their disciplinary background.

If you try to model a complex problem-situation, you will rapidly discover that any “system” of work consists of subsystems, the definition and scope of which depends on where the definer stands in the organization. To act upon a wicked problem, you need to understand the multiplicity of perspectives that various stakeholders take. Often, a single person will hold multiple perspectives depending on the role they are playing at any point in time. For example, I trained as an engineer, I was introduced to systemic analysis during my education, and I adopted a social science perspective as an academic. So I can happily (and obliviously) define any situation in three different ways, depending on which “hat” I am wearing when I do so!

Wicked problems are so-called because they are not “well-structured” – that is, amenable to analytical methods of problem-solving. This means that analysts often experience difficulty in defining the problem that needs solving or selecting an appropriate technique to model the problem.

“Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.”
Russel Ackoff (1974) Redesigning the Future. ‎Wiley.

Wicked Problems Require Systemic Analysis

As a result, Wicked Problems have a number of characteristics not found in the sorts of problems for which professional analysts and change-agents are typically trained. They are solved by trial and error, rely more on problem-negotiation than analysis, and need to be investigated, rather than analyzed. Any analysis imposes a model or structure that includes some aspects of the situation and excludes others, imposing an expectation that the elements found will be related in specific ways:

“… it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
Maslow, Abraham Harold (1966). The Psychology of Science: A Reconnaissance. Harper & Row.

The bottom line is that, while most analysis approaches focus on the form of the solution, wicked problem analysis needs to investigate the nature and scope of the problem. Successful resolution of wicked problems requires appreciative design techniques (Vickers, 1968), where the definition of a solution emerges in tandem with the definition of the problem. Analysts must become enculturated in the problem-situation to understand the stakeholder perspectives that drive various definitions of wicked problems. They need to be familiar with systemic analysis of problems . Plus, they need to be good facilitators, capable of negotiating solutions across multiple stakeholders, with multiple viewpoints and priorities.

References

Mitroff, I.I., Kilmann, R.H. (2021). Wicked Messes: The Ultimate Challenge to Reality. In: The Psychodynamics of Enlightened Leadership. Management, Change, Strategy and Positive Leadership. Springer, Champaign. https://doi.org/10.1007/978-3-030-71764-3_3

Pickering, Andrew (1995) The Mangle of Practice. University of Chicago Press, Chicago IL.

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

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

Vickers G. (1968) Value Systems and Social Process. Tavistock, London UK.

November 19, 2024
Appreciative Design & Soft Systems

Appreciating The Context of Organizational Activity

Human-centered design requires that we understand – or rather, appreciate – the need for changes to a “real-world” situation that is viewed as a governed by business logic and goals – rather than the engineering logic employed for IT system requirements. The intention is to improve how we understand the need for change – and the systemic impacts of making changes – through an iterative learning process based on Vickers’ concept of Appreciative Systems (Vickers, 1968; Checkland, 2000b).

Geoffrey Vickers observed the diversity of norms, relationships, and experiential perspectives among those involved in, or affected by, a system of human-activity such as that found in business work-organizations. He argued that organizational change analysts needed methods for analysis that explored how to reconcile these perspectives, developing the concept of an “appreciative system,” the set of iterative interactions by which members of an organization explore, interpret, and make collective sense of their shared organizational reality (Vickers, 1968).

The Concept of an Appreciative System Source: Checkland and Casar (1986), via Checkland (2000b)

Vickers conceptualized organizational work as a stream, or flux, or events and ideas that were interpreted by participants in the organization by means of local “standards,” reflecting shared interpretation schema and sociocultural values (Checkland and Casar, 1986). Interpretations of new events and ideas are subject to the experiential learning that resulted from prior encounters with similar phenomena; these will vary across stakeholders, depending on how they interpret the purpose of the system of work-activity. To achieve substantive change, we need to understand and reconcile these multiple purposes, integrating requirements for change across the multiple system perspectives espoused by various stakeholders. These are separated out into distinct perspectives, which model subsets of activity that are related to a specific purpose or group of participants in the problem situation (Checkland, 1979, 2000b).

Real-World Analysis Vs. Systems Thinking About the Real World

While both real-world analysis and systems thinking about the real world aim to produce representations of complex situations, the key difference lies in their focus: real-world analysis primarily examines data from actual scenarios to identify patterns of human-activity, relationships between actors, and issues that affect performance, whereas systems thinking takes a broader view by considering the interconnectedness of elements within a system, analyzing how they interact and influence each other to understand the big picture – and to engage in debate about how it may be improved.

The concept of appreciative design underpins Soft Systems Methodology (SSM), an approach devised by Dr. Peter Checkland of Lancaster University in the UK, to capture and make sense of complex change requirements across multiple goals for change and the multiple rationales that underpin any organizational system of work-activity. SSM is now a highly-regarded approach to managing complex change, especially suited to the untangling of “wicked problems” (Rittel, 1972). Its contribution is to separate the analysis of “soft systems” of human-activity – what people do in their work and the logic that makes sense of that activity – from the “hard system” of IT and engineering logic that usually underpins system requirements.

Soft Systems Methodology (SSM)

The development of integrative system thinking methods and analysis techniques to solve ill-structured, “soft” problems is Checkland’s (1979) contribution to the fields of change management and systems analysis. Soft Systems Methodology (SSM) provides a method for participatory design centered on human-centered information systems. The analysis tools suggested by the method — which is really a family of methods, rather than a single method in the sense of modeling techniques — permit change-analysts, consultants and researchers to surface and negotiate feasible aspects of change, to explore and reconcile alternative viewpoints, and to anticipate (to some extent) the knock-on effects of changing one part of a complex system of work on other parts of this system.

Problems are ultimately subjective: we select things to include and things to exclude from our problem analysis (the “system boundary”). But real-world problems are wicked problems, consisting of interrelated sub-problems that cannot be disentangled — and therefore cannot be defined objectively (Rittel, 1972). The best we can do is to define problems that are related to the various purposes that participants pursue, in performing their work. By solving one problem, we often make another problem worse, or complicate matters in some way. Systemic thinking attempts to understand the interrelatedness of problems and goals by separating them out.

In understanding different sets of activities and the problems pertaining to those activities as conceptually-separated models, we understand also the complexity of the whole “system” of work and the interrelatedness of things – at least, to some extent. It is important to understand that, given the evolving nature of organizational work, a great deal of the value of this approach lies in the collective learning achieved by involving actors in the situation in analyzing changes, and that this approach in inquiry is, in principle, never ending. It is best conducted with and by problem-situation participants (Checkland, 2000b).

Summary

To summarize, appreciative design is an approach where emergent perspectives on what a “system” of work should achieve and how that work should be performed are modeled to produce actionable changes to the system that can be evaluated around agreed standards of performance and that preserve desired relationships between human actors and between elements of work-activity and their outcomes. This approach to modeling work-systems influenced the development of Soft Systems Methodology (Checkland, 2000b), a method to operationalize the representation and negotiation of systems of purposeful human-activity around which desirable and feasible changes can be identified and implemented.

References

Checkland, P. (1979) Systems Thinking, Systems Practice. John Wiley and Sons Ltd. Chichester UK. Latest edition includes a 30-year retrospective. ISBN: 0-471-98606-2.

Checkland P., Casar A. (1986) Vickers’ concept of an appreciative system: A systemic account. Journal of Applied Systems Analysis 13: 3-17

Checkland, P. (2000a) New maps of knowledge. Some animadversions (friendly) on: science (reductionist), social science (hermeneutic), research (unmanageable) and universities (unmanaged). Systems Research and Behavioural Science, 17(S1), pages S59-S75. http://www3.interscience.wiley.com/journal/75502924/abstract

Checkland, P. (2000b). Soft systems methodology: a thirty year retrospective. Systems Research and Behavioral Science, 17: S11-S58.

Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its Use, for Practitioners, Teachers and Students. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-470-02554-9.

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

Vickers G. (1968) Value Systems and Social Process. Tavistock, London UK.

November 19, 2024
Human-Centered Design
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.

Gasson, S. (2005) ‘Boundary-Spanning Knowledge-Sharing In E-Collaboration’ in Proceedings of Hawaii Intl. Conf. on System Sciences (HICSS-38), Jan. 2005. http://doi.ieeecomputersociety.org/10.1109/HICSS.2005.123

Gasson, S. (2003) ‘Human-Centered vs. User-Centered Approaches To Information System Design‘, Journal of Information Technology Theory and Application (JITTA), 5 (2), pp. 29-46.

Gasson, S. (1999) ‘A Social Action Model of Information Systems Design’, The Data Base For Advances In Information Systems, 30 (2), pp. 82-97.

Gasson, S. (1999) ‘The Reality of User-Centered Design‘, Journal of End User Computing, 11 (4), pp. 3-13.
November 7, 2023
Why is design improvisational?

Why is design improvisational? 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. Why does that approach fail so often?

The key issue is the problem of “the problem.” Designers are taught a repertoire of designs-that-works: patterns that fit specific circumstances and uses. Experienced designers are capable of building up a deep understanding over time, of which problem-elements each of these patterns resolves. So they can assess a situation, recognize familiar problem-elements, then fit these with design patterns that will work in these circumstances. The problem comes when a designer is faced with a novel or unusual situation that they have not encountered before. Novice designers encounter this situation a great deal, but even experienced designers must deal with emergent design in a novel context. In these circumstances, designers iterate their design, as shown in Figure 1. They identify (often partial) problems, ideate/conceive relevant solutions, give those solutions form with a prototype, then evaluate the prototype in context. This often reveals emergent user needs or problems, that are explored in the next iteration.

Figure 1. Iterative Design

An important aspect of iterative design is that iterations can occur within cycles. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and to understand which design elements will work or fail in that situation, looping back to remediate the design as they spot logical flaws and gaps in the design. The problem with this is that (as the Princess said) you have to kiss an awful lot of frogs to get a Prince. An awful lot of people end up with really bad designs, because their designer did not recognize elements of the situation well enough to understand which pattern-elements to implement. If you are really unlucky, you will also end up with one of those designers who feel it is their mission in life to prevent the end-user “mucking about with” their design. If you are lucky, your designer will recognize that it is your design, not theirs. They design artifacts and systems in ways that allow people to adapt and improvise how they are used.

Which means that design-goals are constantly changing between iterations, as shown in Figure 2. 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 2. Goal-emergence in design

Improvisation takes a multitude of forms. It might be that a user wishes to customize the color of their screen (because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the first step, then go back later to change this, once you have the real data. This is because IT systems designers treat software design as a well-structured problem. A well-structured problem is one that contains the solution within its definition. Defining the problem as a tic-tac-toe game application means that you have a set of rules for how the game is played which absolutely define how it should work. This is fine if everything goes to plan, but a huge pain for users when it does not. The only discretion left to the user is how to format the results in a printed report, which is not much comfort if your whole transaction failed because you were prevented from going back to change one of the inputs. This is not rocket science – developers need to design systems that let users work autonomously.

Business applications tend to present wicked problems [2]. A wicked problem cannot be defined objectively, for all the reasons identified in Figure 3. Solving a wicked problem needs business users and stakeholders to agree on what problems that they face, their priorities in resolving these, and what their change-goals are.

Figure 3. Constraints on Design Posed by Wicked Problems (Rittel & Webber, 1973) [2]

A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing these solutions may make other, related problems worse or better. This is why iterative design is central to resolving wicked problems. In general, stakeholders don’t understand what they need until they see it. So solutions must be designed flexibly, for changes to be implemented as the consequences are realized and to permit adaptation-in-use by stakeholders and users. People are infinitely improvisational. They develop work-arounds and strategies to manage poor design. But, as Norman [1] observes, why should users have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on flexible work-procedures?This website reflects findings from my research studies and reflections from my own experience in design, to discuss some key underlying principles of design, to explore how the design process works in practice (rather than how we manage it now, which is based on unsupported theoretical models), and to present a way of managing design differently. Improvisationally.

References

[1] Norman, D. A. (2013). The Design of Everyday Things: Revised and Expanded Edition. Basic Books, New York.

[2] Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a General Theory of Planning. Policy Sciences, 4, 155-169.

April 7, 2023
Coordination, Cooperation, and Collaboration

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.

June 27, 2015
Improvising Design

Why is design improvisational? 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. Why does that approach fail so often?

The key issue is the problem of “the problem.” Designers are taught a repertoire of designs-that-works: patterns that fit specific circumstances and uses. Experienced designers are capable of building up a deep understanding over time, of which problem-elements each of these patterns resolves. So they can assess a situation, recognise familiar problem-elements, then fit these with design patterns that will work in these circumstances. The problem comes when a designer is faced with a novel or unusual situation that they have not encountered before. Novice designers encounter this situation a great deal. As designers succeed or fail at successive designs, they accumulate experiential knowledge, that allows them to assess new situations quickly and to understand which design elements will work or fail in that situation. The problem with this is that (as the Princess said) you have to kiss an awful lot of frogs to get a Prince. An awful lot of people end up with really bad designs, because their designer did not recognize elements of the situation well enough to understand which pattern-elements to implement. If you are really unlucky, you will also end up with one of those designers who feel it is their mission in life to prevent the end-user “mucking about with” their design. If you are lucky, your designer will recognize that it is your design, not theirs. They design artifacts and systems in ways that allow people to improvise how they are used — and the role that they play in the work that people do.

Improvisation takes a multitude of forms. It might be that you customize the color of your screen (often because the designer thought that a good interface should look like a play-school). This may not do much for the function of your work-system, but it does mean that your disposition towards work is a heck of a lot sunnier as you use it. Or it might be that the information system which you use expects you to enter data on one step of your work before another. You might be able to enter data into a separate screen for each step, reordering the steps as you wish. More usually, you have to enter fake data into the first step, then go back later to change this, once you have the real data. This is because IT systems designers treat software design as a well-structured problem. A well-structured problem is one that contains the solution within its definition. Defining the problem as a tic-tac-toe game application means that you have a set of rules for how the game is played which absolutely define how it should work. The only discretion left to the designer is whether to support one or two players and how to present the functions in a usable screen interface. This is not rocket science: most designers can manage this level of design without making the game unusable.

But information systems applications tend to present wicked problems. A wicked problem is a problem that cannot be defined objectively, but needs the people involved (the stakeholders) to agree on what the problems that they face are, what are their priorities in resolving these, and what they want to achieve in changing things in the first place. A wicked problem can be understood as a web of interrelated problems. It is not always clear what the consequences will be, of solving any part of this mess. Some of the problems may have “obvious” solutions. But implementing these solutions may make other, related problems worse or better. For example, consider the problem of providing State-based unemployment benefit in the USA (see the diagram on the “systems thinking” page). If one State offers such benefits and a neighboring State does not, unemployed people will move to the State which does offer benefit payments. This will place a greater tax burden on that State, causing the more affluent residents and businesses to move out. This increases unemployment, raising the tax burden, causing more people and businesses to move out. The act of offering State-based unemployment benefits leads that State into a downward spiral in which their budget becomes unmaintainable and employment opportunities are significantly reduced. For wicked problems, a wider perspective is needed, that examines interactions between problem elements and which analyzes the impact of one problem-solution on other problems. It is not always possible to foresee all unintended consequences. So solutions must be designed flexibly, for changes to be implemented as the consequences are realized and to permit customization by stakeholders and users.

People are infinitely improvisational. They develop work-arounds and strategies to manage poor design. But I constantly ask myself why should they have to develop work-arounds for poor design? What is it, about the design process, that leads us to such constraining IT systems, interfaces, and work procedures that are based on the system design, rather than system designs that are based on flexible work-procedures? This website reflects findings from my research studies and reflections from my own experience in design, to discuss some key underlying principles of design, to explore how the design process works in practice (rather than how we manage it now, which is based on unsupported theoretical models), and to present a way of managing design differently. Improvisationally.

April 14, 2015
The Co-Design of Business & IT Systems

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. While the stakeholders of change each understand only a fraction of what the business does.

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 people fudge this by kludging viewpoints together under a single goal, with multiple objectives that reflect the main things that stakeholders seem to value. Objectives move in and out of the picture, as the focus shifts. Analysts have to understand multiple business domains, as stakeholders pull in different directions like the wild horses in the site header. Even business managers don’t really understand their processes – and know very little of the processes they interface with. Conflicts, priorities, and omissions in change objectives are seldom realized as current analysis methods don’t provide ways to map out the full scope of change, or to present this to business managers for input.

Systemic analysis uses a divide-and-conquer strategy. The parts of the jigsaw puzzle are assembled separately, then the analyst can piece together the whole. Conflicts, priorities, and omissions from the change requirements become obvious because of the way in which the whole picture is explored. This allows the change analyst and — more importantly — the managers, system users, victims, and beneficiaries of change to understand the scope and priorities of what will change.

This website provides a tour of how to perform a systemic analysis of requirements for change in business organizations (nonprofit and for-profit). It deals with how to get groups of people, who come from very different backgrounds, on the same page – talking a common language for the co-design of business and IT systems.

December 7, 2014
Design Methods as Performative Objects

Brown and Duguid’s (2001) concept of a “network of practice” has been niggling away at my consciousness. The idea is that a collection of people are enabled to understand each others’ work because of commonalities in practice, but not to the extent that a Community of Practice creates shared ways of framing and performing work:

“we include under the rubric … groups whose members, to the extent that they have common practices, are able to read and understand one another’s work. Disciplinary networks of practice cut across heterogeneous organizations, including, for example, universities, think tanks, or research labs. Professions make up yet other such networks of practice, where again similar practitioners, by virtue of their practice, are able to share professional knowledge through conferences, workshops, newsletters, listservs, Web pages and the like. … different networks of practice cut horizontally across vertically integrated organizations and extend far beyond the boundaries of the latter. Along these networks, knowledge can flow.” (Brown and Duguid 2001, p. 206)

So create closer bonds than organizational membership, spanning organizational boundaries. If the type of intersubjectivity that derives from shared practice (i.e. what Polanyi calls tacit knowledge) does not underpin a network of practice, what does? This rings true, given the observation that IT professionals identify more with the interests of their profession than with their organization (Chou and Pearson 2012). Which brings me to the second property of networks of practice:

“it is important to note that networks of practice may also inhibit the flow of knowledge. As Lynn et al (1996) show, professional networks will occasionally work to resist the spread of ideas felt to be inimical to the interests of the network’s members.” (Brown and Duguid 2001, p. 207).

So how do networks of practice share knowledge? Brown and Duguid have an explanation:

“We have used the notion of networks of practice to explain leakiness. This is not, we have suggested, simply an inherent property of some kinds of knowledge. It does not result from making knowledge explicit and so tradable. It is, rather, a function of the common underlying practice, which creates social-epistemic bonds. Where practice doesn’t prepare the ground, knowledge is unlikely to flow.” (Brown and Duguid 2001, p. 207)

But this is not very satisfying when members of the network are not co-located. Surely, “common underlying practice” includes some form of shared framing as the basis of those social-epistemic bonds? I thought back to the work of Howard Rosenbrock (1981), who explains that IT professionals’ paradigm of system design with the aim of making users interchangeable results in deskilled, repetitive, and unfulfilling jobs for those who use these systems. He explains:

“The paradigm is transmitted from one generation to another, not by explicit teaching but by shared problem-solving. Young engineers take part in design exercises, and later in real design projects as members of a team. In doing so, they learn to see the world in a special way: the way in fact which makes it amenable to the professional techniques which they have available.” Rosenbrock (1981, p.6),

So we have design methods as a form of performativity, embedding ways of framing job design, as well as creating a shared design practice that ignores users’ psychological and motivation needs. But surely, IT professionals are continually learning, acquiring new skills and approaches to system design? It would appear not:

“The fact that most IS professionals learn the bulk of their technical skills during college or immediately afterward encourages recruiters to focus on technical skills for new hires. IS professionals generally learn non-technical skills in the workplace.” (Lee et al. 2001, p.28).

All is not lost. Lee et al. (2001) go on to observe

“IS professionals generally learn non-technical skills in the workplace. And because these non-technical skills are so valuable in the long term, new hires need to possess the aptitude to learn these skills. This may help explain why recruiters prefer graduates who took more MIS classes than those who concentrated strictly on computer science courses.” (Lee et al. 2001, p.28).

How can we remedy the perspective that leads to such impoverished outcomes? As Rosenbrock observes, IT systems can be seen as a replacement for human ingenuity and skill, or as a way of supporting these. We have a choice to automate or to informate work (Zuboff 1988). We also have two chances to undermine the automation-on-rails approach taught in so many methods classes. Back to the network of practice idea. IT professionals have a network of practice with really strong bonds. We can teach IS methods more thoughtfully to those who return – for ongoing education in Masters degrees, etc. Finally, we can mobilize the network of practice, on LinkedIn and elsewhere, to ensure that IT professionals are aware of the types of skill and knowledge-preserving approaches to organizational system design that we would want to see used in our own organizations.

References

Brown, J.S. and Duguid, P. 2001. “Knowledge and Organization: A Social-Practice Perspective,” Organization Science (12:2), pp. 198-213.

Chou, S.Y. and Pearson, J.M. 2012. “Organizational Citizenship Behaviour in It Professionals: An Expectancy Theory Approach,” Management Research Review (35:12), pp. 1170-1186.

Lee, S., Yen, D., Havelka, D., and Koh, S. 2001. “Evolution of Is Professionals’ Competency: An Exploratory Study,” The Journal of Computer Information Systems (41:4), pp. 21-30.

Rosenbrock, H.H. 1981. “Engineers and the Work That People Do,” IEEE Control Systems Magazine (1:3), pp. 4-8.

Zuboff, S. 1988. In the Age of the Smart Machine. New York NY: Basic Books.

July 10, 2014
Responsive Web Design

I manage the website for an Animal Rescue shelter. I have been struggling with the design of the site for some time now, as I have some users who are still using IE6 under windows XP (on an SVGA screen), some who want to view the site on their mobile phones, and some who have really wide displays and think my two column design looks outdated (it does). While looking for a solution, I came across the concept of responsive web design. Because the reference I just provided is stuffed with code snippets (and I personally think it is obscure), I will point you instead to some really great examples that demonstrate how a website design can be responsive.

There is a neat concept at play in most of these designs, where a webpage layout is segmented into multi-device layout patterns, that simply “flow” differently, depending on the screen size that the user will display the site on. But screen size is not the only consideration – images have to be resized to scale with the device and the performance of the device must be considered (it is painful to load a large, graphics-intensive page on a slooow tablet!). I was also musing that – most relevantly to this course – site menus and navigation toolbar interfaces have to be designed so that they will work on any device or layout. Which is harder than you’d think, simply because of the layout conventions that we use on a typical web-page.

Off to experiment with scripts and pageflow layouts …

March 12, 2014
On Realizing The Relevance of Actor-Network Theory

A recent emphasis on sociomateriality appears to have entered the IS literature because of discussions by Orlikowski (2010) and the excellent empirical study of Volkoff et al. (2007). Now that people have been sensitized to the literature on material practice, actor-network theory is classified as “tired and uninformative” [1]. Which leads me to wonder just how many IS academics have actually read the actor-network theorists? Or pondered how this applies to technology design?

Long before people started discussing socio-material “assemblages,” Bruno Latour (1987)and John Law (1987) were discussing how technology developed by means of “heterogeneous networks” of material and human actants, the combination of which directs the trajectory of technology design and form. Latour (1999) suggests that he should recall the term “actor-network,” as this is too easily confused with the world-wide web. Yet actor-networking – in the sense of a web of connectivity, where heterogeneous interactions between diverse individuals, between virtually-mediated groups, and between individuals and material forms of embedded intentionality – is exactly what is going on in today’s organizations.

In addition, Michel Callon’s (1986) work on how the “problematization” of a situation in ways that aligns the interests of others leads to their enrolment in a network of support for a specific technological frame. Once support has been enrolled, such networks endow irreversibility, which makes changes to the accepted form of a technology solution incredibly difficult. So we have paradigms that are embedded in a specific design. Akrich coined the term “script” to define the performativity of technology and the term was adopted by the other leading actor-network theorists [2]. This thread of work articulates incredibly deeply the ways in which technology design directs its users (and maintainers) into a set of roles and worldviews that are difficult to escape. We must “de-script” technology to repurpose it to other networks and other applications – which is much more difficult than one would suppose, given the embedded social worlds that are carried across networks of practice with the use of common technologies (Akrich 1992).
So what does actor-network theory give us? It provides a conceptual and practical approach to understanding and modeling why design takes specific forms – and what needs to be “undone” for a design to be conceived differently than in the past [3]. It provides a rationale for understanding technology as a network actor in its own right, influencing behavior and constraining discovery. The assumptional frameworks for action embedded in – for example – a software book-pricing application will direct the evaluation of price alternatives in ways that reflects the model of decision-making adopted by the software’s author. This results in the type of stupid automaticity that recently saw an Amazon book priced at $23,698,655.93 (plus $3.99 shipping). The cause of this pricing glitch was traced back to an actor-network of two competing sellers, unknowingly connected via their use of the same automated pricing software [4].

Finally, I want to observe that a lot of the recent “materiality of practice” literature has identified new phenomena and new mechanisms of actor-networks. For example Knorr Cetina (1999) has sensitized us to how epistemology is embedded in socio-technical assemblages, Rheinberger (1997) has demonstrated how some technical objects are associated with emergence while others enforce standardization and Henderson (1999) demonstrates how the use of specific representations can conscript others around an organizational power-base. But I would argue that these effects can be understood by using Actor-Network Theory as one’s underpinning epistemology – and that exploring actor-network interactions continues to reveal ever newer mechanisms that are relevant to how we work today. I would strongly recommend Bruno Latour’s latest book, Reassembling The Social.

Notes:
[1] I have to declare an interest here – this comment was contained in a review of one of my papers … 🙂
[2] As Latour (1992) argues: “Following Madeleine Akrich’s lead (Akrich 1992), we will speak only in terms of scripts or scenes or scenarios … played by human or nonhuman actants, which may be either figurative or nonfigurative.”
[3] One of my favorite papers on the topic of irreversibility in design is ‘How The Refrigerator Got Its Hum,’ by Ruth Cowan (1995). Another good read is the introduction to the same book by MacKenzie and Wajcman (1999).
[4] The amusing outcome is recounted by Michael Eisen, at http://www.michaeleisen.org/blog/?p=358

References:
Akrich, M. 1992. The De-Scription Of Technical Objects. W.E. Bijker, J. Law, eds. Shaping Technology/Building Society: Studies In Sociotechnical Change. MIT Press, Cambridge, MA, 205-224.
Callon, M. 1986. “Some elements of a sociology of translation: domestication of the scallops and the fishermen of St Brieuc Bay.” J. Law, ed. Power, Action, and Belief: a New Sociology of Knowledge? Socioogical Review Monograph 32. Routledge and Kegan Paul, London, 196-233.
Cowan, R.S. 1995. “How the Refrigerator Got its Hum.” D. Mackenzie, J. Wajcman, eds. The Social Shaping of Technology. Open University Press, Buckingham UK, 281-300.
Henderson, K. 1999. On Line and on Paper: Visual Representations, Visual Culture,and Computer Graphics in Design Engineering. MIT Press, Harvard MA.
Knorr Cetina, K.D. 1999. Epistemic Cultures: How the Sciences Make Knowledge. Harvard Univ. Press, Cambridge, MA.
Latour, B. 1987. Science in Action. Harvard University Press, Cambridge MA.
Latour, B. 1992. “Where Are the Missing Masses? The Sociology of a Few Mundane Artifacts.” W.E. Bijker, J. Law, eds. Shaping Technology/Building Society: Studies In Sociotechnical Change. MIT Press, Cambridge MA.
Latour, B. 1999. “On Recalling ANT.” J. Law, J. Hassard, eds. Actor Network and After. Blackwell, Oxford, UK 15-25.
Law, J. 1987. “Technology and Heterogeneous Engineering – The Case Of Portugese Expansion.” W.E. Bijker, T.P. Hughes, T.J. Pinch, eds. The Social Construction of Technological Systems: New Directions in the Sociology and History of Technology. MIT Press, Cambridge MA.
MacKenzie, D.A., J. Wajcman. 1999. Introductory Essay. D.A. Mackenzie, J. Wajcman, eds. The Social Shaping Of Technology, 2nd. ed. Open University Press, Milton Keynes UK, 3-27.
Orlikowski, W. 2010. “The sociomateriality of organisational life: considering technology in management research.” Cambridge Journal of Economics 34(1) 125-141.
Rheinberger, H.-J. 1997. Experimental Systems and Epistemic Things Toward a History of Epistemic Things: Synthesizing Proteins in the Test Tube. Stanford University Press, Stanford CA, 24-37.
Volkoff, O., D.M. Strong, M.B. Elmes. 2007. “Technological Embeddedness and Organizational Change.” Organization Science 18(5) 832-848.

September 23, 2013