Duignan's outcomes model rules


Academic references to outcomes theory:
Duignan (2009c; 2008g; 2008f; 2008e; 2008a; 2007)*

The best way to represent, communicate and work with them is in the form of visual outcomes models using an outcomes processor such as DoView Strategy, Outcomes and Measurement Software.

Outcomes models show high level outcomes and all of the steps you think are needed to achieve them. They can be represented in text, tables, visually, or even as mathematical models.

Outcomes models come in many different forms, but if an outcomes model is to be fit-for-purpose for use within a robust outcomes system, it needs to be built according to the set of rules below.

2. Name them as outcomes, not activities/processes.

Chaning the wording from '. . .ing' to '. . .ed' (e.g. from 'increasing stakeholder support' to 'increased stakeholder support').

1. Keep your steps/outcomes as short as possible for quick reading.

Every extra word in an outcome is likely to lose you readers.

3. Maintain focus by only including a single concept in each box.

E.g Don't put 'achieve A by doing B'.

5. Build freeform models, not rigidly divided into inputs, outputs, outcomes columns.

Build the model first and then put the labels on later, only if necessary.

4. Build external-focused, not organizationally-focused models.

Your thinking needs to go beyond your organization. Model what you want to happen in the outside world. Include things you can't control (often referred to as assumptions). Also include risks by wording them in the positive.

6. Don't siloize you models.


Let lower-level boxes link to more than one higher-level box.

8. Future-proof your models by building a generic model and mapping priorities onto it.

Working in this way, when priorities change, you don't need to change your outcomes model.

7. Keep measurement separate by mapping measures (indicators) onto your model.

Map indicators onto your model next to the boxes they measure and mark up those which are controllable with '@' (use these for your direct accountability Key Performance Indicators (KPSs).

9. Don't assume that an organization needs a single high-level outcome.

If it is working on multiple issues, it might need to have multiple high-level outcomes.

11. Include all relevant and necessary steps at each level.

Ask yourself: 'do we have all the things we need in order to move to the next set ot boxes in the outcomes model'.

10. Put outcomes into a left-to-right format with the highest-level outcomes on the right.

Stakeholders generally find left-to-right models easier to read quickly. To put your steps and outcomes in the right order, use the following rule. 'A' is an 'end' and 'B' a 'means' in the case where, if you have achieved 'A' you would not bother doing 'B'. So 'A' goes to the right of 'B'.

12. If appropriate, put a descriptor such as 'adequate', 'sufficient' in front of your steps and outcomes.

For example. 'sufficient caseworker support'.

13. Make your outcomes models as large as you like by dividing them up into meaningful 'levels' (sub-pages).

E.g. national, regional, organizational and individual.

Source: Duignan, P. (2009c). Rejecting the traditional outputs, intermediate and final outcomes logic modeling approach and building more stakeholder-friendly visual outcomes models. American Evaluation Association Conference 2009, Orlando, Florida, 11-14 November 2009. 

* These particular references can be cited to refer to the material on this page.