In systemic thinking, we often debate whether to start with the “big picture” and then decompose the problem situation into sub-problems (the traditional, decompositional approach to requirements analysis), or whether to start with the detailed problems that stakeholders articulate and analyze how these are related (the bottom-up approach). As a systemic analyst, these have always seemed to be two halves of the same approach, so it was interesting to remember my own confusion in the early days of my career when this was not so obvious … 🙂
Systemic analysis can be related to the learning-cycle. There are many variants of this. Dewey introduced the world to the idea that we learn about how the world works through interactions with that world (experiential learning):
‘An experience is always what it is because of a transaction taking place between the individual and, what at the time, constitutes the environment’ (Dewey, 1938, p. 43)
Lewin suggested a four-stage model of experiential learning, that cycles between the concrete and the abstract – this later became known as the “hermeneutic circle” as an individual cycles around these stages of learning, pondering the meaning of what they experience in each cycle, then using this meaning to construct an increasingly complex mental model of the world.
To engage in systemic thinking, we need approaches to analysis that permit us to cycle around these stages multiple times – especially when we encounter new information. In the pages that follow, I explore some methods and techniques used to support cyclical, systemic analysis.
Appreciating The Context of Organizational Activity
Human-centered design requires that we understand – or rather, appreciate – the need for changes to a “real-world” situation that is viewed as a governed by business logic and goals – rather than the engineering logic employed for IT system requirements. The intention is to improve how we understand the need for change – and the systemic impacts of making changes – through an iterative learning process based on Vickers’ concept of Appreciative Systems (Vickers, 1968; Checkland, 2000b).
Geoffrey Vickers observed the diversity of norms, relationships, and experiential perspectives among those involved in, or affected by, a system of human-activity such as that found in business work-organizations. He argued that organizational change analysts needed methods for analysis that explored how to reconcile these perspectives, developing the concept of an “appreciative system,” the set of iterative interactions by which members of an organization explore, interpret, and make collective sense of their shared organizational reality (Vickers, 1968).
The Concept of an Appreciative System
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).
Real-World Analysis Vs. Systems Thinking About the Real World
While both real-world analysis and systems thinking about the real world aim to produce representations of complex situations, the key difference lies in their focus: real-world analysis primarily examines data from actual scenarios to identify patterns of human-activity, relationships between actors, and issues that affect performance, whereas systems thinking takes a broader view by considering the interconnectedness of elements within a system, analyzing how they interact and influence each other to understand the big picture – and to engage in debate about how it may be improved.
The concept of appreciative design underpins Soft Systems Methodology (SSM), an approach devised by Dr. Peter Checkland of Lancaster University in the UK, to capture and make sense of complex change requirements across multiple goals for change and the multiple rationales that underpin any organizational system of work-activity. SSM is now a highly-regarded approach to managing complex change, especially suited to the untangling of “wicked problems” (Rittel, 1972). Its contribution is to separate the analysis of “soft systems” of human-activity – what people do in their work and the logic that makes sense of that activity – from the “hard system” of IT and engineering logic that usually underpins system requirements.
Soft Systems Methodology (SSM)
The development of integrative system thinking methods and analysis techniques to solve ill-structured, “soft” problems is Checkland’s (1979) contribution to the fields of change management and systems analysis. Soft Systems Methodology (SSM) provides a method for participatory design centered on human-centered information systems. The analysis tools suggested by the method — which is really a family of methods, rather than a single method in the sense of modeling techniques — permit change-analysts, consultants and researchers to surface and negotiate feasible aspects of change, to explore and reconcile alternative viewpoints, and to anticipate (to some extent) the knock-on effects of changing one part of a complex system of work on other parts of this system.
Problems are ultimately subjective: we select things to include and things to exclude from our problem analysis (the “system boundary”). But real-world problems are wicked problems, consisting of interrelated sub-problems that cannot be disentangled — and therefore cannot be defined objectively (Rittel, 1972). The best we can do is to define problems that are related to the various purposes that participants pursue, in performing their work. By solving one problem, we often make another problem worse, or complicate matters in some way. Systemic thinking attempts to understand the interrelatedness of problems and goals by separating them out.
In understanding different sets of activities and the problems pertaining to those activities as conceptually-separated models, we understand also the complexity of the whole “system” of work and the interrelatedness of things – at least, to some extent. It is important to understand that, given the evolving nature of organizational work, a great deal of the value of this approach lies in the collective learning achieved by involving actors in the situation in analyzing changes, and that this approach in inquiry is, in principle, never ending. It is best conducted with and by problem-situation participants (Checkland, 2000b).
Summary
To summarize, appreciative design is an approach where emergent perspectives on what a “system” of work should achieve and how that work should be performed are modeled to produce actionable changes to the system that can be evaluated around agreed standards of performance and that preserve desired relationships between human actors and between elements of work-activity and their outcomes. This approach to modeling work-systems influenced the development of Soft Systems Methodology (Checkland, 2000b), a method to operationalize the representation and negotiation of systems of purposeful human-activity around which desirable and feasible changes can be identified and implemented.
References
Checkland, P. (1979) Systems Thinking, Systems Practice. John Wiley and Sons Ltd. Chichester UK. Latest edition includes a 30-year retrospective. ISBN: 0-471-98606-2.
Checkland P., Casar A. (1986) Vickers’ concept of an appreciative system: A systemic account. Journal of Applied Systems Analysis 13: 3-17
Checkland, P. (2000a) New maps of knowledge. Some animadversions (friendly) on: science (reductionist), social science (hermeneutic), research (unmanageable) and universities (unmanaged). Systems Research and Behavioural Science, 17(S1), pages S59-S75. http://www3.interscience.wiley.com/journal/75502924/abstract
Checkland, P. (2000b). Soft systems methodology: a thirty year retrospective. Systems Research and Behavioral Science, 17: S11-S58.
Rittel, H. W. J. (1972). Second Generation Design Methods. Design Methods Group 5th Anniversary Report: 5-10. DMG Occasional Paper 1. Reprinted in N. Cross (Ed.) 1984. Developments in Design Methodology, J. Wiley & Sons, Chichester: 317-327.: Reprinted in N. Cross (ed.), Developments in Design Methodology, J. Wiley & Sons, Chichester, 1984, pp. 317-327.
Vickers G. (1968) Value Systems and Social Process. Tavistock, London UK.
SOFT SYSTEMS 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.
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).
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).
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!).
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 travel
Reduce traffic accidents
Provide easy, safe pedestrian access to stores
Provide safe environment for disabled ppl.
Parking system is self-funding*
Improve air quality: reduce particulate & CO2 emissions
Total Score For Each Transformation
T1: Cars parked in dangerous or thoughtless places cause traffic congestion ➔ Cars parked in safe places ease traffic flows
7
5
4
4
0
8
29
T2: Pedestrians at risk of traffic accidents ➔ Pedestrians can move around safely
2
10
10
10
0
0
32
T3: Free for all parking ➔ Charges for time-limited parking
0
8
8
8
10 x 2
0
44
T4: No parking restrictions ➔ Parking restrictions in place and policed by parking enforcement officers
T4a: No parking restrictions ➔ Parking restrictions in place
0
8
8
7
0
0
23
T4b: No parking enforcement ➔ Parking restrictions policed & fines imposed by enforcement officers
0
8
8
7
10 x 2
0
43
T5: Business access difficult ➔ Business access easy & quick
10
0
10
10
0
0
30
T6: Sidewalk parking presents dangers to disabled people ➔ Sidewalk parking prevented
0
8
8
10
0
0
26
T7: Traffic congestion causes high C02 & particulate emissions ➔ Congestion and emissions are reduced, so people want to spend more time in location
0
0
10
8
0
10
28
* 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
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.
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.
T1
Cars parked in dangerous or thoughtless places cause traffic congestion
Cars parked in safe places ease traffic flows
T2
Pedestrians at risk of traffic accidents
Pedestrians can move around safely
T3
Free for all parking
Charges for time-limited parking
T4
No policing of how long people park
Policing by parking enforcement officers
T5
Business/shopping access by car is difficult
Business/shopping access by car easy & quick
T6
People park on sidewalks when no available parking spaces, forcing pedestrians into roadway & endangering disabled people
Increased parking availability and enforcement of parking regulations leave sidewalks free for pedestrian use & roadways clear of pedestrians
T7
Traffic congestion causes high C02 & particulate emissions
Convenient 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.
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.
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
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 Definitionnames 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)?
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.
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.
Figure 3-3. Sample transformation, demonstrating need to reduce pedestrian accidents due to parked carsFigure 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:
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:
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.
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.
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.
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.
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:
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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. (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.
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 Sciences4, 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.
.
