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).

**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.

**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.

**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.

**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).

**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.

**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.)

**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.

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

**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).

**Put a 'value' in front of your outcomes**

**and steps**(e.g. suitable, sufficient, adequate, effective).

**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 www.OutcomesModels.org 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).

**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.

**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.