Qué necesita tu proyecto Horizon Europe antes del cierre digital

Faltan seis semanas para el plazo de cierre. El análisis de datos no está terminado. El entregable digital prometido en el plan de trabajo existe en fragmentos repartidos por los portátiles de tres doctorandos. El mockup del dashboard sigue en Figma. El evaluador ya ha preguntado cuándo estará listo el artefacto público. Tu equipo sigue enfocado en la ciencia — donde debería estar — pero el paquete de cierre no se va a montar solo.

Es el patrón más común que vemos en trabajo de cierre de proyecto europeo. La ciencia era sólida; los entregables digitales tenían poca capacidad asignada desde el arranque. Cuando alguien empieza a prestar atención, no queda capacidad de ingeniería, no hay tiempo para contratar y no hay margen para fallar.

Este artículo es una lista de verificación previa al cierre para proyectos Horizon Europe y convocatorias equivalentes. Cubre qué revisan realmente los evaluadores, los tres entregables que más se descontrolan, y qué hacer si ya estás dentro de la zona de peligro.

Qué significa realmente el cierre digital

El cierre digital es el conjunto de artefactos que el proyecto se comprometió a producir y que no son la investigación publicada en sí: los dashboards, datasets, repositorios, documentación, plataformas demo y salidas de software listadas en los paquetes de trabajo del Anexo 1. Financiadores como la Comisión Europea, el ERC, las MSCA y las agencias nacionales esperan que estos estén terminados, documentados y traspasados para el cierre formal del proyecto — o, en algunos casos, antes de la reunión de revisión final.

El error que cometen los equipos es tratar el cierre digital como papeleo administrativo. No lo es. Para Horizon Europe en particular, las salidas digitales públicas forman parte de cómo se evalúa el proyecto. Un consorcio que entregó investigación brillante pero una plataforma a medio terminar suele puntuar más bajo en diseminación, explotación e impacto que uno con ciencia mediocre y un artefacto pulido, documentado y ejecutable.

La asimetría importa: la calidad de la investigación la juzgan tus colegas; los entregables digitales los juzga tu evaluador. No son la misma audiencia.

Los tres entregables que más se descontrolan

Después de entregar trabajo de cierre para varios consorcios europeos, las mismas tres cosas se descontrolan en casi cada proyecto.

1. El pipeline de datos a informe

Cada proyecto con financiación produce datos. Pocos producen las salidas analíticas que esperan los evaluadores. La brecha es real: limpiar, estructurar y analizar un dataset multi-sitio, y luego producir las figuras y tablas que el entregable requiere, son varias semanas de ingeniería y trabajo estadístico enfocado. Los doctorandos lo hacen bajo presión las dos últimas semanas; el resultado es apresurado y sin documentar.

Lo que quiere el evaluador: datos limpios con esquemas documentados, pipelines de análisis reproducibles y figuras del informe exportadas desde esos pipelines — no capturas de Excel. Memoria final de proyecto de investigación que sobrevive al plazo es estructurada y re-ejecutable.

2. El artefacto digital público

La línea "plataforma que construiremos" del plan de trabajo. En el mes 30 de un proyecto de 36, suele existir como: un mockup de Figma, un prototipo Streamlit en el localhost de alguien, una app Shiny que el postdoc desplegó en un servidor gratuito que ahora está caído, un esqueleto Next.js apenas estilado de un hackathon. Nada de eso es un entregable.

Lo que quiere el evaluador: una versión ejecutable, accesible y documentada de lo que prometía el plan de trabajo. URL que carga, README que explica lo que hay y credenciales si está autenticado. Si tu plataforma no es accesible desde un portátil nuevo con la documentación que aportaste, no está entregada.

3. La documentación de traspaso

Lo que nadie disfruta escribiendo y todo el mundo necesita al cabo de tres años. Sin ella, el siguiente consorcio que retome el trabajo no puede continuar. Sin ella, tu institución no puede demostrar que el entregable se mantendrá. Sin ella, el compromiso de alineación FAIR que hiciste en la propuesta es demostrablemente falso.

Lo que quiere el evaluador: diccionarios de datos, metadatos alineados con FAIR, guías de despliegue, runbooks, READMEs de repositorios y una declaración clara de qué se mantiene, por quién, durante cuánto tiempo.

Lista de verificación previa al cierre

Entre 6 y 10 semanas antes, repasa esta lista. Si no puedes marcar una casilla, ahí está la brecha.

| Verificación | Qué significa "hecho" | |---|---| | Dataset final limpio y documentado | Una única versión canónica, documento de esquema, plan de gestión de datos actualizado | | Pipeline de análisis reproducible de extremo a extremo | Una sola comanda ejecuta limpieza → análisis → figuras, sin pasos manuales | | Figuras y tablas generadas desde el pipeline | Sin capturas de Excel; cada número trazable a un script | | Artefacto público desplegado en una URL estable | Accesible desde fuera de la VPN de tu institución, con uptime durante la revisión | | README + guía de instalación probados por alguien externo al equipo | El test del portátil nuevo pasa; un nuevo miembro del equipo puede ejecutarlo | | Metadatos alineados con FAIR | Findable, accessible, interoperable, reusable — no aspiracional | | Secciones del informe final redactadas con referencias a entregables | Cada salida del paquete de trabajo citada con URL o DOI | | Repositorio archivado en almacenamiento a largo plazo | Zenodo, repositorio institucional o equivalente | | Documento de traspaso a stakeholders completo | Quién mantiene qué, hasta cuándo, con qué contactos | | Agenda de la reunión de cierre preparada | Flujo de demo ensayado; sin programar en directo durante la revisión |

Si tres o más están en rojo, estás en territorio de toma de relevo. No es catastrófico — pero necesitas ayuda que no es tu equipo.

Cuándo incorporar ayuda externa

Las señales suelen ser claras retrospectivamente y ambiguas en el momento. Algunos patrones que hemos visto:

• Tus doctorandos son brillantes investigando, no en ingeniería — no tienen tiempo para construir la plataforma además de escribir su tesis
• Probaste con una agencia genérica pero no entendieron el contexto del proyecto, las obligaciones del Anexo 1 ni el formato del entregable que espera el evaluador
• El equipo de Research Software Engineering (RSE) de tu universidad está saturado y no puede asumir tu proyecto antes del plazo
• Tienes un prototipo en Streamlit, Shiny o REDCap que necesita convertirse en una herramienta de producción mantenible y documentada
• El plazo de informe se acerca, el cierre del proyecto está a la vuelta de la esquina y los entregables digitales no están listos

Si alguno te describe, necesitas un colaborador que lea planes de trabajo de proyectos europeos de forma nativa, que conozca cómo es un paquete de cierre y que pueda moverse en 3–6 semanas en lugar de seis meses. Las consultoras genéricas construirán lo equivocado o tardarán demasiado. Las consultoras estratégicas no construirán nada.

Cómo es una buena toma de relevo de cierre

La estructura de un buen trabajo de cierre no es misteriosa. Son tres fases comprimidas en el tiempo que te queda.

Auditoría (semana 1). Qué existe, qué está documentado, qué se ejecuta. El equipo que incorpores lee el Anexo, lista cada salida digital comprometida y señala la brecha. Aún no hay trabajo nuevo.

Definición de alcance (semana 1–2). Qué puede entregarse realísticamente en el tiempo disponible — no qué sería ideal en un universo paralelo con doce meses más. Donde la brecha sea demasiado grande, ¿cuál es la versión mínima viable que satisface al evaluador? Documenta los compromisos explícitamente para que el financiador no se sorprenda en la revisión.

Entrega (semanas 2–6). Construir, documentar, traspasar. Cada salida del paquete de trabajo recibe una marca clara de "entregado". El paquete de traspaso se escribe mientras la feina ocurre, no al final. El artefacto público se despliega pronto y se itera, no se despliega en el plazo.

El estado final: un paquete de entregables que un evaluador externo puede ejecutar, leer y verificar, con documentación que sobrevive al equipo cuando se desplaza.

Dónde encaja Pragma

Pragma Digital Labs es un estudio pequeño que construye los entregables digitales que los proyectos de investigación prometieron. Hemos entregado trabajo de cierre para consorcios europeos, diseñado pipelines de informe listos para evaluador y reconstruido prototipos a medias en herramientas de producción documentadas. El equipo lee el Anexo 1, entiende qué esperan los evaluadores y entrega en 3–6 semanas en lugar de seis meses.

Si tu plazo de cierre está más cerca que tu preparación de entrega, ese es exactamente el proyecto para el que existimos. Nuestro Pack de Cierre Digital define el alcance de la toma de relevo en la primera semana y entrega el paquete que el evaluador revisará.

Tres cosas que hacer esta semana

1. Abre tu Anexo 1 y lista cada salida digital comprometida. Compáralo con lo que existe realmente.
2. Elige el entregable menos avanzado. Define la versión mínima viable que el evaluador aceptaría.
3. Si la brecha es más amplia de lo que la capacidad restante del equipo permite, solicita una revisión de proyecto. Cuanto antes la conversación, menos comprimida la entrega.

El plazo es fijo. El paquete de entregables no — pero el tiempo para hacerlo realidad es corto. Mejor saberlo ahora que en la semana uno.