Skip to main content
Repurposing Logic Models

What to Fix First in a Logic Model That's Meant to Be Reused, Not Recycled

Logic models are like old blueprints. They show how a program is supposed to work—inputs, activities, outputs, outcomes. But most of them get used once, for a grant, then filed away. That's recycling: you take last year's model, revision a few labels, and call it new. This article is about something different: repurposing. Making a logic model that can be reused across different programs, years, or contexts without feeling like a stale copy. But to do that, you need to fix the right things primary. Not the formatting. Not the font. The logic. Why This Topic Matters Now A shop-floor trainer explained that the pitfall is treating symptoms while the root cause stays in the checklist. The grant cycle trap: why most logic models are disposable I have watched program directors treat their logic models like tax forms—fill once, file, forget.

Logic models are like old blueprints. They show how a program is supposed to work—inputs, activities, outputs, outcomes. But most of them get used once, for a grant, then filed away. That's recycling: you take last year's model, revision a few labels, and call it new. This article is about something different: repurposing. Making a logic model that can be reused across different programs, years, or contexts without feeling like a stale copy. But to do that, you need to fix the right things primary. Not the formatting. Not the font. The logic.

Why This Topic Matters Now

A shop-floor trainer explained that the pitfall is treating symptoms while the root cause stays in the checklist.

The grant cycle trap: why most logic models are disposable

I have watched program directors treat their logic models like tax forms—fill once, file, forget. That works until the next grant cycle rolls around three months later with a slightly different scope. Suddenly you are staring at a blank template again, starting from scratch. Most groups skip this: checking whether last year's model can stretch to cover a new program. Instead they rebuild the whole thing, because it feels safer. The trap? Safe is expensive. I have seen nonprofits burn two full weeks rewriting assumptions that never changed. A logic model designed for reuse should survive a funding shift, not collapse the moment a new outcome column appears.

The cost of starting from scratch every slot

That feels like wasted phase—but it is worse than wasted. It is corrosive. When you rebuild every quarter, you lose the institutional memory hidden in the old model's arrows and feedback loops. The catch is obvious the second you try to explain a program's theory of adjustment to a new hire: 'Wait, why did we drop the outreach component?' Nobody remembers. The old model is a corpse in a drawer. The real cost is not hours; it is accumulated ignorance. We fixed this in one organization by treating their logic model like a living document—versioned, debated, but never orphaned. The result? They onboarded a new director in two days instead of two weeks.

What happens when a model works for two programs at once

Here is where reuse gets interesting—and dangerous. A colleague once described a youth mentoring model that was accidentally serving as the framework for both a literacy initiative and a substance-abuse prevention program. Same inputs, same long-term outcomes. That sounds fine until you realize the activities for literacy versus prevention are night-and-day different. The model held together on paper. In practice it created a confusion so thick that staff started double-counting participants across both programs. The seam blew out. Not every shared model is a strength—sometimes it is just a lazy shortcut.

'A logic model that fits everything perfectly is a logic model that fits nothing specifically.'

— overheard during a messy post-mortem, after the double-counting disaster

The Core Idea: Reusable Logic vs. Recycled Labels

Recycling: Changing the Name, Keeping the Boxes

I once watched a team take a logic model built for an after-school tutoring program, swap the header to read 'community health workshop,' and call it done. The inputs still said 'trained literacy volunteers.' The outputs counted 'books distributed.' Nobody laughed—they were too busy. That is recycling. You revision the label on the can but the contents stay spoiled. The problem isn't laziness, it's speed—crews under pressure grab the nearest template and rename columns, assuming context is decorative. It is not. A recycled logic model gives you the comfort of structure while delivering the wrong causation entirely. The inputs and outputs mismatch the new environment so badly that the model becomes a polite fiction. Honest—I have seen grant reviewers spot these in under thirty seconds. The giveaway? Every box makes sense on paper but none of them align with how the new program actually fails or succeeds.

Repurposing: Redesigning the Causal Chain for a New Context

Repurposing hurts worse. You keep the bones—the idea that inputs lead to activities produce outputs create outcomes—but you break every specific connection and rebuild it for the new soil. The tricky part is that most people stop after swapping nouns. They keep the same causal arrows and just rename the boxes 'participants' instead of 'students.' That isn't adaptation; that's a search-and-replace job. Real repurposing asks: does this activity still trigger that outcome here? A community health model might keep 'weekly check-ins' but change who runs them and what data gets collected—because trust networks in a clinic differ from trust networks in a housing complex. We fixed this once by taking a youth employment logic model and literally cutting the paper into strips, then reassembling the causal order for a senior digital literacy program. Three arrows reversed. Two outputs deleted. One outcome added. The program director said it felt like dismantling a clock to fix a watch. She was right. That is the whole point.

'A repurposed logic model should embarrass its original—if it doesn't, you just changed the font.'

— overheard at a nonprofit strategy session, after someone admitted their 'new' model was last year's file

The Litmus Test: Can You Drop This Model Into a Different Setting Without Laughing?

Here is the test: Email the logic model to a colleague in a completely unrelated sector—say, a food pantry coordinator if your model is for job training. Ask them to read it aloud. If they finish without once saying 'wait, that doesn't fit here,' you are still recycling. The model should creak under the weight of unfamiliar context. That discomfort signals you actually rebuilt the causal chain. What usually breaks primary is the intermediate outcomes—the ones that assume a specific population trajectory. A housing-opening model assumes stability before employment. Drop that into a workforce program and the sequence inverts: people need income before they can hold a lease. Wrong order. That hurts. But the laugh test only works if you let someone who doesn't know your jargon read it cold. I do this in workshops now. The room goes quiet. Then someone mutters 'we literally just changed the logo.' Correct. That was not reuse—that was deception by template. The fix is brutal: delete the entire outcomes column and write it from scratch for the new context. Keep the format, not the content. Then, and only then, you have something worth reusing.

How to Diagnose a Broken Logic Model

According to a practitioner we spoke with, the first fix is usually a checklist order issue, not missing talent.

Finding the 'activity trap': outputs that are really just tasks

The most common fracture I see in logic models meant for reuse is the activity trap. You list 'conduct workshop' as an output. Fine—but that's a task, not a measurable output. A reusable output is something another team can replicate and count: 'three 90-minute workshops reaching 45 new referrals.' The difference? Precision. Tasks are verbs with a deadline; outputs are countable, transferable units. When I audit a model, the first thing I check is whether each output could survive being handed to a stranger. If it reads like a to-do list for your team, it won't travel. The trap feels innocent—everyone writes 'hold focus groups'—but that label collapses under reuse. Someone else's focus group looks nothing like yours. Wrong order. You need '12 focus groups with 8–10 participants each, recruitment via community partners.' Now it's reusable. Now it's a logic model, not a sticky note.

Spotting vague outcomes: 'improved community health' vs. '30% reduction in ER visits'

Vague outcomes are the second fracture. 'Improved community health' sounds noble. It's also useless. A reused logic model needs outcomes specific enough that another program can measure the same thing, in a different city, on a different budget. '30% reduction in ER visits for asthma patients under 18 within 18 months'—that travels. The tricky part is most groups resist this. They worry specificity locks them in. Honestly—it does. That's the point. Reuse demands fidelity to a target, not flexibility to reinterpret. If your outcome is vague, every new site will define 'improved' differently. Suddenly the model isn't reused; it's renamed. That hurts. The trade-off is real: narrow outcomes mean some teams can't use your model. But broad outcomes mean nobody can use it consistently.

An outcome you can't measure in two different places isn't an outcome. It's a wish.

— paraphrased from a program officer who watched six grantees all claim 'improved outcomes' with completely different data

Checking for hidden assumptions: the logic you didn't write down

What usually breaks first isn't the activities or outcomes—it's the invisible chain between them. Assumptions. Every logic model has them: 'if we train nurses, they will change their screening protocol.' But you didn't write down that the nurses need manager approval, or that the EHR system must be updated first. When you reuse that model in a new clinic, the assumption fails silently. The seam blows out. We fixed this once by asking a simple question for each connection in the model: 'What has to be true for this step to work?' The answers became a one-page assumption log. Ugly. Practical. Reusable. Try this: pick one output-to-outcome arrow in your model. Write down three things that must be true for that arrow to hold. If you can't name two, your model is hiding assumptions that will ambush the next user. Not yet caught? They will be.

One more diagnostic: check your model for orphaned logic—where an output points to nothing, or an outcome appears with no supporting activity. That's a sign someone copied a template and didn't finish the edit. We see it constantly. A reused model can't have loose ends; every node must serve a transferable purpose. Otherwise you're recycling labels, not logic.

A Walkthrough: Fixing a Community Health Model

The original model: after-school program for teens

Here is what we started with—a logic model built for a youth after-school program in a mid-sized city. It was clean, funded, and had run for three cycles. Inputs: trained youth workers, a school gymnasium, snack funding, a van for field trips. Activities: homework help, basketball leagues, one-on-one mentoring. Outputs: hours of programming, attendance rates, number of referrals to counseling. Short-term outcomes: improved grades, lower truancy, stronger peer relationships. Long-term: high school graduation and reduced juvenile justice contact. Nothing flashy. It worked because the inputs matched the outcomes—the van got teens to the gym, the gym kept them engaged, the mentors knew how to talk about prom stress. But then a different organization asked us to adapt it for a senior wellness program in the same neighborhood. That’s when the seams showed.

What broke when we tried to reuse it for a senior wellness program

We dropped the model into a new population without rethinking the assumptions, and honestly—it was a mess. The inputs didn’t travel. The van? Seniors needed door-to-door medical transport at 7 AM, not 4 PM field trips. The gymnasium? Arthritis-friendly chair yoga needs a flat floor with grab bars, not basketball hoops. The mentors? Youth workers knew gang prevention; they didn’t know fall-risk screening or medication management. The activities section listed “homework help,” which for seniors translates to “help with Medicare forms”—a completely different skill set. And the outcomes? The original model measured truancy reduction; the senior program needed social isolation scores and blood pressure readings. The broken part wasn’t just the labels—it was the logic chain itself. The causal link between “van ride to gym” and “improved health” for teens came from structured, supervised play. For seniors, that same link required chronic disease education and a nurse on site. We kept the boxes; we lost the arrow.

That hurts more than a wrong label. A recycled model looks right on paper but delivers wrong results—attendance spikes but health outcomes flatline. The catch is that most teams stop at swapping nouns (“teens” to “seniors”) without checking whether the theory of change still holds water. They think reuse means search-and-replace. It doesn’t.

“We kept the box labeled ‘transportation, ’ but the seniors needed a different kind of trip with a different kind of driver for a different kind of destination.”

— notes from the model redesign session, four weeks in

The fixed version: what we changed and why

We rebuilt the model from the middle out. Not the inputs—the core activities. First, we asked: what is the actual output that enables health? For teens: structured social window in a safe, supervised space. For seniors: safe social time plus chronic condition monitoring plus mobility assistance. Three outputs, not one. So we split the activities row: van service became “medical appointment transport + pharmacy pickup,” the gym became “low-impact movement class + blood pressure station,” and mentoring became “health navigation check-ins with a community health worker.” The outputs changed from “number of basketball games played” to “number of medication discrepancies caught”—a different metric entirely. Short-term outcomes shifted from “improved grades” to “reduced 30-day hospital readmission.” We kept the same general format (inputs → activities → outputs → outcomes), but we broke the assumption that one structure serves two populations just because they share a zip code.

Trade-off: splitting activities doubled the staffing cost. We lost the economy of scale that made the teen model cheap to run. That’s the pitfall of reuse—you can repurpose the framework, but you cannot repurpose the funding formula. The fixed model added a nurse part-time and a van schedule rewrite. It also dropped the basketball equipment line entirely—no more gym rental, which offset some of the new cost. We ended up with a model that looked structurally similar but was wired different on every row. The logic chain now ran: “transport and monitoring → increased medication adherence → reduced ER visits.” That’s a different theory than “van to gym → supervised play → better grades.” Both are valid, but they are not interchangeable. The fixed version also added a feedback loop: monthly check-ins where senior participants told us if the van time was too early or the blood pressure station felt rushed. The teen model didn’t need that—teenagers just stopped showing up if something was wrong. Seniors stayed quiet and got non-compliant. Different signal, different fix.

Now the model is reusable—not because the labels are generic, but because the logic repair process is documented. Next time a team wants to shift from seniors to homebound adults with disabilities, they won’t swap nouns. They’ll run the same diagnostic: does the activity still produce the output? Does the output still produce the outcome? If not, rewrite that row. The walkthrough left us with a template for the question, not a template for the answer. That’s the distinction worth keeping.

Edge Cases: When Reuse Gets Tricky

Multi-site programs: one model or many?

The trap is elegance. You build one perfect logic model for a pilot site—clean inputs, tight activities, straight-line outcomes. Then a funder says 'scale it to five cities.' Suddenly the model that looked pristine becomes a straightjacket. I have seen teams force-fit a rural health program into an urban model and watch the 'community engagement' box become a dead weight. The trade-off is brutal: one model gives you comparability across sites, but it also masks local context. What usually breaks first is the 'activities' column. A food distribution program in a city with strong infrastructure looks radically different from one in a flood-prone region—same intended outcome, completely different path to get there. The fix is not a single model. It's a core model with site-specific overlays. Keep the central 'theory of change' fixed—that's your reusable spine—but let each location rewrite the activities and short-term outputs. That smells messy to grant writers. Good. Messy is honest.

Time-bound grants: how to plan for a model that ends

Most logic models assume permanence. They map a steady state where inputs flow forever and outcomes accumulate year after year. But a three-year grant with no renewal clause? That model needs a different architecture entirely. The catch is that long-term outcomes—reduced recidivism, improved literacy—rarely show up inside a funding window. So teams fudge. They stretch short-term outputs and call them outcomes. '150 people attended training' masquerades as 'workforce readiness improved.' Wrong order. For a time-bound model, the reusable part is the monitoring framework, not the outcome story. Build your logic model so that the three-year output data feeds someone else's long-term model down the line. That means designing outputs that are standardized enough to be useful outside your grant's lifespan—metrics on attendance, dosage, demographic reach. Not sexy. But it keeps the model from becoming landfill the day the money stops.

Funders with conflicting definitions of 'outcome'

'We want measurable behavior change, but no, surveys don't count.'

— frustrated program director, overheard at a grantee convening

That is not a logic model problem—it is a language war. One funder calls 'increased knowledge' an outcome; another insists only 'reduced hospital visits' qualifies. Map both definitions onto the same model and you get a contradiction in the middle column. Most teams skip this: they build two models, one for each funder. That doubles your work and destroys reuse entirely. A better edge case fix: separate your model into proximal outcomes (knowledge, skills, attitudes) and distal outcomes (behavior, health status, system change). Then label each row clearly with what evidence type qualifies. 'Proximal outcome: verified by pre/post test (funder A acceptable). Distal outcome: verified by claims data (funder B requirement).' The model itself stays intact—you just add a metadata layer. One more hard truth: if two funders' definitions are genuinely incompatible—like one demands attribution and the other accepts contribution—no logic model can bridge that gap. Honesty about that limit saves months of wasted alignment meetings.

The Real Limits of a Reusable Logic Model

No model survives contact with a new funder

The hard truth—a logic model that worked beautifully for the city grant will gag on the foundation RFP. I have watched teams spend weeks polishing a single diagram, only to submit it to a new funder who uses entirely different outcome categories. The model itself is fine. The labels are wrong. Most teams skip this: a reusable model must be structurally neutral, not content-specific. If your logic model says 'reduce recidivism by 12%', you have already locked yourself into one funder's language. Swap the sector instead—replace 'justice-involved youth' with 'first-generation college students'—and the causal chain often holds. The catch is that funders reward precise language, not adaptable structure. They want to see their own vocabulary mirrored back. That is the moment reuse becomes a liability: you either rewrite the model for each submission, which defeats reuse, or you keep the generic frame and risk sounding vague. Pick your poison.

When you should just start over (yes, really)

The bizarre thing is how long teams cling to a broken frame. A donated logic model from a different program area arrives, and everyone nods—'We can adapt this.' Six weeks later the seams blow out. The assumptions are wrong. The causal links were built for a population with housing stability, and your group faces eviction. Straight reuse masks deeper mismatch. I have seen a youth employment model get bolted onto a senior nutrition program; the only thing they shared was the word 'outreach'. Start over when your inputs diverge by more than one variable—when staff, setting, or population shifts radically. Not yet. That hurts. But a forced fit costs more in confusion than a clean sheet costs in time. One honest afternoon of diagramming beats three weeks of editing a foreign model into something that never quite fits.

The trade-off between flexibility and clarity

Here is where the rubber meets the road: every time you make a model more reusable, you sand off a detail. Detail is what makes the logic convincing to skeptical colleagues. Detail is what shows your board that you understand the specific mechanism at work. So you face a real trade-off, not a happy middle ground. A highly flexible model—one with blank slots for short-term outcomes, with 'if applicable' stages—reads like a choose-your-own-adventure book. Nobody wants to fill in the blanks every single quarter. What usually breaks first is the clarity: the model becomes a container for anything, which means it explains nothing.

The trick is to identify which parts must stay rigid.

  • Core assumption linkage: this row does not bend. If you swap cause and effect, the whole thing collapses.
  • Measurement indicators: these can flex across funders, but the metric type (count vs. percent vs. narrative) should stay fixed.
  • Population descriptor: this is where most reuse fails. Make this the only truly replaceable slot in the diagram.
'Reuse is a discipline, not a shortcut. If you cannot name what stays constant, you are not ready to reuse.'

— Program officer, after her third recycled logic model submission

That sounds fine until the funder demands a logic model that matches their exact template, column by column. Then reuse becomes recycling—you are just relabeling last year's outputs. The honest move: build two models. One is your internal engine, reusable and structurally sound. The other is a translation layer, written fresh for each audience. You lose the purity of a single diagram, but you gain something better—credibility. Do not aim for one model to rule them all. Aim for one core logic and a thin wrapper that changes per funder. That is the real limit of reuse: it stops where institutional language begins.

Share this article:

Comments (0)

No comments yet. Be the first to comment!