DoView is flexible enough for you to build your outcomes models any way you, or those you work for, want you to. However, to get the most out of the outcomes models you build in DoView (or in other software for that matter) you might like to look at the guidelines for drawing outcomes models set out below. In particular, if you draw your outcomes models in this way you will find that they can be used for a broad range of purposes. 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, leads to very limited outcomes models.  Such models may be able to be used for accountability but are not much good for other purposes such as helping you think strategically about other things you could do or about what you can and what you cannot evaluate in terms of outcomes. A well built DoView model should be able to help you with strategic planning, priority setting, monitoring, evaluation, research and development planning, contracting and other aspects of organizational life.

 

Guidelines* for drawing good outcomes models are:

1. Use outcomes not activities as your step names. You can change an activity (doing) into an outcome (done) by just changing the wording (e.g. 'Increasing stakeholder support' to 'Increased stakeholder support').

2. Let your outcomes models include any of the 'cascading set of causes in the real world'. In DoView we just refer to every type of cause at whatever level as an outcome. See the What is an Outcomes Model? Section for the reasons why. The steps that are 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 is usually a lot of resistance to putting in 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 go into such models. This is a genuine risk but is best managed by dealing with measurement, attribution and accountability after your have built your base model. For instance, by dealing with measurement by putting indicators onto your model (doing it this way lets you see which outcomes you do not yet have indicators for); by dealing with attribution by going through later and marking those steps which are attributable to a particular player (you could do this with color, brief letter codes, or put the player in as a step and making links between them and all of their attributable indicators); and by dealing with accountability by also going through later and marking those steps for which a particular player is going to  be held to account (or contracted to do).

3. If you are not required to by others, do not force your outcomes model into particular horizontal 'levels' within the model such as inputs, outputs, intermediate outcomes and final outcomes. It is possible to do this in DoView if you want to (e.g. see program logic and strategy maps), however in some cases it may distort a good clear visualization of the flow of causality in the real world. For instance, some types of outputs (for instance) 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 logical flow of causality in the model. The concept of outputs is useful for accountability purposes and they can be identified later at whatever level of a model they are located by going through and marking them with color or brief letter codes.

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 a model, the way you draw the model should allow for this. In contrast to may other software visualization and database approaches DoView never forces you to siloize your outcomes model. Any outcome (step) can be connected to any other outcome at any level through using linking.

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 show that you are looking at a composite, rather than a singular outcome.

6. Keep outcomes short. Outcomes models with wordy outcomes are hard to read. To help you do this, DoView lets you include separate descriptive notes in rows within the details table where you can put as much detail as you like about any outcome (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. 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 outcome(s) above it.

9. Keep measurements/indicators separate from the outcomes they are attempting to measure. Measurement should not be allowed to dominate an outcomes model. If it does you are drawing a model of what you can measure, not what you want to do. Using DoView measurement can be introduced at a later stage by putting indicators onto a page. In those relatively small number of cases where a measurement also acts as an intervention in its own right (e.g. some audit procedures), then it can be included as an outcome (step) within a model.

10. Put a 'value' in front of your outcome (e.g. suitable, sufficient, adequate). You do not need to define this at the time you first build your outcomes model. If it is not clear exactly what it amounts to, it can become the subject of an evaluation project later on.

11. Develop as many outcome pages as you need (but no more). In an outcomes model you are trying to communicate to yourselves and to other stakeholders the nature of the world in which you are trying to intervene. Pages can be seen as a series of cuts through the world of outcomes in your area of interest. For instance you might have pages at the national, locality, organization and individual level. The trick is to get the smallest number of pages needed to effectively communicate the relevant outcomes in the model. DoView lets you quickly move through your pages once you have built them with page-jump hyperlinks.

12. Do not 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 your 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 you are 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 as the specific outcomes model which they are interested in is not enmeshed with other outcomes from other sectors they are 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 outcomes which are attributable (ones you can absolutely prove just you changed) to you, you will find that they make a lot more sense to external stakeholders. External stakeholders can then just map onto the outcomes model the particular outcomes they are focusing on.

13. Include both current high-priority and lower priority 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 is 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 have 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 steer as to how your current priorities map onto 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 – i.e. the cascading set of causes in the real world. It is also consistent with the idea of evidence-based practice. It is then up to elected government officials to decide what their priorities will be and these can be mapped onto the underlying outcomes model. This approach means that outcomes models do not have to change every time there is a change in the elected official in charge or of the government as a whole. If elected official priorities change they are simply mapped onto the more comprehensive outcomes model.

 

*  Based on Duignan, P. (2008). Standards for drawing outcomes models. Outcomes Theory Knowledge Base Article No. 210. [http://knol.google.com/k/paul-duignan-phd/standards-for-drawing-outcomes-models/2m7zd68aaz774/28].