What if you spent five days getting the learning architecture right at the start?
Have you ever developed a project proposal with a slight sense of dread?
You can have a perfectly sensible intervention. A clear set of deliverables. A committed implementation team. You can even deliver exactly what you promised. And still find that very little shifts because the surrounding system does not move with it. I keep coming back to that.
We have become much more interested in systems thinking in the development sector, but I wonder whether we still bring it in too late. We talk about systems when we evaluate programmes, or when we are trying to understand why outcomes did or did not happen. Maybe we should be doing more of that thinking right at the beginning.
The same goes for Theory of Change work. We have known for years that participatory approaches matter in evaluation. When implementers sit together and work through the logic of a programme, the value is not only the diagram they produce. Quite often, the useful bit is the conversation that happens before everyone agrees on the arrows.
Bring the funder into that conversation and it gets even more interesting. You start surfacing expectations, assumptions and constraints on both sides. Sometimes people discover that they have been using the same words to mean slightly different things.
The process matters as much as the diagram.
A Theory of Change is much more useful when the diagram is the record of a good conversation, rather than the purpose of the exercise. And once that conversation gets going, the questions tend to change.
- What problem are we actually trying to change?
- Who else is working on it, and what have they learned?
- What do we think will make a difference, and what has to be true for that to happen?
- What should we pay attention to while implementation unfolds?
- If the programme hopes to influence a wider system, what would we expect to see changing beyond the immediate project results?
And perhaps the question I like most:
What are we genuinely trying to learn?
That is where the Theory of Change starts becoming something more useful. It becomes the beginning of a learning architecture:
Theory of Change → indicators and evidence → learning questions → reflection and reporting → evaluation → adaptation and future decisions.
So how might we do this differently?
One approach we are increasingly interested in is to spend a small amount of concentrated time up front with people who understand the sector, can work practically with indicators and evaluation design, and are willing to ask the difficult questions.
Not only:
“How will we measure whether this worked?”
But sometimes also:
“Should we really be doing this?”
We think five focused days can create useful space for that work. Not five consecutive days sitting in a workshop room. Some of it is better face to face. Some can happen in focused online sessions. And some is technical work between engagements: reading documents, testing the logic, refining indicators, and working the emerging thinking back into the Theory of Change and Learning Agenda.
Days 1–2: Understand what we are dealing with
The first part is really about getting to know the territory. And by territory, I do not only mean the intervention. We want to understand the organisation around it too. What is the strategy? How is long-term progress already being tracked? What does management need to know? What does the Board expect to see? What are the contractual reporting requirements? How strong is the internal M&E capacity? What is the reporting rhythm? How does the organisation actually learn?
Those things matter more than they sometimes appear to. You can design a beautiful framework, but if nobody has the time or systems to collect the information, it is not going to help much. We also want to understand what the organisation means when it talks about systemic change.
- Is the programme mainly expected to deliver a defined set of outputs and outcomes?
- Or is there also an expectation that it should influence relationships, institutions, practice, policy, funding decisions or the behaviour of other actors?
Then we look outside the programme.
- Who else is working on the same problem?
- What are government, funders or civil society organisations already doing?
- Where might there be duplication?
- Where are the gaps?
- Is there somebody the programme should probably be talking to?
We are not pretending that two days gives you a systems map. It doesn’t. But you can learn quite a lot by simply asking who else is working on the problem and what they already know. Sometimes that changes the programme logic quite substantially.
Days 3–5: Work on the Theory of Change, measures and Learning Agenda
Then we get into the technical work. We use whatever already exists. That might be a Theory of Change diagram, a logframe, an indicator matrix, a proposal, a strategy document, a contract — or several of these that do not quite agree with each other. That happens more often than one might hope. The point is not to replace everything. It is to work out whether the different pieces tell a coherent story.
- What is the intended change?
- How is the programme supposed to contribute to it?
- What assumptions are we making?
- What might get in the way?
- Which parts of the logic are reasonably within the programme’s control, and which depend on other actors or on the wider system?
This sounds like quite a technical distinction, but it changes the conversation a lot.
- What are we actually accountable for?
- What are we hoping to influence?
- And what are we still genuinely uncertain about?
I think those are much better questions to sort out at the beginning than halfway through an evaluation. Then comes the other very practical question:
What can we actually measure and report on?
Not what would be lovely to know if we had unlimited time and data.
- What can this programme realistically track?
- Which indicators are meaningful?
- Which are feasible?
- Which ones will somebody actually use?
- And which ones are we collecting because they have somehow always been there?
From there, we can start building the Learning Agenda.
- Some information is needed to manage implementation.
- Some is required for formal reporting.
- Some matters because management or the Board needs it.
- And some questions are worth returning to simply because we do not know the answer yet.
That last category is important. Not every question needs an indicator. Not every indicator needs to be discussed every month. Not every interesting issue needs an evaluation. And not everything worth learning can be reduced to a number. We also need to decide how the learning will actually happen.
- What gets discussed regularly?
- What belongs in a formal report?
- What should trigger a deeper conversation?
- Where would a deliberate Learning Moment help?
- What might need a more rigorous evaluation later?
- And how will what we learn actually feed back into decisions?
That, for me, is the point.
The result should not be another MEL document that sits on a shared drive. It should be a shared understanding of what the programme is trying to change, what it can reasonably be held accountable for, what sits outside its control, and what everybody wants to keep learning while the work unfolds.
Five days will obviously not solve everything. But I suspect five good days at the beginning can save a lot of confusion later. And perhaps more importantly, they can get some of the difficult questions onto the table before the programme architecture hardens around them.
