Lines, arrows and ‘Engineering’ solutions March 20, 2009
Posted by Paul Duignan in : Communicating outcomes models, DoView, Easy Outcomes, Using the approach , trackbackAt a national philanthropy conference I presented at this week I demonstrated using the Easy Outcomes approach as a way for grantees to communicate what they are doing in their programs to their philanthropic funders. The visual models underlying the Easy Outcomes approach are drawn in DoView outcomes and evaluation software. The particular example I used was a user-friendly mock-up which I will put up on the internet in a week or so. It uses the latest version of DoView (1.17) which is planned for release in a couple of weeks – it is very cool in that it allows images to be inserted into a DoView file – really bringing outcomes models (logic models) to life. Check out this initial mock-up here (it will also let you drill-down with a hyperlink ‘hop-to’ beneath text, indicators, evaluation questions etc.). There were lots of positive comments about the model, including one community group woman saying ”Hallelujah, finally someone has started talking our language and realzing that we like working with pictures and images not just tables and text’. However, one other person did comment that they though the model looked rather like an ‘engineering approach’.
This comment taps into the ongoing discussion about whether (and how) outcomes models (logic models) can (or should) represent the reality of the programs we work with. At one extreme is the position that the claimed causality within programs should be able to be represented in a simple linear model to assist in working out whether or not the program works. At the other end of the spectrum is the view that the programs we work with are so complex, interactive and dynamic that attempting to represent them in a simple linear causal model is a waste of time.
My perspective is that we need to move away from the simplistic idea that linear causality can represent all that we need to represent in regard to programs, but that we have to watch out for the ‘everything is connected to everything’ attitude which we can end up in if we go too far in the opposite direction. I think that if we are running programs we have a responsibility to be able to explain to those who are funding us and other stakeholders the way in which we think our programs will work. This does not mean that we have to be able to: 1) set it out in a very simplistic one page diagram which can only deal with simple causal interactions; 2) provide evidence for every link in the model; or, 3) always undertake evaluations which somehow prove that what we have in our models is actually what is happening in practice.
There are ways of writing the ‘steps or outcomes’ (as I call them) within our outcomes models which can allow for lots of dynamic processes within one step or outcome. For example, ‘Successful interaction with a therapist’ could be a step within an outcomes model. Within this step there would be all sorts of dynamics, feedback loops and changes in direction. For the purposes of modeling in a particular situation such a step may be the best way of representing that element in the outcomes model.
A lot of the issue we are dealing here comes from the ‘technology of representation’ used to represent our models. Certain technologies of representation naturally encourage us to draw very simplistic models. Tables are an obvious example as I blogged about the other day. The almost universal attempt to cram models onto a single letter/A4 sized page is another disaster. Lines and arrows to represent causal links is the final killer. When we have letter/A4 sized models with line and arrow links we might as well give up if we think that they are going to be able to represent anything but the simplest of projects.
Now, back to the ‘engineering’ comment. DoView does actually let you draw line and arrow links. Initially it didn’t, but they were put in at the request of users who felt they could not do without them. We are working hard on other paradigms to show multiple links. At the moment there is the innovative ‘link end-point icon’ which I have not seen in any other software, which lets you represent a causal link without a line and arrow representation. This means that you can record causal linkages and record information about those links (e.g. evidence that they are credible) in the record table associated with the causal link in DoView. When using lines and arrows, if you cannot fit them on the page you have to lose information about the causal link permanently from the model. However in DoView at the moment you can only see the ‘link end-point icons’ for a single step at a time (we working on adding more functionality than this in the near future). When you click on the step it will show the ‘link end-point icon’ for all of the other steps on the same page.
When actually drawing outcomes models for clients I almost never use line and arrow links. Particularly at the start they are a problem because as soon as you put them in and if you try to move any of the boxes around the model, the whole pattern of lines and arrows becomes very distracting to the viewer. DoView does actually let you turn off viewing the line and arrow links (without deleting them), but usually I don’t even bother putting them in at the start.So I tend to build models in which, if needed, any step or outcome can be connected to any step or outcome. (In DoView you can actually create a feedback loop where Step A causes Step B to occur and Step B then causes more of Step A to occur – this is the type of thing we are building into DoView to make sure that the ‘technology of representation’ does not force us to distort the complexity of the causal interactions which actually exist in the programs we are attempting to model.
So how did I end up with a model with lines and arrows in it which attracted the ‘engineering’ comment in the session earlier this week? I find that because people are used to seeing lines and arrows representing causality, if you only have a little time to show them the concept of outcomes modeling and Easy Outcomes, it works to show them an initial simple model with lines and arrows in it just so that they can understand that you are drawing causal models. You can then wean them off the need for lines and arrows by showing them that most of the time you can simply work with the boxes without the line and arrow links. In such models, the general notion that moving from the bottom of the page to the top shows the overall flow of causality (See the paper on conventions for visualizing outcomes models for more on this).
So, I ended up catching some mild flack on an issue where I totally agreed with the person who made the ‘engineering’ comment because I had oversimplified what I was doing just for the purposes of presenting it in a short period of time.
Comments»
no comments yet - be the first?