I got a very good feedback on my blog post last week on complexity informed Theories of Change, it was shared widely on Twitter. But I also got some questions. One person pointed out the fact that the method I described in that post was mainly focusing on new programmes that are developing their first Theory of Change. But what about programmes that are in the middle of implementation? Programmes where the programme team sense that things are not going the way they are supposed to according to their Theory of Change, Logframe or project plan. Should the managers of such programmes just stop operations and go back to the drawing board to develop a complexity aware Theory of Change? This is in most cases not possible, unless things are really going badly. How can these programmes incorporate some of the ideas of complexity informed Theories of Change?

My advice to managers and team leaders who are in such a situation is to start tinkering with their existing Theory of Change in small ways and see how it can be amended here and there to better reflect the reality the programme team faces during implementation. Which are the assumptions that seem to hold? Which are the ones that don’t? If they don’t, was it simple the wrong assumption and you could now figure out how the causality works? Or do you find yourself in a situation where you are facing competing hypotheses and data does not give you clarity on which one is correct? In the latter case, I would advise you to scale down interventions that follow the original assumptions and transform them into more experiment-like activities to test different assumptions.

There is a lot of resistance to more flexible ways of programme planning. Donors feel that they are loosing control and allow implementers to hide their lack of knowledge of what is going on behind a veil of adaptive management and trial and error. To counter that fear, it is important that flexibility is not translated into ‘anything goes.’ Adaptive management and experimentation need to be done in a systematic way, having clear processes of establishing what is being tried and how data is collected to determine if it worked or not.

Instead of shifting a whole programme from blue-print implementation of a plan to complexity-aware exploration, which is a cultural shift that takes time, team leaders can  start tinkering in small ways to see if complexity ideas can be introduced informally and actually make a difference. The idea is to include some core-team members and experiment in a small but safe to fail way. If this works and a few positive results can be generated, more team members can be introduced, gradually shifting the culture in the team from implementing a blue-print plan to critically assessing success and failures and building in feedback and learning loops.
What I want to re-iterate from my last post is that not every aspect of a programme is necessarily complex, non-linear and unpredictable. Experienced staff have a pretty good understanding of many things so they can be planned relatively well in advance.