The Systems Practice course defines these operational terms for the creation of a system map or in the early stages perhaps more like creating pieces of a puzzle. Unfortunately, these operational terms are not defined as adequately or precisely as they might be so what follows is my interpretation of them. The understanding of each concept can be dependent upon the understanding of other concepts, often introduced later in the course, ideally creating a holistic perspective by the end.
In Systems Practice a factor, according to Rob Ricigliano the course instructor, is "something, a person, an environmental condition, an attitude, an institution, a phenomenon, etc., that makes other things happen or has agency."
The first step then in the Systems Practice mapping process is brainstorming as many factors as possible related to the system under review, based on the previously established mission focus through the Guiding Star, Near Star and Framing Question created prior by the group.
A Google spreadsheet, such as Factors Themes Grouped used with the Plastic Pollution in Thailand project can be provided to collect the team member’s suggested factors for the system. The Google sheet created for the Plastic Pollution project consisted of six columns. Who suggested the factor, the factor itself and the four different forms of categorization that could be applied to those factors.
- Author
- Factors
- Inhibitor/Enabler
- Themes
- Upstream or Downstream
- S.A.T.
What the Systems Practice course calls factors Kumu systems mapping calls elements and they are by default the filled circles on a map which can be sized and colored as desired (or even made different shapes or images). Kumu elements are the visual graphic representation of Systems Practice factors. This involves another transition in thinking, moving from text-based linear, what I have labeled longitudinal thinking to graphics based latitudinal thinking which can be more holistic but still requires certain rules to be followed based on Systems Thinking concepts.
Our Jerusalem Vision team began expressing some of the factors, or influences or as the course termed it "forces" that affect the system. The collected factors are also considered as “drivers” by the Systems Practice course. A driver is the idea of one factor or thing changing or causing an effect to another thing.
Our approach was endeavoring to understand the forces that constitute the system in its present form, in this case, Jerusalem, not to try to reconfigure the system or targeting certain factors to change into the shape we believed to be better though at times we had to again remind ourselves of this.
In saying that we should be endeavoring to understand the forces that constitute the entire system in its present form I should explain my understanding of the Systems Practice concept of force. It is the dynamic causal relationships between two factors. One factor, the cause, has an effect on another factor. It is the Kumu connections forming relationships between elements that represent forces. Similar to gravity as a force only occurring when two or more bodies are in relation to each other. These can then be categorized according to the course as different types of forces, either as enabling or inhibiting within the system under question.
At this stage then, prior to actual mapping, there is only a collection of separate factors presumed to be part of a system but with no real understanding as of yet of their relationships, like cutting up pictures for pieces of a puzzle and putting them in a box. A collection though is not a system, it requires dynamic and purposeful assembly.
The Systems Practice approach, as it will be shown, disaggregates factors and then seeks to develop fresh connections between them to provide new insights. This also enhances complexity, unrealized at this point and potentially to be made more coherent by the Systems Practice process.
The course then speaks of forces between the factors, basically connoting causality or correlation. As I explained above, it takes two factors to create a force. Kumu represents these forces graphically as connections between the elements. In the course, the format used is + and - signs. This is where categorization of factors as either upstream or downstream and very often both.
A connection originates with either a plus sign meaning an increase in that factor (cause/upstream) or a minus sign meaning a decrease in that factor and ends in either a plus or minus sign to the connecting factor (effect/downstream). So an increase/decrease in A can lead to an increase/decrease in B and all the combinations possible. It can also mean moves in the same or opposite direction as in when A moves in a certain direction B moves either in the same direction or the opposite direction.
Again, any actual connections between factors representing causal relationships or forces have not been established at this point. Factors are grouped together first as either enablers or inhibitors and then categorized under a set of common characteristics or what the course called “themes”.
Taking a step back with the benefit of some hindsight, themes are part of the dynamic assembly mentioned above occurring after factor collection, separating enabling forces from inhibiting forces and then subsequently combining such forces into various themes or collections of common ideas. Themes illuminate the related forces at work within the system.
My own Systems Practice approach avoids lumping factors or blending them together by a common label to make them more homogeneous even though based on different aspects or perspectives, instead emphasizing a diversity of ideas across themes.
Factors under Systems Practice hopefully then retain a certain independence or isolation from being made to specifically serve solely one side of the system conflict or the other until their influences within the larger system are determined. They are often shown to have counterparts that they were either influenced by or that they influenced or as said above more likely both.
So a collection of related enabling factors should become a cluster of enabling or an enabling theme and the same is done then with inhibiting factors. Similar, it would seem, to the practice of separating outside, edge puzzle pieces from inside ones or sky pieces from the ground pieces.
It is presumed to be less confusing for a group if the clusters are made up of either all enablers or all inhibitors. There can be enabling factors that drive the cost of living down alongside inhibitors that drive that same cost of living up. It will be suggested then doing two different types of loops based on a particular thematic cluster, one for the dynamics that drive the cost of living down and then another one on the dynamics that drive the cost of living up when creating systems maps with Kumu.
Another reason for separating forces into two groups of enablers and inhibitors is to ensure that the group is putting sufficient attention on those factors that make things better in the current system configuration before merging them into loops and not only focusing on those that were making things worse.
The tendency had been for past groups doing the mapping to focus on what was not working, what was making things worse, giving too little attention to the things that stabilized the system or that could have even made things better. It is hoped that focusing on enablers and inhibitors separately gets groups to put significant attention looking for those "forces" or phenomena that aren't thought about in the first place, particularly on the enabler side of the equation. Sometimes this might require taking a second look.
So the group has various collections of factors organized into different themes bringing up again the image of a puzzle party, though a closer analogy would be if instead of puzzle pieces each person brought their own photos of their particular perspective to create one common photo collage. What is being sought is moving from talking about things to creating a story.
No comments:
Post a Comment