Logic models have a basic vertical split — the left side, which has columns for:[1] Resources, Activities, and Outputs represents tangible, practical things which we have are are, things which we do and things which we produce (respectively). The right side, Outcomes and Impact[2] has things which we expect to happen as the result of our outputs, leading to greater change we expect to result overall.
The Logic Model framework has some overlap with OKRs — a popular planning framework which calls for “Objectives” and “Key Results”.[3] The “O” in OKRs maps pretty directly to what logic model calls “impact”[4] And KRs are very similar to items in the Outcomes column — measurable results that show you’ve succeeded.[5]
I’ve observed people working on OKRs many times in practice, and it’s really hard to get right. One of the most common mistakes is putting things you’ll do in the “Key Results” — like, “200 documents written”. That should be something like “20,000 users read the new documentation” — or maybe even better “Percent of users who say we have useful documentation goes from 10% to at least 80%”. Using the Logic Model framework helps avoid this, because with the Outputs column right there, it’s easy to remember that the things you will produce go to the left — and then that helps you think about why that’s the thing being done. [6]
Again, this is really easy to accidentally do[7], as you’re coming up with ideas, either as a team or on your own. I think it’s more a shortcoming of the OKRs framework as a tool than People Are Doing it Wrong[8].
The Logic Model framework helps avoid this — and has other advantages too. If you “nest” OKRs[9], asking on-the-ground teams to have OKRs supporting the organizational ones, there can’t be a direct link, since a good Key Result is never a good Objective, and vice versa. By contrast, the practical side of the logic model can gain more columns if you want to get more granular, and the strategic side can be extended as far as you want to go by alternating columns that answer “what will that do” and “what will that do for us[10]” in turn. And if it’s well-done, you can trace a line from any input (time, money, whatever) to see how it affects the top goal — and back down from the top goal to make sure that you’re asking for the resources you really need.[11]
An OKR can be a nice, tight way to keep on track, but the logic model framework gives more context — which you can actually use.
Note: This whole post was a long tangent at the beginning of something else I’m writing, and I’m trying to follow @bcotton’s advice to me.
Footnotes (because I am still writing like an engineer):
-
usually: some models may have variations, or additional levels ↩︎
-
Again, usually: see below! ↩︎
-
see Wikipedia on OKRs if you’re not familiar ↩︎
-
Although in the model we’re working on for Fedora Strategy 2028, I actually directly added an “Objectives” column, and we focused Impact on answering “But Why?” for the corresponding Objective items — stay tuned to see what I mean. ↩︎
-
and possibly that you’re on the right path along the way. ↩︎
-
More than once, I’ve see whole pages of OKRs where everyting is shifted a column to the left — KRs are Outputs, and the listed Objectives are really KRs (or Outcomes). ↩︎
-
I see it in a examples in a ton of OKR-explainer blog posts, too ↩︎
-
although as with all things business-process-buzzwordy, Some People Definitely Are Doing It Wrong ↩︎
-
as many companies do ↩︎
-
that is, “why” ↩︎
-
Or, if you’re looking at some work you’re doing — an Action — or something someone has asked your team to do — an Output — you can validate that it has a place. ↩︎
