1. ergh: used when in a state of disgust, confusion, frustration, or convulsion. “ergh, I just threw up all over the keyboard.” “ergh, that’s wrong.” (from Urban Dictionary)
It’s proposal purgatory time at the aid agency where I’m currently working. And one of the joys, the inescapable joys of this time, is completing the accompanying logframes.
Knowing that I would have to help a variety of programs complete one-year (!) logframes in a uniform format as required by the donor would be one of my tasks last week, I did the most logical thing a person could do in this situation–I read up on and compiled a list of all the reasons logframes come up short. (This page, Working with the Logical Framework: Under duress or by desire, from MandE News was really helpful.)
Ok, maybe that’s not the most “logical” thing to do. But I do think that an understanding colleague is what most program folks need most to get through the frustration of this exercise, which in this case was ultimately about filling in the boxes, a hoop to jump through to obtain funding.
Don’t get wrong. I love a good logframe. I love the conceptual thinking (culturally-specific as it is) that goes into them. I love the concise representation of the key elements of a project. I love the articulation of what is supposed to happen, the results we’re after, and the assumptions we’re making, all providing a basis for M&E activities (though often not for organizational learning).
The predictable, linear, rational progression of activities is what can make a sound logframe clear and elegant. But this predictable, linear, rational progression of activities is also what can render a logframe useless in the context of providing relief and fighting poverty and injustice.
In spite of any amount of bellyaching on my or anyone’s part, the logical framework and the logical framework approach is not going away any time soon. Thus I think it’s important for aid workers to be aware of its purpose and its limitations.
First, let’s understand where logframes came from:
“Its origins lie in a planning approach for the US military, which was then adapted for the US space agency NASA before being adopted by USAID for development projects over thirty years ago. It was picked up by European development organisations in the 1980s and by the end of the 1990s the LFA (or an adapted form of it) had become the standard approach required by many donors for grant applications (Hailey & Sorgenfrei 2004: 7).” In “The use and abuse of the logical framework approach” by Oliver Bakewell and Anne Garbutt for SIDA, 2005.
If we’re honest, for most aid workers or grant seekers, completing a logframe is rarely an exercise that is completed in a participatory or even a consultative manner with the people we aim to serve. Logframes’ origin demonstrates why they are not tools that lend themselves easily to ongoing, participatory decision-making. Decisions are made by the generals. Logframes tell the soldiers what to do.
One of the most common criticisms of logframes is that they assume a constant environment and they do not (or cannot by their very nature) represent local realities. Rigid? Over-simplified? Yes. But remember logframes were originally used to move and deliver resources, to achieve an end, to carry out orders to defeat “the enemy.”
But what about the means to that end? There is certainly no place for descriptions of step-by-step processes in a logframe. No place to help us understand the relevance of the activities being carried out to those benefitting. No place to understand the relationship between vulnerability, assets, policies and politics. But if your army is trained coherently and responses to changing circumstances are entrusted to the chain of command, understanding how something happens must not be important for the implementers. This is not true however for development programs.
Any good aid program manager worth their salt knows that logframes are not sufficient in and of themselves for project planning and management. A data collection plan and ways to track and compare indicator measurements over time are necessary if there’s any chance of reporting results down the road. Only looking at a logframe when the proposal goes in and then again when the first report is due ends up in lots of “estimated” reporting of project results. (I’m working on an upcoming post on this issue. Hint to donors: It happens more often than you think, and most often it’s due to your impractical requirements.)
Obviously these are not new or revelatory insights. Ultimately, M&E and learning activities, including the results frameworks within logframes, have to be feasible and realistic given programmatic and on-the-ground realities. Luckily there are efforts underway by agencies to modify logframes to be more flexible and adaptive, as well as to quantify qualitative stories of change at the community level. When these efforts will influence donors and trickle down to alter people’s day-to-day work is yet to be seen.
The question is—how do we get beyond logframes’ use within the aid industry as merely a bureaucratic requirement? The challenge for aid workers, grant makers, and grant seekers is to ensure we are not just going through the motions with logframes, using them as a claim that we care about results rather than a tool to help achieve them.
In the meantime, I guess I’ll be there to as a “technical support” to hold the hands of project managers, to continue to try to de-mystify logframes’ inherent concepts. I just hope that before then, they don’t throw up on their keyboards.