Lo que el contrato no ve

Entregamos a tiempo. Entregamos con la calidad que habíamos prometido. El cliente aprobó, el pago llegó y el proyecto cerró en verde. Meses después, en una conversación informal, alguien comentó que los cursos que habíamos construido probablemente nunca se abrieron para las personas a las que estaban dirigidos. Un año más tarde nos escribieron por fallas en la plataforma: los cursos seguían ahí, terminados, sin haberse cargado del todo. No encontramos registro de que alguna cohorte los hubiera tomado.

No hubo un informe que lo dijera. No hubo un indicador en rojo. Según todos los instrumentos de gestión, aquel proyecto fue un éxito. Según la única pregunta que importaba, ¿llegó a las personas?, nadie lo sabe.

Llevo años dirigiendo proyectos para agencias de cooperación y entidades de gobierno en América Latina desde Innovahub. Este texto nace de esa incomodidad: la distancia entre cumplir un contrato y cambiar algo. No es un estudio académico. Es el ensayo de alguien que ejecuta, apoyado en tres experiencias reales, contadas sin nombres de personas ni de proyectos, y en lo que otros ya han investigado sobre por qué tantos proyectos de desarrollo cumplen y no transforman.

00 — Antes de empezarComida de casa

Hay dos maneras fáciles de equivocarse al gestionar proyectos de cooperación y de gobierno.

La primera es la cocina de estrella Michelin: metodología servida en platos enormes con porciones diminutas. Un plan para gestionar cada plan, matrices de cuarenta filas, informes que nadie lee, certificaciones que se exhiben más de lo que se usan. Cuesta un riñón y uno se levanta de la mesa con hambre.

La segunda es la comida callejera: el "vamos haciendo", la hoja de cálculo que solo entiende una persona, el cronograma que vive en la cabeza del coordinador. Es rápida, barata y conveniente. Y a veces deja un recuerdo doloroso.

Lo que propongo es comida de casa. Preparada con cabeza, con ingredientes reales y en la cantidad justa. En gestión de proyectos eso significa algo muy concreto: tomar de los métodos formales lo que se gana su lugar en la mesa, dejar lo demás y no perder nunca de vista para quién se cocina.

01 — El problemaCumplir no es transformar

Cualquiera que haya trabajado con cooperación conoce la cadena del marco lógico: insumos, actividades, productos, resultados, impacto. Es una buena herramienta. Pero esconde una trampa que casi nunca se nombra: el contrato termina en los productos y el proyecto existe por los resultados.

A quien ejecuta se le paga por entregar cursos, plataformas, documentos, talleres. Se le evalúa por tiempo, costo y alcance. Lo que pasa después, si esos cursos se abren, si esas plataformas se usan, si esos talleres cambian una decisión, queda en un territorio que no le pertenece del todo a nadie: el ejecutor ya cerró, la entidad contratante tiene otras urgencias y el donante mira el informe final.

La literatura sobre éxito de proyectos distingue desde hace décadas entre el éxito de la gestión del proyecto (cumplir tiempo, costo y alcance) y el éxito del proyecto (lograr aquello para lo que existe). Lavagnon Ika, uno de los pocos académicos que estudia de manera sistemática la gestión de proyectos en el desarrollo internacional, ha mostrado que en este sector la brecha entre ambas cosas es especialmente ancha, y que buena parte de la explicación no es técnica: está en los incentivos, en la distancia entre quien financia y quien recibe, y en la presión por mostrar productos.

El contrato nos paga por los productos. El proyecto existe por los resultados. Entre los dos hay un vacío del que nadie es dueño.

Ese vacío no se cierra con más metodología. Se cierra mirando, desde el primer día, lo que el contrato no ve.

02 — Tres experienciasDe dónde sale esto

Antes de las ideas, los casos. Los tres son proyectos de formación virtual y fortalecimiento institucional que dirigí o en los que participé de cerca.

El primero fue una iniciativa internacional de gran escala, financiada por cooperación y ejecutada con varias agencias e instituciones de gobierno. Construimos un conjunto amplio de cursos virtuales y recursos de aprendizaje sobre temas sensibles. Tuvimos una contraparte excelente. Y el trabajo llegó cuando la iniciativa se acercaba a su fin.

El segundo fue para una entidad pública nacional que necesitaba formar a miles de servidoras y servidores en temas complejos. Un programa de cursos virtuales con muchos componentes, decenas de entregables y un plazo que hubo que ampliar. Meses de trabajo muy intenso. Hoy esos cursos se están usando.

El tercero fue un programa de varios años con gobiernos locales: formar a personas funcionarias públicas para que incorporaran un marco internacional de desarrollo en sus planes de gobierno, con metas e indicadores. Hubo experiencias muy buenas y otras que no funcionaron.

Ninguno fracasó en los términos del contrato. Los tres enseñan algo sobre lo que pasa fuera de él.

03 — Lo que no se veSiete fuerzas que mueven un proyecto

Ninguna de estas fuerzas aparece en el cronograma. Todas lo mueven más que él.

1. El dinero que se acaba

Cuando una iniciativa se acerca a su cierre, el objetivo cambia sin que nadie lo declare. El marco lógico es el mismo, los indicadores son los mismos, el nombre es el mismo. Pero lo que se persigue ya no es un cambio en la población: es ejecutar el presupuesto antes de una fecha.

Eso nos pasó en el primer caso. Había que entregar sí o sí, en tiempos muy ajustados, con la presión del cliente y la del financiador detrás. Los contenidos de autor, que escribían especialistas contratados por el propio cliente, llegaban tarde: los últimos nos llegaron cuando quedaba muy poco contrato por delante. Las fechas de facturación, en cambio, eran fijas. Algunos productos terminaron de aprobarse después de la fecha de cierre. Cumplimos. Pero cumplimos en un proyecto que se había convertido, en la práctica, en un ejercicio de ejecución presupuestal. Los productos nacieron sin presupuesto para lo que venía después: difundirlos, abrirlos, acompañar a quienes los iban a tomar.

Lo que no se ve: la presión por gastar y la presión por transformar no siempre empujan en la misma dirección. Cuando chocan, casi siempre gana la primera, porque es la que tiene fecha.

2. El entregable huérfano

Comparemos los dos primeros casos. Los dos eran cursos virtuales de gran calidad sobre temas parecidos. Uno se usa y del otro no sabemos nada. La diferencia no estuvo en el producto. Estuvo en que uno tenía dueño y ruta de uso y el otro no.

En el segundo caso, la entidad contratante era la misma que tenía la plataforma, el público, el mandato de formar y la obligación de rendir cuentas por ello. El curso tenía a dónde llegar antes de existir. En el primer caso, el producto se entregaba a una iniciativa que estaba por terminar, sin una institución que lo adoptara como propio.

Lo que no se ve: un entregable aprobado sin alguien que lo vaya a usar, mantener y defender después del cierre es un activo que empieza a perder valor el día en que se aprueba.

3. El calendario que no está en el cronograma

Los cronogramas se hacen en semanas y meses. Las instituciones viven en periodos de gobierno, vigencias fiscales, ciclos de planeación, temporadas electorales y vacancias.

En el tercer caso lo vimos con claridad. Donde la formación coincidió con el momento en que los gobiernos locales estaban formulando sus planes, funcionó muy bien: lo que aprendían lo aplicaban esa misma semana en un documento que tenían que entregar. Donde llegó en otro momento, el mismo curso, con los mismos contenidos, fue un trámite.

En el segundo caso, las restricciones de contratación en época electoral y un cambio de gobierno retuvieron pagos durante un tiempo. Luego se destrabaron. El proyecto no tenía ningún problema técnico; tenía un problema de calendario.

Lo que no se ve: el momento institucional pesa más que la calidad del producto. El mismo entregable vale mucho o casi nada según cuándo llegue.

4. Las personas que cambian

En el primer caso tuvimos una de las mejores contrapartes con las que he trabajado. Una sola persona centralizaba la comunicación, compilaba los comentarios de todas las instituciones, no dejaba que hubiera dudas en las aprobaciones ni en el envío de insumos. Generaba confianza hacia su organización y hacia nosotros como proveedores. Si aquel proyecto cumplió en tiempos imposibles, fue en buena parte por ella.

Esa es la buena noticia. La mala es su reverso: un punto focal así es también un punto único de falla. En el tercer caso hubo cambios de personal a lo largo del programa, y cada cambio obligaba a reconstruir el contexto, los acuerdos y la confianza. En gobierno, la rotación no es una excepción: es parte del clima.

Lo que no se ve: el acelerador más poderoso de un proyecto no aparece en ningún organigrama, y casi nunca tiene un reemplazo preparado.

5. El público equivocado

En el tercer caso hubo grupos en los que una parte de las personas participaba para cumplir una cuota de formación que su institución les exigía. Hubo espacios en los que se incluyó a grupos de jóvenes con temas que no les resultaban cercanos. Y hubo desgaste: al principio, webinarios llenos y mucho interés; con el paso de los meses, cansancio.

No fueron malos cursos. Fueron buenos cursos para las personas equivocadas, o en el momento equivocado.

Lo que no se ve: la selección de quién participa suele quedar fuera del alcance de quien diseña, y es una de las decisiones que más determinan el resultado.

6. Las rondas de revisión

Nadie presupuesta las rondas de revisión. Se escribe en el contrato que el cliente tendrá cinco días para revisar cada entregable y se planea como si fuera a revisar una vez. La realidad es otra: comentarios que llegan tarde, revisores que se suman a mitad de camino, observaciones contradictorias entre instituciones, criterios de aceptación que se descubren al revisar. En el primer caso, los términos de referencia exigían incorporar los comentarios de varias organizaciones y contrapartes; los correos de revisión se contaban por decenas, y hubo cambios que llegaron cuando todo parecía cerrado. En la evaluación interna que hicimos al final, el equipo lo dijo sin rodeos: nos faltó una fase entre la escritura de los contenidos y su guionización, y lo pagamos en rondas.

En el segundo caso lo medimos. En una de las etapas, los entregables pasaron más tiempo esperando revisión del que había tomado producirlos. Lo curioso es que la calidad no era el problema: la gran mayoría se aprobó sin ajustes o con una sola ronda. El problema era la espera. Una de las razones para pedir la prórroga fue, precisamente, no saturar la capacidad de revisión de la entidad.

Y la espera no se queda en el cronograma: se traslada a la caja. Cada pago dependía de que se aprobara una etapa completa, así que un solo entregable pendiente retenía el pago de toda la etapa. Uno de esos pagos llegó meses después de lo previsto. Durante ese tiempo, la empresa financió la ejecución con recursos propios. Eso tampoco aparece en ningún marco lógico: muchas veces quien ejecuta un proyecto de desarrollo también lo está financiando, sin que nadie lo haya decidido.

Lo que no se ve: buena parte del retraso de un proyecto no está en la producción sino en la aprobación, y casi nunca se mide.

7. El héroe invisible

En el segundo caso estoy orgulloso de algo que también me preocupa. Durante meses, muchas personas del equipo trabajaron en productos que no estaban bajo su responsabilidad, porque no había tiempo, porque los recursos no alcanzaban, porque alguien tenía que hacerlo. Cumplimos con productos de muy buena calidad. Y lo hicimos, en parte, gracias a un esfuerzo que no estaba en ningún plan. En nuestro propio registro de riesgos quedó escrito: capacidad del equipo por encima del 95 %.

En 1967, el economista Albert Hirschman observó proyectos de desarrollo en terreno y describió lo que llamó la mano que se esconde: tendemos a subestimar las dificultades de un proyecto, pero también subestimamos nuestra capacidad de resolverlas, y una cosa compensa la otra. Décadas después, Bent Flyvbjerg y Cass Sunstein revisaron datos de más de dos mil proyectos y encontraron que esa mano muchas veces no es benévola: la subestimación se repite y la creatividad no siempre alcanza a compensarla.

El héroe es la mano que se esconde en carne y hueso. Sostiene el proyecto, no aparece en el informe, no se factura y no se puede repetir indefinidamente.

Lo que no se ve: si un proyecto solo sale adelante gracias a héroes, no fue un buen plan. Fue un buen equipo cubriendo un mal plan.

04 — De la cocina formalLo que sí sirve del PMBOK y de PRINCE2

Nada de lo anterior es un argumento contra la gestión de proyectos formal. Es un argumento contra usarla como ceremonia. El PMBOK, en su séptima edición, ya pasó de los procesos a los principios y a la entrega de valor. PRINCE2 se construyó sobre siete principios, varios de los cuales responden directamente a las fuerzas que acabo de describir. Esto es lo que yo me llevo a la mesa:

• Justificación continua (PRINCE2). Un proyecto debe seguir teniendo sentido en cada etapa, no solo al firmarse. En cooperación esa pregunta tiene una forma concreta: ¿sigue existiendo alguien que vaya a usar esto?
• Enfoque en productos (PRINCE2). Antes de producir, describir cada entregable: para qué sirve, qué criterios debe cumplir para aceptarse, quién lo aprueba. Esta sola práctica elimina buena parte de las rondas de revisión.
• Gestión por etapas (PRINCE2). Dividir el proyecto en etapas con un punto de decisión al final de cada una. En un contrato cerrado, esas puertas son el único lugar honesto donde cabe la adaptación.
• Gestión por excepción (PRINCE2). Acordar tolerancias de tiempo, costo y alcance, y escalar solo cuando se superan. Menos reuniones de seguimiento, más decisiones a tiempo.
• Registro de interesados (PMBOK). Incluyendo a quienes no firman: la población, los usuarios finales, quien va a mantener el producto cuando nosotros ya no estemos.
• Riesgos en una página (PMBOK). Con los riesgos de calendario y políticos en primera línea, no al final de la lista.
• Control de cambios (ambos). Por escrito, simple, con impacto en tiempo y costo. No para defenderse del cliente, sino para que ambos sepan qué se está decidiendo.
• Aprender de la experiencia (PRINCE2). Las lecciones aprendidas se leen al empezar el siguiente proyecto, no se escriben al terminar este para archivarlas.

Y esto es lo que dejo en la cocina: los planes de gestión de cada plan, las matrices de responsabilidades de cuarenta filas, los informes semanales que nadie responde, las plantillas que se llenan porque existen y la idea de que más documentación equivale a más control.

La metodología es la receta. El objetivo es que alguien coma.

05 — La propuestaSeis principios, una herramienta cada uno

Esta es la receta. Seis principios que salen de las siete fuerzas, cada uno con una sola herramienta, lo bastante liviana como para usarse de verdad.

1. Empieza por el uso, no por el producto

Antes de diseñar un entregable, responde por escrito quién lo va a usar, cuándo, por qué canal y quién se hace cargo de él después del cierre. Si no hay respuesta, ese es el primer riesgo del proyecto y hay que decirlo en voz alta, aunque incomode.

La herramienta: una ficha de destino de una página por cada producto importante, firmada por quien lo va a adoptar.

2. Planea con el calendario del otro

Antes del cronograma propio, el calendario institucional: elecciones y restricciones de contratación, cierres de vigencia fiscal, ciclos de planeación, vacancias, cambios de administración. Luego, el cronograma se acomoda a eso, y no al revés.

La herramienta: una línea de tiempo institucional, en la misma página que el cronograma, revisada en cada punto de decisión.

3. Acuerda qué es "terminado" antes de empezar

Cada entregable con sus criterios de aceptación, el nombre de quién revisa, el plazo de revisión y el número de rondas incluidas. Lo que salga de ahí es un cambio, y se trata como tal.

La herramienta: la descripción de producto de PRINCE2, reducida a media página.

4. Mide para decidir, no para reportar

En el segundo caso, el tablero que usábamos para gestionar el proyecto terminó siendo usado por la entidad para su propia rendición de cuentas, y luego la entidad lo pidió para llevar sus propios proyectos. No fue por su diseño. Fue porque medía pocas cosas, las mismas que el cliente necesitaba ver: avance ponderado por estado, entregables en revisión, pagos habilitados, alertas. Tenía también indicadores clásicos de valor ganado, como el índice de desempeño del cronograma, pero lo que más se miraba era lo más simple: cuánto estaba aprobado y qué estaba esperando a quién.

La herramienta: un tablero con no más de cinco o seis indicadores, compartido con el cliente, que responda una sola pregunta: ¿qué tenemos que decidir esta semana?

5. Protege el puente humano

Reconoce explícitamente el rol del punto focal, del lado del cliente y del propio. Dale lo que necesita para funcionar y prepara su reemplazo antes de necesitarlo: un resumen vivo del proyecto, los acuerdos tomados y las decisiones pendientes, de modo que una rotación cueste días y no meses.

La herramienta: una carpeta de relevo, de no más de tres páginas, actualizada en cada punto de decisión.

6. Presupuesta la realidad, no el heroísmo

Incluye en el plan lo que siempre ocurre: rondas de revisión, ajustes, retrasos de aprobación, tiempo para la transferencia. Y mira con desconfianza cualquier plan que solo funciona si el equipo da lo mejor de sí todos los días. Si en la mitad del proyecto aparecen héroes, la tarea no es aplaudirlos: es revisar el plan.

La herramienta: una reserva explícita de tiempo y costo, visible para el cliente, con reglas claras de uso.

06 — LímitesDónde no alcanza esta propuesta

Sería deshonesto terminar sin decir lo que esto no resuelve.

• No arregla un proyecto mal diseñado. Si el problema que se quiere resolver está mal formulado desde la propuesta, gestionar mejor solo permite equivocarse con más orden.
• El ejecutor no controla el uso. Puede hacerlo visible, insistir, dejarlo escrito. No puede obligar a una institución a adoptar lo que recibió.
• Requiere un cliente dispuesto. Algunas de estas herramientas incomodan, porque obligan a decir en voz alta lo que todos saben y nadie escribe.
• No garantiza impacto. El impacto depende de muchas cosas que ningún equipo de proyecto controla. Lo que sí se puede hacer es dejar de impedirlo.

07 — En diálogoNo es el primero en decirlo

Hay trabajo serio en este terreno, y vale la pena reconocerlo. La guía PMD Pro, de PM4NGOs, adapta la gestión de proyectos formal al sector del desarrollo, de manera práctica y gratuita. El enfoque PDIA (adaptación iterativa orientada a problemas), de Matt Andrews, Lant Pritchett y Michael Woolcock, propone resolver problemas concretos en ciclos cortos en lugar de importar soluciones. Y el movimiento de gestión adaptativa en la cooperación ha empujado la idea de aprender y ajustar sobre la marcha.

Lo que este texto intenta sumar es un punto de vista que casi no se escribe: el de quien ejecuta, dentro de un contrato cerrado, con presupuesto fijo, alcance pactado y un calendario ajeno. Desde esa silla no siempre se puede iterar como se quisiera. Pero sí se puede gestionar con la mirada puesta más allá del contrato.

No puedo prometer que un proyecto vaya a salir bien. Nadie puede. Lo que sí puedo hacer es mirar lo que el contrato no ve, decirlo a tiempo y organizar el trabajo para que lo importante tenga una oportunidad.

Eso es la comida de casa: nada espectacular, nada improvisado. Ingredientes reales, preparados con cabeza, para que alimenten. Al final, la medida de un proyecto no es lo que entregamos. Es lo que alguien pudo hacer con eso.

Entregar no es el final. Es la mitad.

La receta en una página: ficha imprimible con los seis principios y sus herramientas ↗