Category: Co-design of business & IT

The co-design of business & IT systems – i.e. sociotechnical design, balancing the needs of business process optimization and technology design,

  • Design as Bricolage.

    Design as Bricolage.

    When attending a boundary-spanning design meeting the other day, I was reminded of how important pattern sensitization is to design. When we explore a new problem-situation, we structure it according to the patterns that we perceive in that situation. This is why experienced designers are so much better at design than novices. It is not that experienced professionals are sharper, or better at design — but just that they have a wider repertoire of patterns to call upon. As they recognize familiar elements of the situation, they fit partial solutions to those elements. Problem decomposition is not hierarchical, in the sense proposed by Alexander (1964), but convergent. The problem-space and the solution-space co-evolve, as designers explore these in tandem (Maher and Poon, 1996; Maher and Tang, 2003).

    Back to the meeting.
    A group of strategic managers (including the systems people and the business process change manager) were examining how to revise business process support for a routine workflow. The problem that they faced was that this had been adapted by several workgroups (whose representatives were present) over time. So each of these managers had a different perspective of the problem, depending on what each group was trying to achieve. The customer support group were frustrated that they could not access all of the customer information in the system, but had to call another group to obtain missing information. The order-processing group were frustrated that they could not track the progress of an order without having to run three separate IT applications. The sales and marketing group were incensed that not all of the latest products and services were publicized on the website. None of these people – including the IT group managers – could see that these were related problems. They spent hours debating the fields to be displayed on the screens and the detailed reports needed, without realizing that the workflows were related.
    The breakthrough came by accident, when the Process Improvement Manager was mapping the “requirements” on a whiteboard. He started to link two of the requirements, stood back and then said “So this step is also related to this one, isn’t it?” Then the Marketing Manager said “That comes just before the promotions stage.” As the Process Improvement Manager drew a process diagram, each individual kept adding in pieces of the puzzle, with how they were related.

    Design as bricolage.
    Bricolage involves repeated “trying out” and experimentation until a pattern is discerned that is useful. (The word derives from Bricoleur, a French term meaning “handy-man” or “jack- of-all-trades.”) Claudio Ciborra described bricolage as “the constant re-ordering of people and resources that is the true hallmark of organizational change.” 

    Bricolage is based on leveraging the world “as defined by the situation” (Ciborra, 2002).  This process is not random experimentation – it is the construction or creation of a design from the range of available things or ideas. In other words, bricolage is what we do when we call on the patterns – the arrangements of, and relationships between technology, people, and concepts – to which we have been sensitized. There is a fascinating article, just as relevant now as when it was written, that discusses “How The Refrigerator Got Its Hum” (Cowan, 1995). It will come as no surprise that refrigerators hum because …. refrigerators have always hummed.  But it is much more complicated than that. There was a point in time when designers had to make choices about which technologies to use. These choices are embedded in a whole set of assumptions about users, networks of power, and influence.

    Becoming aware of Pattern sensitization adds another dimension to bricolage. It makes us aware of the sources that we use as inspiration. Design can now be seen as an ordering of situation elements until they make sense according to previously encountered patterns. So design is like a jigsaw. Each person carries around a partially-completed set of jigsaw pictures in their heads. The core problem of design is to use a problem-representation that can allow people to communicate the structures in their “mental jigsaw picture” to others.

    References

    Alexander, C. Notes On The Synthesis Of Form. McGraw Hill, New York NY, 1964.

    Ciborra, C.U. The Labyrinths of Information: Challenging the Wisdom of Systems Oxford University Press, Oxford UK, 2002

    Cowan, R.S. 1995. “How the Refrigerator Got its Hum,” in: The Social Shaping of Technology, D. Mackenzie and J. Wajcman (eds.), Buckingham UK: Open University Press, pp. 281-300.
    – You can check this book out of the Internet Archive to read the chapter cited – do look at the other chapters as well, because there are lots of fascinating ideas in this book!

    Maher, M.L., and Poon, J. “Modelling design exploration as co-evolution,” Microcomputers in Civil Engineering (11:3) 1996, pp 195-210.

    Maher, M.L., and Tang, H.-H. “Co-evolution as a computational and cognitive model of design ” Research in Engineering Design (14:1) 2003, pp 47-64.

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

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

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

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

  • Co-Design of Business & IT Systems

    The Co-Design of Business-Process & IT Systems

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

    Goal-emergence in Design

    My research in this area has revealed that design is not the planned, carefully managed process that technocentric project management approaches would lead us to expect. Because design is collaborative and interactive, it proceeds through a series of punctuated equilibrium episodes, where collaborative framing of the situation shapes the solution. Until a critical mass of cognitive dissonance on the part of design participants and stakeholders causes a breakdown in the collaborative agreement (equilibrium) and forces collaborators to complicate their collective framing of the situation. Which, in turn, complicates and redefines the designed solution.

    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. This leads to a complex “parabola of design” as goals evolve with a better understanding. But external stakeholders only see the perceived path of design, shown in the diagram above. So the most frequent comment on design is “what took you so long?”

    Diagram showing parabola of design emergence as a series of successive changes to design requirements are realized and integrated into the design

    Figure 1. Goal-emergence in design

    Boundary-spanning design involves collaboration across organizational domains. Organizational change processes and the design of information systems are situated in wicked problems that confound the definition of requirements for change. The reconciliation of multiple perspectives on “the problem” and the coordination of disparate requirements that are often related to different perspectives require an approach to distributed sensemaking that treats the target system as emergent and involving a distribution of design labor.

    Related Publications

    Gasson, S. (2006) ‘A Genealogical Study of Boundary-Spanning IS Design’, European Journal of Information Systems, Special issue on Action in Language, Organizations and Information Systems. 15 (1), pp. 1-16. http://dx.doi.org/10.1057/palgrave.ejis.3000594

    Gasson, S. (2021) “Managing Boundary-Spanning Cognition Through Emergent Problem-Framing in Enterprise Systems Design” Hawaii Intl. Conference on System Sciences (HICSS-51), Jan. 5-8, 2021. Organizational Systems and Technology (OST), Advances In Design Science Research minitrack.

    Gasson, S. (2008) ‘Goal-Framing and Breakdowns in the Design of Boundary-Spanning Information Systems,’ in: Third Int. Conf. on Design Science Research in Info. Systems and Technology, May 7-9, 2008. Atlanta GA

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

  • Coordination, Cooperation, and Collaboration

    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.

    Work Breakdown Schema, where the work required to achieve a goal is broken down into subtasks, which may be performed by different people without coordination

    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.

    A Collaboration schema, where sub-goals required to achieve the final goal are defined and developed separately, then merged to achieve an integrated outcome )(the final goal)

    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.

     

  • Improvising Design For Emergent Problems

    Improvising Design For Emergent Problems

    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.

  • Designing Social Media Platforms For Online Learning

    Designing Social Media Platforms For Online Learning

    Recently, I have been using a new social media platform to run one of my classes. The idea was, that as we are studying social informatics, we could study the effect of using social media on our own workflows first hand. I also thought that – in these days of daily Facebook and Twitter use – a social media site would add some relevance to the class. My thinking was that the “right-brain” expression that Daniel Pink  extolls as critical to motivation in the 21st Century – the design, narrative, synthesis, empathy, play and sensemaking skills – would be enabled by the use of social media (Pink, 2005). The site has a WIKI, blogs, discussion forums, and an interactive chat facility. I was proposing that we used Google+ hangout for short class discussions by video. For the first week, I set students the task to post to the WIKI, to post to their own blog, to locate some web readings, and to join Google+ if they had not already done so.

    By Thursday (from a Monday start), almost all of the students had posted to the discussion forum. Several had asked me questions by email. But no-one had posted to the Blog or the WIKI. By Friday, two of the more technologically-literate students had made blog posts. But most of the activity was still on the discussion forums – and only three students had provided me with Google+ contact details. Then I started to question my own assumptions. All of the students had used Blackboard for their online course access, which revolves around an asynchronous discussion board. So they were used to interacting via an asynchronous forum. I had assumed that they would be excited to use more “social” media for class interactions or for sharing what they had discovered about the topic. But how did this fit into their idea of how they would behave in an online class? Very badly. Most students sign up for online courses because this provides them with choices about what to do, when. They have a low learning-curve for using a discussion forum. Anything else is hard work.

    Clay Shirky talks about the cognitive surplus that is available from zillions of digitally-literate people with mundane jobs and untapped creativity. He argues that this expresses itself in the groundswell of free, open source software initiatives and in the crowdsourcing phenomenon (Shirky, 2010). But graduate students with a full-time job are already using their cognitive surplus in grappling with new areas of learning. My assumption that they may have some left over for experimenting with social media may be false. The problem is that the learning curve gets in the way of the “right-brain” expression that I wanted to encourage. I may need to rethink how far experimenting with social media is constraining people’s’ ability to express themselves.

    References
    Daniel Pink  (2005) A Whole New Mind: Why Right-Brainers Will Rule the Future. Berkely Publishing: New York.
    Pink (2005) Revenge Of The Right Brain, Wired Magazine, Feb. 2005.
    Clay Shirky (2010) Cognitive Surplus: Creativity and Generosity in a Connected Age, Penguin Press: New York.
    Clay SHirky (2010) An Extract From Cognitive Surplus. Wired Magazine, Business Video, June 16, 2010.
    Clay Shirky and Daniel Pink  (2010) Cognitive Surplus: The Great Spare-Time Revolution. Wired Magazine, June 2010.

  • Organizational Coordination

    Organizational Coordination

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

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

    • Tightly-coupled work organizations rely on well-defined work roles and responsibilities to coordinate tasks across group members. When people in this sort of group have to make decisions, they partition these decisions, based on expertise. Because they all know each others’ capabilities and roles, they don’t have to think about who-knows-what: this is just obvious. This type of organization falls down when people don’t perform their role reliably. For example, if the whole system relies on accurate information coming into the group, someone who misinterprets what they observed can undermine the whole group system.
    • Event-driven organizations rely on external crises and pressures to coordinate group action. People in this sort of group have strongly-defined roles in the wider organization that take precedence over their role in the group — for example in management taskforce groups, business managers tend to prioritize their other work over problems that the group needs to fix. When people in this sort of group make decisions, they partition these decisions according to who-claims-to-know-what, who has time to do the work, and who knows people connected to the problem. They get to know each others’ capabilities over time, but this is a slow process as priorities and decisions are driven by external events, rather than a shared perception of what needs to be done. This type of organization falls down when decisions or actions that were put on a back burner because of another crisis inevitably become a crisis themselves because they were not followed through.
    • Loosely-coupled organizations rely on ad hoc work roles and cooperation among group members. This type of group is commonest in business process change groups, professional work-groups, and community groups, where people are there because they share an interest in the outcome.  When people in this sort of group make decisions, they partition these decisions according to who can leverage external connections to find things out and who has an interest in exploring what is involved. People often share responsibilities in these groups, comparing notes to learn about the situation. This type of organization falls down because it is hard to coordinate. So shared tasks are performed badly because someone knew something vital that they failed to communicate back to the group.
    Why would we care about these different types of organization? Well these structures affect how we approach problem-solving and design. If we (process and IS analysts) need to work with one of the tightly-coupled work-groups, we need to identify who has the decision-making capability for what. It would not occur to a tightly-coupled group member that anyone would not realize who to go to for what. If we need to work with an event-driven group, we have to realize that our work will not be a priority for them -- it must be made a priority by gaining an influential sponsor who can kick a$$ within the group(!).  If we work with a loosely-coupled group, we need to engage the interest of the group as a whole. Working with individuals can lead to failure, as this type of group makes decisions collaboratively, not on the basis of knowledge or expertise.
    Coordinating group work can be like taming wild horses

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

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

  • Design as the Serendipity of Location

    Design as the Serendipity of Location

    I can’t help but reflect on the similarities between research methods, processes and outcomes, and design methods, processes and outcomes. I read an article which argued that there were two types of people: people with tidy offices and people with untidy offices. Tidy-office people are organized and so can find anything they need. These are the people who work top-down, creating an outline then writing or designing according to that scheme. Untidy-office people are disorganized, spend a great deal of time searching for things, but also tend 1 to be more creative because they are inspired by things which they bump into, while looking for other things. These people work bottom-up, assembling elements into a coherent whole. The article argued that there are cognitive rewards in both styles of working, that lead people to subconsciously adopt one or the other style consistently.

    I was reflecting on this as I try to make sense of the piles of material that I have assembled for the book. I am definitely an untidy-office type and I wonder if this has something to do with introvert/extrovert personalities? [My project management students and I just explored an online Myers-Briggs personality test; as expected, I was an INTP type.] Perhaps introverts just prefer a “life of the mind,” where we can construct inductive models of the real world?2

    My semi-organized and shifting piles of research data, models and representations, interim findings, academic articles, and books provide a three-dimensional, systemic representation of design processes that can be reorganized as I comprehend different patterns. Of course, they are both preceded and supplemented by painstaking (and frequently revisited) processes of categorization, synthesis, and validation. But the kaleidoscope of patterns that they reflect is invaluable in suggesting different views of my findings. The same is true for design – we create the patterns that we perceive as relevant in the problem situation. As our perceptions shift, so do the design patterns that we follow.

    I would argue that innovative design is neither deductive or inductive, but consists of cycles of induction and deduction. It follows a hermeneutic circle of sensemaking, as designers attempt to work from an abstract problem to concrete fragments of a solution that solve those sub-components of the problem that they understand, then relate these back to a meaningful, integrated problem definition. This combination of deductive and inductive thinking has been described as abductive reasoning, but reasoning about design is more disciplined and rigorous than most descriptions of abduction [a hunch] would indicate. I prefer Thagard and Shelley’s (1997) argument that hypotheses about reality are layered, incomplete, and too complex to be comprehended easily3. Often, the only way to comprehend complex, interrelated elements of behavior and context is to use a visual, systemic representation and an iterative process of decomposition into parts of the solution that you understand, integration back to a coherent problem-definition, then back to decomposition until the design as a whole makes some sense.

    As someone who has spent a good portion of their career as a systems designer, I have never considered design creative. Design is more about synthesizing from preconceived elements than creating from scratch4. We need to be sensitized to contextually-relevant components of a solution in order to synthesize a design.

    So I wonder if – just as in research – the greatest inspiration in design derives from the serendipity of location? Being in the right place, at the right time, to see elements that can be reused in designing a specific solution to a complex and ill-understood problem.

    Footnotes (click on ↩ to return to post)

    1. If anyone knows the reference for this paper, please let me know. I saw an NYT article on the subject, but I can’t locate the academic paper again – which was published in an information science journal, if I recall correctly … ↩︎
    2. There is a neat discussion of deductive vs. inductive reasoning over at the research methods knowledge base. ↩︎
    3. Paul Thagard and Cameron Shelley (1997) “Abductive reasoning: Logic, visual thinking, and coherence.” Available at http://cogsci.uwaterloo.ca/Articles/Pages/%7FAbductive.html (last accessed 11/27/2009) ↩︎
    4. Like sex, design seems to be 30% inspiration and 70% perspiration … ↩︎
  • Double Loop Learning in Design

    Double Loop Learning in Design

    Double-loop learning occurs when we question the values, assumptions and recipes-for-success that we typically apply to a situation. This type of paradigm-shift is essential when the business environment, or the context of work changes.
    Typically, we learn how to do something well and we keep on applying that recipe-for-success. It is called expertise. We are proud of the knowledge and experience that led to our becoming an expert and so we tend not to question this. But when things change, expertise can become a handicap.

  • Design as a trajectory of goal-definitions

    Design as a trajectory of goal-definitions

    The focus of IS design has moved “upstream” of the waterfall model, from technical design to the co-design of business-processes and IT systems.  This focus requires an improvisational design approach.  IT-related organizational innovation deals with wicked problems. 

    Wicked problems tend to span functional and organizational boundaries as business process and information management problems are intertwined.  There are clusters of interrelated problems:  these cannot be defined objectively because the problem is defined differently, depending on who you ask.  IS designers cannot analyze this type of problem in isolation – we need to involve diverse groups of stakeholders in negotiating suitable problem definitions and boundaries for change.  But wicked problems also involve distributed knowledge, where understanding of the problems is stretched across (rather than shared between) stakeholders. 

    So design goals evolve, as designers and stakeholders learn more about the context and the problems facing the organization by engaging in incremental change.   This is often approached by means of agile design methods. But our lack of understanding about how to establish a “common language” for this type of design means that information system innovation tends to be pretty hit-and-miss. Most design initiatives spend more time arguing about process definitions than achieving change. We need a new approach that focuses on the co-design of business (process) and IT systems: a collaborative process that involves problem stakeholders as collaborators in analyzing change. This is the basis of improvisational design.

    Goal Emergence in Design

    The collaborative design of system solutions for wicked problems seems to follow a trajectory of goals, as the group’s understanding of the design progresses. The key to making (and evaluating) progress is understanding what triggers the changes in goal-direction.

    From my research studies, it seems that goal changes are triggered by breakdowns in individual buy-in to the group’s consensus definition of the design vision. Both the breakdowns and the most important parts of the vision are concerned with how the design problem is structured and defined — not (as we usually assume) how the designed system will work. Of course, the solution is important: individual group members constantly test their understanding of the problem against the emerging solution, then realize that the design goals need to change. But it is the consensus problem-vision that drives design goals.

    An important implication of this design model is how to manage design effectively. We need to keep influential decision-makers in the loop, when design goals are redefined, or they just see the start and end points. The natural response is “what took you so long?”. Managing external expectations is key to design success.

    This blog discusses how we design information system solutions for real-world problems.