Category: wicked problems

SSM: A Summary

SSM As an Iterative Inquiring/Learning Cycle of Change

SSM is based upon a simple concept: that we separate and analyze systems of purposeful human activity (what people do), rather than data-processing or IT systems (how IT components should function to support what people do). 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. It is systemic, rather than systems-focused, exploring relationships between participants and between perspectives (Checkland, 2000a).

Separating Out Purposeful System Perspectives

SSM relies on the explicit declaration of worldviews which make each purposeful system model meaningful to participants. In defining purposeful models, the Soft Systems Method (SSM) avoids what Russell Ackoff (1974) called “messes”: the typical situation where none of the requirements for change are understood or implemented fully, because the relationship between requirements is systemic (each requirement has “knock-on” implications for other requirements). Unraveling systemic messes needs a divide-and-conquer approach that separates out the requirements for each separate purpose that the system-of-work exists to achieve, as shown in Figure 4. We delay this stage until we have a reasonable understanding of the problem situation: what various actors do, why they do it, and how they interact to achieve their purposes.

SSM transformation process overview, showing key elements: input, transformation, output, worldview, and success criteria — Figure 4. SSM Transformation Process Overview

Generating one perspective on the work-system at a time allows us to analyze what work-activities need to be done to achieve a single purpose — and how actors’ work-outcomes are evaluated — in isolation from all the other purposes, before merging perspectives back into a (better understood) integrated system-of-human-activity so we may determine priorities for change. This divide-and-conquer strategy employs the CATWOE framework to define each perspective (or purposeful system):

Client	Who is the victim or beneficiary of these changes?
Actors	Who performs the work for this transformation?
Transformation	How is an entity, the input to the transforming process, changed into a different state or form to become the output of the process?
Weltanschauung	What is the perspective that makes the transformation significant to participants (the purpose)?
Owner	Who has the power to say whether the system will be implemented or not?
Environment	What needs to be known about the environmental conditions that the system operates under?

Table 1. The CATWOE Framework

Complex transformations should be separated into distinct purposes, with a single set of actors. It is usually an indication that you have conflated two purposes if you have two different sets of actors involved – you will tie yourself in knots attempting to model both points of view at the same time. You can happily repeat the exercise using another perspective, to see if you can balance the needs of two purposes with the same system, but conflating perspectives often leads to change requirements being overlooked. Sometimes it may not be possible to balance two perspectives – for example, how do you integrate the needs of drivers to park easily with the needs of pedestrians to be kept safe in congested areas? 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, rather than to make this decision for the client (!).

Defining and Prioritizing Requirements For Change

Once each transformation is defined, it can be explored in terms of the potential sequences of activity needed to achieve that purpose. Participants and other stakeholders are involved in developing conceptual models that reflect “ideal world” sub-systems of activity. Not all of these activities may be implemented – or they may not be implemented in the way originally envisaged. Subsequent changes to the real-world system of work are evaluated by managers and the client of the change initiative, to determine the order and priorities for change. But it is important to understand what work needs to be done, so you can consider constraints on achieving the desired outcomes should your client not choose to implement some process-changes. Actions to improve the problem-situation are based on finding accommodations that balance the interests of competing perspectives. This involves defining versions of the situation which stakeholders with competing interests can live with (Checkland, 2000b).

In much of his later work, Checkland addresses the difficulty of converting a model that represents a system of human activity into a set of requirements for an IT-based information system by distinguishing between the supporting system (IT) and the supported system (human activity). The supported system represents the problem domain, the amalgam of purposeful systems of human activity that underpins the problem situation. The supporting system represents the solution domain, that combination of people, processes, and technology that provides a solution to problems identified by participants in the problem situation.

Fig 4. The supporting system of IT vs. the supported system of human activity

Reconciliation between the two system views depends on the translation of requirements for change to the human-activity system to IT system requirements. If these changes are undertaken incrementally, with a focus on a single purposeful system perspective at a time, this is generally fairly simple to accomplish – it aligns well with the business-process (re)design approach used by most organizations in driving IT change.

The Contribution of SSM

Soft Systems Methodology (SSM) was devised by Peter Checkland and elaborated in collaboration with others at Lancaster University in the UK: (Winter, Brown, & Checkland, 1995; Checkland & Scholes, 1999; Checkland & Holwell, 2007; Checkland & Poulter, 2006). Its contribution is to separate the analysis of the “soft system” of human-activity from the “hard system” of IT and engineering logic that serves the needs of the human-activity system.

Checkland distinguishes between the hard, engineering school of thought and soft systems thinking. The development of systems concepts and system thinking methods to solve ill-structured, “soft” problems is Checkland’s (1979) contribution to the field of systems theory. Soft Systems Methodology (SSM) provides a method for participatory design centered on human-centered information systems. It also provides an excellent approach to 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 exercise reflexivity and to explore alternatives. In his valedictory lecture at Lancaster University, Peter Checkland listed four “big thoughts” that underlie soft systems thinking (Checkland, 2000a):

1. Treat linked activities as a purposeful system.

2. Declare worldviews which make purposeful models meaningful (there will be many!).

3. Enact SSM as a learning system, finding accommodations enabling action to be taken.

4. Use models of activity systems as a base for work on information systems.

Systems thinking attempts to understand problems systemically. Problems are ultimately subjective: we select things to include and things to exclude from our problem analysis (the “system boundary”). But real-world problems are wicked problems, consisting of interrelated sub-problems that cannot be disentangled — and therefore cannot be defined objectively (Rittel, 1972; Rittel & Webber, 1973). The best we can do is to define problems that are related to the various purposes that participants pursue, in performing their work. By solving one problem, we often make another problem worse, or complicate matters in some way. Systemic thinking attempts to understand the interrelatedness of problems and goals by separating them out.

In understanding different sets of activities and the problems pertaining to those activities as conceptually-separated models, we understand also the complexity of the whole “system” of work and the interrelatedness of things – at least, to some extent. It is important to understand that, given the evolving nature of organizational work, a great deal of the value of this approach lies in the collective learning achieved by involving actors in the situation in analyzing changes, and that this approach in inquiry is, in principle, never ending. It is best conducted with and by problem-situation participants (Checkland, 2000b).

SSM is an approach to the investigation of organizational problems that may – or may not – require computer-based system support for their solution. In this sense, SSM could be described as an approach to generating early requirements for change analysis, rather than as a systems design approach. The original, seven-step method of SSM (Checkland, 1979) has been replaced by more nuanced approaches to soft systems analysis (note the loss of the word “method”). Checkland now considers the approach more of a mindset, or way of thinking than a strict set of steps that should be followed (Checkland & Holwell, 1997). However, without the roadmap provided by the seven stages of analysis, it can be difficult to understand where to start. For this reason, the discussion on this site employs the terminology and approach of the seven-stage method originally proposed, while attempting to iron out some of the complexities and confusions in the original (Checkland, 1979).

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, but as a reflection of my own tussles with the approach.
As a result, it may well subvert some of Checkland’s original intentions, in my attempt to make the subject accessible to students and other inquiring minds … .

Note [1]: Weltanschauung is a German word, used in philosophical works to represent a particular philosophy or view of life, especially when analyzing the worldview of an individual or group. Checkland (1979) adopted the term in its philosophical sense when he was making the argument that the purposes for which a system of human-activity (or work) exist are situated within a specific sociocultural framework of rules and expectations that govern who-does-what and how. The idea is similar to Anselm Strauss’ concept of social worlds, where participants draw on experience-based interpretations, culturally-situated, relational identities, and shared interpretations of organizational structures that allow them to respond automatically to new phenomena and events (Strauss, 1978). The term “worldview” may be substituted, with the understanding that this reflects the broader use of the term to indicate socioculturally-situated interpretations, not simply an individual’s point of view.

References

Ackoff, R. L. (1974). Redesigning The Future: Wiley.

Checkland, P. (1979) Systems Thinking, Systems Practice. John Wiley and Sons Ltd. Chichester UK. Latest edition includes a 30-year retrospective. ISBN: 0-471-98606-2.

Checkland P., Casar A. (1986) Vickers’ concept of an appreciative system: A systemic account. Journal of Applied Systems Analysis 13: 3-17

Checkland, P., Holwell, S.E. (1998) Information, Systems and Information Systems. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-95820-4.

Checkland, P. & Scholes, J. (1999) Soft Systems Methodology in Action. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98605-4.

Checkland, P. (2000a) New maps of knowledge. Some animadversions (friendly) on: science (reductionist), social science (hermeneutic), research (unmanageable) and universities (unmanaged). Systems Research and Behavioural Science, 17(S1), pages S59-S75. http://www3.interscience.wiley.com/journal/75502924/abstract

Checkland, P. (2000b). Soft systems methodology: a thirty year retrospective. Systems Research and Behavioral Science, 17: S11-S58.

Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its Use, for Practitioners, Teachers and Students. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-470-02554-9.

Churchman, C.W. (1971) The Design of Inquiring Systems, Basic Concepts of Systems and Organizations, Basic Books, New York.

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.

Winter, M., Brown, D. H., & Checkland, P. B. (1995). A role for soft systems methodology in information systems development. European Journal of Information Systems, 4(3), 130-142.

von Bertanlaffy, L. (1968) General System theory: Foundations, Development, Applications, New York: George Braziller, revised edition 1976.

December 27, 2014

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.

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.
December 7, 2014
Soft Systems Methodology (SSM)

Intro to Soft Systems Methodology

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-line thinking” (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 … .

References

Checkland, P. (1999) Systems Thinking, Systems Practice: includes a 30-year retrospective. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98606-2.

Checkland, P. & Scholes, J. (1999) Soft Systems Methodology in Action. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-98605-4.

Checkland, P., Holwell, S.E. (1997) Information, Systems and Information Systems. John Wiley and Sons Ltd. Chichester UK. ISBN: 0-471-95820-4.

Checkland, P., Poulter, J. (2006) Learning for Action: A Short Definitive Account of Soft Systems Methodology and its Use, for Practitioners,

Churchman, C.W. (1971) The Design of Inquiring Systems, Basic Concepts of Systems and Organizations, Basic Books, New York.

von Bertanlaffy, L. (1968) General System theory: Foundations, Development, Applications, New York: George Braziller, revised edition 1976.

December 6, 2014