Blog

Evaluating Systems as Systems and Using that Knowledge to Inform Program Evaluation

There is much talk about how our programs are (or should be) thought of in terms of systems, and quite a bit of progress is being made toward that end. But there is a difference between: • evaluating programs in terms of systems, and • evaluating the systems themselves, i.e. abstracting the system structure from the details of a program. The purpose of this document is to take a stab at the latter. Why bother? For two reasons. First, Understanding the system that underlies a program will help us understand the program. Second, similar systems structures may indicate similarities across seemingly disparate programs.

The Logic in Logic Models Part 2:

This is the second of two blog posts on the logic in logic models. (More will come in the future.)I discuss three levels of model specificity. The first is the siloed model that is specific only at a high level of abstraction (e.g., outputs --> outcomes). This model form lists, but does not specify relationships among elements within each high-level category. The second form is the “box and arrow” layout that is so common in evaluation. The third adds to the “box and arrow” form with additional information on relationships, e.g., designations of how strong or likely relationships are likely to be.

The Logic in Logic Models Part 1: Extending Models in the Directions of Less, and More Specificity

I’m working on a series about the logic that can/should be contained in logic models. This is the first in the series . It’s message is that the range of knowledge that can be reflected in a model can be extended in two ways. One is toward less specificity and detail. One is toward more specificity by designating connections in AND/OR terms. Either tactic can be appropriate, depending on the circumstances.