Tables versus visual models March 19, 2009
Posted by Paul Duignan in : Doing evaluation more efficiently, Reporting systems, Communicating outcomes models, Using the approach, Outcomes models, Easy Outcomes , trackbackEach day this week I am blogging on some of the themes that came up at a national philanthropy conference earlier in the week where I presented on the Easy Outcomes approach. There was some discussion in the conference session about the dynamic nature of what grantees do and how it is hard to capture such dynamism in any rigid system of evaluation. However, as is often the case, at the end of the day, some tabular logic models were presented as an example of how to set out an evaluation. I am not criticizing their presentation, because this is currently standard practice in evaluation planning, and the use of some sort of logic model is always much better than not having one. However, in my view, we fall back on the use of tables because we do not realize that there are better ‘technologies of representation’ (i.e. visual outcomes models) that we could use.
The problem is that tables are inadequate devices for communicating the complexity of what is happening in any but the simplest of programs. The only way tables can represent complexity is to have many levels of nesting (and this results in much duplication if there are multiple relationships between the elements represented in the table); or to use many of cross-reference numbers. People tend to avoid nesting and cross-reference numbers because they, or others, think that it makes the tables look ‘messy’ or ‘incomprehensible’. However, when they do this it means they fail to capture the complexity of the program they are trying to represent.
Obviously I would argue that the way out of this ‘table-problem’ is to draw visual outcomes models in software designed to handle complexity but which is still simple enough to let you draw models in real time in meetings with stakeholders - like DoView outcomes and evaluation software which I’ve been involved in developing (one of the reasons I developed it was that trying to work with tables started to drive me mad (check out this report I wrote mostly using tables to see what led me to get involved in developing DoView!)).
If you want more on this, I discuss a set of conventions for drawing logic models here; talk about the advantages of working with visual outcomes models here; and have a set of standards for drawing such models here.
Paul Duignan, PhD
Comments»
[…] are better ‘technologies of representation’ (i.e. visual outcomes models) that we could use. Read full article […]
[…] are better ‘technologies of representation’ (i.e. visual outcomes models) that we could use. Read full article […]
[…] Tables versus visual models The steps in a Rich Dialog Process March 23, 2009 From Paul Duignan’s Outcomes Blog - Read full […]