The 'Lock' Frame

I recall the first time I had to develop a logframe. I had no idea what I was supposed to do. I couldn’t see how the boxes all linked together, I felt that the information it contained was repetitive, I had no idea what my colleagues were talking about when they carried on about ‘assumptions.’ I wanted to cry. I wanted to quit. I was pretty sure this was something I never wanted to have to work on again.

15 years later, I have a far different view of logframes. Once I had understood them – once someone had decoded them for me – I understood their utility. They are a project organizational tool; they are an accountability tool; and they are basically the (over)simplification of projects aiming to address complex issues. However, while I appreciate their utility in some respects, I am also aware of just where they fall short.

Over the past five to six years, the development community has come to recognize that development programming is ineffective if it pretends to be able to address complex issues with simplified, linear, cause-effect projects. We all know this, and we have all spent time drafting reports where we jump through creative hoops to demonstrate why project X has created sustainable change on issue Y. We are generally forced to do this because no matter how much we acknowledge that development is complex, a majority of projects are required to simplify their work by shoe-horning it into a logframe, or a ‘lock’ frame as it has come to be known in my household.

In and of itself, the logframe is a good tool. The challenge that we face in using it tends to be its external limitations: rigid donor requirements to demonstrate linear cause and effect, overly bureaucratic processes to change anything within a logframe, and the logframe set up itself: we start with outcomes and proceed down the line to assumptions, rather than starting with assumptions and seeing where that leads us.

In a world where development practitioners are pushing for more adaptive management in recognition of complexity and the need to do development differently, we cannot be pushed to lock ourselves into a logframe. We need to talk to our donors about the appropriateness of the tools they want us to use vis-a-vis the project they want us to implement. We need to look at what tools work better where: in adaptive management, logframes may not be best placed as overarching project monitoring tools, but better used at the activity level, for example. Or they better placed for use by certain types of projects as opposed to others (infrastructure vs capacity building or advocacy). In my upcoming book, I dissect the most common tools used for monitoring in development programmes (and some not so common) and identify which tools/approaches may be more appropriate for which type of intervention as we pursue more adaptive programming.

As I have argued previously, approaches to development are rapidly changing, and those of us in the M&E field need to stay in step with those changes if we are to ensure that our programmes remain relevant and initiate sustainable change. Breaking out of the ‘lock’ frame will be a necessary step forward.