The term "theory of change" (ToC) has established itself in the development world. Agencies invite consultants (including your blogger) to facilitate workshops which would help them develop the theory of change for a particular programme; donors ask prospective grantees to come with a sound theory of change; evaluators (including your blogger) bemoan the absence thereof. There are companies which have developed theory of change software and dedicated websites that propose to help you build your own ToC. The picture below shows a fraction of what I get when I ask a popular search engine to find images of "theory of change":
Clearly, theories of change come in many shapes and colours. Back in 2004, the Annie E. Casey Foundation (AECF), a reliable source of no-nonsense guidance for non-profit organisations, produced a practical tool for ToC development. It proposes two approaches in building a ToC. The first is a cause-to-effect chain of activities and outcomes (with the term "so that" connecting the consecutive links of the chain), somewhat similar to what we find in today's "results based management" (RBM) workshops. The second way revolves around thinking in terms of different scenes, each describing a different aspect of the theory of change:
- the context and rationale for the proposed change effort (i.e. what is the situation like and why it needs changing);
- the assumptions and beliefs about how change will occur (i.e. what you believe must happen for the change to come about - the kinds of things logical frameworks usually describe);
- the conditions which must be established before strategies can be articulated (i.e. what needs to be done to plan and carry out the kinds of activities that you hope to provoke the change).
I like that second model because it acknowledges that there is a context - the people whose situation you intend to help changing, and the people and aspects of the current situation that might hamper or further the desired change -, and that it takes good preparation, participation and partnerships to walk down that cause-to-effect pathway.
A Dutch-based Theory of Change Resource Portal defines ToC as "the understanding an organisation, project, network or group of stakeholders has about how political, social, economic, and/or cultural change happens, and its contribution to such a change process." Fair enough. The page Recognising a good TOC introduces quite abstract concepts: "Power analysis", "assumptions and values", "wide ownership". This is when it becomes complicated. For instance, "power analysis" is defined as a "discussion on how power relations exist and how these might shift for those ignored, excluded or oppressed" (note that there is no reference to the likely shifts against those acknowledged, included and favoured). "Values that underpin the analysis" also tend to be hard to pin down: This could be anything from "all human beings are born equal" to "results-based management is a precondition for effectiveness". The 72-page manual by Iñigo Retolaza Eguren (who quotes Edgar Morin in the introduction) offers plenty of useful materials for seasoned practitioners, but does it answer the question as to how one can tell a good theory of change from a poor one? I'm not sure. Big words and abstraction tend to invite more big words and abstraction. The ToC portal offers many more resources; I admit I have not studied all of them.
I would argue that a theory of change is only useful if everyone involved in the change can understand it. Abstraction can lend you a certain air of competency, but does that help the project and its theory of change? I would plea for a theory of change which:
- Is expressed in such straightforward terms that even your grandmother or grandfather (or anyone who hasn't had much secondary education) can understand it;
- describes the situation that you intend to help changing;
- acknowledges what has been done by others to bring about the desired change;
- explains how your activities and their products (outputs, outcomes etc.) will contribute to the expected change (along with what others do)...
- under what conditions - i.e. what needs to happen - or not (risks!) - within the project, around, before and after it.
Under this model, the ToC would be more comprehensive than the simple input-output-outcome logframes we see around - and so much closer to reality. By the way, there is an earlier post on this blog which reflects on improving on log-frames.