SSM – The Method

The conventional seven-stage model of SSM is shown here. 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 1. The Seven-Stage, Soft Systems Methodology Approach

Step 1: Understand the Problem Situation

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

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

Figure 2. A Rich Picture, Showing the Complexity of Parking Enforcement

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 2: Structure The Situation By Defining Relevant Purposeful Systems

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

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.

Figure 3. Defining Input-Output Transformations, to Suggest the Purposes of the System

A set of input-output diagrams is given in Figure 3 (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.

Step 3: Clarify what the system exists to achieve by defining Root Definitions of relevant systems of activity

This is achieved by defining root definitions, that describe all aspects of the “root purpose” of the system, from a single perspective. The formal SSM method uses the CATWOE framework, to produce a complete Root Definition for each transformation defined earlier. 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 4.

Success measure = what a successful transformation will achieve (measure for evaluation)
Worldview = how the world works and why this improvement is worth achieving

Figure 4. A Minimalist Root Definition, Used Where Defining CATWOE Elements Presents Barriers to Working With Stakeholders

The most important part of the CATWOE is the Weltanschhaung(W), as this communicates why we want to achieve this purpose of the system. So we need to work hard at communicating a rationale for the transformation. If we just said W: “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, W: “Parking in congested streets causes accidents, so it should be punished by law” communicates two things – the rationale for prevention of parking in congested streets and the reason that the stakeholder wants this as a purpose of the system. Defining the worldview that makes a transformation meaningful, in combination with the success criteria as shown in Figure 4, provides a “minimalist” Root Definition.

Root Definition for Transformation (2)

Pedestrians at high risk from car accidents

Â

Pedestrians at low risk from car accidents

Weltanschauung: Pedestrian safety should have priority over driver convenience and drivers will not consider pedestrian safety unless they fear punishment.
Success criteria: Reduce accident rate by at least 50% over 5 years  Environmental pressure to decrease car emissions Decrease in car emissions because number of cars is reduced

Root Definition: A system owned by City Government representatives, which 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 and the culture of City Government that ascribes a low priority to road safety.

Root Definition for Transformation (7)

Environmental pressure to decrease car emissions

Â

Decrease in car emissions because number of cars is reduced

Weltanschauung: The number of cars on the road is directly related to environmental degradation and public health problems. Reducing the number of cars reduces emissions, which in turn improves public health.
Success criteria: Reduce car emissions by at least 50% over 5 years

Root Definition: A system owned by State Government, which makes driving less attractive than public transport on behalf of Environmental Lobbyists among the public because the number of cars on the road is directly related to environmental degradation and public health problems, but limited by the need to find alternatives to financial incentives alone and the power of drivers’ lobby groups.

Stage 4: Deriving Conceptual Models

Deriving a conceptual model is a method of analyzing the activities which need to take place in order to clearly define what the actors need to do in order to achieve the transformation.  I have covered conceptual modeling in more detail – I present an overview here. First, the activities are defined, then a model is produced that shows how these activities feed into each other.

For example, the activities required for Transformation 2 (above) are:

1. Determine places where parking causes danger to pedestrians.
2. Designate and sign those places where parking is not permitted.
3. Monitor parking in those places.
4. Record drivers parking in those places.
5. Collect fines from punishment.
6. Fund the additional monitoring with collected fines.
7. Measure the number and locations of pedestrians involved in accidents.
8. Assess the impact upon pedestrian safety
9. Report to the public on the results.

These activities build into the following conceptual model:

Figure 5.  A Conceptual Model, Which Shows All Required Activities To Operate The System From The Perspective of Transformation (2)

Do not include activities performed by anyone other than the actors whom you have named in the root definition (and if possible, limit the actors to one group of people – activity-monitoring becomes very complicated when more than one group are involved). Disciplined thinking is required – list the activities needed to achieve the objectives of the system and split off other objectives into separate root definitions.

It is important to include activities which monitor the system and feed-back results, so that system activities may be performed effectively. There are normally two feedback loops in any conceptual model:

• An internal feedback loop, that permits actors involved in the human-activity system perspective modeled to adjust how they perform their work (in this case, this loop is between the “Assess” and “Determine” activities).
• An external feedback loop, between the inputs and the outputs of the activity system model. This permits managers to assess and manage the system of activity as a whole. (This loop is indicated by the dotted lines on the model).

To permit the effective management of any system, you need to define a measure of success for a particular transformation. This is shown below the conceptual model in Figure 7.

Stage 5: Comparing Conceptual Models With The Real World

One of the best things about SSM is that you are never allowed to forget that your model does not represent the “real world”.  So what does “system thinking about the real world” (your set of conceptual models) represent?

Best case: your models represent a more effective way of achieving the work goals, based on how the core stakeholders perceive that the system of human activity should take place.

Worst case:  your model automates what’s there now – the manual system, or worse still, the current computer system (if the current computer system is so effective, why do you think they called you in to investigate how it could be replaced?).

Consider how far your model lies between either of these extremes (nobody’s perfect). Validate conceptual models by presenting them to stakeholders and asking for feedback. Once you are happy with them …

…  The purpose of all this activity is not to just draw pretty pictures, but to provide a solid set of prioritized recommendations for what changes need to be made to existing activity systems (which is a prerequisite for defining what information systems are needed to support those changed systems!). Figure 6 represents the process of SSM analysis (from a “what is modeled” perspective, rather than the seven stage process model). Once you become practiced with the approach, you will notice how useful it is to include social and political aspects of the problem situation in your analytical models.

Figure 6.  What Aspects of the Situation Are Modeled Using An SSM Approach

Now our task is compare system models of the real world with what happens in the real world. It is helpful to involve participants in this process.
To continue our example, taking system transformation (7), we can observe that:

1.  Driving is less expensive that public transport. Action = determine the extent of cross-subsidy required and implement it.

2.  There is no road rationing system in place. Action = implement a road rationing system.

3.  We have no effective way of gathering statistics on road use vs. use of public transport. Action =  put information gathering mechanisms in place.

 

Stage 6: Analyzing Feasible And Desirable Change

At the end of the day, you will (probably) not be the person implementing the changes that you suggest. The system owners and actors – the people involved in the system – have to live with these changes and make sure that they are happy with them and consider them appropriate.

There are three elements that need to be considered: Feasibility, Priorities and Risk

Feasibility

In the course of your analysis, you will have come to understand a great deal about how the various activities are performed. Make sure that you write down which changes are feasible and which are not (and why), so that this understanding is communicated to the people who inherit your analysis.

Consider:

• Cultural feasibility: what is acceptable to the people working in this part of the organization (from their perspectives).
• Technical feasibility: what it is appropriate to support with computer technology and what should be left as a manual process – as well as what it is possible to computerize.
• Dependencies between work-systems and between technical systems. Sometimes it is necessary to complete one set of changes before another set can take place.
• Win-win: does the change make life easier for people. If you are recommending that people perform six steps instead of three, to accomplish a task, perhaps you should reconsider? If people’s lives are made more difficult, they will resist change and probably find ways to sabotage it. It makes sense to define changes that the people involved in the activity system will accept. Perhaps you need to find ways of compromising, so that everyone wins by the changes that you propose.

Priorities

Prioritizing changes is one of the most important tasks in the whole analysis. One way of prioritizing change is to use a balanced scorecard approach, as demonstrated here:

• Assign each system ALTERNATIVE a score out of 10, depending on extent to which it helps the system solution achieve a main goal or solve a main problem.
• Weight the scoring (e.g. score goal achievement out of 10 and problem solution out of 5, or vice versa, depending on whether you are there to make the organization more effective, or  to solve a set of pressing problems, OR BOTH!).

The changes with the highest scores should take the highest priority for implementation. However, you also need to consider feasibility and risk, when determining priorities. (You could make the table bigger, to assign each change a score for feasibility and a score for risk).

Risk Analysis

** Highest scores indicate risks/benefits that need managing carefully
* Starred activities require an evolutionary or experimental prototyping approach

Stage 7: Taking Action

At the end of the day, you will (probably) not be the person implementing the changes that you suggest. Bear in mind that the people involved in the system have to live with these changes and make sure that they are happy with them and consider them appropriate.

When implementing change, consider two cardinal rules of change management:

1. Do not try to change everything at once. Plan a set of incremental changes and reassess the need for change after each one has been implemented.
2. Involve the people actually working in the activity system. If you do not get their ownership and buy-in to the changes, it is likely that these will be a dramatic failure.

End Note: Defining IT Requirements Using SSM

You’re probably thinking – OK, I got this far, but how does this relate to computer system requirements? These are just the initial actions for change. Once these mechanisms are in place, we can start to determine a set of detailed requirements for computer support. But unless we understand the details of all this stuff – the multiple purposes that the work-systems (the various human-activity systems represented by each conceptual model) exists to fulfill, the rationale behind these work-systems and the ways in which performance and success are measured, there is no way that we could define requirements for a computer system to support these work activities.

These steps depend on iterations of determining what is not done (or not done well), what is not communicated in the way required (i.e. information-flow between activities is missing), or what is not monitored appropriately. The success measure defined for each transformation should be monitored, as shown in the conceptual model above. The blue activities in the conceptual model represent activities that are not currently done. This is where feasibility is considered: how and can these activities be performed effectively? What should be fixed first? The “take corrective action” activity is complex and may suggest a new transformation that needs to be modeled as a whole, or it may relate to another transformation that was already modeled. To analyze priorities for change (and to analyze missed synergies between the subsets of activity), we can assemble a “bricolage model” from various transformations.

Each process in model above represents the T from a single Transformation (purposeful sub-system), as modeled in step 2. When we assemble the system of systems, we have the requirements for an integrate IT system to manage the complex situation. Each of the conceptual models can easily be modeled as a use-case, to define system requirements in detail.