Documentos del Proyecto · Serie 15 · Semana Ejecución y control · Tema 450
Todas las metodologías piden lecciones aprendidas. Todas las organizaciones dicen que las recogen. Y casi ninguna las usa, por una razón que no tiene nada que ver con el formato del documento.
Para qué sirve, en una línea
Dejar escrito algo que este proyecto ha descubierto, en términos que le sirvan a alguien que aún no ha empezado el suyo.
El motivo real de que no funcionen
Amy Edmondson, de Harvard, hace desde hace años una pregunta a los directivos con los que trabaja. Primero: de los fallos que ocurren en su organización, ¿cuántos son de verdad reprochables, es decir, alguien hizo algo que no debía? Las respuestas van de un 2 a un 5 %.
Después pregunta cuántos se tratan como reprochables. Ahí, cuenta ella, suele haber una pausa o una risa incómoda antes de contestar: entre un 70 y un 90 %.
Esa distancia explica el documento entero. Si casi cualquier fallo se va a tratar como culpa de alguien, nadie lo cuenta. Y lo que no se cuenta no se aprende.
Edmondson ordena los fallos en un abanico que va de lo reprochable a lo encomiable: desviarse a propósito de un procedimiento, hacerlo por descuido, no tener la capacidad o la formación necesarias, seguir correctamente un proceso que estaba mal diseñado, enfrentarse a una tarea demasiado difícil para salir bien siempre, y toparse con la complejidad de un sistema que se rompe en una combinación nueva.
Solo los dos primeros son razonablemente reprochables. Los demás son información, y son la mayoría.
Qué lleva una lección aprendida
- Situación. Qué pasó, con datos y fechas. Sin nombres.
- Por qué pasó. La causa, no el síntoma.
- Consecuencia. Cuánto costó, en dinero o en días. Sin cifra, la lección no convence a nadie.
- Qué haríamos distinto. Una acción concreta, no un propósito.
- A quién le sirve y cuándo. El campo que decide si alguien la va a encontrar.
«Mejorar la comunicación» no es una lección
Es la frase que aparece en la mitad de los repositorios de lecciones aprendidas del mundo, y no dice nada: ni qué hacer, ni cuándo, ni quién.
Una lección aprendida se escribe en imperativo y con detalle suficiente para ejecutarla:
«No fijar hitos de validación con el área financiera entre el día 25 y el 5 del mes siguiente: es su periodo de cierre y no hay disponibilidad real. Detectado en dos proyectos. Coste del segundo: seis semanas.»
Eso sí lo puede aplicar alguien que no estuvo.
El problema de encontrarlas
Hay repositorios con ochocientas lecciones aprendidas que nadie consulta. No porque no valgan: porque buscar entre ochocientas es peor que no buscar.
Dos cosas lo arreglan, y ninguna es una herramienta:
- Etiquetar por momento de uso, no por materia. No «riesgos», sino «al planificar el arranque», «al contratar un proveedor», «al cerrar una fase». Así la lección aparece cuando toca.
- Convertir las buenas en otra cosa. Una lección que se repite dos veces deja de ser una lección: se convierte en una línea de una plantilla, un punto de una lista de comprobación o una pregunta en un formulario. Ahí sí se aplica sola, sin que nadie recuerde buscarla.
Qué la vuelve papel mojado
- Se escriben solo al cerrar. A los ocho meses nadie recuerda el detalle que hacía útil la lección.
- Solo se registran fracasos. Lo que salió bien también se aprende, y además anima a escribir.
- Llevan nombres. Y entonces son un informe disciplinario disfrazado, y se acabó la fuente.
- Sin coste. «Hubo retrasos» no mueve a nadie; «seis semanas» sí.
- Nadie las lee al empezar. El momento de consultarlas es la planificación, no el cierre.
- Genéricas. «Mejorar la comunicación» ocupa sitio y no aporta nada.
Y si me falta lo que pide
No consigo que el equipo cuente lo que salió mal. Cambia la unidad de análisis: pregunta por el proceso, no por las personas. «¿Qué hizo que esto fuera difícil de hacer bien?» saca mucho más que «¿qué pasó?».
No sé la causa real. Escríbelo igual, diciendo que no se sabe. Una lección honesta con la causa abierta es mejor que una causa inventada que despiste al siguiente.
Nadie va a leer esto. Probablemente tengas razón. Por eso la lección buena no termina en el repositorio: termina en una plantilla o en una lista de comprobación que sí se usa.
Caso práctico: la lección que estaba escrita dos veces
Escenario construido con patrones habituales; las cifras son ilustrativas.
Una organización con una oficina de proyectos ordenada y un repositorio de lecciones aprendidas con más de cuatrocientas entradas, alimentado religiosamente en cada cierre.
Un proyecto de implantación se atascó en las pruebas de aceptación porque el área usuaria no tenía gente disponible: coincidió con su periodo de mayor carga operativa. Seis semanas de retraso y un equipo entero esperando.
En el cierre se escribió la lección, correctamente redactada.
Al archivarla, alguien buscó por curiosidad y encontró dos entradas anteriores que decían esencialmente lo mismo, de proyectos de 2022 y 2023. Las tres estaban etiquetadas como «gestión de interesados».
Nadie las había encontrado porque nadie buscaba «gestión de interesados» mientras montaba un cronograma. Y aunque hubiera buscado, esa etiqueta tenía setenta y una entradas.
La organización había aprendido la lección tres veces y no la había incorporado ninguna.
Lo que se hizo entonces no fue escribir una cuarta. Fue añadir una línea a la lista de comprobación de planificación: «¿Se ha cruzado el cronograma con los periodos de máxima carga de las áreas que tienen que validar?».
Una pregunta en una lista que sí se usa vale más que cuarenta lecciones en un repositorio que no se abre.
Checklist
- ¿Se recogen durante el proyecto, no solo al cerrar?
- ¿Están sin nombres?
- ¿Cada una dice cuánto costó?
- ¿Están en imperativo y se pueden ejecutar?
- ¿Están etiquetadas por el momento en que sirven?
- ¿Alguna se ha convertido ya en una línea de plantilla o de checklist?
- ¿Alguien consultó el repositorio al planificar este proyecto?
Para cerrar
El objetivo no es tener muchas lecciones aprendidas: es tener pocas y que estén incorporadas donde se trabaja. Una lección que sigue siendo una lección al cabo de tres proyectos no se ha aprendido; solo se ha escrito tres veces.
Te leo en los comentarios: ¿cuándo fue la última vez que alguien de tu organización consultó una lección aprendida antes de empezar algo?
Referencias
- Edmondson, A., Strategies for Learning from Failure, Harvard Business Review, abril de 2011, sobre el abanico de causas del fracaso y la distancia entre los fallos reprochables y los tratados como tales.
- Project Management Institute, Guía del PMBOK, sobre el registro de lecciones aprendidas y los activos de los procesos de la organización.
- ISO 21502:2020, sobre aprendizaje organizativo a partir de los proyectos.
← Anterior en la serie: Trabajar en equipo también se evalúa
Siguiente en la serie: Acta de reunión: decisiones, no relato →
Este artículo forma parte de Documentos del Proyecto, una serie de 73 artículos. Ver todos los de esta serie · Índice completo por materia.