AEA365 | A Tip-a-Day by and for Evaluators

Jan/17

29

A Pathway to Logic Modeling Freedom by Kirk Knestis

Kirk Knestis, CEO of Hezel Associates and huge logic model fan, back on aea365 to share what I think are useful tweaks to a common logic modeling approach. I use these “Conditional Logic Models” to avoid traps common when evaluators work with clients to illustrate the theory of action of a program or innovation being studied.

Rad Resource – The W.K. Kellogg Foundation’s Logic Model Development Guide is an excellent introduction to logic models. It’s very useful to getting started or to ensuring that members of a team are on the same page regarding logic models. The graphic on the first page of Chapter 1 is also a perfect illustration on which to base description of a Lesson Learned and some Hot Tips that inform the Conditional Logic Model approach.

Lesson Learned – Variations abound, but the Kellogg-style model exemplifies key attributes of the general logic model many evaluators use—a few categorical headings framing a set of left-to-right, if-then propositions, the sum of which elaborate some understanding of “how the program works,” as such:

Inputs > Activities > Outputs > Outcomes > Impact

While the multiple levels of “intended results” (Outputs to Impact, above) provide some flexibility and accommodate limited context and complexity, program designers or managers often get bogged down in the semantic differences among heading definitions. Alternate labels may help but even then, clients and evaluators are either constrained by the number of columns, or have to work out even more terms for headings.

Hot Tip – Free yourself from labels! Rather than fussing over these terms, leave them out completely. Instead, define each element—still in its left-to-right structure—as a present-tense statement of a condition. For example, the Input “Running shoes” might become “Running shoes purchased.” The Activity “Run 3x per week” becomes “Exercise increases.” The Outcome “Weight will decrease” becomes “Weight decreases.” This mostly requires using passive language for Activities, but also necessitates thinking of what results look like once achieved, rather than describing them as expectations. These changes in semantic structure eliminate confusion about terms, and head off issues related to tense. The lack of constraining headings also accommodates the complexity and context often left out of typical logic models (e.g., our US Department of Labor projects, illustrations of which require 12+ columns).

Hot Tip – Translate the logic model into evaluation data needs by considering measures of quantity and quality for every element of the model, irrespective of where it falls in the chain of logic. Address the extent to which, and the quality with which, each condition is realized. One interesting note, in this approach Outputs become part and parcel to those measures, rather than pieces of the causal puzzle, but that’s an additional post.

Do you have questions, concerns, kudos, or content to extend this aea365 contribution? Please add them in the comments section for this post on the aea365 webpage so that we may enrich our community of practice. Would you like to submit an aea365 Tip? Please send a note of interest to aea365@eval.org . aea365 is sponsored by the American Evaluation Association and provides a Tip-a-Day by and for evaluators.

·

1 comment

  • Tom Chapel · January 29, 2017 at 6:04 pm

    Thanks for this nice post. A few kudos and comments: (1) Yay. I like the idea of using the outputs to help come up with measures. I think that’s been very helpful to show clients how thinking about outputs add value (2) I like the idea of getting rid of column labels in early stages, but with my own clients I take it further and build the early models using only activities and outcomes and then layer in the other stuff. But do see the advantage of your approach in some cases (3) BUT, while I do see some advantages is using common syntax for activities and outcomes, I do worry that you’ll lose the ability of the LM approach to distinguish the “what” of the program from the “so what”. With my clients, that is actually one of the most clarifying–even if depressing–parts of logic model exercises. If I DO this, then THIS should result. But can see how your approach might be helpful as a first step and then convert the statements to activity lingo in a next stepZ?

    Reply

Leave a Reply

<<

>>

Archives

To top