5.4 Methodology, method, technique, and tools
As you engage with systems thinking and practice you will become aware how different authors refer to systems methodologies, methods, techniques, and tools, as well as systems approaches. Having just spent some time explaining what I mean by a systems approach, I now want to distinguish between methodology, method, technique and tool.
Several authors and practitioners have emphasised the significance of the term methodologies rather than methods in relation to Systems. A method is used as a given, much like following a recipe in a recipe book whereas a methodology can be adapted by a particular user in a participatory situation. There is a danger in treating methodologies as reified entities – things in the world – rather than as a practice that arises from what is done in a given situation. A methodology in these terms is both the result of, and the process of, inquiry where neither theory nor practice take precedence (Checkland, 1985).
For me, a methodology involves the conscious braiding of theory and practice in a given context (Ison and Russell, 2000). An aware systems practitioner, aware of a range of systems distinctions (concepts) and having a toolbox of techniques at their disposal (e.g. drawing a systems map) as well as systems methods designed by others, is able to judge what is appropriate for a given context in terms of managing a process. This depends, of course, to a large extent on the nature of the role the systems practitioner is invited to play, or chooses to play. When braiding theory with practice, there are always judgements being made: ‘Is my action coherent with my theory?’ as well as, ‘Is my experience in this situation adequately dealt with by the theory?’ and, ‘Do I have the skills as a practitioner to contribute in this situation?’ There are also emotional feelings – ‘Does it feel right?’
Within systems practice, a tool is usually something abstract, such as a diagram, used in carrying out a pursuit, effecting a purpose, or facilitating an activity. Technique is concerned with both the skill and ability of doing or achieving something and the manner of its execution, such as drawing a diagram in a prescribed manner. An example of technique in this sense might be drawing a systems map to a specified set of conventions.
There is nothing wrong with learning a method and putting it into practice. How it is put into practice will, however, determine whether an observer could describe it as methodology or method. If a practitioner engages with a method and follows it, recipe-like, regardless of the situation then it remains method. If the method is not regarded as a formula but as ‘guidelines to process’, and the practitioner takes responsibility for learning from the process, it can become methodology.
In this course you will encounter in some detail the hard systems method (HS-method), the viable systems model (VS-method) and soft systems methodology (SS-method). I will use these abbreviations except when I quote other authors who may refer, for example, to SSM (soft systems methodology) or VSM (viable systems model).
When speaking of SSM, Peter Checkland claims:
One feature never in doubt was the fact that SSM is methodology (the logos of method, the principles of method) rather than technique or method. This means that it will never be independent of the user of it, as is technique.
(Checkland and Scholes, 1990)
From the perspective of this course SS-methodology arises from a particular form of practice using SS-method. The transformation of method into methodology is something to strive for in the process of becoming an aware systems practitioner.
Describe a circumstance in which each of the following could be classified as either a tool, a technique, a method, or a methodology.
(a) Idea generating (sometimes called ‘brainstorming’)
(b) A systems map of the CSA case study
(c) Learning by reflecting on experience
(d) Adapting the HS-method for a new IT development
(e) Checking personal reactions and investments in situations
(a) Idea generating. I do not envisage many situations where I would call idea generating a method, or where I would recognise its use as methodology, though I recognise it could be a component of both. I regard it as either a tool or technique depending on how I experienced it being used by myself or someone else.
(b) A systems map of the CSA case study. I regard this as a tool. With practice it becomes a technique.
(c) Learning by reflecting on experience. My classification depends on how experienced I was at doing this, including the sophistication of my practice.
By sophistication, I mean the extent to which I was theoretically and emotionally informed and aware. Depending on my understanding of these factors, it could be technique, method, or methodology.
(d) Adapting the HS-method for a new IT development. If, in the adaptation, I was able to contribute new insights into the theories of HS-method and also improve my use of HS-method and enhance the IT development, I would regard it as methodology.
(e) Checking personal reactions and investments in situations. I only have enough information to class it as a technique. In use, it could be a method or it could become incorporated into a methodology.
Which of the examples that follow best exemplifies for you the process of contextualising. Give your reasons. Note, I am asking here about the generic process of contextualising, not the more specific case of contextualising a systems approach.
(a) I am preparing a dinner for guests on Saturday. My guests are business associates from the Middle East whom I have not met before. I am renowned for my skills in cooking pork-based dishes so I think I will build my menu around this experience.
(b) I am adept at getting people to contribute creative ideas during a brainstorming session. For this reason, I always start my workshops with a brainstorming session.
(c) I have just finished a Systems course at the OU. Most of my colleagues at work are not really interested in these ideas and don't really understand them but I found a lot of the tools useful in thinking about my own situation. Because of this, I have sometimes suggested using a particular systems diagramming tool when I thought my colleagues would be receptive to the idea.
The final example (c) best exemplifies the process of contextualising. It does so principally because the protagonist understands their own situation – diagramming can be useful for them – but does not seek to impose their latest fad on colleagues. This person is sensitive to their context. In contrast, the protagonists in examples (a) and (b) both impose their experience onto the context. In example (a), this may have disastrous consequences for the dinner party because no allowances appear to have been made for the range of possible diets of the guests.