Guidelines for drawing good outcomes models

iStock_000003575000XSmall copy

Outcomes models set out all of the steps needed to achieve higher-level outcomes for an organization, program, policy, sector or collaboration. Variations on the concept of an outcomes model go under names such as: logic models, program logics, intervention logics, program theories, theories of change, strategy maps, ends-means diagrams, results-chains, fishbone diagrams etc.). If you draw your models according to the guidelines below you'll find that your outcomes models can be used for any of the steps within Easy Outcomes and also for a variety of other purposes, even if you're not using Easy Outcomes. The examples used below are shown visualized in DoView outcomes software. (You can find a copy of these guidelines inside any copy of DoView - look in Help>DoView Help >Building Outcomes Models>Building Good Outcomes Models). 

Some other ways of drawing outcomes models, for instance those that demand that you only include outcomes which you can currently absolutely prove you changed, lead to much more limited outcomes models.  Such models may be able to be used to deal with your accountability issues, but they're not much good for other purposes. You want your model to be able to be used for more than just accountability, for instance to help you think strategically about alternative steps you could take to achieve outcomes and to help you identify potential evaluation questions etc. A well built outcomes model will be able to help you with all aspects of priority setting, monitoring, evaluation and contracting when you are using steps within the Easy Outcomes system. A Powerpoint presentation setting out the guidelines below is available on the Easy Outcomes Resources page - you can use the presentation with a group prior to working with them to build an outcomes model.    

Drawing good outcomes models is as much an art as as a science, the guidelines* below provide a starting point for those new to drawing outcomes models, and points for consideration for those who have drawn outcomes models in the past. 

1. Use outcomes not activities. You can change an activity (doing) into an outcome (done) by just changing the wording (for example, 'Increasing stakeholder support' to 'Increased stakeholder support'). So don't get too worried as to whether something is an 'outcome' or a 'activity' or 'process' when you are putting it into your model. You can always turn an activity or process into outcomes form by just changing the wording. 

2. Let your outcomes model include any of the 'cascading set of causes in the real world'. The steps that you put into your models do not have to be limited just to your measurable, attributable (ones you can absolutely prove you changed) or accountable outcomes. There's usually a lot of resistance to putting into your outcomes models non-measurable and non-attributable outcomes. This is because stakeholders want to manage their risk around being held to account for the outcomes that appear in their models. This is a genuine risk, but it is best managed by being making it clear to all stakeholders that the initial outcomes model is not limited only to accountable outcomes, it should include all outcomes and steps. Measurement, attribution and accountability are all dealt with in Easy Outcomes, but at a later stage after you have drawn your initial model. 


The diagram above shows a 'full' outcomes model on the left which contains all of the 'cascading set of cause in the real world' related to a program. In the middle of the diagram there is an outcomes model has been restricted to just 'measurable' outcomes and steps (the green ones) and the model on the right, has been further limited to just those outcomes which are attributed to a single player. The much reduced outcomes model on the right is useful for accountability purposes for the particular player and their funders, but it is not much use for any other stakeholders. However, the outcomes model on the left can be used for all of the steps within Easy Outcomes and is of much more interest to a range of players than the very restricted model on the right. 

3. Don't force your outcomes model into particular horizontal 'levels' within the model such as inputs, outputs, intermediate outcomes and final outcomes. In some cases this may distort a good clear visualization of the flow of causality in the real world. For instance, in some outcomes models, outputs may reach further up one side of an outcomes model than another. Forcing artificial horizontal layers onto an outcomes model often distorts it and makes it harder for stakeholders to 'read' the natural logical flow of causality in the model. 


The diagram above shows how forcing outcomes into horizontal levels can distort an outcomes model. For some outcomes models it may make sense to think only in terms of one level of 'intermediate outcomes' between outputs (in yellow at the bottom) and high-level outcomes (at the top of the model). However for other types of program, it may be more appropriate to have many levels of intermediate outcomes between outputs and outcomes. For instance, it would distort the model on the right to force it into the framework of the model on the left and demand that the three levels of intermediate outcomes be amalgamated into only one level. The concept of distinguishing outputs from other steps is useful for accountability purposes and in Easy Outcomes it can be achieved not by using layers, but by marking (e.g. with color or brief letter codes) the steps which are outputs after the outcomes model has been drawn.  

4. Do not 'siloize' your model. Silozing is when you draw an outcomes model in a way that artificially forces lower level outcomes to only contribute to single separate high-level outcomes. In the real world, good lower-level outcomes can contribute to multiple high-level outcomes. Any outcome can potentially contribute to any other outcome in an Easy Outcomes model, the way you draw the model should allow for this. (You need to draw your model in software which lets you do this. DoView software does not force you to siloize your outcomes model. Any outcome (step) can be connected to any other outcome at any level through using DoView's linking tool).


The diagram above shows a very simple illustration of siloization. Imagine that the blue steps in the outcomes model on the left can only be visualized as influencing the blue higher-level step and the yellow steps can only be visualized as influencing the yellow higher-level step. The real world usually looks much more like the model on the right. In this case, the highlighted blue lower-level step is shown to influence both the blue higher-level step and the yellow higher-level step. (Influence - 'makes happen' - is shown in DoView by an inverted V on the bottom edge of the step which is influenced. This inverted V represents an arrow head). 

5. Use 'singular' not 'composite' outcomes. Composite outcomes contain both a cause and an effect (e.g. increase seat-belt use through tougher laws). This should be stated as two, rather than just one outcome. Words like through, or by in an outcome or step show that you're looking at a composite, rather than a singular outcome.

6. Keep outcomes short. Outcomes models with wordy outcomes are hard to read. For example, an outcome called: 'A fully developed sense of well-being in all areas of a young person's life' should, if possible, be renamed as: 'increased well-being'. (You need software which helps you keep your outcome and step names short. DoView does this by letting you also include separate descriptive notes in rows within the record table where you can put as much detail as you like about any outcome or step.)

7. Put outcomes into an hierarchical order. The normal DoView convention is to have highest level outcomes at the top and then drill down to lower level outcomes (you could have it another way - for instance from right to left). Use the simple rule that you can tell that outcome A is above outcome B in a case where, if you could magically make A happen, you would not bother with trying to make B happen.

8. Each level in an outcomes model should include all the relevant steps needed to achieve the steps or outcome(s) above it.

9. Keep measurements/indicators separate from outcomes and steps they're attempting to measure. Measurement should not be allowed to dominate an outcomes model. If it does, you're drawing a model of what you can measure, not what you want to do. Put your measurements (indicators) in as a next stage after you've drawn your model. The only time measurement should be included directly in an outcomes model is where the results of the measurement itself is a step in an outcomes model (e.g. an audit process).


In the diagram above, the outcomes model on the right shows the initial outcomes model which has been drawn. The outcomes model on the left shows indicators (measures) for outcomes which have subsequently been placed on the outcomes model. It should not be assumed that all outcomes will always have an associated measurement.

10. Put a 'value' in front of your outcomes and steps (e.g. suitable, sufficient, adequate, effective). 

You don't need to define these 'values' at the time you are first building your model. This allows you to move on and get the model built without having to delay over every outcome as your and those you are working with identify the specifics of how the step or outcome will be 'suitable', 'sufficient, 'adequate' or 'effective'. In a technical sense these values identify parts in the outcomes model where you could drill-down further in the future, if this is necessary. If appropriate, in the future, you can launch an evaluation sub-project to specify what exactly these values mean in regard to a particular step or outcome. 

11.  Build models as large as you like by creating many modular outcome 'slices' (separate sub-diagrams of parts of your outcomes model). Outcomes models should not be limited to just a single page if the world of the organization, program, sector or collaboration needs to be visualized with an outcomes model larger than this. The way to build models as large as you like, is to break them into a set of interlinked sub-diagrams which in Easy Outcomes are known as 'slices'. Slices can be seen as a series of cuts through the world of outcomes in your area of interest. For instance, you might have slices at the national, locality, organization and individual level. Because the steps and outcomes in each slice are related (e.g. all in the 'organizational' slice relate to the organizational level) it is easier for the reader to quickly understand this sub-component of the outcomes model. Using a modular approach also lets you quickly borrow and amend sub-diagrams from other models which have been built in the past (see for models from which you can borrow).  The trick is to get the smallest number of slices needed to effectively communicate the relevant outcomes in the model. (DoView lets you quickly navigate through models made up of multiple slices with it's 'hop-to' hyperlinks).

12. Don't assume that you need a single high-level outcome at the top of an integrated organizational outcomes model. Outcomes models should be about the external world, not just about a particular organization. Often organizations are delegated to undertake interventions in a number of areas or sectors that are best modeled separately. If you build separate models for the conceptually different areas or sectors an organization is intervening in, you can then just take that specific model and use it in discussions with stakeholders from that sector. This keeps things really clear for external stakeholders because the specific outcomes model which they're interested in is not enmeshed with other steps and outcomes from other sectors they're not interested in. In addition, if you have drawn your models as generic 'cascading sets of causes in the real world' as suggested in 2 above, rather than restricting them only to steps and outcomes which are attributable to one particular organization, you'll find that they are a lot more useful for external stakeholders. External stakeholders can just look at the model, identify the particular steps and outcomes their activity may be focused on, and see how this fits into the overall picture of the outcomes model. 


The diagram above shows on the left an overly 'integrated' organizational outcomes model where the brown and green steps and outcomes which relate to different topics have been mixed together into a unitary outcomes model. As an example of this, imagine that a public health organization is working on both smoking and water quality issues where the brown steps and outcomes relate to smoking and the green relate to water quality. It is better for the outcomes model to have been built as it is on the right where the steps and outcomes related to smoking have been drawn separately (brown) from those related to water quality (green). This means that when the public health organization goes to discuss the outcomes model with stakeholders involved in water quality, these other stakeholders can easily see the part of the model which is relevant to them (the green part). In the case above, such discussions have then gone on to result in additional green steps being added to make a more comprehensive diagram of the relevant steps and outcomes on this topic. 

13. Include both current high priority and lower priority steps and outcomes. Your outcomes model should be as accurate a model as you can draw of the 'cascading set of causes in the real world ' therefore it's not just about the current priorities you can afford to work on if they are a sub-set of the wider outcomes picture. Once you' ve drawn your outcomes model you can then map, a typically more limited number of, priorities onto your more comprehensive outcomes model. This allows you to think strategically about alternative options in the future and reflect this by changing your priorities. If your outcomes model only includes your current priorities it gives you no guidance as to how your current priorities map onto the range of options which are available in the real world. In a public sector context, this also allows outcomes models to support public sector employees providing 'free and frank advice' about how the world is – that is, the cascading set of causes in the real world. It's also consistent with the idea of them providing evidence-based policy advice as they can accumulate evidence under the links within the model (see the Easy Outcomes Step 2b on adding evidence to links within models). It's then up to elected government officials to decide what their priorities will be and these can be mapped onto the underlying broader outcomes model. This approach means that outcomes models do not have to change every time there's a change in the elected official in charge or of the government as a whole. If elected official priorities change then the priorities mapped onto the model simply change. 


The diagram above shows how the broader outcomes model on the left build, for instance by a public service department, has had an elected representative's priorities mapped onto it (in pink). These could change at any time that the elected representative changes, but the underlying model should stay the same unless the external world which it is modeling changes. The model on the right which just consists of the pink priority steps, shows how limiting an outcomes model just to current steps produces an impoverished model compared to the comprehensive model on the left.  

* These guidelines are an adaptation of the set of outcomes model standards which has been developed Duignan, P. (2006) Outcomes model standards for Systematic Outcomes Analysis [].

 Creative Commons Copyright Dr Paul Duignan 2007-2010