Emergent Design
Multiple Perspectives of “The Problem”
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.
Modern organizations are complex. The problems we now face are a combination of business-process change and IT system design that we call the co-design of business & IT systems. Such problems can’t be defined around a simple set of issues – they emerge over time, as various stakeholders start to understand the problems of others. There are multiple managers and groups with competing goals for change. Some of these interests overlap, some complement each other, and some are in conflict with others. Even a group of people who work together will have differing goals and perceptions of “the problem,” depending on their experience, their professional background, and their position in the organization. People understand the parts of the organization they have experienced. 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.
Organizational problems – whether operational or strategic – typically span organizational boundaries, so we have the additional complexity of distributed sensemaking. 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. A Venn Diagram Illustrating Different Categories of “Shared” Understanding
The only really shared part of the group vision is the area in the center of the Venn diagram. 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” in a way that is 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 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 are faced with a wicked problem: one that can only be resolved through stakeholder learning and 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.
Goal-based design is a myth
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
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.
Why does that approach fail so often? Because designers fail to design for changes to business processes.
The co-design of complex organizational processes & IT systems
We cannot implement changes to IT systems without changing the way in which people work, how work is organized, and what it achieves. Most often, achieving improved business goals is the whole reason for IT change, as business environments and competitors change – and our business strategy needs to change to match this (or anticipate it).
The drivers of change are shown in Figure 2.
Figure 2. Drivers of IT Change
Because IT change is always accompanied by changes to how people work, we need to design IT systems to support the changes we want, rather than work against them. For example, if we want people to collaborate, designing a system that prevents people from sharing information is a non-starter. So we need analysis methods that models the various systems of work-activity, understands the complex purposes of these systems, and defines requirements for the IT system to achieve these purposes. As shown in Figure 2, IS applications support business processes – they do not define them. Too often, IT design is performed in isolation, by technical developers who do not understand how the business works.
Figure 3 presents a revision of Leavitt’s diamond model (Leavitt, 1960), updated for the 2020s. The original model related four aspects of the organization – structure, technology, task, and people – in a diamond model that communicated how changing any of these factors impacted the others. In 1991, Michael Scott Morton updated the model, to place managerial processes at the center, redefining the four “diamond model” factors as structure, strategy, technology, and individuals & roles. Scott Morton also related the organization to the external technological and socioeconomic environment.
Figure 3. Leavitt’s diamond model, Updated for the 2020s
The updated model presented here is my version of this framework. It presents the organization as situated within its environments – business/competitive, global, socioeconomic, and technological – rather than separate from these. Organizations are much more complex than in the 1990s. They incorporate multiple structures and power-centers/roles (management), business strategy cannot be separated from business intelligence, IT is integrated with data management and analytics, and people are identified with the work-activities they perform and the knowledge that they bring to their work. These four aspects of business organization are organized around the flows of high-level business processes that are performed to achieved each of the multiple purposes that the business exists to achieve.
So What?
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.
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 emergent group definitions of the change problem, in tandem with emergent solutions.
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. 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 business managers and stakeholders each understand only a fraction of what the business does.
References
Leavitt, H. J. (1964). Managerial psychology: An introduction to individuals, pairs and groups in organizations. Chicago: University of Chicago Press.
Scott Morton, M. (1991) The Corporation of the 1990s: Information Technology and Organizational Transformation, Oxford University Press.