Cierre de proyecto: el checklist que casi nadie hace
Por qué los proyectos “terminan” sin cerrar
La fase de cierre es la única de las 5 fases de un proyecto que no tiene un entregable urgente empujándola. Nadie reclama el cierre como reclama un retraso en la ejecución — así que compite en prioridad contra el siguiente proyecto que ya tiene fecha, y pierde.
El costo aparece después, cuando ya es más caro resolverlo:
- Nadie recuerda por qué se tomó una decisión clave, seis meses después.
- El acceso a una cuenta o repositorio queda abierto sin necesidad.
- El último hito de facturación se factura tarde, o nunca.
- El equipo repite un error que la retro habría evitado.
El checklist de cierre
| Área | Qué verificar |
|---|---|
| Entregables | Todo lo comprometido está entregado y aceptado formalmente, no solo “enviado” |
| Aprobaciones | Firma o confirmación explícita del cliente/stakeholder de que el proyecto se dio por terminado |
| Facturación | Último hito facturado y cobrado; sin pagos pendientes sin fecha |
| Documentación | Decisiones clave y su porqué quedan escritas, no solo en la memoria del equipo |
| Accesos | Revocar accesos temporales que ya no hacen falta (repos, herramientas, cuentas compartidas) |
| Personas | Liberadas formalmente para el siguiente proyecto, no “a medias” en dos a la vez |
| Archivo | El proyecto se mueve a un estado “cerrado” claro, no queda como “en curso” fantasma en el portafolio |
La retrospectiva de cierre (distinta de la de sprint)
Si el equipo ya usa retrospectivas de sprint, la de cierre de proyecto no es más de lo mismo a otra escala: mira el proyecto completo, no una iteración. Tres preguntas alcanzan:
- ¿Qué entregamos que valió la pena, más allá de si llegó a tiempo?
- ¿Qué decisión temprana nos hubiera ahorrado más tiempo si la sabíamos antes?
- ¿Qué del proceso repetiríamos igual en el próximo proyecto, y qué cambiaríamos?
Documentá las respuestas en un lugar donde el próximo proyecto similar las encuentre — si quedan solo en la cabeza de quien estuvo, el aprendizaje se pierde con la rotación del equipo.
Archivar y liberar recursos
Un proyecto “cerrado” de palabra pero “en curso” en el tablero sigue consumiendo atención administrativa: aparece en reportes, confunde el conteo de portafolio activo y a veces sigue recibiendo pedidos tardíos de cambios menores. Cerrarlo formalmente en el sistema —no solo en la conversación— es lo que realmente libera capacidad para el siguiente frente.
Comunicar el cierre (interno y con el cliente)
Un mensaje de cierre corto, a ambas puntas, evita ambigüedad sobre si el proyecto sigue “técnicamente abierto”:
“Damos por cerrado [proyecto] al [fecha]. Entregables: [lista]. Pendientes fuera de alcance quedan en [backlog/próximo proyecto]. Cualquier pedido nuevo a partir de hoy se evalúa como proyecto o mejora aparte.”
Esa última línea es la que más ahorra fricción: sin ella, el cierre se diluye con pedidos “chiquitos” que reabren el proyecto de facto sin nunca decidirlo explícitamente.
Qué pasa si el proyecto se cierra “a medias”
No todo cierre es un éxito completo — a veces se cierra con alcance recortado o insatisfacción parcial del cliente. Igual conviene cerrarlo formalmente en vez de dejarlo indefinido:
- Documentá explícitamente qué quedó afuera y por qué — protege al equipo de que se interprete como olvido en vez de decisión.
- Si hubo riesgos que se materializaron, dejalo anotado como insumo para el próximo proyecto — ver gestión de riesgos para equipos pequeños.
- Separá el cierre administrativo (facturación, accesos) del cierre emocional del equipo — el primero no debería esperar al segundo.
Preguntas frecuentes
¿Cuánto tiempo debería llevar cerrar un proyecto chico?
¿Hace falta cierre formal en proyectos internos, sin cliente externo?
¿Qué hago si el cliente no responde para dar la aprobación final?
¿La retrospectiva de cierre reemplaza a las retrospectivas de sprint?
Equipo Hito
Producto · Escribimos sobre gestión de proyectos local-first desde la práctica de construir Hito.