Typically, systems requirements analysis fails because of two reasons:
The analysis is not sufficiently systemic – it reduces a complex system down to a subset of activities and work-goals that can be understood.
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.
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.
Deriving a conceptual model is a method of analyzing the activities which need to take place in order to clearly define what the actors need to do in order to achieve the transformation. Do not include activities performed by anyone other than the actors whom you have named in the root definition (and if possible, limit the actors to one group of people – activity-monitoring becomes very complicated when more than one group are involved). Again, disciplined thinking is required – list the activities needed to achieve the objectives of the system. It is important also to include activities which monitor the system and feed-back results, so that system activities may be performed effectively. Ask: what defines success for this system? how can I measure that success? what do my actors need to do, to measure success?
I have chosen to provide a conceptual model for transformation (7), in the two examples below. The Root Definition for this system is:
A system owned by Local Government Administration, where a combination of parking restrictions, to alleviate congestion at bottlenecks, and public transport provision, to make driving less attractive for short journeys, reduces the number of cars on the road and so improves air quality and traffic flow on major routes.
The list of activities which I perceive as necessary for this transformation are: 1. Determine the extent of the problem (congestion & emissions), by major traffic route 2. Assess potential impact on these factors by managing parking, or implementing public transport 3. Take those actions that produce these impacts 4. Measure the number of people who transfer from cars to public transport 5. Measure the impact upon the environment of that transfer 6. Report to the public on the results.
In Figures 4-1 and 4-2, I contrast a weak attempt at a conceptual model with a strong(er) attempt, for Transformation 7: Traffic congestion causes high C02 & particulate emissions ⟶ Easy and convenient public transport replaces need for short car journeys on local routes.
Figure 4-1. A Weak Conceptual Model for Transformation 7.
The conceptual model shown in Figure 4-1 would be considered weak because each activity in the conceptual model is defined minimally. The activity defines what is to be done (the basic steps of the transformation), but not how to do it so that the purpose of the transformation (the combination of transformation, worldview/rationale, and evaluation of outcomes is achieved. Even the evaluation of the subsystem of activity is minimal, using only a single indicator to evaluate success.has fallen into the “consultancy mode” trap. What I have defined here is not what needs to be done, but how I, as a consultant, intend to find out what needs to be done and then take action. This happens whenever you do not have sufficient information from the stakeholders about what actually needs to be done – so you fudge the set of requisite activities! This is a core part of the “appreciating the situation” work of step 1.
As part of the step 1 analysis, you need to interview as many stakeholders as you can, to gather perspectives and to understand what they would like to happen – and why this system-purpose is important to them. This is often an iterative process: you define a transformation from one perspective, explore what needs to be done to achieve it , then realize that you need more information from stakeholders to understand the “hows” and “whys” of these activities. Having iterated a couple of time, you can then define a much more informed – and feasible conceptual model, as shown in Figure 4-2.
Let us imagine that I have done this – and the core stakeholders suggested two main strategies for achieving transformation (7): – Increase fines for driving offenses and cross-subsidize public transport with the revenue raised. – Make driving more difficult and time-consuming than public transport by rationing road use and policing parking at bottlenecks.
Figure 4-2. A Strong Conceptual Model for Transformation 7.
This conceptual model shown in Figure 4-2 is stronger, as it defines activities in terms of what needs to be done, and how, to achieve the desired purpose of the transformation. Each activity is defined from the worldview of why this transformation is important to the success of the system as a whole (of which it reflects one perspective). At each stage of the sequence of activity, evaluation criteria are considered – for example, when cost-benefit analyses are used to prioritize traffic routes for change implementation. This analysis of activities produces multiple indicators by which we can evaluate success, which allows us to tweak both activities and success criteria, on each cycle around the steps of this subsystem (which would be repeated multiple times, over the duration of the change project).
An important element of conceptual models are the feedback loops. There are normally two feedback loops in any conceptual model: 1. An internal feedback loop, that permits actors involved in the human-activity system perspective modeled to adjust how they perform their work (in this case, this loop is between the first and last “Measure traffic flows, congestion-points, CO2 and particulate emissions, in key places along each route” activities, enabling the state of the system at the start of the activity to be compared to the state of the system at the end of this round of activity). This feedback loop (the dotted line inside the model boundary) permits the people doing the work to evaluate their performance. 2. An external feedback loop, between the inputs and the outputs of the activity system model for this perspective. This feedback loop (the heavier dotted line outside of the model boundary) permits external managers to evaluate the performance of the system from this perspective. To permit the effective management of any system, you need to define measures of success for each transformation-purpose of the system. There is rarely a single measure that will indicate success – instead, use compound measures to evaluate complex outcomes – as shown to the right of the conceptual model in Figure 4-2.
Soft Systems Methodology (SSM) provides a philosophy and a set of techniques – a method – for investigating a “real-world” problem situation. SSM provides an approach to participatory design that focuses on human-centered information systems by analyzing organizations as systems of human-activity. It also provides an excellent method for surfacing multiple perspectives in decision-making, complex problem-analysis, and socially-situated research. 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 explore alternatives for change, while exercising reflexivity in considering the effect of their own prejudices and biases on the analysis.
SSM could be described as an approach to change requirements analysis, rather than a systems design or IT requirements approach. It questions what operations the system-of-work should perform and, more importantly, why. The approach provides a “soft” investigation (into what the system should do) which can be used to precede the “hard” investigation (into how the system should do it). The approach focuses on the investigation of situated problems that may or may not require computer-based system support as part of their solution. It investigates an unstructured problem situation that is viewed as a governed by business logic, rather than the engineering logic normally attached to IT system requirements. Unlike most systems requirements analysis techniques (e.g. UML, entity-relationship modeling or data-flow diagrams), which focus on how the computer system should operate, SSM focuses on the system of work – the “human activity system” that requires computer system support. SSM asks the fundamental question that should (but usually does not) precede system requirements analysis:
“Why do we want a computer system and what role will it perform, in supporting people and organizational work?”
The analysis is based upon a simple concept: that we model systems of purposeful human activity (what people do), separating these out into sub-systems that serve different purposes in order to understand the complexity involved. It models the sequence and interactions of human processes rather than data-management or IT components (the more usual focus of systems analysis). It is systemic, rather than systems-focused, calling upon the tradition of general systems theory (von Bertanlaffy, 1968) and inquiring systems (Churchman, 1971) in acknowledging the disparate elements of a situation. SSM is helpful for analysis approaches that wish to understand the connections, conflicts, and discrepancies between elements of a situation rather than attempting to subsume all elements into a single perspective.
The Origins of SSM
Soft Systems Analysis is 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 we explore, interpret, and mutually construct our shared organizational reality (Vickers, 1968), shown in Figure 1.
Figure 1. 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).
From Appreciative Systems To Soft Systems
Following from his studies of the appreciative systems approach to change and IT requirements analysis, Checkland (1979) focused on the analysis of SOFT SYSTEMS, purposeful systems of human activity that represent how various business processes, groups, or functions work, are organized,and interact. The idea is to apply systems theory to the modeling of organizational work, representing what people do (or need to do, to achieve their goals) rather than losing sight of stakeholder perspectives as we model information or technology architectures.
Soft Systems Methodology (SSM) provides a framework for the analysis of organizational change. It focuses on the human activities required to achieve participant-goals, using a divide-and-conquer approach to manage complexity. The method starts by exploring unstructured representations of the problem-situation in context, then models relevant “systems of human-activity” that achieve purposes valued by participants. Each human-activity system is compared to work activities in the real world, to identify areas where changes could improve outcomes, improve coordination, or otherwise improve organizational work as a whole. The set of changes is prioritized and implemented, then evaluated – after a suitable time-lag – to determine the effects of change and identify aspects of organizational work that might be explored in the next iteration. This process is shown in Figure 1.
Figure 2. The inquiring/learning cycle of SSM (Checkland, 2000b)
SSM provides a way of engaging in joint learning with stakeholders and participants about the problem-situation. It allows all parties involved to understand the implications of achieving various purposes and involves participants in defining relevant work-activities and exploring what needs to change. Initially, the process of inquiry focuses on the real-world problem-situation, exploring how this works using representations such as Rich Pictures, which impose as little structure on what exists as possible. In this way, we get to appreciate how this world “works” rather than viewing it through the filter of the models we construct. Whatever insights a model may give us, it does not represent the real world. Instead, it represents systems thinking about the real world. Checkland (1979) distinguishes between “above-the-linethinking” (about entities, relationships, and activities performed in the real-world situation) and “below-the-line thinking” (which models the potential/ideal-world sub-systems of human-activity required to achieve each separate purpose of the real-world system). Below-the-line thinking produces the “Relevant models of purposeful activity” shown in Figure 2, above. These are separated out, as shown in Figure 3, so we can model and analyze the activities required to achieve each purpose separately.
Figure 3. Contrast between real-world thinking and systemic thinking about perspectives in the real world
The SSM Analysis Process
The point of all this modeling is to provide ongoing cycles of organizational learning. Employing a systemic analysis means that we involve managers and participants in one functional area in modeling and analyzing the enterprise-wide business processes of which their work is a part. Each person gains a view of what others do in the organization, and an interior perspective of others’ problems and priorities. People start thinking in terms of organizational values and interests, rather than their own fiefdoms. The conventional seven-stage model of SSM is shown in Figure 2. A major criticism of this model — later made by Peter Checkland himself — is that it is too linear to represent the actual process of inquiry that SSM requires. Whilst most SSM analysts would accept that, this model provides a useful starting point for novice analysts.
Figure 2. Seven stages of the SSM formal process (Checkland, 1999)
The stages of SSM modeling are described in the following pages. The idea is to represent the problem-situation in ways that make sense to those involved in working there. The method allows us to separate real-world thinking – representing the various purposes that participants ascribe to their work, what they do to achieve these, and what problems they experience – from systems thinking about the real world – tracing how these purposeful systems of work interact, complementing or conflicting with each other, exploring how outcomes are evaluated and which outcomes are not evaluated, and investigating why/how problems occur in the wider scheme of roles, responsibilities, purposes, and coordination mechanisms.
In the pages that follow, I have included some examples of how to produce and use SSM models and processes, to explain the value of exploring problems systemically.
SSM is based upon the idea that we model systems of purposeful human activity (what people do), rather than data-management or IT components (the more usual focus of systems analysis). It is systemic, rather than systems-focused, calling upon the tradition of general systems theory (von Bertanlaffy, 1968) and inquiring systems (Churchman, 1971) in acknowledging the disparate elements of a situation. SSM is helpful for analysis approaches that wish to understand the connections, conflicts, and discrepancies between elements of a situation rather than attempting to subsume all elements into a single perspective.
Soft Systems Methodology (SSM) was devised by Peter Checkland and elaborated in collaboration with Sue Holwell and Jim Scholes (among others) at Lancaster University in the UK. SSM provides a philosophy and a set of techniques for investigating a “real-world” problem situation. SSM is an approach to the investigation of the problems that may or may not require computer-based system support as part of its solution. In this sense, SSM could be described as an approach to early system requirements analysis, rather than a systems design approach. This website attempts to explain some of the elements of SSM for educational purposes. It is not intended as a comprehensive source of information about SSM and may well subvert some of Checkland’s original intentions, in an attempt to make the subject accessible to students and other lifelong learners … .
.