In my time thinking about development programming, one of the topics that I see come up a lot is the Theory of Change (TOC). Development bloggers debate in hushed tones whether TOC is really new or just a “logframe on steroids.” I think that a big part of the issue is that there is a missing piece – if a Theory of Change describes how we think a given development outcome will happen, we also need something to talk about what we will do as USAID – a Theory of Action (TOA). So this post is an effort to link together the two concepts and to talk about why they might be a useful way to think about our work. First, I’d like to describe how I understand TOC and TOA. Then, I’ll suggest ways that this might be a step forward over current practice, and finally, some implications around how this can be used.

TOC and TOA: What are they?

For me, a Theory of Change describes how the situation prevailing in a place where we work will change, from a present status that is not good to one that is better. I would ground this in a description of the situation – what is the local system relevant to our result – and describe how that situation will change, and why the changed situation will be better. For example, if I’m interested in access to justice, in a place with long court backlogs and little trust in the judiciary, I might look at the roles of judges, court administrators, judicial training academies, relationships between citizens and government, between businesses, laws covering court access and burden of proof, incentives for prosecutors and defense attorneys, availability of paralegals, and the like, and describe all of this as the current state of the local system around access to justice. Then I can identify my theory of what will change it – say, a new policy that I believe will better synch traditional justice with formal courts so that traditional elders’ verdicts in family disputes are ratified or can be challenged; a more transparent arbitration system for business disputes that I think can be made to work; and a set of annual reports on court backlogs that I think will incentivize judges to hear more cases. After those changes, the system won’t be perfect, but it should be faster and better, and I can describe how it will work. The TOC is my belief that these changes will affect the bottom line result – reduce court backlogs and increase public trust in the judiciary – and my two depictions of the system describe why and how I think that these changes will work.

My TOC can be mistaken – the reports I think will shift judges’ incentives may just result in them dismissing more cases in order to move quickly, or the arbitration system may be captured by a few big businesses and used to harass their competition – these may not be the changes that will in fact affect my bottom line of backlogs and public trust. My TOC is at the core of my Project Design.

Even if I’m right, though, these changes will not happen just because I can point to them. Changing policy around traditional justice may be hard and may be fought by folks who fear it; an arbitration system may not take off unless a lot of businesses can be induced to try it out and good arbitrators reach reasonable outcomes in those first few cases; and annual reports on court backlogs may be unacceptable or considered unfair, private, or a threat to the existing way the Ministry of Justice rates and rewards its judges. My TOA describes how I think we can catalyze change in the system – how support for a traditional justice incorporation can be built through careful dialogue; how training of arbitrators in international standards and outreach to the business community through business associations can get enough folks to try it out; and other ideas. These tasks I see are what I would do (or more precisely have an implementing partner do) to move change along. My TOAs are at the core of my Activity Designs.

Why Is separating TOC and TOA a step forward?

In my professional circles, there is a lot of excitement about the new ADS 200 series, and it is often boiled down to this phrase: “They are letting us get beyond logframes!” Why are people who work in development excited to get beyond the logical framework? I think that the answer, and the ways we’ve tended to misuse logframes, is centered on TOC and TOA.

The two words I will always associate with logframes are Necessary and Sufficient, and I am hoping that with the new ADS, we can skirt the perils of these two words. You see, logframes in my experience fall down because of the pressure for each lower level box to be necessary and sufficient to get to the higher level. This means that we are saying that what we do, way down at output level, will (if we’ve thought through Necessary and Sufficient) make outcomes happen, which will in turn make us reach still higher objectives, like the falling of a stack of dominoes. It obscures and combines two critical questions: is our activity doing what we wanted it do, and is doing what we wanted causing the higher-level results we hope to achieve? These are the two questions prised apart by calling one TOA and the other TOC.

In my experience, this resulted in a strange situation where most of our energy in design was spent thinking about the higher level, trying to ensure that we could justify what we would do (in this example, something like “if we transform traditional justice and establish fair arbitration, it will be necessary and sufficient to enhance public trust in the judiciary”). Once we had decided we were right, we would let out solicitations to do the smaller things. And then all learning during the course of implementation would address the lower level – checking on the number of meetings with businesses to promote arbitration, say – with a near infallible belief that if only the activity could get on track with its workplan and hit its indicators, this huge transformation was sure to follow, because our outputs were deemed Necessary and Sufficient! In implementation, most of the energy would then get spent pushing contractors and grantees to catch up with their workplan, and most discussions were around whether we were on track or not. We killed our curiosity – we only needed to know if we were on course – and poor implementers who suggested we might rethink our assumptions about what was Necessary and Sufficient were impertinent excuse-makers who should be told to mind their place.

So I see the willingness to move beyond logframes as important because it helps us not to close the door on what we can learn at a higher level, in between Project Design periods.

How can TOC and TOA be used?

There is a lot of emphasis placed on learning at USAID at the moment, through approaches like CLA and the promotion of adaptive management. To me, the critical hinge that effective learning rests on is the ability to communicate to our partners and other stakeholders what we are interested in learning, and then to take stock and respond with integrity to what we learn. TOC and TOA help us to do this, by inviting learning about both whether we’re on course and whether our course still seems true – what the M&E crowd may recognize as “double-loop learning” that questions the assumptions behind our specific action.

More than this, having separate but related TOC and TOA helps us to make clear to partners that what we really care about is the higher level change, where our TOC resides. We ultimately shouldn’t care much about activities except where they are levering change in the local system. The activities are what we do, but the change is what we accomplish, and we are in the business of accomplishing development, not just getting tasks done.

The only way that we can communicate to partners what we really care about, and invite them to be partners, as well as hold them accountable for the flexibility we may be giving them in their day-to-day activities, is to have a clear language around how their tasks are expected to fit into the bigger picture, and to invite them to share their knowledge about the big picture as it evolves. We want them to adjust and achieve activities, but ultimately want them to correct so that activities catalyze change.

I’ve seen findings from studies of Missions by Samir Doshi and his colleagues in the Lab showing that real-time data is most used in contexts where there is trust between the Mission and its implementing partners. This makes tremendous sense; collective reflection and learning simply makes more sense in the safer space of the TOC, where no single agent is responsible for the outcome. Otherwise, it is simply more opportunity to check on workplan progress. 

Framing learning about TOC also makes it easier to invite interested local stakeholders to be part of the conversation – expanding our collaboration and building local ownership by taking an issue of importance to other actors (in our example, folks interested in public trust in the judiciary and fairness in verdicts) and framing conversations around what we know about that, rather than about our specific activities. In language I’ve borrowed from Mark Meassick in Uganda, as our programming gets more mature, it should be moving the locus of learning out from the Mission and to the local change agents who should be most invested in that outcome.

This blog by David Jacobstein, from USAID's Democracy, Rights and Governance Policy, Learning and Integration Office, was initially published on USAID's blog page and is republished here with his permission.