Wild horses sculpture at Drexel

Category: problem-analysis

  • Wicked Problems

    Organizational Problems are Wicked Problems

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

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

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

    What are Wicked Problems?

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

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

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

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

    Wicked Problems Require Systemic Analysis

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

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

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

    References

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

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

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

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

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

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

  • 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 priority — this 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.

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

  • Analyzing Problems Systemically

    Analyzing Problems Systemically

    Problem Cause & Effect Analysis

    Problem diagrams work from cause → effect (i.e. problem 1 causes problem 2).
    • 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.
    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.

    PCE1
    Figure 1: Simple Cause & Effect Analysis

    A simple example of a problem cause and effect analysis is shown in Figure 1. 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 1.

    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,” “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 2 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.

    PCE2
    Figure 2: Structuring A Cause & Effect Analysis

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

    PCE4
    Figure 3: 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 4: 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 5 shows a real-life analysis, derived from a management workshop. In Figure 5, it can be seen that there is a vicious circle of problems bounded in red, 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.

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

    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.

    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.

    PCE5a

    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

    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

    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.

    PCE5d

    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.

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

  • Systems Thinking

    Systems Thinking

    Typically, systems requirements analysis fails because of two reasons:

    1. The analysis is not sufficiently systemic – it reduces a complex system down to a subset of activities and work-goals that can be understood.
    2. The analysis is too focused on what can be computerized. It does not analyze what needs to change, but what the IT system should do to support an [implicit] set of changes.

    Why are systems changes counter-intuitive?

    The human mind is not adapted to understand the consequences of a complex mental model of how things work. There are internal contradictions between future structures and future consequences, that become difficult to balance when multiple mental models are involved. Most people are “point thinkers” who only see part of the big picture. It is easy to misjudge the effects of change, when you only base your arguments on a subset of cause and effect. Systemic thinkers analyze interactions between various factors affecting a situation, to understand cycles of influence that affect our ability to intervene in changing the situation.
    An example of counter-intuitive set of influences is shown in the “systemic” view of a limited social welfare system, given in Figure 1.

    Image showing interconnections between elements of local society affected by raising social welfare payments: business attractiveness, response of wealthy, affect on tax-base, and impact of no. of people seeking work
    Figure 1. A Systemic View of A Limited Social Welfare System

    We have two opposing “vicious cycles” of influence, in this model:

    • The left-hand cycle reinforces the argument that raising welfare payments encourages “entitlement” and disincentivizes work.
    • The right-hand cycle supports a counter argument, that raising welfare payments attracts job-seekers and increases employment, raising tax base revenue, to provide a net benefit (as well as humane assistance).

    Unless a complete view of the whole system of interrelated processes is obtained, well-intentioned changes have unintended consequences. It is necessary to understand the system as a whole, rather than individual effects between factors, to understand these “vicious circles” of cause-and-effect. Tweaking one element will affect others, with knock-on effects as the two cycles interact. The only way to ensure a specific outcome is to intervene to break the cycle of influence (change the relationship between factors), or appreciate the interaction effects, so you can predict the outcome.

    In the pages that follow, I explore Soft Systems Methodology (SSM) – an approach that provides a philosophy and a set of techniques for investigating an unstructured problem situation without the constraints and blinkers that come with systems requirements techniques. SSM investigates an organization as a system of work-activities that may or may not require computer-based system support in solving problems with this system of work. Most methods for Information Systems requirements determination place the investigator (the systems analyst) in the role of “expert”. In other words, the analyst attempts to understand the organizational situation, determines what computer system functions are required by interviewing potential system users and/or managers, then draws on their expert knowledge of other computer systems to specify a hardware and software “system”, based upon their understanding of the organizational situation and tasks. If the analyst’s understanding is incorrect or incomplete, this is usually not detected until the system is tested by its organizational users, which may not happen until the system has been installed. This situation occurs because system users do not normally possess sufficient technical knowledge to understand and question the highly-technical system specification documents which the analyst produces, so any misunderstandings are not revealed until the system is built. One way of avoiding this problem is to produce a system prototype, where the system designer builds a trial version of the system for the users to try out. Comments and criticisms are fed back to the designer, who changes the system and produces another prototype; this process is repeated until both designer and users are happy with the system’s operation. However, prototyping is not appropriate for all development situations (such as very large, complex systems, where each user will only understand a very small part of the system’s operations) and also, a great deal of effort in producing and modifying inappropriate prototype systems can be avoided if a more effective investigation is performed into the system requirements in the first place.

    The advantage of SSM in such cases is that it models explicitly the different value-systems (perspectives) of various people in the organization, representing different people’s differing beliefs about the effectiveness and purpose of the organization (or their part of the organization) and their perceptions of current information systems within it. When organizational problems are difficult to define, many problems can be due to work “systems” (for example a department) prioritizing one set of organizational objectives at the expense of another set of objectives. For example, a computer-based system for the authorization of traveling expenses, used by staff in the accounts department may have been designed to reject claims which do not conform to low-cost criteria. Use of this system will force (or “encourage”) staff to use the form of travel which has the lowest cost (e.g. train rather than car) even when the company may lose business by someone not being able to reach a business client before a competitor. The use of SSM for the analysis of requirements for a traveling expenses system would make this conflict explicit, leading to the specification of an alternative system which was able to flexibly approve the expense on the joint criteria of cost and urgency.