Often, the stark reality facing the seekers-of-the-brave-new-PDIA-world is this:
But the Donor needs a Logframe!
This would bee case, even in programmes that are committed to adopting the problem-driven-iterative-adaptation (PDIA) approach. Let’s assume that high-level commitments from the donor is in place. Even so, where the rubber meets the road, a logframe is an item in the checklist of requirements for those funds to flow.
Well, fear no more, and watch this Matt Andrews video
Broadly, this video explains how you can adapt your logframe to the PDIA-frame. Matt fittingly calls it a search-frame, reflecting a spirit of iterative learning as we move closer to our goal.
In an earlier post, writing about the ‘results agenda’, I had this to say about logframes:
Have logframes become the blunt hammer in our pursuit of results? Probably. I personally don’t mind logframes as a concept, but detest the way they are usually used. Ideally, a logframe development exercise should reveal the level of complexity of a project design. Those working on it realise during the process that the outcomes that really matter are often misfits in a logframe, because there aren’t clear baselines, nor are there objective and accurate measurement techniques. If a project logframe is then drawn up primarily to satisfy a contractual obligation, it usually sacrifices this complexity and settles for outputs and outcomes that can be easily counted. Donors must resist the temptation to do this.
That may have been all gloom and despair, but I have of course not given up on the logframe. Instead, working with different agencies – donors upstream, as well as implementers downstream – have suggested ways in which we might work a way out of this problem. Some of these are quite simple, and appear obvious. Yet, they require a relationship of trust between different actors in the implementation chain. Here are a few initial ideas:
- Start from the beginning: Ensure that you have a sight of your results framework as you go about designing your intervention. Remember, there is no escaping measurement – every successive iteration of the programme is based on lessons learnt from the previous one. So we are no longer in a world where a programme is fully designed, and then we draw up a results framework/logframe that is ‘fit for purpose’.
- Rethink indicators: Outputs in a PDIA programme are ‘resolved problems’ – for each of the deconstructed small problems. While in a standard logframe, each output has multiple indicators that get scored on the basis of whether the targets have been achieved or not, and the output then gets scored on the basis of the number of indicators that are met. I am suggesting we change the way this works – and have indicators represent the multiple pathways, establishing from the very beginning that not all of these pathways would work. Meaning that as project implementation proceeds, targets for some of the indicators would be met, while some others would not. But we now score outputs on the basis of how far we have moved in terms of tackling our ‘problem’, and not based on the score that each indicator receives.
- Capture progress on processes: Most logframes ignore processes – they concern themselves with only outputs and above. But at the risk of increasing the amount of work involved, there is a case for bringing process indicators into the logframe. Some of these would look like a check-box on activities to be carried out; yet others might focus on key steps that are of importance to the process of change the intervention is attempting – say, a joint meeting of parties involved, the production of a joint manifesto, and so on…
- Logical revision: Matt’s video basically focuses on this: have a clear window and a mechanism for logframe revision at periodic intervals. This is often already the practice, but it is probably fair to say that the overall formulation of the problem (and thereby, the outcomes and outputs designated) remain broadly untouched in this process. (At this point, watch Matt’s video again) It would be great progress if we start tinkering with that, even at a small scale, and accept at the beginning that a programme’s logframe at the end will look nothing like how it did at the beginning. It is important that the rationale for these revisions are honest, and captured accurately. With iterations to your approach as a result of evidence gathered on each ‘bet’, change is inevitable. If the logframe has to keep up with the reality on the ground, this change needs to be captured and represented systematically.
- Empower your team: Make it clear to everyone from the very beginning that data collection and analysis is not the sole responsibility of an M&E officer. Monitoring progress, and results is essentially project management. Therefore, each workstream should have its own decentralised data management system that not only gathers data, but participates in generating lessons from the programme, as well as in iterating subsequent versions of the logframe.
Finally, to borrow a line from the PDIA-crew: All of this might sound like common sense. If so, it might be great to see this all happening in practice too!