La trampa de la Teoría de Cambio: por qué la mayoría luce bien en el papel pero se desmorona en la práctica

He trabajado con suficientes marcos lógicos, diseños de programas y marcos de resultados como para reconocer un patrón: la teoría de cambio que sonaba blindada en el taller de propuesta empieza a resquebrajarse hacia los tres meses de implementación. No porque el equipo no haya sido cuidadoso. No porque el contexto fuera imprevisible. Sino porque ciertas debilidades estructurales estaban ahí desde el principio, esperando en silencio.

De eso trata este artículo. Quiero nombrar esas debilidades con precisión, explicar por qué importan y darte una manera de poner a prueba tu TdC antes de que estés en medio de un año de programa preguntándote por qué la cadena causal no está funcionando.

Lo que una Teoría de Cambio realmente debe hacer

Antes de diagnosticar los fallos, conviene tener clara la vara con la que medir. Una teoría de cambio no es un diagrama. No es un resumen de tus actividades. Es, como lo describe la Guía Práctica del CRS, el "flujo lógico entre un problema clave y sus causas inmediatas y estructurales, el cambio a largo plazo que se busca provocar… y lo que debe ocurrir para que ese cambio se produzca" [1].

La Guía Complementaria del UNDAF añade una dimensión fundamental: una buena TdC debe articular las causas del problema de desarrollo, explicitar los supuestos sobre cómo la estrategia propuesta generará resultados, y contrastar esos supuestos con la evidencia disponible, incluyendo lo que ha funcionado y lo que no en el pasado [2].

Esa última parte es donde la mayoría de las TdC se saltan un paso en silencio. Articulan las causas. Describen el cambio deseado. Pero tratan los supuestos como decoración de fondo en lugar de como estructura de carga.

📝 Nota: Una teoría de cambio y un marco de resultados están relacionados, pero son cosas distintas. El marco de resultados muestra qué se medirá; la TdC explica por qué esos resultados deberían ocurrir. Confundir los dos es una de las puertas de entrada más comunes a los fallos que describo a continuación [1].

Los cinco modos de fallo recurrentes

1. Supuestos escritos como decoración, no como riesgos reales

Toda TdC tiene una columna o recuadro de supuestos. En la práctica, casi siempre dice algo como "los miembros de la comunidad están dispuestos a participar" o "las contrapartes gubernamentales mantienen su compromiso." Son consideraciones reales, pero listarlas como notas al margen de una línea las trata como letra pequeña en lugar de como las juntas estructurales que sostienen toda la cadena causal.

La revisión del DFID sobre el uso de teorías de cambio en el desarrollo internacional encontró que los supuestos suelen estar insuficientemente especificados y raramente se retoman una vez que el programa comienza [3]. La Fundación Annie E. Casey señala que en entornos complejos, donde el contexto operativo es "fluido e impredecible", hacer que los supuestos sean genuinamente explícitos resulta especialmente crítico, porque el propio entorno puede influir en la estrategia o la implementación de maneras que no se anticiparon [4].

Documentar supuestos correctamente es muy diferente de lo que los equipos suelen producir. Cada supuesto debería:

1. Estar formulado como una condición verificable, no como un deseo
2. Tener asignada una valoración de probabilidad (alta/media/baja)
3. Estar vinculado al paso causal específico que sostiene
4. Tener asociado un disparador de monitoreo que indique cuándo empieza a fallar

⚠️ Advertencia: Si tu lista de supuestos pudiera pegarse en un proyecto diferente, en un país diferente, sin cambiar una sola palabra, es probable que tus supuestos no sean lo suficientemente específicos para ser útiles.

2. Lógica causal ausente entre productos y resultados

Esta es la brecha que encuentro con más frecuencia. Una TdC describe un conjunto de actividades, pasa a los productos (número de personas capacitadas, materiales distribuidos, agentes de salud certificados) y luego da un salto a un resultado como "mejora de la seguridad alimentaria en los hogares" o "mayor participación cívica." El mecanismo que conecta el producto con el resultado sencillamente no existe.

La guía del CRS es explícita: la TdC debe mapear no solo los cambios deseados, sino "lo que debe ocurrir para que ese cambio se produzca" [1]. Ese "lo que debe ocurrir" es la lógica causal, y exige nombrar los pasos intermedios y los cambios conductuales o sistémicos de los que dependen.

💡 Consejo: Para cada vínculo producto-resultado en tu TdC, escribe una oración completando este enunciado: "Este producto llevará a este resultado porque..." Si no puedes completar esa oración con precisión, el eslabón causal está ausente.

3. El contexto tratado como algo estático

Una TdC desarrollada durante el proceso de propuesta refleja el contexto tal como se entendía en ese momento. Pero los programas duran tres, cuatro o cinco años. Las dinámicas de conflicto cambian. La voluntad política se transforma. Una intervención vecina tiene éxito o fracasa y modifica las expectativas de la comunidad.

La guía de CDA Collaborative sobre teorías de cambio en contextos de conflicto y seguridad señala específicamente esto: los programas frecuentemente cargan con una "teoría de cambio general" que codifica supuestos fundamentales sobre cómo se producirá el cambio, pero esos supuestos raramente se revisan a medida que evoluciona el entorno operativo [5]. Cuando el contexto cambia, una TdC que nunca fue diseñada para adaptarse se convierte en un pasivo.

Una TdC bien construida debería incluir monitoreo contextual: una lista breve de factores del entorno que, si cambian, te obligan a revisar la lógica causal. Esto es diferente de tus indicadores de resultado. Son señales sobre el mundo que rodea tu programa, no sobre el programa en sí.

4. Sin bucles de retroalimentación

La mayoría de las teorías de cambio son lineales. Las actividades producen productos. Los productos producen resultados. Los resultados contribuyen al impacto. La flecha apunta siempre en una sola dirección.

El cambio social real no es lineal. Los beneficiarios responden a tu programa y modifican su comportamiento, lo cual transforma lo que es posible en el siguiente ciclo. Los líderes comunitarios que desarrollan capacidades se convierten en actores que moldean el contexto en el que trabajas. Un mapa causal unidireccional no puede representar esto y, lo que es más importante, tampoco puede monitorearlo.

La Guía Complementaria del UNDAF describe esto como un principio central: la TdC debe reflejar el aprendizaje iterativo, incluyendo la retroalimentación de la implementación, en lugar de funcionar como un plano fijo [2]. Sin bucles de retroalimentación incorporados en el diseño, no hay una invitación estructural para adaptarse.

💡 Consejo: En tu próxima revisión de TdC, pregunta: "¿Dónde en este diagrama regresa el aprendizaje de la implementación?" Si la respuesta es "en ningún lado," el bucle de retroalimentación está ausente.

5. La TdC es propiedad de una sola persona

Este es un fallo de proceso que genera un fallo técnico. Cuando la teoría de cambio es construida principalmente por una persona consultora durante el desarrollo de la propuesta, o vive principalmente en la cabeza del responsable de MEL, se vuelve frágil. El personal de programa implementa actividades sin entender cómo esas actividades deberían conectarse con los resultados. Cuando los supuestos se rompen, nadie lo señala porque nadie está siguiendo la lógica.

La Fundación Annie E. Casey enfatiza que desarrollar una teoría de cambio implica hacer "explícitos los supuestos colectivos"; la palabra "colectivos" es la que carga el peso [4]. Una TdC que el equipo no comprende ni siente como propia no es una teoría de cambio. Es un diagrama.

Cómo someter tu TdC a prueba de estrés antes de la implementación

Este es el protocolo básico que uso cuando reviso una teoría de cambio para evaluar su solidez operativa:

1. La prueba del "porque": Para cada flecha causal, pregunta: "Esto lleva a aquello porque...?" Documenta la respuesta. Los vacíos en las respuestas son vacíos en la lógica.
2. La prueba de inversión de supuestos: Toma cada supuesto y pregunta: "¿Qué le ocurre a esta cadena causal si este supuesto resulta ser falso?" Si la respuesta es "toda la cadena colapsa," ese supuesto necesita monitoreo activo o una ruta de contingencia.
3. El análisis de contexto: Lista de tres a cinco factores externos de los que tu TdC depende en silencio. Asigna una responsabilidad de monitoreo para cada uno.
4. La verificación de comprensión del equipo: Pídele a dos personas del personal de campo que expliquen, con sus propias palabras, cómo su trabajo cotidiano se conecta con los resultados de largo plazo del programa. Sus respuestas te dirán si la TdC ha sido internalizada o simplemente archivada.
5. La auditoría de bucles de retroalimentación: Identifica al menos un punto en la TdC donde el aprendizaje de la implementación pueda regresar y modificar el enfoque. Si no existe ninguno, constrúyelo.

📝 Nota: Esta prueba de estrés funciona mejor como un ejercicio facilitado en equipo, no como una revisión individual de escritorio. La conversación que genera suele ser más valiosa que el diagrama revisado que resulta de ella.

Si estás entrando en un proceso de diseño, una revisión de medio término o una actualización de programa y quieres una TdC que realmente aguante la presión de la implementación, con gusto lo trabajamos juntos. Puedes encontrarme en vera.ignex.io, trae tu borrador de TdC, tu marco lógico, o incluso solo un planteamiento del problema, y construiremos algo que funcione en el campo, no solo en la propuesta.

Al final, el objetivo no es una teoría que luzca bien en un taller. Es una teoría que sobreviva el contacto con la realidad.

Referencias: [1] CRS Practical Guidance on Theory of Change [2] UNDAF Companion Guidance [3] DFID Review of Theory of Change Practice in International Development [4] Annie E. Casey Foundation, Theory of Change Guidance [5] CDA Collaborative, Theories of Change in Conflict and Security Contexts

Follow Vera for more on MEL & project management: LinkedIn · Instagram · Facebook · X