Getting too eager about building the perfect Theory of Change (ToC) for your organisation, programme or project can lead to an over-designed ToC that can be more of a hindrance than a help to manage and learn. It sucks up a lot of time and team resources to build but then gets out-dated extremely quickly. A ToC should be an idea that is alive and dynamic. For me a ToC is more useful if it is a sketch on the back of an envelope after an intense discussion rather than a page in a high-gloss brochure. A ToC in a complex setting is necessarily imperfect. But it can still be extremely useful.

The more energy a team invested in developing a ToC, the more resistant they will be to change it. This is true for a team but gets even more difficult when the ToC process was done in a participatory way including many different stakeholders and a painful process to find a consensus on The ToC (there are other problems with aiming for consensus, see my earlier post). This is not to say that participatory processes should not be part of a ToC process, they do have an important role to play – but this might be a separate process than the day-to-day operational ToC process by the implementation team (food for thought for another post). Changing a ToC is also hard when it has been endorsed by the donor, who might insist that that ToC will be the blue-print for the whole project implementation.

People who get excited about ToC have come up with all kinds of great exercises that can be used to enhance a project’s ToC. One I like is to run a “pre-mortem”, where you run a thought experiment with the team of all the reasons why the pathways you have come up with might not work. I think this is quite a useful exercise in itself particularly in teams who are used to see the ToC as a blue-print of how change will happen. Then there are exercises who try to come up with all kinds of alternative pathways for the same type of change. Also, there is often a request to support every causal link in a ToC with evidence, which can be extremely time-consuming.

All these exercises surely have a value in themselves and in specific situations and it is hard to refute their individual rational and usefulness. At the same time, there is a danger that over-eager ToC advocates and consultants end up facilitating a ToC process that takes months and huge investments in time and team energy. While it is understandable that people want to ‘do everything right’, I think this is quite problematic. A ToC can never be perfect, at least not in a complex environment. Complex systems are systems with loads of un-knowns (known un-knowns to be precise). We can never figure out how change will happen in complex systems. Not only can we not know the pathways, we are also unable to predict the exact shape of how the change will look like. Complex systems can only be understood if we interact with them. ‘Probe-sense-respond’ for people who are familiar with the Cynefin logic.

Also a well-designed ToC cannot change complexity. Often people seem to have a feeling that you can somehow simplify complexity by coming up with a logic model. They try to predict intricate pathways of how change will happen and why. These attempts, I observe, are often based on quite shallow reflexion of reality. For example, I recently saw a results chain that projected that the culture in an organisation on how projects are implemented will be changed by giving them better tools, methods and access to knowledge. While this can certainly be a part of how you can influence culture (especially through knowledge), culture is such a complex beast that reducing that complexity to a number of arrows does not seem to be particularly helpful. Interestingly, the people who came up with that results chain (for who’s work I have great respect by the way) were totally aware of that problem but did not really know what to do with it (I’d recommend as a firsts step to read my post on complexity-informed ToC).

A ToC has in the first place to be useful for the people who work with it. It is a tool to discuss, debate, experiment, learn, change. How exactly the ToC process is designed needs to fit the organisations, programme or project that uses it. In some instances it needs to be more formal than in others. This also depends on the relative stability of the context. If you are operating in a complex context, I would recommend you use the ToC to sketch down what you know (where you have evidence) plus your hypotheses which you want to experiment on. Maybe you have multiple small ToCs in parallel because you have competing hypotheses.

The basic things that are needed in a ToC as a minimum are what you want to do (the intervention), why you want to it (which goal of the project the activity contributes to), what are the signs of success, and what are the signs or failure (and potentially how you capture them). That’s it. Then we can use the ToC to structure activities and learning. The ToC needs to work for you, not you for the ToC.