Diagramming a theory of change

The previous post looked at the benefits of using a Theory of Change (TOC) to better understand your program or project. This post will look at how to use post-it notes and an expanded logic model framework to involve stakeholders in beginning to develop this bigger picture.

Often rallying participants around the development of a visual logic model is a good place to begin the development of a theory of change. The use of key headings and post-it notes makes it easy to provide a structure to help people develop some early models that contribute directly to their program planning, and build confidence and capacity in the use of TOC outcomes-based approaches.

Logic models are narrative or graphical depictions of processes in real life that communicate the underlying assumptions upon which an activity is expected to lead to a specific result.  There are four components commonly included in logic models (Fig. 2). These are the four primary components of the project or program itself – inputs, activities, outputs and outcomes. There are also four supporting activities which encourage participants to think more carefully about the underlying theory of change that they are planning to use. These supporting activities are: i) an outline of the current situation and desired vision; ii) stakeholder analysis, to identify which stakeholders should be involved in model development; iii) the scoping and planning exercise that underpins any model development; ensuring that underpinning assumptions are documented; and iv) noting internal and external factors – including related activities – that may influence outcomes.

There is no single or correct way to draw a logic model. It can be drawn horizontally (as in Fig. 1) vertically, or even in a more free-form fashion. Ideally, a logic model should be able to be displayed on a single page with sufficient detail that it can be explained fairly easily and understood by other people. Much of the value of a logic model is that it provides a visual expression of our underlying beliefs about why the program is likely to succeed through one step leading to another. Thus, each step between an activity and an output or between an output and an outcome can be thought of as an ‘if this happens … then that is likely to happen’ statement. For large or complex programs, the logic model may be divided into more detailed sections or sub-models. These may be summarized by a less detailed ‘overview’ model, often given on the first page, that shows how the component sub-models fit together into a whole.

As an example, Fig. 2 illustrates the main program logic elements set out in a horizontal fashion. The inputs are the resources used to resource the activities, produce the program outputs, and ultimately contribute towards desired outcomes. Inputs typically include such things as money, staff, and equipment/infrastructure. Inputs are usually measured as counts, such as hours of staff time, dollars spent, etc. Activities are the actual interventions and actions undertaken by program stakeholders, staff and agencies to achieve specified outputs. Activities can range from writing a memo, to holding workshops, to creating infrastructure. Activities are usually measured in terms of number of things done – e.g. x meetings held with communities. Outputs are the tangible results of the major activities in the program (the goods and services produced). They are usually measured by their number – e.g. reports produced, newsletters published, numbers of field days held. Collectively the inputs, activities and outputs define what the program does, and how efficient it is in managing those elements. Outcomes represent the effectiveness of the program – are the desired states of the community, biological system or production sector achieved by the program.  Outcomes may be specified in terms of short-term, intermediate and long-term, or just intermediate and long-term. A long-term outcome will usually have a number of intermediate outcomes that together contribute to its ultimate achievement.

The diagram above also shows the supporting information and activities that help the model (and the intended program) to be understood in its wider context. Starting out with outlining a planning and scoping phase helps participants to clearly define the problem or need, and the desired outcome. An ‘issue’ statement should explain briefly the current situation: what needs to change; why is there is a need for intervention; and, what problem/issue does my program aim to solve? This requires that ‘who, what, why, where, when, and how’ are all considered in relation to the problem/issue. Then, the overall purpose of the program needs to be defined. What are you trying to accomplish over the life of the program and beyond? The answer to this question is the solution to the issue statement, and will serve as the program’s vision. The program vision serves as a reference frame for all elements of the logic model that follow. Involving your key stakeholders (see the accompanying resources on stakeholder mapping and analysis) in the process of developing an outcomes model provides an opportunity to engage them in a discussion about the program and to get their input to the process.

The link between a program’s activities and outputs and its desired outcome is based on the assumptions that explicitly, or implicitly, are built into your program theory. Your program theory (or theory of change) sets out why you believe that the successful delivery of the program’s activities and outputs is expected to lead to the desired change (the predicted outcomes). It is important to document the program rationale – the beliefs about how change occurs in your field, based on research, experience, or best practice. This needs to be followed by identifying the corresponding assumptions that are built into the program rationale and to acknowledge and document where uncertainties exist.

A final discussion can help participants to take account of the risks and opportunities facing the program. These can derive from both internal and external factors. Programs that are operating in complex environments cannot control all the factors that will influence how, when or even if they reach their goals.  Therefore it is also important to be aware of similar or related external initiatives that will impact on the final outcomes. This is important in terms of attribution – how to ascertain how much impact can be attributed to your program. It also provides the opportunity to look for other initiatives to link and integrate with, to develop useful synergy and maximize the overall influence of the program.  Internal factors might relate, for example, to staff and stakeholder capacities.

Three key reasons for using logic models in program design are that they: i) helps you understand why and how something works; ii) provide a guide for implementing useful monitoring and evaluation systems; and iii) help you tell the story of your program quickly and visually. Logic models are most useful when they are developed at the beginning of a program.  In this way they can be used to plan how resources can be coordinated and even inspire particular  project strategies.  They can also at this stage help set  realistic expectations for outcomes, bearing in mind that the ultimate desired end-state outcomes of an initiative can often take many years to emerge.  Their initial development helps subsequent evaluation as once a program has been described in terms of a logic model, it is then possible to identify meaningful and easily measurable performance indicators. Finally, the simple, clear graphical representation that a logic model provides helps with program communication, and can serve as the basis for expanding the underlying TOC.

Finally ––Some tips for working with logic models

• Start with ensuring a common understanding of the current situation and a shared vision:   It’s important to know where you are, and where you are trying to get to. These positions will have often been expressed in already published documents, mission statements, etc. The important thing is to ensure that there is some common understanding around the problem and the desired outcomes among all those that you are trying to work with on your journey.
• Involve stakeholders:   A strong focus on the process of developing a logic or outcomes model (rather than seeing it as just a task to complete) can increase engagement in the program. Building a logic model provides an opportunity, often rare in the everyday provision of services, to involve stakeholders in a discussion on what it is about the planned initiative that is most meaningful to constituents.
• Keep the model simple:  Concentrate on the most important activities and outcomes, and cut back on detail. Describe your activities and outcomes in language that is understood by a wide range of stakeholders.  This lets your logic model provide a common picture of your project that is easily understood. It’s important to get an  overview of the model on one page that can be used as a communication aid, and more detail can be added behind it if necessary.
• Minimise the use of arrows:   In complex situations there are always many links and potential feedback loops between the boxes on the page. It is often enough to indicate the general movement of time and direction of the model.
• Avoid siloed thinking:   Don’t just include steps and outcomes that are measurable or which you can absolutely prove you changed (attributable to you) – these may not end up being the most important part of the programme. Similarly don’t force lower steps to only contribute or influence a single higher-level step or outcome. Most elements influence a number of things in the real world.
• Work constructively with disagreement:  Although it might be difficult, keep key stakeholders involved, including staff, program participants, collaborators, or funders. Take time to explore the reasons for disagreement about what should be captured in the logic model. Look for the assumptions, identify and resolve disagreements, and build consensus.

More information: Often people talk about logic models and theory of change processes interchangeably. Logic models typically connect programmatic activities to client or stakeholder outcomes. But a theory of change goes further, specifying how to create a range of conditions that help programmes deliver on the desired outcomes. These can include setting out the right kinds of partnerships, types of forums, particular kinds of technical assistance, and tools and processes that help people operate more collaboratively and be more results focused.

Will Allen( Principal, Will Allen & Associates )

An independent systems scientist, action research practitioner and evaluator, with 30 years of experience in sustainable development and natural resource management. He is particularly interested in the development of planning, monitoring and evaluation tools that are outcome focused, and contribute towards efforts that foster social learning, sustainable development and adaptive management.