Por qué las lecciones aprendidas rara vez cambian el siguiente proyecto
La mayoría de los equipos las escriben, pero pocos las aplican. Lo que descubrieron las auditorías de la NASA, cómo funciona Pause and Learn y un ciclo que vincula cada lección con un cambio real.
Ibrahim Elkobeissi · · 6 min de lectura ·
Todo proyecto termina con una lista: qué salió bien, qué salió mal y qué haríamos de forma diferente. La lista se archiva. El siguiente proyecto comienza y, más a menudo de lo que los equipos admiten, comete los mismos errores.
El problema rara vez es la captura. Es la distancia entre una lección identificada y una lección aplicada. Uno de los programas de lecciones aprendidas más documentados del mundo, el de la NASA, ha medido esa distancia. Sus hallazgos son lo primero. Un pequeño ciclo que cierra esa distancia es lo segundo.
Identificar no es lo mismo que aprender
Una lección se identifica cuando alguien la escribe. Se aprende cuando la organización se comporta de manera diferente gracias a ella. Entre ambas existe una gran carga de trabajo que la mayoría de los procesos de lecciones aprendidas nunca asignan a nadie.
La investigación sobre organizaciones de proyectos nombra este patrón directamente. En el International Journal of Project Management, Duffield y Whitty descubrieron que los procesos de lecciones aprendidas rara vez ocurren y, cuando lo hacen, se centran en la "identificación de lecciones en lugar del aprendizaje organizacional". El resultado es un documento. El objetivo previsto es un cambio en la forma de trabajar del siguiente equipo. Son cosas distintas, y solo una de ellas es fácil de producir.
Lo que descubrieron las propias auditorías de la NASA
La NASA se toma las lecciones en serio. Gestiona el Lessons Learned Information System (LLIS) y su requisito procedimental NPR 7120.6, el Lessons Learned Process, establece cómo se recopilan, validan, evalúan y codifican las lecciones. Esto convierte a sus auditorías en un caso de estudio útil. Si las lecciones se estancan allí, la causa no es la falta de intención.
En 2001, la U.S. General Accounting Office (ahora Government Accountability Office) encuestó a los gerentes de programas y proyectos de la NASA. De los 115 que respondieron:
- El 27% no conocía el LLIS antes de la encuesta.
- El 17.5% había aplicado una lección que encontró a través del LLIS.
- El 58% afirmó que los sistemas actuales no les permitían recuperar las lecciones adecuadas en el momento oportuno.
La GAO concluyó que "las lecciones no se identifican, recopilan o comparten de forma rutinaria". El aprendizaje sí ocurría, pero principalmente mediante revisiones y conversaciones con colegas, no a través del sistema diseñado para ello.
En 2012, la Oficina del Inspector General de la NASA retomó la cuestión. Encuestó a 28 proyectos de ciencia y vuelos espaciales lanzados entre 2005 y 2011. Dieciséis gerentes de proyecto dijeron utilizar el LLIS, y solo seis de ellos lo consideraron útil. Doce habían aportado lecciones. Solo diez conocían la obligación de aportarlas. Los gerentes describieron el sistema como obsoleto y difícil de consultar, y muchos consideraron que sus propios proyectos eran demasiado únicos para que las lecciones pasadas fueran aplicables. La OIG también descubrió que solo dos centros de la NASA cumplían plenamente con la norma NPR 7120.6 en la gestión de su propio proceso.
El patrón es constante a lo largo de once años. Las lecciones se almacenaban. Pocas se recuperaban. Menos aún cambiaban el trabajo.
Por qué se estancan las lecciones
Al analizar detenidamente las auditorías, tres causas aparecen recurrentemente. Se aplican mucho más allá de los vuelos espaciales.
- Las lecciones se escriben como historias, no como instrucciones. Un párrafo sobre lo que sucedió es difícil de ejecutar. No indica qué documento, paso o decisión debería ser diferente ahora.
- Las lecciones viven separadas del trabajo. Una base de datos independiente exige que la gente ocupada vaya a buscarlas. La mayoría no lo hará, especialmente bajo presión de cronograma. La GAO descubrió que los gerentes aprendían más de sus colegas y revisiones que del sistema.
- Nadie supervisa. Se contabiliza la captura, pero no la aplicación. Cuando la única métrica es cuántas lecciones se registraron, los equipos se vuelven expertos en registrar.
Ninguno de estos es solo un problema tecnológico. Cada uno es un eslabón perdido: entre la lección y aquello que debe cambiar, y entre ese cambio y la evidencia de que ocurrió.
Pause and Learn: aprender mientras el proyecto sigue en marcha
El Centro de Vuelo Espacial NASA Goddard respondió en parte a esto con una práctica llamada Pause and Learn. En lugar de esperar a una revisión de cierre, el equipo del proyecto se detiene en puntos significativos del ciclo de vida para reflexionar en conjunto.
Según describen Edward Rogers y Barbara Fillip, una sesión estándar reúne a entre 10 y 20 personas de un equipo de proyecto durante unos 90 minutos. Se abordan cuatro o cinco temas elegidos previamente y se analizan tres preguntas: qué salió bien, qué no salió bien y qué haríamos de forma diferente. Las reglas básicas se leen en cada sesión. La discusión se registra como un mapa de conocimiento, se revisa con el director del proyecto y se comparte en talleres posteriores. Las sesiones se planifican dentro del plan de lecciones aprendidas del proyecto, no se convocan solo cuando algo falla.
Pause and Learn acierta en dos aspectos. Captura las lecciones mientras la memoria está fresca y mantiene la conversación dentro del equipo que debe actuar sobre ella. Lo que no hace por sí solo es garantizar que el siguiente proyecto adopte la lección. Para eso se necesita un paso más.
Un proceso de lecciones aprendidas que cierra el ciclo
El estándar internacional para sistemas de gestión del conocimiento, ISO 30401, establece los requisitos para establecer, implementar, mantener, revisar y mejorar un sistema de gestión del conocimiento. El marco de excelencia NIST Baldrige pregunta, en el punto 4.2, cómo construye y gestiona el conocimiento organizacional, cómo comparte las mejores prácticas y cómo utiliza su conocimiento para integrar el aprendizaje en la forma en que opera su organización. Ambos apuntan a la misma idea: el conocimiento tiene un ciclo de vida y la captura es solo su primera etapa.
En la práctica, un ciclo de trabajo tiene tres pasos.
1. Capturar en cuatro campos. Para cada lección, escriba qué esperaba, qué sucedió realmente, por qué ocurrió la brecha y qué cambiará. El último campo es el más importante. Si un equipo no puede identificar un cambio, tiene una observación, no una lección.
2. Vincular la lección con su objetivo. Cada lección debe apuntar al procedimiento, lista de verificación, plantilla o decisión que modifica. Actualice ese documento y registre el vínculo. Ahora la lección vive donde trabajará el siguiente equipo, no en una carpeta que tengan que recordar abrir.
3. Comprobar que el siguiente proyecto la aplicó. Cuando un proyecto posterior llegue al paso que afecta la lección, confirme que se utilizó el procedimiento actualizado. Si se utilizó, la lección se ha aplicado. Si no, averigüe por qué. Quizás el cambio no fue claro o se omitió el paso. Ese hallazgo es, en sí mismo, una lección, y vuelve al primer paso.
Nuestra regla en Roadyom es la prueba antes que la afirmación. Para las lecciones, esto significa que nada cuenta como aprendido hasta que un trabajo posterior lo demuestre. Por tanto, mida el ciclo por su último paso. Un indicador útil es sencillo: de las lecciones capturadas el año pasado, ¿cuántas están vinculadas a un procedimiento y cuántas de ellas fueron aplicadas por un proyecto posterior? Ese número es más difícil de aumentar que el recuento de lecciones registradas. También es el único que le indica si realmente está aprendiendo.
Una lección que no propone un cambio es una observación. Un cambio que ningún paso posterior utiliza es un borrador.
Cómo Prism gestiona este ciclo
Prism integra las decisiones y el conocimiento de una organización como pasos dentro del propio trabajo. Un equipo puede abrir un registro de Pause and Learn en cualquier momento, capturar qué se esperaba, qué sucedió, por qué y qué cambia, y vincular cada lección al procedimiento que debe actualizar. Prism considera que una lección se ha integrado solo cuando está vinculada a un procedimiento y un paso posterior la ha aplicado. Hasta entonces, permanece visible como abierta. Las personas deciden qué cambiar; Prism mantiene el registro de si el cambio perduró.
Fuentes
- Survey of NASA’s Lessons Learned Process (GAO-01-1015R). U.S. General Accounting Office (ahora Government Accountability Office), 2001.
- Review of NASA’s Lessons Learned Information System (IG-12-012). NASA Office of Inspector General, 2012.
- Mapping Lessons Learned to Improve Contextual Learning at NASA. NASA Goddard Space Flight Center (E. W. Rogers, B. Fillip), NASA Technical Reports Server, 2016.
- Developing a systemic lessons learned knowledge model for organisational learning through projects. International Journal of Project Management 33(2) (S. Duffield, S. J. Whitty), 2015.
- ISO 30401:2018 Knowledge management systems — Requirements. International Organization for Standardization, 2018.
- Baldrige Excellence Builder 2021–2022 (Item 4.2, Information and Knowledge Management). NIST Baldrige Performance Excellence Program, 2021.
Comentarios
Integrado en ROADYOM Prism
Más información
