How-To Note: Developing a Project Logic Model (and its Associated Theory of Change)

Comments (1)
Organization(s):
Date Published:
September 1, 2017
Contribution:
USAID Official
Toolkit(s):

This How-To Note describes considerations for developing a project logic model, as well as steps for thinking through a more complete theory of change (TOC). A logic model is a graphic or visual depiction that summarizes key elements of a TOC, and it is often used as a facilitation tool during the design process. There are many types of logic models, including but not limited to logical frameworks (logframes), results chains, results frameworks, and local actor-oriented models, among others. The project logic model and its associated TOC are included in the Project Appraisal Document (PAD) that approves a project design (see ADS 201.3.3.13).

While this How-To Note focuses on logic models at the project level, logic models are also used at the strategy level (specifically, results frameworks – see Box 1), and often at the activity level. The concepts and steps presented here are generally applicable to the process of developing logic models and TOCs throughout the Program Cycle.

COMMENTS (1)

It’s great to see this new How-to-Note on the important topic of the logic model/TOC. We’ve recently evaluated a large, complex program without either and not surprisingly it’s been a struggle to assess whether the intended impacts have been achieved, and when not, why. It’s not too much to assert that the correct type of a well-prepared logic model/TOC is part of the Program Cycle’s foundation.

When developing any type of logic model/TOC it’s important to consider the type of logic or reasoning to use. People generally think in terms of two types of logical reasoning: deductive and inductive. The second is what is normally used to construct the development hypothesis associated with the TOC. Depending on the type of development challenge being addressed, there is a third type of logical reasoning that may well be better suited for the task. This is known as “abduction” and it particularly useful in situations of greater uncertainly and complexity – which includes many if not most development problems. Abductive logic starts with an incomplete set of knowledge and observations and proceeds to the likeliest possible explanation for the set; i.e., the hypothesis.

Abduction is the predominate type of reasoning used in medical diagnosis, and is also widely used by juries when hearing trial evidence. Many believe abductive reasoning involves a greater degree of creativity and even intuition than the other forms of logic. It is the basis of what has become known as “design thinking,” which I can attest to as someone trained in design and then who served as a USAID Project Design Officer.

I was also pleased to the emphasis placed on assumptions, and that the author of the note distinguishes between assumption types (e.g., programmatic, contextual, explicit, implicit, key & critical, etc.).  As the note states, all should ideally be monitored. This is no easy task. One tool to consider, for those of us that are interested in this important and fascinating area, is “assumption-based planning,” originally developed by the RAND Corporation. Today, the available literature on it largely pertains to its use in the business world, but the potential utility for CLA-oriented development efforts is huge. At a minimum, identified critical assumptions central to a TOC must be periodically tested – which is a central feature of assumption-based planning - and if no longer valid then adaptive management steps employed in response. Such a procedure should be covered in the MELP of any project with a “complexity-aware TOC.”

Finally, it should be remembered that during the last decade or so use logic models fell out-of-favor among some development practitioners and other approaches were developed as an alternative; e.g., Outcome Mapping. This was due to a sense, again, held by some but not all, that the USAID Logical Framework and other similar models were too rigid and inappropriate for the real world of development work. Although I have developed more than my share of LogFrames, I have some sympathy for this view.

While the standard logic model/TOC may be appropriate for “intended” (or “deliberate”) strategies/project design, I think not for what are known as “emergent” strategies/designs which should be more widely used in development practice. This “design thinking” approach aligns very well with abductive reasoning and the challenges of uncertainty and complexity.  What is needed is a type of logic model/TOC with the concept of emergence built into it for use when these types of challenges are faced.

posted 2 months ago