Conventions for visualizing outcomes models (program logic models)

A Topic Article within the Outcomes Theory Knowledge Base

In the past there have been many ways of drawing outcomes models. Such models go by various names including: logic models, program logics, intervention logics, means-ends diagrams, logframes, theories of change, program theories, outcomes hierarchies and strategy maps. The traditional ways of drawing such models are a combination of the purposes for which people want to use the models, plus the limitations of the 'technology of representation' being used to represent the model (whiteboard, paper, software etc.). A standard convention visualizing an outcomes model is described which should be generally suitable for any performance management, strategic prioritization, evaluation, monitoring, contracting or related outcomes system.

Introduction [1]

Outcomes models are models used to show how a program, organization or intervention, works to achieve high-level outcomes. They go by a variety of different names, including: logic models, program logics, intervention logics, means-ends diagrams, logframes, theories of change, program theories, outcomes hierarchies and strategy maps.

A more general discussion of outcomes models is available in an article which should be read with this article: What are outcomes models (program logics models)? That article contains references to a set of standards for drawing outcomes models. This current article focuses more narrowly on conventions for visualizing outcomes models for use within outcomes theory (i.e. the type of model suited for use across any strategic prioritization, performance management, monitoring, evaluation or contracting outcomes system). 

There may be other ways of setting out outcomes models which conform to the requirements of outcomes theory, so the convention described here should be seen as an example of a convention which meets the requirements of outcomes theory, rather than being the only way that outcomes models can be set out.

Talking about outcomes models in outcomes theory 

Outcomes models occupy a central place within outcomes theory. They are the first of the five building-blocks of outcomes systems identified within outcomes theory. In order to have a standard way of talking about outcomes models when discussed within the theory, outcomes models are conceptualized as being vertical graphical models, with high-level outcomes at the top of the model and lower level steps (which cause the outcomes) cascading down below them. The elements within an outcomes model are described with the generic term -  steps and outcomes. This term is used to to refer to any element in any part of the causal pathway from the lowest level cause or causes right up to final high-level outcomes. The term steps and outcomes therefore includes: outputs, intermediate outcomes, final outcomes etc. The notion of a model conceptualized in this way is a convenience which allows one to talk about 'further up' or 'further down' an outcomes model as a short-hand way of saying 'further along the causal path within an outcomes mode in the direction of high-level outcomes' or 'earlier in a causal pathway within an outcomes model'.

The advantages of using vertical models with high-level outcomes at the top and the steps that lead to them below

There are various ways in which outcomes models (program logics, logic models, results chains etc) have been drawn in the past (e.g. top to bottom, left to right). Why has the convention of drawing them as vertical models with the highest-level outcomes at the top been adopted within outcomes theory? The reasons for adopting this approach are that:

  • It emphasizes the importance of high-level outcome(s) by putting them in the most prominent place on the page (at the top).
  • It encourages 'outcomes thinking' by having the reader start with high-level outcomes and then move down to look at the steps which it is believed will lead to these outcome(s). This is the normal flow for the way a written page is read in most written languages. It is also consistent with recommendation within outcomes theory for the way in which outcomes models should be built in practice - i.e. starting with a box at the top of a page and asking the question 'what is it, at the highest level, that we are trying to do here?'
  • It works against just 'program justification' thinking, in contrast to more appropriate 'outcomes thinking'. Program justification thinking only sets out a justification for a project rather than focusing on the outcomes that one is trying to achieve and working backwards from these to specific programs. The preferred 'outcomes thinking' approach leaves open the possibility that one can consider that there may be more than one way (program, or intervention) through which an outcome can be achieved. 'Outcomes thinking' is the type of process that funders and other external stakeholders want program providers to have gone through in regard to the programs and interventions they are proposing. They do not just want them to think up some outcomes that justify their programs without carefully considering the alternatives programs or interventions which could be undertaken to achieve high-level outcomes.
  • It conforms to some visual and language metaphors related to causality - 'higher-level outcomes', 'top-level outcomes', 'raising one's vision' and visual metaphors which often to put the most important items at the top of a visual representation.
  • From a practical visualization perspective, it easily allows for navigation within diagrams which have more items at the bottom of the visualization than at the top. In general (although not necessarily always), there tend to be more items listed as one moves further down an outcomes model. 

Why not a left to right visualization?

Traditionally, an alternative to the top to bottom visualization has been one where an outcomes model has run from left to right with outputs or activities on the left-hand side of the page and outcomes on the right-hand side. Obviously, if an organization has invested in such an approach, there may be a practical argument for continuing with using it. However, the development of outcomes theory provides an opportunity to reexamine the conventions for drawing outcomes models and to examine the advantages of top to bottom versus left to right approaches. The disadvantage with a left to right approach is that it tends to encourage a presentation which has outputs on the left-hand side and then leads to outcomes on the right. A left to right outcomes model could be drawn which has outcomes on the left and the steps which lead to them on the right, but this is not done often. A left to right presentation with outputs on the left and outcomes on the right, reinforces 'program justification' thinking rather than 'outcomes thinking'.

Technologies of representation and outcomes models

Outcomes models have, in the past, been developed with different 'technologies of representation'. These include models described in narrative text (probably by far the most common representation of outcomes models if we think of them in the most general sense); text-based tables; graphic representations of various sorts; and mathematically specified models. In terms of graphical visualizations, these have been represented on: white-boards; post-it notes; systems which allow larger pieces of paper to be stuck and moved on a wall (including using reusable glue on plastic sheets, or pin boards on which letter/A4 type size pages can be stuck); letter/A4 paper; ledger/A3 paper; larger poster size paper; drawing software of various types; and in outcomes modeling software (e.g. DoView) [1].

A suitable 'technology of representation' for outcomes models that can meet the needs of outcomes theory must allow:

  • Models to be developed which are as large as needed to represent the pattern of causality between steps and outcomes in real world programs and interventions (i.e. not just limited to a single page).
  • Any step or outcome to have a causal link to any other step or outcome represented (including allowing for feedback loops - i.e. Step A makes Step B increase and Step B, in turn, makes Step A increase).
  • Evidence to be mapped onto the links between steps and outcomes within an outcomes model.
  • Measures to be visualized separately from steps and outcomes.
  • Other elements such as evaluation questions to be mapped onto an outcomes model. 
  • Outcomes models to be used as the central organizing structure for strategic planning, prioritization, evidence-based practice, best-practice identification and sharing, monitoring, evaluation, contracting and other purposes.
  • Outcomes models to be drawn and amended in real-time in groups.
  • As much as possible, for models to be represented across different modes (e.g. software on screen, printed paper, dataprojected, web-based) so that there can be interaction with the model in any setting where issues to do with the program or intervention are being discussed or considered (e.g. worked on by an individual, in a program planning meeting, in a stakeholder meeting, when browsed by a stakeholder on the web, when read in a report).

These requirements inevitably mean that models need to have their primary representation in software of some sort because of the power of that 'technology of representation' but ideally that they are also, to the extent possible, able to be represented in other modes (e.g. dataprojected, printed paper, web-based models). Being able to work with dataprojected models is particularly important if outcomes models are to be able to take their place at the heart of project planning, implementation, monitoring, evaluation, contracting etc. This is because the practical application of outcomes theory puts a great deal of emphasis on working with outcomes models as an intrinsic part of programs and interventions. See the Easy Outcomes approach for a practical applied version of outcomes theory. 

Mathematical representations

Mathematical representations of outcomes models are ultimately the richest way of modeling the pattern of causality running from a program or intervention to high-level outcomes. Visualizations are a way of representing models which allow them to be worked with by humans (including those who do not have a sophisticated grasp of mathematics). In an ideal world, models would be visualized and also represented mathematically behind the visualization to add the richness of mathematical modeling. 

Examples of visualized outcomes models 

Some examples of visualized outcomes models are available from www.OutcomesModels.org. These have been drawn according to a set of standards for drawing outcomes models and visualized in DoView [1] outcomes and evaluation software which has been explicitly designed to visualize outcomes models for use within outcomes theory and its applications (e.g. models of any size, any step or outcome linked to any other, able to be amended when working with a group when dataprojected, able to be printed out on paper, able to be turned into a web-page model).

Conclusion

This article has described a convention for visualizing outcomes models for use in outcomes theory. The reader should look at the article on outcomes models (program logic models) for more detail on outcomes models (including the use of labels such as output, intermediate outcomes and final outcomes to describe layers within a model). Because outcomes theory is a generic theory which relates to all outcomes systems, it is likely that this convention for visualizing outcomes models will have general applicability for many performance measurement, strategy prioritization, evaluation, contracting and other systems where people are working with specifying, measuring and attributing outcomes.  

Citing this article

This article should be cited as Duignan, P. (2009). Conventions for visualizing outcomes models (program logic models. (http://knol.google.com/k/paul-duignan-phd/conventions-for-visualizing-outcomes/2m7zd68aaz774/49).

[If you are reading this in a PDF or printed copy, the web page version may have been updated].

[Outcomes Theory Article # 225 http://www.tinyurl.com/otheory225].

References

  1. Disclosure: The author is involved in the development of DoView outcomes software as a way of creating, working with, and reporting on outcomes structures.

Comments

©2009 Google