Module 2: Program Design
2.1. Why focus on program design?
Some aspects of program design have particularly heavy influence on the ability of project teams to measure the results achieved. For GBV prevention, this is especially relevant given the absence of clear and consistent program designs and theories of change in the sector. [1]Vigaud-Walsh (2020) noted that, in humanitarian settings, GBV prevention activities were often implemented without explicit and context[1]specific theories of change being developed at all. Instead, many of the GBV prevention activities reviewed relied on globalized theories of change, based on evidence about what influences GBV risk outside of the specific context in which the program operates.
Importantly, a lack of attention paid during design stage does have a negative impact on project effectiveness. A recent study of what works in the prevention of violence against women and girls highlighted the importance of “carefully planned interventions, built on deep local knowledge of all relevant aspects of the intervention and underlying assumptions, and designed around a well-conceived theory of change”.[2] The study concluded that the presence of a context-specific theory of change at project-level was one of the common factors among successful interventions.
As such, this module aims to present program teams with a toolset for developing explicit and contextualized theories of change at the project and program levels, and within the resource and time constraints observed in the field.[3]
2.2. Context-specific theories of change
2.2.1. What is a theory of change
A Theory of Change (ToC) is just a description of how a project intends to bring about change for individuals, groups and communities.[4] When done well, it can support outcomes-based approaches by helping apply critical thinking to the design, implementation and evaluation of projects aiming to bring about change in their contexts.[5] Theories of change can take the form of results diagrams, narratives, tabular structures, or combinations of each. They typically seek to map a pathway to change, including activities, outputs, outcomes and final impacts of the project. Critically, ToCs also explain the assumptions that the project team is making about the causal mechanisms. This allows monitoring and evaluation teams to test these assumptions during implementation, and provide useable learning back to decision-makers.
2.2.2. What a theory of change should look like
At its most basic, a ToC is just a statement of the form “IF we do this activity, THEN this change will happen, BECAUSE of these factors”. For example:
“IF we increase household food security, THEN we will reduce the risk of girls being forced to trade sex for resources, BECAUSE food insecurity is a primary driving factor behind this practice”.
Or:
“IF we provide training and education on IHL for armed groups, and IF we support the capacity of disciplinary and accountability mechanisms for perpetrators of sexual violence within armed groups, THEN the risk of sexual assault of men from this specific ethnic group by armed actors will reduce, BECAUSE lack of knowledge and awareness of IHL obligations combined with insufficient accountability mechanisms are driving factors behind the sexual violence.”
These statements can be spelled out for each stage of a logframe. Thus, if the project logframe looks like this:
Then a theory of change can be applied to each step of the results-chain:
When this is done, we can list all the causal assumptions underlying the program design in a clear and transparent manner. This can help M&E teams to design monitoring frameworks that can test these assumptions, and helps program teams to question and adapt their projects as they implement them.
It is really important to be clear about what makes an assumption “causal”. Causal assumptions are descriptions of the things that must be true for the program activity to have the intended effect; or for the output to cause the intended outcome; or for the outcome to have the intended impact, etc. Thus, assumption 1 in the diagram above is that food insecurity is a primary driving factor behind the practice of forcing girls into trading sex for resources in the particular context in question. If this isn’t true, for example, because girls are being forced into trading sex for resources for any other reasons, then the cash provision will not reduce this form of GBV in this context. That is why we call assumption 1 a “causal assumption” in this theory of change.
On the other hand, background assumptions are descriptions of the things that must be true for the program activity to be implemented. Households must be willing and able to accept unrestricted cash, for instance. If this is not true, for example due to the absence of a suitable money-transfer system in this context, then the activity will not take place. For that reason, it is called a “background assumption” in the theory of change.
It is important to specify both background and causal assumptions. Doing so helps evaluators to test how true the project theory of change is, and make suggestions about how to change the program design in the future. But it is critical not to mix up background and causal assumptions when doing this.
As an example, the theory of change above can generate a simple table of background and causal assumptions, like the one below:
Of course, it is always possible to list more assumptions for any project. But the critical point is to make sure that, during the program design process, the most important and most pressing assumptions – both background and causal – are clearly listed by program teams. Doing so can greatly improve the quality of evidence generated through monitoring and evaluation efforts.
A simple way to develop project-level theories of change is to build a table like the one below for each project logframe you develop:
Cause |
Background assumption |
Effect |
Causal assumption |
| Activity 1 | 1-2 bullet points on what needs to be true for the cause to take place | Output 1 | 1-2 bullet points on what needs to be true for the cause to have this effect |
| Activity 2 | 1-2 bullet points on what needs to be true for the cause to take place | Output 1 | 1-2 bullet points on what needs to be true for the cause to have this effect |
| Activity 2 | 1-2 bullet points on what needs to be true for the cause to take place | Output 2 | 1-2 bullet points on what needs to be true for the cause to have this effect |
| Activity 3 | 1-2 bullet points on what needs to be true for the cause to take place | Output 3 | 1-2 bullet points on what needs to be true for the cause to have this effect |
Each row of this table represents an individual arrow in the logframe. So if the logframe has four activities contributing to one output, then the table will need four separate rows for these. Likewise, if one activity is intended to have three different outputs, the table will need three separate rows for these.
2.2.3. How to make one
Wherever possible, theories of change should be developed in as participatory manner as possible. Community participation in the design process has the potential to improve community engagement and ownership of the process, which can improve program effectiveness and potentially sustainability once the program has closed.
But the process of developing a high-quality theory of change can be complex. As outlined above, it requires careful consideration of the change you want to bring about, the assumptions about what underpins the violence being addressed, and a breakdown of who can do what to bring it about. Theories of change also typically involve a lot of technical terminology and phrasings that don’t translate that well to natural language workshops.
As a result, it is important to think about how participation can realistically take place.
The following presents one option for prioritizing community participation in the theory of change design process, adapted from literature on participatory theories of change in the public health and international development sectors.[6] The emphasis of these approaches is on group-based workshops with community members, where all members are free to make suggestions about the changes they want to bring about and the underlying factors driving the problems being addressed. In the case of GBV prevention, this risks doing further harm by asking vulnerable people to describe GBV risks and underlying factors in a non-confidential setting.
As a result, the follow template is suggested for use in confidential 1-2-1 discussions with community case-workers, who can assure the confidentiality of the discussion and already have the trust of the community. As such, it is recommended that these discussions take place alongside ongoing programming with vulnerable persons, rather than through stand-alone program design workshops. It may simply be too time-consuming to cover each of these steps with every vulnerable person consulted. It is suggested, therefore, that program teams experiment with different approaches to test different steps of the design process with different vulnerable people, building up the overarching theory of change by compiling the fragments from different individuals.
| Step | Approach |
|---|---|
| 1. Identify intended outcomes | Present the risk analysis compiled in Module 1 to the community member, and propose top three suggested intended outcomes in response to these risks. Identify both what changes you are hoping to achieve for whom. Ask the community member to propose alternative outcome-level changes they would like to see, prioritizing those with the biggest potential for preventing the forms of GBV that most concern them. |
| Identify possible driving factors | Once the outcomes have been discussed, present the driving factors identified in the GBV risk analysis canvas in Module 1, and ask the community member to challenge any assumptions you have made, or propose other factors behind the types of violence you are hoping to address. |
| Propose activities to tackle this type of violence | Present a selection of proposed activities that your organization can offer in relation to the intended outcome and driving factors. Also include activities that will be needed by other actors and highlight how to collaborate/coordinate with them to ensure they are engaged. Ask the community member to challenge the feasibility and relevance of these activities, and to suggest additions or nuances to those you have proposed. |
| Check causal and background assumptions | Present the list of background and causal assumptions you are making in your emerging theory of change, and ask the community member to challenge, amend or add to this list. |
| Synthesize the outputs | Working with your local GBV advisors and program teams, synthesize the fragments of the discussions above to build the most relevant and coherent theory of change possible, taking care to consider the differential impacts of your activities on different vulnerable persons in the community and to consider what is needed to collaborate with other disciplines to achieve an outcome. |
2.2.4. How to test it
Once developed, it is worth checking the project’s ToC against the core normative standards for quality ToCs. The following checklist has been developed for GBV prevention projects, and is intended to be quick and easy-to-use:
Table 1: Theory of Change Checklist for GBV Prevention[7]
In detail – including intermediate results leading to the ultimate outcomes? No missing links? Conceptually clear – no congested boxes containing several inputs, outputs, outcomes or causal links all lumped together? Presenting the specifics of this program not just a generic type of intervention? Relating to all the relevant domains of GBV risk outlined in a clear risk model?
Context Analysis |
Does the theory of change make logical sense as a response to the specific risks identified in the crisis context?
Are the components of risk (including threat, vulnerability and capacities) well identified? |
Causal pathways |
Are causal pathways well mapped in a logframe or diagram?
|
Assumptions |
Are assumptions made explicit (in the diagram or text) –
Do the assumptions underlying the activities take account of community-capacities to prevent GBV? And of external actors? |
Evidence-base |
Is the evidence for each key hypothesis explicitly outlined?
|
2.2.5. When to make one
The tools presented above have been designed specifically to reduce the time needed to complete them. Any project team that already has a project-specific logframe will already have a full list of activities, intended outputs, outcomes and impacts. Adding causal and background assumptions in this manner should be possible with minimal additional time investment, and should certainly take less time to develop than the logframe itself. This is important given the limited time project teams often have between donors announcing a call for proposals and the proposal deadline.
But the question of when to construct a theory of change, and at what level, is also worth asking. There are at least two obvious points when a project team might want to develop this type of theory of change.
Firstly, during the proposal-writing process itself. Here the aim would be to focus entirely on the project-level logframe, outlining the key assumptions – both background and causal – that underpin this project logic. The theory of change can then be shared with the donor and used to design the monitoring and evaluation framework if the project is awarded.
Secondly, the team might want to develop a theory of change prior to donor appeals being launched. This is most likely in a context where an organisation has a longstanding presence and a previous history of GBV prevention programming. In these contexts, it makes sense to develop project and crisis-level theories of change for GBV prevention. For example, an organisation with five years’ experience of repeated GBV prevention program cycles in South Sudan, could bring together the key stakeholders within the organisation and the communities they serve, to workshop the organisation’s country-level theory of change for GBV prevention. This could start by asking communities and organisational stakeholders what changes they want to see with respect to GBV risk over the next 3 years. The team could then work backwards through different outcomes and activities to identify the types of programming that could contribute to this change. Finally, once this is done, they could identify the fundamental causal and background assumptions behind the work they are doing.
Both of these options have pros and cons, and project teams will need to consider these when deciding when and how to use theories of change for their GBV prevention work. A preliminary list of the advantages and disadvantages of these two approaches is presented below:
Approach |
Advantages |
Disadvantages |
| Project-level TOC during proposal design-stage |
|
|
| Country-level TOC over multi-year time horizon |
|
|
Where possible, a combined approach is recommended, with a wider consultation process taking place at country-level, which feeds into project-specific theories of change designed in a shorter timeframe during project design stage. When done well, this can turn the Theory of Change into a strategic management tool, rather than merely a reporting format. A country- or area-wide TOC can feed into project-specific TOCs which then feed back into revised country-level TOCs, allowing for iterative development of the program team’s strategic direction over several project cycles. The process of doing this on an iterative basis could, hopefully, provide program teams with increased spaces for reflection and decision-making about the strategic direction of their GBV prevention work in-country, which could in turn highlight gaps in current program designs and areas which the organization could prioritize for future fundraising opportunities. This in turn should pay-off in terms of improving the quality and efficiency of the proposal-writing stage.