Category: improvisation

  • The Co-Design of Business & IT Systems

    Multiple Perspectives of “The Problem”

    Modern organizations are complex, and the sorts of problems that remain to be resolved using process redesign, IT systems design, or the combination of both that we call the co-design of business & IT systems can’t be defined around a simple set of issues. There are multiple managers and groups of stakeholders, with competing goals for change. Some of these overlap, some complement each other, and some are in conflict with those of other stakeholders. Even a group of people who work together will have differing requirements and goals, depending on their experience, their professional background, and their position in the organization. People understand the parts of the organization they have experience of. Those who have worked in multiple groups will have a much wider – and more complex – view of what needs to change than those who have worked in the same role for years.

    There’s a management consultancy joke that says if you get five stakeholders around a table, you’ll have at least fifteen different goals.

    The co-design of business & IT systems is like piecing together a jigsaw puzzle without the picture. You get an edge here and there, part of a building outline, or a connecting feature, but mainly you are assembling bits and pieces that are tacked together in whatever way makes sense at the time. Most IT analysts fudge this by merging stakeholder requirements for change under a single, vague business goal. But this doesn’t prevent the shift in focus between multiple objectives that stakeholders prioritize, as these become salient to the current area of design. Change analysts have to understand multiple business domains, as stakeholders’ requirements indicate different types of solution and the analyst attempts to integrate these around a coherent business vision.  Even business managers don’t really understand their processes – and know very little of the processes with which their area of responsibility interfaces. Conflicts, priorities, and omissions in change objectives are seldom realized as the logical analysis methods used for IT requirements don’t provide ways to map out the full scope of change – the big picture.

    We lack ways to represent the big picture of how the organization “works” in ways that would allow business managers to understand the implications of changing things. Business analysts, change managers, and IT systems analysts are in a no-win situation. They are expected to understand myriad interpretations of the business strategy, reconcile conflicting viewpoints on how business processes work, and somehow define a coherent set of change objectives that pleases everyone. All while business managers and stakeholders each understand only a fraction of what the business does.

    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.

    The parabola of process steps introduced by goal emergence in design
    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.

    Changes in business drivers lead to inadequate IT application support. This gap drives strategic business planning, which drives changes to business processes, IT applications, info services, and IT infrastructure
    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.

    Updated version of Leavitt's diamond, relating organizational structures & management, business strategy & intelligence, people, knowledge & work activities, and data analytics, information & technology, to purposeful business processes at the center
    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.

    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.

  • Defining Organizational Problems

    The way in which problems are defined is critical to producing a good enough solution. Most people don’t stop to think about the constraints they introduce to problem-solving by defining problems in a certain way.

    • If you ask how something is done (IT requirements analysis), you get a focus on how a solution can support EXISTING processes. This defines the solution only in the vaguest terms.
    • If you ask what is done, you get a focus on how existing processes could be performed, which allows you to examine alternative ways of working and alternative ways of solving the problem. This approach provides more detail, to define the elements and purpose of the solution.

    In the examples that follow, I use an IT system solution, as this illustrates how solution requirements are missed or constrained by ways of defining the problem.

    Example 1 – Focusing On How (A Typical Mistake)

    Element Description
    The problem of … Order processing is too slow and prone to human error because this is done manually.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Orders are not processed in a timely manner, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to automate order-processing would eliminate errors, provide more time for order processing staff and order fulfillment staff to get on with their work, and increase customer satisfaction, resulting in more business.

    What the system will actually do (its functional purpose) is not defined here – you now need a lot of investigation (and negotiation) to agree what should be involved in automating order processing.

    Example 2 – Focusing On What (Better)

    Element Description
    The problem of … Order processing is too slow and prone to human error because there is no way of recording what has been done, to process an order, and no way of tracking the status of an order.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Orders are not processed in a timely manner, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to record and track order-processing activities would eliminate errors, provide more time for order processing staff and order fulfillment staff to get on with their work, and increase customer satisfaction, resulting in more business.

    This problem definition hinges on what is not being done properly. The functional purpose of the system is defined by the problem definition – all that remains is to determine how this should be performed by people using an information system.

    Example 3a – Focusing On Parts of “What” (Best) – Part 1

    The best way is to define problems around what people need to do, rather than what the IT system does not do, in supporting them. Then you can think really laterally about whether solving this problem requires work-process changes, IT system changes, or both.

    Element Description
    The problem of … Order processing is too slow and prone to human error because staff are not trained in effective work procedures and lack any formal coordination mechanisms to ensure that they understand and follow best practice.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to manage and track order-processing activities would ensure that staff process orders effectively, increasing customer satisfaction and resulting in more repeat business.

    Example 3b – Focusing On Parts of “What” (Best) – Part 2

    Element Description
    The problem of … Order processing is too slow and prone to human error because there is no way of recording what has been done, to process an order, and no way of tracking the status of an order.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to record and track customer orders would flag errors and communicate order priority and progress, allowing problems to be detected before they affect customers.

    Example 3c – Focusing On Parts of “What” (Best) – Part 3

    Element Description
    The problem of … Order processing is too slow and prone to human error because work is poorly coordinated, between departments, and between individual staff.
    Affects … Customers, order processing staff, order fulfillment staff, complaints staff and managers.
    And results in … Customer dissatisfaction – orders are not processed in a timely manner, rush orders are not prioritized, some orders are never dispatched, and some customers receive the wrong items.
    Benefits of a solution … A system to record and target delivery of the information required to process each step of order processing would eliminate errors and communicate work priorities.

    These three problem definitions allow us to specify the (IT system) solution purpose:

    The new system will support order processing and fulfillment activities. Specifically, it will fulfill the following high-level purposes (functions):

    1.The system will coordinate order information between the order processing system and the order fulfillment system, so that orders are scheduled for fulfillment by the expected date of delivery. This is determined by the combination of (i) date of placing order, and (ii) order priority (1-day, 3-day or 4-5 days). Order processing staff will be able to determine and to change the status of an order in case of customer queries.

    2.The system will manage and track order fulfillment processing. The system will signal, through a daily management report and on-screen tracking reports, how many and which orders have not been processed to meet their scheduled delivery date. The main stages of order processing tracked will be: (i) order placement, (ii) order verification against inventory, (iii) customer confirmation of order, (iv) inventory delivery to packing station, (v) order packed, (vi) order delivery to shipping station, (vii) order shipped, (viii) delivery confirmation received.

    3.The system will communicate the information required to process orders effectively. It will provide daily management reports, that summarize the percentage of orders processed on time for expected delivery and that list outstanding orders for immediate action. This report will also be available on request, reflecting real-time order processing and fulfillment status. The system will communicate order processing information to each work-station, on the basis of priority and staff availability.

    Because of their depth, they also allow us to specify the (IT system) solution features:

    The new system will support order processing and fulfillment activities. Specifically, it will provide the following user features:

    1.An order processing staff member can determine the status of an order from customer or order identifying information. A list of recent orders will be presented for selection, if order ID code is not available.

    2.An order processing staff member can change the status of an order (cancel or change priority) in case of customer queries.

    3.A manager can print or view a dynamic order-tracking report. A daily management report will summarize the percentage of orders processed on time for expected delivery and list outstanding orders for immediate action. On-demand reports will summarize real-time order processing and fulfillment status. The user can drill down to locate and see the progress of an individual order.

    4.A manager can view or print the status of work at each stage of order-processing, for each employee work-station. The main stages tracked will be: (i) order placement, (ii) order verification against inventory, (iii) customer confirmation of order, (iv) inventory delivery to packing station, (v) order packed, (vi) order delivery to shipping station, (vii) order shipped, (viii) delivery confirmation received.

    5.Order processing and order-fulfillment staff will receive work-scheduling information at their work-station, that provides them with the information that they need to process the next order, on the basis of priority and staff availability. The information provided will depend on the stage of order processing (see feature 4).

    Validating The System Purpose and Features

    The system purposes can be validated fairly easily – ask people if this is what they need a new system to do!

    System features are more difficult — how do you know if you’ve missed anything?

    • You can use scenarios (paper walkthroughs) to validate sequence of events
    • You can use swimlane diagrams to determine sequence of interactions with system
    • You can use use-case models, to understand detailed system interactions required for each purpose
    • You can use event-lists, to determine if you have included all the processes that you need

    Any of these methods is useless unless validated by people who will work with the system (and their managers).

    © Copyright Susan Gasson, 2014-17. Created 12 December 2014.

  • Improvising Design for Wicked Problems

    Improvising Design for Wicked Problems

    IT-related change in complex business organizations involves the co-design of business (work-activity) systems and systems of IT. These designs emerge, as we learn about the situation as we deal with wicked problems.

    Wicked problems are the type of interrelated, subjective problems that we encounter in organizational change. We can never resolve (or even agree) such complex problems in one go – each stakeholder has a different perspective on what the problems are. As Rittel & Webber (1973) observed, there is no single problem definition – and no stopping point by which to judge if you are finished.

    Goal-based design is a myth. Instead, we face emergent design, comprising cycles of inquiry, systemic analysis, organizational & IT change, and evaluation. The best we can do is to agree a scope for action, analyze the problems within that scope and take action, then evaluate whether we made the situation better or worse. Design is emergent because we constantly need to change our scope and goals, depending on that evaluation – and on changes to organizational goals in response to a changing business environment.

    IT and change management fail when they are managed as if each project is self-contained. Instead, we need to manage these processes as a single cycle in an ongoing process of managing organizational fit with an evolving business environment.

    Emergent Design

    Parabolic trajectory followed by the design process as goals emerge over time

    Explore the co-design of business and IT systems, why wicked problems require improvisational design, and appreciate the history of IS design.

    Systemic Analysis

    Interconnectedness of elements from systems thinking perspective

    Understand what systemic analysis involves and why you need to use it!
    Then explore Soft Systems Analysis, a method for defining change to business processes and IT in tandem

    Human-Centered Collaboration

    Two stick men communicating with metal cans and string

    Appreciate the difference between user-centered and human-centered design, how to design knowledge systems, and how to understand requirements for boundary-spanning systems .

    References

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

  • Chapter 1 of Book Available

    Chapter 1 for Improvising Design book has been uploaded. The first chapter discusses why we need better models and methods for design … and why design is improvisational. Doubtless, stuff will be shifted around a little, as I complete my write-up of research findings chapters. But this is a good introduction to why we need to change our approach to design.

  • Design as the Serendipity of Location

    As I ruminate on design processes, 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 offices1. 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 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 problem to solution and to reconcile those fragments of a solution that they understand back to a meaningful problem definition. The 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.

    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. But I wonder if – just as in research – the greatest inspiration in design derives from the serendipity of location?

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

  • Design as a trajectory of goal-definitions

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