Written on 17/06/2016
Our first model – A Context Diagram
So, this week we built our first model. A Context Diagram. Much of the Systems Thinking approach is about building models of various types, so this will be the first of many we build, and this particular one made for a very good starting point I think.
We created the diagram on a large piece of paper which we put in the middle of the table we were sitting around. The conversation we had felt like a kind of structured brainstorming session and it was interesting to see the way it highlighted things that we didn’t know about our wider system and how it works. For example, it became clear that I didn’t really know how our allotment association works and exactly who owns the land, what arrangements are, and even the legal form of the allotment association, of which I’m a shareholder and whether liabilities are limited or not. I need to go away and find out more.
What’s our System of Interest
It also pushed us to make decisions about what our System of Interest is. What was inside and what was outside. This is where the “Thinking” in Systems Thinking comes in. We are having to think not only about problems and solutions, but about how we are going to frame and view the problem/situation/thing. I think this is an important point. It’s the conscious and documented decisions we are making about what we are interested in and understanding how they affect the System of Interest if we leave them in or out, that is beginning to set this approach apart.
Things or Functions?
One possible trap we fell into was naming some stakeholders/things in their object, rather than functional form. For example, we created a terminator for the Allotment Association and Committee and also for the Council. If we we’re designing a new allotment, rather than exploring the situation as it is, it would be better to have a terminators for functions, rather than organisations, so instead have “management” and “ownership” for example, as they are functions that will need to be fulfilled, because at this stage we wouldn’t need to commit to “how” those functions are to be delivered. But, we’re exploring the existing system as it is, so it’s OK to have done it the way we have I think, but this is something to remember for the future.
Cmap – Free and fun
Last night, I turned our drawn diagram into a computer based diagram using a program (or “App” for the younger and more trendy members of our group) called Cmap. It’s an excellent tool and I’d urge you to have a look. There are several similar free tools, including InsightMaker and Kumu, but I particularly like this one because it works as both an we based application and a downloadable computer based program and diagrams can be saved online in “the cloud” or on your machine. It makes it a very versatile and practical tool. It’s easy to pick up and use, and also to print diagrams from. The printing of diagrams is a bit of a problem in Kumu and Insightmaker and some other tools. They’ve been designed with collaborative working on/from a screen or projected image in mind, rather than with ability to print off diagrams. Anyway, Cmap ticks all the right boxes for me, and is free, so have a look and play with it. Here’s a link to the website:
And here’s the model we built.
If you want to view a larger version, go here.
Here is another copy of the diagram. I’ve redrawn a possible new system boundary around what we thought was probably our System of Interest. Click on the picture to enlarge.
We started the exercise with the premise that the System of Interest is just the physical allotments and that everything else was outside of it and in the “context”. It became clear as we built our Context Diagram that this boundary was probably inappropriate and we would need to include some of the key actors, including the allotment holders, association and committee and also the local Council within our System of Interest.
I think an argument could also be made that we should include services and transport infrastructure.
We’ll debate the boundary
I suggest we begin next week’s session by looking at this boundary and deciding what we want to put inside and what we want to leave out. We’ll need to justify why we are happy to leave out the things that we do. For example, suppliers of seeds and plants are so ubiquitous locally as physical shops and as online retailers and we don’t have any control or influence over them, it’s probably reasonable to leave them outside. We need to consider, justify and document our decisions though. Again, we’re “Thinking”.
We can then draft a new Context Diagram with our newly defined System of Interest in the centre, and then any new stakeholders, functions, and things that become apparent. There may not be any, or many, and this shouldn’t take long, but I think it’s worth doing to double check we’re happy with our new boundary, wherever that is.
Changing the boundary changes the purpose
Then, we can return to our other favourite subject, “Purpose”. We will need to define the purpose of this new System of Interest. The interesting thing here is that our decision/s about where to draw our system boundary will have an effect on the Purpose of the system. We should take some time in the session to reflect on this. And also, to think about why it’s important to define Purpose. For one thing, we can never know if a systems is performing well or not, if we don’t know what it’s purpose is.
To help us define the Purpose, we can use our old friend, the “18 Word Statement”, but I’d like us to also start to get into defining the sub-purposes / functions. Looking through Stuart Burge’s material, it looks as though the “Tree Diagram” is a nice way to do this. He does recommend we put together an “Affinity Diagram” before doing so though, so this week’s homework is to read his papers on both.
The Affinity Diagram paper is here.
and the Tree Diagram paper is here.
I look forward to seeing you next week and picking this up again.