Turning systems models into projects

A while ago my esteemed friend and colleague Patrick Mayfield wrote about using Systems Thinking to build Outcome Relationship models.

Never being too proud to plagiarise something good, I wondered how Patrick's diagram would work as a Funnel Timeline in a software mind map. Would it be a case of trying to make a different tool do something it's not designed for? Would it genuinely create additional value, or would it be a compromise that required rose-tinted spectacles to see advantages?

Although software maps were never designed to represent systems and networks, they are very good at helping to focus on outcomes and priorities in context. So whether a representation of a system diagram is better or worse when mangled into a tree depends on what you wanted to do with the diagram in the first place. If you wanted to understand the dynamics of a closed system without any particular emphasis on one angle, then a systems diagram is best for this. But if you want to use the systems diagram to deliver change, i.e. if it develops into a project or process, then focusing on outcomes can have distinct benefits.

Without repeating Patrick's arguments for systems thinking and visualisation here, this is his diagram showing how the various factors driving improved teaching in schools inter-relate:

Here is the same information, interpreted as a Funnel Timeline in a MindManager map:

What are the pros and cons of each approach?

It is not a case of one visualisation being "better" than the other, but that each can be applied differently. The system diagram shows an interacting set of entities. The Funnel Timeline shows the relationships in terms of the influences needed to reach a new state, using the systems model to determine the consequences of positive changes. In fact Patrick's diagram is a model of an open system. If it were a closed system in balance, the legends would be "Teacher professionalism" instead of "Increased teacher professionalism", and there would be feedback loops showing the relationship between the level of teaching performance and other conditions such as pay (assuming that the perceived value of the teaching system influences how much money is spent on it).

The systems diagram version has no specific central point that might distract users into seeing it one particular way. There is no real priority built into the spatial position of the elements, although this could be added. The elements have more of a feel of "black boxes" to them. There is no ambiguity about what feeds into what. Bilateral influences are entirely possible, although the nature of the influence between them might need clarification.

The map version requires some conventions to understand the Funnel Timeline technique. In a Funnel Timeline, topics represent outcomes or achievements of a certain status, and sub-topics are the predecessors or preconditions required to achieve that status. This makes the Funnel Timeline version strongly outcome-focused, and much better suited for representing open systems rather than closed ones. You can easily see the actions or achievements in the context of the overall outcome.

By flattening out a systems network into a tree, you can identify primary themes or groupings, and the relationships between the components in these groups are stronger (by implication) than those drawn "across" the tree. This is much easier to see in the tree format. You can also add more detail to a particular node without disrupting the diagram. This is because in the tree version, we have sacrificed a whole axis to "level of detail". In the systems diagram, we use both axes to draw information. In the tree version, we use one virtual axis for information, and the other for the level of detail of that information. Because of this, you can arrange the tree version to show first and second generation factors; things connected more closely to the final outcome are direct influencing factors, whereas things at a lower level are indirect. Again, this is a bit easier to see in the tree version than in the systems diagram.

Another advantage of the tree layout is that you can easily take it forward as an action plan, as the sequence of changes is identified. Interestingly, one of the analytical questions that Patrick cites is identical to the analysis needed to create Funnel Timelines, viz. "What are the necessary things that must happen or be in place for this to happen?" This question creates a bridge between systems modelling and planning for change, i.e. project planning. With the map version, the sequence of changes is clearly laid out, and even benefits from hierarchy & inheritance - you could make one person responsible for delivering everything below one particular node, for example.

So, are we actually better off, or have we forced a round peg into a square hole? I don't think it's a question of choosing between one and the other - each has its own merits. The systems approach is the foundation for understanding how a closed system stays in balance, i.e. what the balancing forces are. Armed with that knowledge, you can then define the actions necessary to move that balance point. This can be presented as a project plan, even though it is derived from a system diagram. Understanding the systems forces already at play helps to make change more effective.

Comments

[Matt Whyndham]

Nice look at how the structure of diagrams can illustrate thinking, and influence it as well.

I find then whenever there is a computer-drafted diagram is use, interactivity (argument, dialogue, suggestion) is often suppressed as a result, unless the thing is live in a meeting.

[Ian Glendinning]

I'm sceptical that going beyond crayons to mind-manager is necessarily progress .... often the impression of formality mis-represents the original subtler message.

As you indicate above, the choice of "formal" layout influences the message and is part of the choice of layout "for a given purpose". I gave up on mind-manager in truly complex situations because the choice of "seemingly" hierarchical nodes gave them unfair precedent over the vaguer wiggly cross-links. The choice pre-empts the analysis.

[Nick Duffill]

Ian - you make a good point, bnt moving from crayons to MindManager is not "better" or "worse", but "different". Issues arise if one is expected to substitute for the other. The key is to exploit the features and limits of the hierarchical diagram, rather than hope it will be as effective as a network. In the above example, this is done by extracting focus and a path to action out of a flat network.