Category: systemic thinking

  • Systemic Analysis

    In systemic thinking, we often debate whether to start with the “big picture” and then decompose the problem situation into sub-problems (the traditional, decompositional approach to requirements analysis), or whether to start with the detailed problems that stakeholders articulate and analyze how these are related (the bottom-up approach). As a systemic analyst, these have always seemed to be two halves of the same approach, so it was interesting to remember my own confusion in the early days of my career when this was not so obvious … 🙂

    Systemic analysis can be related to the learning-cycle. There are many variants of this. Dewey introduced the world to the idea that we learn about how the world works through interactions with that world (experiential learning):

    ‘An experience is always what it is because of a transaction taking place between the individual and, what at the time, constitutes the environment’ (Dewey, 1938, p. 43)

    Lewin suggested a four-stage model of experiential learning, that cycles between the concrete and the abstract – this later became known as the “hermeneutic circle” as an individual cycles around these stages of learning, pondering the meaning of what they experience in each cycle, then using this meaning to construct an increasingly complex mental model of the world.

    Stages of the hermeneutic circle of learning: concrete experience, observations and reflections, the formation of abstract concepts and generalizations, testing implications of concepts in new situations,

    To engage in systemic thinking, we need approaches to analysis that permit us to cycle around these stages multiple times – especially when we encounter new information. In the pages that follow, I explore some methods and techniques used to support cyclical, systemic analysis.

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

    Diagram showing investigation of a complex, real-world situation vs constructing models that represent the real world
    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.

  • Soft Systems Analysis – Insights and Supplementary Tools

    Insights on Soft Systems Analysis

    SOFT SYSTEMS are purposeful systems of human activity, that represent how various business processes, groups, or functions work, are organized,and interact. The key idea, as presented by the originator of the approach, Peter Checkland, is to generate multiple views of a situation of interest that reflect the multiplicity of perspectives on what people are trying to achieve. We employ a “divide-and-conquer” approach to modeling each purpose of the larger system separately, exploring its interior logic, problems with how or what activities are performed, and measures or processes for monitoring success of this purpose. This provides us with a set of “sub-system” models of human-activity that can be compared with the real world to define desirable and feasible change, as shown in Figure 1. But it also provides insights into a larger set of activities that can be integrated into a model of the “big picture” system of work (or play) that we are attempting to improve.

    The Process of Soft Systems Methodology (Checkland, 1999)
    Figure 1. The Process of Soft Systems Methodology (Checkland, 1999)

    By focusing on the method – the generation of Root Definitions and Conceptual Models to be compared with real-world-activity – it is easy to miss the small miracle that defining multiple models of relevant purposeful activity systems enables. System requirements methods are almost universally reductionist in nature, striving to merge every struggling purpose of what people do into a “sub-goal” or subsystem of a unifying system goal. SSM, on the other hand, legitimizes diversity of goals. It surfaces all the emergent purposes of work that – in future years, when using traditional requirements analysis methods – will pop their heads above the surface as “bug reports” or “supplementary requirements.” Requirements are multivocal. They fulfill multiple objectives because people are working to rich understandings of work outcomes, not the over-simplistic definition of work outputs that traditional IT requirements analysis produces.

    For example, when I was investigating the requirements for improvements to a UK Charity’s regional store management system, an output that repeatedly reared its head was that the weekly store report should be compiled by 11 am on Friday. This made little sense, until one of the middle managers let slip that the senior Regional Manager played golf on Friday afternoons, so he needed the report an hour before lunch, so he could address any issues and also be familiar with the performance figures before he left for his game. Odd though this seemed, it was an important deadline and needed to be included in the system requirements. I later discovered that the Friday golf game was where the Regional Managers caught up with each other, and with the Chief Financial Officer, to strategize and report on their region’s performance. Understanding this outcome provided context and meaning for the IT system output that the report should be available by 11am on Fridays.

    It is also important to note that individuals develop rich understandings of their work that provide them with multiple purposes for the activities that they perform, even on an individual basis. We are all the products of experiential learning, which produces multiple ways of framing any situation. Sometimes one frame is salient, sometimes another, depending on circumstances. As an instructor, sometimes my effort is focused on grading my students work, normally to a deadline, so I can report on their progress. But at other times, my effort is focused on providing detailed feedback to my students, so they can learn from the work that they did and improve their professional and analytical skills. This is the same activity: grading assignments. But I have (at least!) two purposes in performing that activity. I would judge success differently, depending on which perspective I take at any point in time. The reporting-on-progress perspective always becomes especially salient in the hours leading up to my grade-entry cut-off deadline!

    The ability to generate multiple purposes for a system of work provides an opportunity for brainstorming that is unique in generating perspectives that might otherwise be missed early on in requirements analysis. For example, a rather tongue-in-cheek set of alternative purposes, many of which are complementary, are shown in Figure 2. While many of these may be informal purposes, accidental purposes, or secondary (to the main goal – whatever that may be) purposes, they are purposes of the system of activity that makes up a prison. If we are trying to define requirements for an IT system to support this activity, we need to understand all of these purposes (even if only to control and monitor the less desirable aspects of prison life).

    Multiple root-definitions of a prison system
    Figure 2. A Set of Alternative/Complementary Purposes For A Prison System

    Using Multiple Purposes To Model the Big Picture

    A system of work may be viewed as the combined, purposeful work of multiple individuals who perform parts of the work to achieve a “big picture” goal for an organization. By interviewing those individuals and understanding the multiple purposes they strive to achieve with their work, it is possible to gather a systemic map of purposeful activity for the whole unit, be it a functional department, a specialist workgroup, or a targeted business unit serving a specific market segment. Figure 3 shows the general structure of a Purposeful Human Activity System Model. This structure may apply at the detailed level, to a subsystem purpose, or it may be used to assemble and integrate (co-relate) subsystems in a big-picture model of a business unit purposeful system. In other words, each of the model components (numbered 1 to 7 in Figure 3) might be a single activity, in a Conceptual Model of a single purposeful subsystem of activity, or it might represent a Conceptual Model in its entirety, when these are integrated into a big-picture model of the business department (for example).

    The general structure of a model of a Purposeful Human Activity System, showing interconnected elements, each of which is defined separately
    Figure 3. The General Structure of a Purposeful Human Activity System Model

    This sort of “drill down” and “drill up” modeling allows us to engage in the “zoom-in” and “zoom out” analysis that is required for systems thinking. An example is presented in my analysis of a Market Research field research department (to be added soon!).

  • Wicked Problems Explained

    Wicked Problems, Explained

    Wicked problems are problems that defy definition. They are too complicated for any one person to understand in their entirety, they span organizational and group  boundaries, and call upon knowledge from multiple, specialized areas of work. We only ever understand a small part of what people in other groups and departments do. Solving a wicked problem is like piecing together a jigsaw puzzle — without the picture on the box.

    When faced with uncertainty, we retreat to what we know – knowledge that is based on our own experience. In our day-to-day practice, we develop a repertoire of solutions-that-work, patterns and decision-criteria that fit the problems we face. We know (from research studies), that people try to fit partial solutions, based on this experiential knowledge, to the problems they perceive. When that does not work, they ask colleagues and trusted contacts for a solution. When that does not work, they re-define the problem to fit the partial solutions available to them.

    That is why change management groups get bogged down in political disputes. Managers from one function don’t realize that people from different areas of the business understand their words and ideas differently than they intended. They make assumptions about how these other areas work, based on what they know from their own area. When we extend our personal solutions to fit how people work in other business groups and functions, they fail miserably because, in essence, everyone is solving a different problem.

    In 1973, Horst Rittel and Melvin Webber wrote a paper exploring organizational planning and change-management problems were not amendable to logical analysis techniques. They contrasted “tame” problems, which could be expressed as a set of rules, or constraints, with “wicked” problems, which could not be defined in terms of an algorithm. They defined ten characteristics of wicked problems, shown in Figure 1.

    Ten aspects of wicked problems, discussed in text following
    Figure 1. Ten Characteristics of Wicked Problems (Rittel & Webber, 1973)

    1. There is no definitive formulation of a wicked problem.
    Wicked problems cannot be defined and have no clear boundary. They consist of multiple problem-elements, some of which appear more important to some stakeholders than others, depending on their experience and where they are in the organization. Rittel (1972) argues that we cannot use conventional problem analysis methods, as our understanding of the problem-situation and potential solutions emerge in tandem, through mutual exploration and “argumentation” concerning the nature of the problem and appropriate solutions.

    2. Every wicked problem is essentially unique.

    “… by ‘essentially unique’ we mean that, despite long lists of similarities between a current problem and a previous one, there always might be an additional distinguishing property that is of overriding import­ance. Part of the art of dealing with wicked problems is the art of not knowing too early which type of solution to apply.” (Rittel & Webber, 1973)

    In software design, the idea of not converging on a solution too early is known as avoiding premature design. In management science, the term complexification is used to explain how shared mental models, or frames become more complicated as groups of problem-solvers develop a shared language and pool perspectives on a problem-situation. The iterative processes of perspective-taking (from others in the group) and perspective-making (to improve shared understanding), underpin effective argumentation for wicked problems (Boland and Tenkasi 1995). 

    3. Wicked problems have no stopping rule.
    Because Wicked Problems have no definitive formulation, we cannot define criteria to evaluate when we have a good enough solution. Problem-definitions are negotiated across those involved in the situation to be changed. They incorporate multiple perspectives, some of which become more salient as specific aspects of the situation or its solution are explored, or as various stakeholders attempt to incorporate their own perspectives and agendas for change (Davidson 2002). We don’t know when we are done with this process – we can only judge individually if all the elements we wanted to see in a solution have been included.

    4. Solutions are subjectively good-enough, rather than optimal.
    As there is no clear set of criteria for a solution, we cannot evaluate when we have reached a solution that would “work.” Stakeholder assess­ments of proposed solutions are subjective and negotiated, defined around fit with the framing perspective they adopt, and expressed as ‘good enough,’ rather than right or wrong.

    5. There are no criteria to judge if all solutions have been identified.
    Lacking a definitive problem formulation and boundary, we cannot define any rules or logic to judge whether we have included all the important aspects of the problem in our analysis. Implementing a solution will generate waves of consequences, which may have repercussions that outweigh the intended benefits. We may end up making the situation worse than when we started.

    “The full consequences cannot be appraised until the waves of repercussions have completely run out, and we have no way of tracing all the waves through all the affected lives ahead of time or within a limited time span.” (Rittel & Webber, 1973)

    However, we can explore the knock-on effects of various solution elements by employing a systemic analysis that allows us to analyze the likely impacts of change in conjunction with our emerging understanding of the problem.

    6. Every solution to a wicked problem is a ‘one-shot operation’; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
    Every attempt at a solution changes things, in ways that are irreversible. Once we make changes to the problem-situation, we face a different set of problems. So we cannot plan an incremental set of changes, then reverse course if something does not work. We can attempt to predict the knock-on effects of changes using a systemic analysis, but some solutions may introduce unforeseen consequences, requiring us to start again with a fresh analysis.

    7. Wicked problems do not have an agreed scope, or set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan for a solution.
    Wicked problems tend to span organizational, functional, and management boundaries. So nobody fully understands what the problem is – just the parts that they can see from where they stand. Wicked problem exploration is like assembling a jigsaw puzzle – you get glimpses of a face, or a building, but are never quite sure what the big picture looks like. So solutions are partial and negotiated around “fit” with the emerging problem, rather than any objective definition of scope or legitimacy. We can agree a set of elements we’d like to incorporate into a plan of change, but we don’t know if we understood all the requirements, or if we missed something big. All we can do is to work of collective representations of the problem and debate the expected consequences of solution elements, using representations and methods to explore interactions between the parts.

    8. Every wicked problem can be considered to be a symptom of another problem.
    Wicked problems can be conceived of as “messes” (Ackoff 1974) or “soft systems” of human-activity (Checkland 1999). Because wicked problems are so complex, incorporating multiple chains of cause-and-effect (many of which may have multiple causes) into a coherent representation of the problem-situation is difficult. Problem-components are interrelated: some problems may be causes or symptoms of others, some problems have multiple causes, and some share a common cause. To untangle these problems, the relationships between them – and the consequential knock-on effects of changing part of the system of related elements – needs to be modeled and appreciated. This requires systemic analysis methods.

    9. A wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem’s resolution.
    As discussed above, we need to assess and argue the value of a solution across multiple stakeholders who have differing perspectives on the problem and competing agendas for change. Their perspectives are likely to depend on where they are in the organization, their disciplinary background and education, and their prior experience. Their priorities for change are likely to differ widely according to their group or personal interests and values, and their sensitization to various types of organizational problem and solutions. It is unlikely that everyone will define either problems or solutions in the same way. The process of argumentation used to explore problems mush therefore focus on building consensus, as the way in which the problem is defined tends to direct the type of solution considered. For example, if we define the problem as one of disorganized work processes, an appropriate solution might be to implement a team-coordination system, whereas if we define the problem as a lack of relevant information, the solution would be more likely to focus on an information repository.

    10. We need to involve participants in the situation – and to listen to what they say.

    “Planners are liable for the consequences of the actions they generate; the effects can matter a great deal to those people that are touched by those actions.” (Rittel & Webber, 1973)

    The consequences generated by changes last for a long time. Some of these may be predictable, but because problems are interrelated, some changes may introduce unforeseen consequences. The lives and work of peo­ple involved in the problem-situation are irreversibly changed, and these changes will influence how they work, and what they are able to do (or not do) in the future. The aim is to improve some aspects of the organizational situation, but changes may have unintended consequences that need remediation.

    Conclusion: Wicked Problems Need Exploration, Appreciation, and Systemic Analysis

    Solving Wicked Problems requires appreciation of the problem-situation, accompanied by systemic analysis. Horst Rittel (1972), who originated the term, suggested that we use a process of argumentation to design solutions: “a counterplay of raising issues and dealing with them, which in turn raises new issues, and so on, and so on.” He saw the goal of argumentation as piecing together a big picture from the fragmented viewpoints and problem-definitions held by change-agents, stakeholders, and those people who work in the problem-situation.

    The main thing to note about wicked problems is that they can be defined in multiple ways, which means that various stakeholders will define them differently, depending on their experience and their position in the organization. That means that wicked problems are not goal-oriented, nor are they simple to define. Instead, we need to employ a systemic problem analysis approach to resolve them – one where stakeholders can explore and negotiate the boundary and the elements included in the problem to be resolved.

    References

    Boland, R.J. and Tenkasi, R.V. 1995. “Perspective Making and Perspective Taking in Communities of Knowing,” Organization Science (6:4), pp. 350-372

    Rittel, H.W.J. 1972. “Second Generation Design Methods,” DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.

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

  • Step 5: Implementing Change

    Comparing Conceptual Models To The Real World

    The last stage of SSM is implementing changes to the current ways of working. Although this overview of SSM covers this fairly superficially, this is probably the most complex and political stage of the analysis. The activity stages of each Conceptual Model of “ideal world” activity (one per Transformation) must be compared to real-world activities performed by human actors in the existing system of work.

    At this point, we often realize that two potential transformations have been conflated in our earlier analysis. For example, when the changes for Transformation 4: No parking restrictions ➔ Parking restrictions in place and policed by parking enforcement officers were considered, it became apparent that this transformation contained activities concerned with two separate sets of activity, which achieved different purposes. The first set was concerned with identifying where parking should be regulated (because of congestion or accident locations), setting up restrictions: posting signs, painting road markings, etc., and reviewing how well these are working. The second set was concerned with policing these regulations and financing the system as a whole: ticketing parking offenders, collecting fines, and reviewing how well the system is working. So Transformation 4 was split into two sub-systems of human activity:

    T4: No parking restrictions ➔ Parking restrictions in place and policed by parking enforcement officers
    T4a: No parking restrictions ➔ Parking restrictions in place
    T4b: No parking enforcement ➔ Parking restrictions policed & fines imposed by enforcement officers.

    Each of these sub-systems was modeled using a separate Root Definition and Conceptual Model, each of the latter models was compared with real-world activity separately, to determine what changes to make to the current system of parking in the city.

    Changes to real-world systems of activity must be considered by stakeholders, to determine the priority of various changes, and the feasibility of making each change. Sometimes a compromise must be sought, when changes would disrupt a core business process, or upset key groups of workers, so some changes may not be judged feasible at this point in time. Sometimes, an incremental plan must be derived, where changes are implemented one area of the business at a time, so as not to cause major disruption. For this reason, changes must be prioritized before an order of implementation can be planned.

    Priorities for Change and Implementation Strategies

    As with all approaches to organizational and IT systems change, there are two main planning strategies:

    Incremental change, where changes in each of the various areas of impact (e.g. by functional workgroup or a single, cross-functional business process) are implemented one area at a time;

    Integrative change, where changes required across business functions and areas of impact are prioritized and implemented according to strategic business needs.

    Both types of change rely on prioritizing the areas of impact, one transformation (Root Definition) at a time.

    Integrative Change

    For incremental change, changes will be implented one activity-system at a time, to minimize business disruptions. Changes are defined around a comparison of the “ideal world” Conceptual Model of human-activity to support that transformation and implemented in order of transformation priority. A basic way to prioritize changes is to use a weighted scorecard approach, as shown in Table 1. This starts with the strategic goals of the change initiative, scoring each system perspective against all goals, to prioritize those perspectives (system purposes) that meet most elements of the strategic goals.

    Table 1. Weighted Scorecard Prioritization of Change-Impact Areas

    Strategic Organization Goals

    Relevant systems of human-activity:
    Reduce costs of local travelReduce traffic accidentsProvide easy, safe pedestrian access to storesProvide safe environment for disabled ppl.Parking system is self-funding*Improve air quality: reduce particulate & CO2 emissionsTotal Score For Each Transformation
    T1: Cars parked in dangerous or thoughtless places cause traffic congestion ➔ Cars parked in safe places ease traffic flows75440829
    T2: Pedestrians at risk of traffic accidents ➔ Pedestrians can move around safely21010100032
    T3: Free for all parking ➔ Charges for time-limited parking088810 x 2044
    T4: No parking restrictions ➔ Parking restrictions in place and policed by parking enforcement officers
    T4a: No parking restrictions ➔
    Parking restrictions in place
    08870023
    T4b: No parking enforcement ➔
    Parking restrictions policed & fines
    imposed by enforcement officers
    088710 x 2043
    T5: Business access difficult ➔ Business access easy & quick10010100030
    T6: Sidewalk parking presents dangers to disabled people ➔ Sidewalk parking prevented088100026
    T7: Traffic congestion causes high C02 & particulate emissions ➔ Congestion and emissions are reduced, so people want to spend more time in location0010801028
    * The self-funding goal is weighted at twice the importance of other goals, as the system cannot be implemented without this goal being met.

    For an incremental change approach, the changes required to set to the conceptual model for each transformation would be implemented before changes for additional transformations. Given the scoring for each transformation, shown in Table 1, Transformation 3 wins – mainly because the self-funding aspect is integral to the success of the scheme, so this goal is weighted double the importance of others. The ability for the system to be self-funding also depends on policing, so Transformation 4 is also high priority. The other transformations are prioritized according to how many of the goals each one supports – this is integral to using this type of prioritization method. So the order in which changes would be considered as core requirements for change depends on their being part of the conceptual model for this order of transformations

    T3: Free for all parking ➔ Charges for time-limited parking
    T4b: No parking enforcement ➔ Parking restrictions policed & fines imposed by enforcement officers
    T2: Pedestrians at risk of traffic accidents ➔ Pedestrians can move around safely
    T5: Business access difficult ➔ Business access easy & quick
    T1: Cars parked in dangerous or thoughtless places cause traffic congestion ➔ Cars parked in safe places ease traffic flows
    T7: Traffic congestion causes high C02 & particulate emissions ➔ Congestion and emissions are reduced, so people want to spend more time in location
    T6: Sidewalk parking presents dangers to disabled people ➔ Sidewalk parking prevented
    T4a: No parking restrictions ➔ Parking restrictions in place

    The order of transformations always surprises me, when using a simple prioritization scheme such as this. This is mainly because we have not considered the core values that drive the changes.

    Value-Based Change Prioritization

    For a value-based change prioritization, the core values driving changes to the system of parking regulation are debated and used for explicit weighting of goals before transformations are prioritized. In a sense, we used a value-based prioritization when we defined that the need for the system to be self-funding should be weighted at twice the importance of other goals. But we seldom question “business priorities” as values – these are seen simply as “living in the real world.” For a realistic value-based analysis, we need to discuss the relative importance of each goal. We might weight some goals as “worth” more than 10 points, scoring some (e.g. Reduce traffic accidents, and Provide easy, safe pedestrian access to stores) out of 15 because they represent driving values of the initiative.

    Debate about core values driving the initiative may lead change sponsors and stakeholders to define additional goals that reflect the underlying values left implicit in the original drive to regulate parking, for example supporting a strategic planning goal to make the city’s downtown area more pleasant and pedestrian-friendly, or supporting a financial goal to minimize the legal liability of allowing dangerous parking to go unchecked. The core idea here is debate. As a change agent, it is not your job to define priorities or weights unilaterally; they should be negotiated, debated, and weighted by the key project stakeholders. The resultant priorities may change the order in which changes associated with the conceptual model for various transformations are considered for implementation. Additional goals may even suggest additional transformations (root definitions and conceptual model analysis) that need to be implemented for the project to achieve its aims.

    Integrative Change

    An integrative change planning approach would be used when changes to one area of the business will not achieve the desired effect without commensurate changes to other parts of the business work-system. Changes are first prioritized according to support for goals, then dependencies between changes are considered, to re-prioritize the order of implementation. In the Appendix pages that follow this summary of SSM, some examples are included, to provide more insight on how “ideal world” Conceptual Models are compared to the real world, and how changes are defined for implementation.

  • Step 2: Structure The Situation Around Relevant Purposeful Systems

    Step 2: Structure The Situation Around Relevant Purposeful Systems

    Clarify multiple perspectives on what the system is to achieve or change, using input-output transformation diagrams

    To separate out the various subsystems of activity required, we need to define relevant systems, that represent the messiness of the situation, while reducing the context of human activity to a set of ordered transformations that represent multiple perspectives, defined as purposes of the system. A system of human-activity never has a single purpose. It is tempting to think that it has, because this is what we attempt to define when we define computer-system requirements. If we are honest with ourselves, even a computer system has multiple purposes. One of the reasons that requirements analysis is so difficult is because we do not understand this and we do not separate out the different purposes, but get them confused in our heads. By separating out the various purposes of the system, we can model the requisite activities separately, without worrying about tradeoffs and conflicts between sub-systems (that comes later).

    There are two types of input-output transformation that can be used. The first, shown as Type A below, is more useful for thinking about what needs to change and why, defining what Churchman calls “inquiring systems.”  It explores the gap analysis between the current state and the future state of the system (from a single perspective of why the system exists). Checkland (2000b) argues that this is the more productive of the two ways to conceptualize a system perspective, as it focuses on gaps in system objectives rather than processing resources.

    Type A. Defining Input-Output Transformations As State Changes, to Suggest the Purposes of the System

    Personally, I find the type of transformation shown as Type A to be too focused on the rationale for change and not sufficiently focused on how we need to change things. It is very helpful as the basis of thinking through how change is to be accomplished, but less helpful in analyzing what activities are missing, or need to change.

    A second type of input-output transformation is used to separate our subsets of the human-activity processes (workflow-steps) that need to be performed for different reasons. This type of transformation, shown as Type B, is better for thinking about the lower-level activities as it focuses attention on the sequence of work-activities that turn the inputs into the outputs specified.

    Transformation-Type2
    Type B. Defining Input-Output Transformations As Resource Conversions, to Suggest the Purposes of the System

    The “system” of purposeful human activity is split up into [related] sub-systems of human-activity that reflect separate purposes (or goals). This is done by defining sets of transformations that explain how the system works (input/output) or how it needs to change. Input-output transformation diagrams separate the various purposes of the system of human-activity. They reflect multiple perspectives, so it is a good idea to include as many people as possible, in providing these perspectives. Include people from all levels of management and work, from all areas of the organization (both involved in, and external to, your human-activity system). Look at the system from as many “angles” as possible and attempt to understand them all – once you have defined them, you should present them to the core stakeholders, so that they may decide which of these perspectives are most useful, in achieving the sorts of changes that they need.

    T1Cars parked in dangerous or thoughtless places cause traffic congestionTransformation of inputs to outputsCars parked in safe places ease traffic flows
    T2Pedestrians at risk of traffic accidentsTransformation of inputs to outputsPedestrians can move around safely
    T3Free for all parkingTransformation of inputs to outputsCharges for time-limited parking
    T4No policing of how long people parkTransformation of inputs to outputsPolicing by parking enforcement officers
    T5Business/shopping access by car is difficultTransformation of inputs to outputsBusiness/shopping access by car easy & quick
    T6People park on sidewalks when no available parking spaces, forcing pedestrians into roadway & endangering disabled peopleTransformation of inputs to outputsIncreased parking availability and enforcement of parking regulations leave sidewalks free for pedestrian use & roadways clear of pedestrians
    T7Traffic congestion causes high C02 & particulate emissionsTransformation of inputs to outputsConvenient electric buses & light railways replace need for many car journeys

    Table 1. Input-Output Transformations for Root Definitions of Traffic Calming & Management System

    A set of input-output transformations is given in Table 1, incorporating both types of transformation (Type A and Type B). Some of these transformations may seem contentious, but try thinking about them from the perspective of the “owner”  of the complete traffic management scheme: State or City Government. I have tried to imagine what their objectives would be and therefore to devise a set of transformations which Government officials would choose to leave in the “system”. These diagrams are most useful if the input relates to the output by a simple transformation – if you cannot put a simple name to the “process” by which the input is transformed to the output, then try another input  or output, or try splitting the input-output diagram into two stages.

    Once you have a relatively comprehensive set of transformations that reflect the various purposes of the human-activity system, it is time to define these more fully, as Root Definitions.

  • Step 1: Understand the Problem Situation

    Step 1: Understand the Problem Situation

    Soft systems analysis focuses on how the current system of purposeful human-activity needs to change and why, then breaks this complex analysis down into subsets of change that can be supported by IT systems redefinition. To achieve this, we employ a strategy of “divide and conquer”: we analyze the interrelated systems of human activity that are involved in the area that we wish to improve, then determine change priorities, then define sets of changes to the supporting IT systems. The real difference in perspective is that we need to deal with an increase in complexity to disentangle subsystems that we can improve. The investigator(s), referred to by Checkland and Scholes (1990) as “would-be improvers of the problem situation” try to understand, in as wide and holistic a sense as possible, the problem situation context and content. This can be done by the use of interviews, observations and workshops where organizational actors describe their work and the problems which they encounter. It is important to see this stage as a prelude to expressing the problem situation: a means of moving to a state of affairs where the situation is understood reasonably well and is capable of being expressed in words and diagrams.

    The most critical parts of this step are (i) understanding the relationships, elements, and main activities involved in a problem situation and (ii) deciding a boundary within which the situation can be improved. A rich picture can be drawn, to help analysts and participants to piece the problem situation together, as shown in Figure 1-1. The point of this diagram is to explore various aspects of the situation, without trying to structure or analyze it.

    A rich picture showing the complex problem-context within which parking regulation is required.
    Fig. 1-1. A rich picture showing the complex problem-context within which parking regulation is required.

    In order to make explicit (visible and open to question) the decision on what to include or exclude, we need to include as much information as possible in order to obtain a “rich” (in the sense of full, complete, wide-ranging) picture of how, and in what environment, our system operates. An example for the traffic warden scheme is attached (figure 3, above) – note that, in order to include all aspects of a situation, you cannot represent everything in great detail, or all of the links between aspects of the situation. Just put in the main links and try to include as many points of view as you can. Then work to a set of slightly more structured diagrams, which you can use to make decisions about system boundaries and system interfaces.

    Just drawing these rich pictures makes you (the analyst) think of factors which affect the situation – the more you draw, the more you are stimulated to new ideas by what you have drawn. If you are performing a SSM analysis with a client, ask them to draw pictures. Don’t feel that you have to limit the number of pictures – draw as many as you want, to get a full picture of the situation. Peter Checkland suggests that you draw three different pictures, showing different aspects of the situation:

    The intervention (analysis process) and your role in it: why are you performing the analysis? for whom? with whom? what does your client want to achieve from the analysis (this is very important: what are the goals of your system?) – this information informs your decisions about what to leave in and what to exclude from your system.

    The social context: who are the people involved in the situation being analyzed and how do they relate to each other?

    The political context:
    – Who holds power?
    – Over whom?
    – How is power exerted?
    – How is it resisted?
    – Is the person “in charge” the person who makes things happen?

    These three diagrams are useful if you are analyzing a structured organizational situation. However, don’t draw them too early in the process; try to let your rich pictures be as unstructured as possible, to start with, so that you can examine what is not there at present, as well as what is there. Remember that SSM is a facilitative method: try to persuade organizational actors to draw pictures of their part of the organization (a good way to get them started is to draw part of a picture yourself, then ask them to fill in the gaps).

  • Step 3: Define Root Definitions of Relevant Systems

    Step 3: Define Root Definitions of Relevant Systems

    This stage of the analysis clarifies what the system of human-activity exists to achieve by defining Root Definitions. These definitions separate and clarify different purposes of the system (or mess) of human-activity, allowing you to define what needs to be done by using a “divide-and-conquer” approach.

    Checkland argues that until you have put a name to something, you cannot possibly understand its function or purpose. The Root Definition “names” the system in a structured way. Various subsets of work-routines perform similar activities but for different purposes, with different success criteria and outcomes. Root definitions start with the “purposeful system” transformations from stage 2, then clarify these alternate perspectives on work-system purpose, defining exactly what each activity subsystem needs to accomplish.

    A Root Definition names the system which supports each transformation.

    The important thing is to examine each transformation from one perspective: you can happily repeat the exercise using another perspective, to see if you can integrate the two (sometimes this may not be possible, for example, how do you integrate the needs of drivers in transformation (1) with the needs of pedestrians?). If you cannot integrate competing perspectives, you must take a decision about whose perspective will have prioritythis is where your client’s objectives come into play. In every change, there are winners and losers; your job is to make it explicit who loses and who wins to your client – not to make the decision for them.

    Use the CATWOE framework to produce a Root Definition for each transformation defined in Step 2:

    Customer:Who is the system operated for?
    Who is the victim or beneficiary of this transformation-system?
    Actor(s):Who will perform the activities involved in the transformation process?
    It is important to define a set of people acting in concert. If you have multiple sets of people, this normally indicates that you are confusing two or more transformations.
    Transformation:What single process will convert the input into the output?
    It is important to define a single (not complex) transformation. If you have multiple verbs, this normally indicates that you are confusing two or more transformations.
    Weltanschhaung
    aka Worldview:
    What is the view which makes the transformation worthwhile?
    Understanding this element communicates the real purpose of the system from this perspective, so you should work hard at this part.
    Owner:Who has the power to say whether the system will be implemented or not? (Who has the authority to make changes happen?)
    Environment:What are the constraints (restrictions) which may prevent the system from operating? What needs to be known about the conditions that the system operates under?

    The most important part of the CATWOE is the Weltanschhaung (German term for a particular philosophy or view of life; the worldview of an individual or group). You can just phrase this as “Worldview” if it makes life easier. The Worldview attached to a transformation communicates why it is important to the actors involved to achieve this purpose of the system of work. So we need to explore this in conversations with those involved and work hard at surfacing their rationale for the transformation.

    Minimalist Root Definitions

    When working with business people, it may be difficult (and tedious) for them to define the CATWOE elements for each transformation. In these situations, I use a minimalist root definition, as shown in Figure 3-1. I start with the Worldview: why is this transformation important to achieve the purpose you are aiming for. Then I focus on evaluation of the outcomes: what regulates the process (i.e. what causes you to adjust how you achieve the transformation), and how do you measure success (how do you know if you achieved your purpose)?

    A minimalist transformation process, showing just the actual transformation and the evaluation criteria (what regulates the process and what defines success, in the context of a specific worldview)
    Figure 3-1. A minimalist transformation process

    When deriving Root Definitions, the actual transformation can be elusive. You often need to iterate, redefining inputs and outputs, then trying to surface the context of the definition from the input-output combination that you have defined. For example defining the transformation in terms of “running a parking system” is meaningless. It tells us nothing about what the process is which gets us from cars parked in inappropriate places to cars parked in appropriate places. Similarly, defining the input-output as “illegally-parked cars” and “legally-parked cars” tells us nothing about how illegal and legal will be interpreted by different people involved in the system. You need to either define illegal in your Worldview (e.g. Worldview: “Parking in congested streets causes accidents, so it should be punished by law”) or define the input and output more clearly (i.e. Input = cars parked in congested streets; Output = no cars parked in congested streets). By being precise about terms, everyone involved in the system understands exactly what is involved, what activities need to take place, and how the system’s success can be measured, as shown in the example given in Figure 3-2. Note that the name of the transformation is not yet defined – this should follow from the analysis, rather than constraining what we consider as within scope for this purpose.

    Shows a transformation to bring about a state change between cars badly parked and cars well parked
    Figure 3-2. Root Definition for Transformation (2)

    If we just said Worldview: “Parking should be punished by law”, this does not communicate the perspective of how important it is that this should happen, or why it should happen. However, Worldview: “Parking in congested streets causes accidents, so it should be punished by law” communicates two things – the rationale for prevention of parking (unblocking congested streets) and the reason that the stakeholder wants this as a purpose of the system (to reduce accidents).

    However, the example in Figure 3-2 still conflates two separate purposes: to keep pedestrians safe and to maximize traffic throughput (making access by car easier). These need to be split into two separate transformations. The result is the two transformations shown in Figures 3-3 and 3-4.

    Breaks down transformation 1 to focus on pedestrian safety aspects of parking
    Figure 3-3. Sample transformation, demonstrating need to reduce pedestrian accidents due to parked cars
    Breaks down transformation 1 to focus on congestion-prevention aspects of parking
    Figure 3-4. Sample transformation, demonstrating need to reduce congestion from parked cars

    The transformations are analyzed iteratively, in collaboration with actors and stakeholders involved in the problem-situation, to refine and separate purposes until stakeholders feel that these describe the logic and all aspects of the “root purpose” of the system, from a single perspective. They are then written out as Root Definitions, to formalize everyone’s understanding of each purpose. If possible, stakeholders are encouraged to provide details for the rest of the CATWOE framework at this point, as it is needed for the Root Definitions. If this is not feasible, I usually extrapolate from known information, to fill in the blanks!

    Formalizing Root Definitions

    At this point, the Root Definition can be written out, so that everyone understands exactly why we need the system from this perspective, and what transformation is needed to fulfill the system purpose. For example, the transformation shown in Figure 3-3 (repeated here for clarity) could be expressed as follows:

    Breaks down transformation 1 to focus on pedestrian safety aspects of parking
    Figure 3-3. Sample transformation, demonstrating need to reduce pedestrian accidents due to parked cars

    Root Definition 3-4: A system owned by City Government traffic management division, which polices and penalizes parking that puts pedestrians at risk, because pedestrian safety should have priority over driver convenience and drivers will not consider safety a priority unless they fear punishment. The system will operate under the constraints of powerful drivers’ political lobby groups, who consider unlimited road-use a right, the need for a self-financing system of parking enforcement, and the culture of City Government that ascribes a low priority to pedestrian safety.

    Note that the Worldview expressed in the original transformation of Figure 2-4 has been elaborated and developed substantially during the process of formalizing its definition in this way. The addition of the need for drivers to “fear punishment” in order to take pedestrian safety seriously, and the constraints of financing and the local Government culture, both add to our understanding of what needs to be done as part of the system of work that will achieve this purpose!

    Similarly, the transformation shown in Figure 3-4 (repeated here for clarity) could be expressed as follows:

    Breaks down transformation 1 to focus on congestion-prevention aspects of parking
    Figure 3-4. Sample transformation, demonstrating need to reduce congestion from parked cars

    Root Definition 3-4: A system owned by City Government traffic management division, which polices and penalizes parking in traffic junctions and other bottleneck points, because local businesses require high traffic throughput to be successful and drivers often cause major road congestion that can tail back for several miles by parking at these points. The system will operate under the constraints of limited parking space availability (which requires parking time limits), the need for a self-financing system of parking enforcement, and the need to provide additional longer-term, off-road parking for local business employees.

    Once the root definitions have been defined, it is time to explore how these translate into conceptual models, showing the activities needed to achieve the transformation.

  • Analyzing Problems Systemically

    Problem Cause & Effect Analysis

    Designs often fail to be used as intended because problems are over-simplified. Problem root-causes and their effects are treated as both clearly-defined (obvious) and linear (i.e. a single cause leads to a single effect). This is only true for really structured problems, for example a set of rules to play a simple game like tic-tac-toe. In real life, we face wicked problems, problems that consist of a tangle of other problems, that are defined differently by different people, and that evolve over time as you learn more about the situation. So we get poor solutions that don’t solve the problems we actually face, especially in the design of technology and organizational change.

    Systemic cause & effect analysis explores the complexity of a situation, reflecting the multiple perspectives we encounter and reducing the time needed to learn about how problems “work.” Using problem cause & effect analysis reduces the time needed to understand a problem-situation.

    Modeling Problem Cause & Effect, Systemically

    Systemic analysis means thinking through the system of influences that effect a problem. The point is to draw out all the problems which are communicated to you either directly from comments made by people, or indirectly by your analysis of a problem situation, to determine what causes these problems and what you can affect about them. To achieve a systemic problem analysis, we draw problem diagrams that work from cause → effect (i.e. problem 1 causes problem 2). But instead of limiting the analysis to a single cause or effect, we try to include as many factors as we can. Then we validate these models with the people involved in the situation, asking what elements or connections we have missed.

    It helps to start in the middle. People in any situation will tell you about symptoms not problems, because they don’t stop to reflect on the real causes of things that bug them. So draw these out, then ask them “why does this happen,” and in turn, “why does that happen,” and so on … Keep working backwards until you get to human-nature, or “it’s just like that.” The levels of analysis are shown in Figure 1 to provide a guide to the scope of these analyses – they are there to help you to think about whether you have dug deeply enough into the problem situation. If they don’t help, or if your problem doesn’t fall into such layers, ignore them. We stop when we get to problems such as “it’s human nature,” or “that’s the company culture.” These are things we cannot control, but it’s important to model them so we understand the constraints on solving the problem.

    Typical "levels" of cause-and-effect analysis: 
* business and environment (context) problems
* stakeholder need problems
* symptoms of problems
* consequences of problems
* elements of a solution (including changes to how people work)
    Figure 1: Structuring A Cause & Effect Analysis

    After working backwards, we work forwards until we start seeing the need: fragments of a solution that might comprise part of how to solve our problem. These will often be suggested by the stakeholders – although it is important to note these, they may have a partial and uninformed perspective on how to solve the problem, as they only see those parts of the situation that they encounter daily. In the end, it is by integrating multiple points of view that solutions start to emerge.

    A simple example of a problem cause and effect analysis is shown in Figure 2. It demonstrates how problems involved in managing downtown parking  are related – solving one problem will not resolve all the problems necessary for parking management to work. Instead, we need to understand how problems are related, so we can identify clusters of problems and their symptoms to undermine with solutions. The analyst needs to realize that many problems are just beyond their pay-grade (or are just due to human nature). You need to be able to draw a boundary on any problem analysis, where problems inside the boundary can be attacked – and “external” problems act as known constraints. This is shown by the red line in Figure 2.

    PCE1
    Figure 2: Simple Cause & Effect Analysis

    When modeling problems, bear in mind:
    • Effect-problems may be causes of other problems.
    • By linking problems together, you see which problems are related and where your boundary of action can be.
    • Think backwards, as well as forwards, to brainstorm causes of observed problems.
    • Clusters of problems tend to suggest forms of solution: cause → (effect=symptom/cause) → (effect=symptom/cause) → solution requirements.
    • You need to understand the boundary of what can be affected by your (design) solution and what factors are outside of this boundary.
    • Factors outside of the boundary-line act as constraints on your design, so it is important to note these.

    Issues With Problem Analysis

    1) One of the main issues of problem analysis is that problems are never simple. They don’t tend to be related in straight lines.

    Issues with problem determination #1: problems don't tend to be related in straight lines
    Figure 3. Problem-Elements are Modeled As A Single Chain of Cause & Effect (Straight-Line Modeling)

    2) This is exacerbated by people telling us about symptoms (my disk drive is full), rather than problems (I need a way to share data with someone else -> so we are sharing files via my local disk drive -> so my local disk drive is full as it was not provided for this purpose).

    PCE5b
    Figure 4. Problem-Elements are Modeled Around Symptoms, So They Don’t Explore Root Causes

    3) Problems are over-simplified, as problem-analysts are trained to focus on specifics, rather than to think systemically  (even the problem in Figure 1 was simplified so it would fit into one diagram). Even when you bully them into reflecting a wider scope of analysis, they will artificially constrain this around the problems they understand best.

    PCE5c
    Figure 5. Problem Chains of Cause & Effect Fail To Explore Relationships Between Problem-Clusters and Elements

    4) “Lower-level” problems are related to “higher level” problems, in ways that create reinforcing problem-cycles (vicious circles of causality). You need to be able to take one of these problems out of the loop, so the vicious circle is disrupted, before you can solve the rest of these problems. For example, by defining a problem with work being done as the consequence of a company culture of not employing enough people, you are admitting defeat before you even try to solve the problem by reinforcing the vicious circle of causality. If, however, you define the cause as too few people to do the work required, you have two potential solutions: (i) employ more people, or (ii) reduce the work required. Either of these will break the vicious circle you encountered, without a political battle over company culture(!).

    PCE5d
    Figure 6. Lower-Level Problem-Elements are Related to Higher-Level Problem Causes, Leading to Vicious Circles of Causality That Must Be Broken To Produce A Solution

    5) Finally, many problems are just beyond the problem-solver’s pay-grade (i.e. those that are due to human nature).
    You need to be able to draw a boundary on any problem analysis model, to distinguish problems that are inside the boundary of influence – which can be dealt with – and “external” problems that act as known constraints on the system of work inside the boundary.

    Systemic Problem-Analysis is Complex: Real-Life Examples

    As you work, you will find that problems expand – different people add different perspectives and suddenly, your “simple problem” covers five sheets of paper! Done properly, a problem cause-and-effect analysis can be huge – mine often require piecing together many sheets of paper, as shown in Figure 3. The critical thing is to use the analysis to explore areas of problems, especially where multiple people’s area of responsibility overlap. Then you can define related “clusters” of problems to resolve, as shown in Figure 7.

    PCE4
    Figure 7: Exploring The Problem Situation and Identifying Clusters of Related Problems To Resolve

    We can then dig deeper into just one cluster of problems, uncovering the details of why and how things happen- and defining a boundary for what problems can be tackled:

    PCE2b
    Figure 8: Digging Deeper and Defining The Boundary of What Problems Can Be Tackled

    We can also use the “big picture” problem analysis to identify patterns, such as vicious circles of causality that need to be broken before a problem can be resolved.  Figure 9 shows a real-life analysis, derived from a management workshop.

    PCE3
    Figure 9: Identifying Problem-solving Constraints and Vicious Circles of Causality

    In Figure 9, we can see three separate clusters of problems, each of which relates to a different aspect of change that can be considered (and resolved) separately – even though some of the issues are related.

    • There is a vicious circle of problems bounded in orange which starts with the lack of ownership for order-capture, cycles around three separate branches of the same problem-cluster, then loops back through a time-constraint, to reinforce the lack of ownership.
    • There is a cluster of problems bounded in blue which reflect limitations of the Marketing process – and the siloism of the Marketing function.
    • The cluster of problems bounded in green reflect limitations of the bid preparation and response process (the original focus of this analysis). Its scope reflects only about one-third of the issues that need to be tackled, for bid response to be successful in winning new business.

    It takes quite a lot of modeling, validation with stakeholders, and arrangement of problem-elements to get to this type of “tidy” model. But the understanding that results from this analysis means that obtaining buy-in for change becomes much easier.

    Summary

    The point of drawing a cause-and-effect diagram is:
    (a) To distinguish between cause and effect, so that time and effort are not wasted in solving problems which are just symptoms of others
    (b) To understand (as opposed to just listing!) what are the problems of the situation you are analyzing
    (c) to understand which problems are within your scope of analysis and which problems are “somebody else’s problem”.
    (d)You can draw a system boundary on the problem diagram – a line around those problems that are within your power to influence, but which excludes those which it is beyond your power to influence.

    Don’t over-simplify your analysis or accept “obvious” suggestions for root-causes. People often take a limited view of why things happen in the way that they do, suggesting “symptoms” of problems as the root cause, rather than bending their brains around why things really happen in a certain way. It is better to model everything that stakeholders suggest – or you (the analyst) observe – then split your analysis into clusters of problem-elements to be dealt with separately.

  • The Problem of The Problem

    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.

    The stages of iterative design: identify problem, ideate solutions, prototype designed solution, evaluate de4signed solution in context, explore remaining user needs.
    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.

    Design as improvisation

    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.

    But business applications are not well-structured. They represent wicked problems. A wicked problem cannot be defined objectively, for all the reasons identified in Figure 2. 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.

    Diagram lists the constraints on Design Posed by Wicked Problems
    Figure 2. Constraints on Design Posed by Wicked Problems (Rittel & Webber, 1973)

    A wicked problem can be viewed 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 (2013) 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. (1972) “Second Generation Design Methods,” Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327., Interview in: Design Methods Group 5th Anniversary Report, DMG Occasional Paper, 1, pp. 5-10.

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