Flow of causality in outcomes models and feedback loops August 14, 2009
Posted by Paul Duignan in : Communicating outcomes models, DoView, Measurement, Outcomes models, Outcomes theory, Using the approach , trackbackA quick technical blog here. Fellow evaluator Rick Davies pointed out in a post on one of my outcomes theory articles (on how to best represent causal models), that strictly visualizing causality as flowing in one direction within an outcomes model (logic model, results map, logframe, theory of change etc.) could be seen as preventing the representation of feedback loops. This is because if you are, as I usually do, representing causality as flowing from bottom to top within a model (others do it left to right) then when you want to represent a feedback loop it will, of necessity, have to flow back down the logic model against the direction in which causality is being represented.
So when I talk about visualizing causality within a logic model as flowing from bottom to top, following Rick’s point, I need to make clear that what I’m talking about is the general flow of causality (or most of the causal links). Because, like Rick, I think it is essential to be able to represent feedback loops, I’m totally relaxed about having some causal links (feedback loops) whenever necessary flowing ‘back down’ a model. I mocked-up an example of how you can do this in DoView for Rick. It even shows how you can in DoView show one step having a feedback loop to itself! The web page version of the example is here. You can download the DoView file from the bottom of the web page version and have a play with it yourself (if you have a trial copy of DoView installed).
The purpose of having a visualization direction within the models I build according to the outcomes model building standards, is firstly (like most conventions for drawing outcomes models – logic models, theories of change etc) we want to be able to orientate the reader to where causality is generally flowing in the model. Secondly, in the way that I normally draw logic models, it allows you to not put in all of the line and arrow links (the reader can interpret them as being there because of the flow of causality). Diagrams full of line and arrow links have real problems in terms of being functional visualizations for the type of purposes I want to use them (e.g. mapping indicators and evaluation questions, using them for outcomes-focused contracting, amending them in real time in front of stakeholder groups etc. as set out on the Easy Outcomes approach site).
As a side issue, I think (but have not looked into it in any detail) that feedback loops are not represented in some mathematical models normally used because it is difficult to represent them in some types of mathematical representations of causal models. Obvious, this is a problem in that many interesting things in the world do consist of feedback loops. [Later update: I need to look further into which types of mathematical models allow feedback loops (some do) and which don't, once I sort it out I will blog on this point again].
What I am trying to do with my visual modeling of theories of change, logic models etc. is to provide an environment where we can model as accurately as possible what is happening in the real world. We can then attempt to build other ways of representing it – e.g. mathematical models, lists of indicators etc. But by starting out with the visual representation, which contains as much of the complexity of the world (e.g. feedback loops, anything potentially causally connected to anything else, not just restricting oneself to measurable steps within the model) as possible, we can then be very clear about how other representations of our model (e.g. mathematical models, indicator lists etc.) are distorting what we think is really going on (i.e. by in the case of mathematical models (if I am correct) not including feedback loops; and in the case of indicator lists being restricted to only the measurable).
Later update: I understand that in at least some types of mathematical modeling e.g. those using LISREL) feedback loops can be included. I will try to clarify which do and which don’t and blog on this later.
Paul Duignan, PhD. (Outcomes and evaluation blog OutcomesBlog.org)
Follow me on Twitter.com or Subscribe to my E-Newsletter
Comments»
Hi Paul
Re my claim that “strictly visualizing causality as flowing in one direction within an outcomes model (logic model, results map, logframe, theory of change etc.) could be seen as preventing the representation of feedback loops”
This concern applies only to those models where the steps in the causal process are seen as steps at different points in time. As is implicit in a Logical Framework representation of a project design. There Activities happen, then Outputs, then Purpose level changes, then Goal level changes. In this context you cant have feedback loops running backwards in time, from Goal to Purpose or Purpose to Output.
This problem no longer exists if you can get away from this type of causal modelling. Actor networks, or network of other kinds of entities, which don’t privilege time as a key dimension in the layout, don’t have this problem.
Yes Rick, and I think that there is a distinction (which I have not had much time to think about) between a model which has a rigid time sequence right across it – which is more of a business process model and the type of model which I am trying to draw which is a causal model, but the same amount of elapsed time is not shown in different parts of the model. So for a model running from bottom to top (with high level outcomes at the time) as I draw them on the left hand side of the model more time may be elapsing between two boxes than on the right hand side of them model. This approach lets you model causality rather without having to ‘distort’ it with the same time sequences in different sides of the moment. Anyway that is a rather technical point, but in line with my attempt to get rid of as many ‘distortions’ in causal modeling – I think that such distortions with traditional approaches are what have led you quite appropriately towards innovations like actor networks.
Re the approach you have taken to move to looking at actor networks – which I think is a fascinating approach and since you are using it, must be adding value where you are using it – I have a question. Is it true to say that you have moved to this approach because of disillusionment with what we can call ‘causal modeling’ for a moment?
What I am trying to develop is causal modeling which does not have the limitations of things like the traditional table-based logframe. Do you still think that there is a place for such ‘causal modeling’ as a complement to what you are doing with actor networks – or have you abandoned all hope in the causal modeling department?
Regards Paul.
I don’t have a problem with causal modelling as such, just some ways of doing it. Especially those captured in Logical Frameworks, because once the vertical axis is seen as a movement through time this imposes troublesome constraints, as discussed above.
I am in favour of network models of causality because they allow any cause to have multiple consequences, and any consequence to have multiple causes. Actor networks are a specific class of network models which I am keen on (but I don’t use them exclusively to all others) because they are quite concrete and easy to communicate to others (contra concepts of outputs, outcomes, impacts)
I still have to live and work with Logical Framework based causal models. Usually I try to make them more actor oriented. For example, with a Global Witness project, a chain of activity-output-purpose-goal-super-goal is replaced/substituted by a chain of actors: Global Witness UK-their in-country partners- CSOs they work with-governments they try to influence-forest communities they affect. This can be seen as a pathway through a wider network. The assumptions column can be used to describe the connections between each actor in this pathway, and the wider surrounding set of actors (what it is summed they will/will not do)
Using LogFrames as they are, I have also used Excel matrices to work out, during stakeholder workshops, to what extent various outputs are expected to influence the different outcomes (at Purpose level) in a project, and from this identify which outcome is most likely to be affected overall by the project.
Great Rick,
In my modeling I don’t use input, output, intermediate outcome, final outcome layers within the model. I find that they constrain it too much. I think that everything you can do in a logframe can be captures in a more free-form model.
Making a model more Actor orientated as you said above sounds like a good idea to me and I would be happy to see such modeling in any model I developed.
Regards,
Paul.