ToC

Why We Should Have Developed our Logic Model before Our Project Narrative — Not the Other Way Around

This blog post was written by the Monitoring and Evaluation Technical Assistance (META) Project and is included as an archived post on the Switchboard blog.

It’s tempting to start out program design by drafting a narrative. After all, we know what we want to do, many approvals may be needed, and deadlines are looming! But when a program’s initial foundation is a narrative description, rather than a thoughtful theory of change, problems can pop up long after an award is received: confusing activities, hard-to-measure indicators, unachievable outcomes and objectives, and difficulty explaining the purpose and results of a program and how they were achieved.

Staff of one refugee case management program told META they learned this the hard way. Their logic model was a product of the “narrative first, logic model second” methodology. Take a look at their logic model and some of the issues that made themselves clear midway through Year 1.

Staff would likely have noticed these pitfalls if they had held a meeting to develop and test their theory of change rather than just populating their logic model with text from their narrative. They would have developed their project model by working carefully backwards, focusing on the outcomes they want to achieve for clients and the results that need to be seen in order to achieve those outcomes, rather than starting with activities. They would have also tested the theory of change using “if-then” statements. And they would have asked, for each output, outcome, and objective: “Is this clear?” “Why is this important?” “Is this feasible?” and “How will we measure this?” For example, they might have asked whether this statement made logical sense: “If 85% of clients move from “at-risk” to “safe” in one or more assessment categories, then an enhanced referral and support network will be established for a minimum of 500 clients.“ The answer would have been “No.”

Six months in, staff were stuck: They weren’t easily able to explain the logic behind their program or demonstrate the results of their efforts. And they had come to see that results they were tracking were not the right results to track. They had no choice but to explain these issues in reports, then amend their design, indicators, and targets for Year 2. Concentrating on their theory of change initially would not only have prevented some headaches, it would have helped them implement a stronger program from the start, with clear focus on what they wanted to achieve, how they would do it, and why it was important.

A revised logic model for Year 2 might look something like this. It’s not perfect. They rarely are! But the theory of change is clear, the logic seems sound, and the results are more specific and measurable.

So, save yourself time down the line: start your project design process by developing and testing your theory of change. Take the time during that process to think about how you will measure results. Then, develop a logframe and write your budget and project narrative.

 

Related Content

More Posts