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.

[Ian Glendinning]

Nick, so you were saying the "funnel timeline" is taking a time-based priority in the hierarchical / mind-manager view - even though the original system was a "flat" network.

That's OK - the choice of the primary "time" axis is clearly not arbitrary in a planning situation (and I like timelines for other narrative / historical reasons).

I guess what I was saying is that the real "work" is done by capturing the known / perceived data in arbitrary / flat network, and the process of constructing the mind-manager view from it. Mind-manager itself seems to display the result, rather than being used as the tool to create it ?

The other point is that "time" - ie the precedent of cause and effect - seems to be a non-contentious choice of hierarchical axis. However in complex systems the causality and dependency may be not be simply one-way, depending on the objects chosen to represent the nodes or edges in the first place ?

Just thinking out loud here - I am interesting in tools to improve such analyses.

[Nick Duffill]

Ian - the term "timeline" is logical rather than actual, and the use of the tree to visualise dependencies is a shorthand for the more commonly used relationships.
I am not aware of any automated way to create Funnel Timeline maps from another network, so MindManager is the tool used to both create and interpret it. To automate the generation of a Funnel Timeline map would require some arbitrary decisions where a task had multiple dependencies, and the resulting network could be technically correct but not "common sense".
The hierarchical nature of the map is used in two ways in Funnel Timeline maps; one to visualise inherited properties such as ownership and priority, and secondly to show dependencies. In one sense, some of the completion criteria of a task can be inherited by its predecessors; if Task A must finish by date X, then by definition none of the predecessors of task A can finish later than X. So drawing projects in hierarchical trees is not too exotic.
But mainly the funnel timeline layout is intended to be an easy way to visualise and manipulate simple projects without resorting to "proper" project management software. It never clicks with some users, but others love it. It is a very interactive and tactile way to sort tasks into order.

[nicolas stampf]

Nick,

though mindmaps are a powerful tool (mainly because of the right brain/viszualization part), I don't think one should force everything into them (though a lot can already be turned into MM !).

As for networks (systems !), there are software (even free one) that's designed for this such as Vensim, iThink, Stella, etc (see http://systemswiki.org/index.php?title=Simulation_Software)

[SaaS]

Good post, the funnel timeline is an interesting approach. I have seen this kind of hting before but never really used it. It is something that I am looking into to integrate into my studies and learning. Thanks for the post.