Lecciones aprendidas de un proyecto: formato y ejemplo

El ritual típico: el proyecto termina, alguien agenda una reunión de lecciones aprendidas, el equipo enumera “qué salió bien y qué salió mal”, un asistente lo escribe en un documento… y ahí queda. El siguiente proyecto arranca sin abrirlo, repite los mismos errores y genera el mismo documento. El problema no es la reunión: es que el output no tiene forma de decisión.

Tres fallas repetidas: se documentan observaciones (“hubo poca comunicación”) en vez de acciones (“el estatus saldrá por escrito los lunes, dueño: PM”); no tienen dueño (y lo de nadie es de nadie); y viven en un archivo al que el siguiente proyecto nunca llega porque no está en su camino natural de trabajo.

Las lecciones que sí se usan tienen otra anatomía: pocas (5 a 10, no 40), cada una con una acción concreta para el futuro, y un lugar obligatorio donde el próximo proyecto las encontrará: el kickoff.

Una lección aprendida útil cabe en una fila con cuatro columnas. Si no puedes llenar la cuarta, la lección todavía no está madura:

Ejemplo completo, bien redactado:

• Hecho: las aprobaciones del cliente tardaron en promedio 9 días; el plan suponía 2.
• Efecto: 5 semanas de atraso en la ruta crítica y 2 iteraciones muertas.
• Qué haremos distinto: el cronograma incluirá un plazo de aprobación contractual (5 días hábiles) y el silencio pasados esos días aprueba por defecto.
• Dueño y dónde vive: el PM, en la plantilla de plan de proyecto y en el contrato tipo.

El cierre es el momento canónico —en muchos equipos es un punto fijo del checklist de cierre de proyecto— pero tiene un defecto: a seis meses de distancia, el equipo recuerda el último mes y borra el resto. Para proyectos largos funcionan mejor dos sesiones cortas: una intermedia (a mitad o al cerrar una fase grande) y la final, más breve porque la intermedia ya dejó la mitad escrita.

También hay un momento no negociable: después de un incidente serio (semanas de retrabajo, un cliente que casi se va). Ahí la sesión no espera al cierre: se hace en los 5 días siguientes, mientras los detalles están frescos.

Para equipos que trabajan por sprints, la lección aprendida no reemplaza la retrospectiva: la retrospectiva ajusta el proceso del próximo sprint (y sus formatos son ideales para eso); las lecciones aprendidas destilan, al cierre, lo que el próximo proyecto entero debe hacer distinto.

Con el formato de 4 columnas, la sesión no necesita dinámicas: necesita tiempo acotado y un moderador que no sea quien dirigió el proyecto (para que las críticas fluyan). El objetivo declarado no es “analizar qué pasó” sino salir con 5-10 filas llenas.

Ningún documento de lecciones se lee por voluntad propia. La única forma confiable de que el siguiente proyecto las use es hacerlas parte de su arranque: la agenda del kickoff de proyecto incluye 10 minutos de “lecciones del último proyecto similar”, con las 3 filas más relevantes leídas en voz alta y convertidas en ajustes del plan frente al cliente.

Así la lección cambia de estatus: deja de ser historia y pasa a ser restricción del nuevo plan (el plazo de aprobación, el buffer de QA, el canal único con el cliente). Y el ciclo se cierra: cuando este proyecto termine, sus propias lecciones entrarán al mismo carril.

Para mantener la vista de conjunto —si el proyecto está aprendiendo de verdad o solo acumulando documentos— conviene revisar estas filas junto al resto de los KPIs del proyecto en el cierre: las lecciones con efecto medido son las que valen.