Lecciones de gestión de Marte

Resumen.

Reimpresión: F0405A

La legendaria iniciativa Faster, Better, Cheaper de la NASA aceleró el desarrollo de la nave espacial de la agencia. Pero cuando las misiones comenzaron a fallar, la culpa fue un aprendizaje organizacional defectuoso, no el hardware.

En enero, dos pequeñas naves espaciales rebotaron en la superficie de Marte, entregando exploradores que han cautivado al mundo con sus impresionantes fotografías del paisaje marciano. Por el contrario, cuatro años antes la NASA había observado con horror cómo dos misiones sucesivas a Marte dejaban de existir en un lapso de tres meses. Gran parte de la culpa de esos fracasos se debe a la iniciativa Faster, Better, Cheaper (FBC) de la agencia, un programa establecido a principios de la década de 1990 y diseñado para transformar la forma en que la NASA desarrolló naves espaciales no tripuladas. El objetivo era reducir drásticamente los costos del proyecto y, al mismo tiempo, acelerar los tiempos de desarrollo. De hecho, el desarrollo era más rápido y las misiones eran más baratas, pero el enfoque era defectuoso, como sugieren las condenadas misiones de 1999. Mientras hablaba con los gerentes de la NASA sobre el programa FBC, descubrí un problema organizacional general —una discapacidad de aprendizaje, por así decir— que imparte lecciones a los gerentes en muchos otros entornos.

Al pasar a FBC de un enfoque de desarrollo lento, fiable pero costoso, la NASA obligó a sus directores de proyectos a inventar procesos y procedimientos radicalmente nuevos. FBC les impuso restricciones presupuestarias, programadas y de peso que no podían cumplirse utilizando los enfoques tradicionales de la NASA para el desarrollo de naves espaciales. «La actitud era 'El libro no funciona. Así que tira el libro, prueba algo diferente y luego escribe un libro nuevo'», explicó un gerente de la NASA. En este enfoque estaba implícita la necesidad de que los directores de proyectos aprendieran de las experiencias colectivas de la organización, adoptaran lo que funcionaba y desecharan lo que no funcionó. Desafortunadamente, la NASA socavó este proceso de aprendizaje de varias maneras.

En primer lugar, con el lanzamiento de cada misión de FBC, la NASA exigió tiempos de desarrollo cada vez más rápidos y costos aún más bajos. Sin embargo, debido a que una pequeña nave espacial tarda más de cuatro años en pasar de la mesa de dibujo a la misión completada, los gerentes se vieron obligados a satisfacer las demandas más duras de los nuevos proyectos mientras los proyectos anteriores aún estaban en marcha. Así que no podían captar todas las lecciones potenciales de una misión antes de pasar a la siguiente. En resumen, la NASA estaba subiendo el listón antes de ver si los jefes de proyecto podían despejarlo dónde estaba. Para cuando la organización se dio cuenta de que había puesto el listón demasiado alto (cuando las primeras misiones de FBC comenzaron a fallar), la cartera de proyectos estaba llena de misiones potencialmente comprometidas. No es de extrañar que las misiones posteriores del FBC fallaran con más frecuencia que las anteriores.

En segundo lugar, la NASA no se dio cuenta de que, debido a que la iniciativa FBC dependía tanto del aprendizaje compartido, requeriría un enfoque más agresivo y sistemático de la gestión del conocimiento. Aunque la NASA había implementado una base de datos de «lecciones aprendidas» en 1995, una encuesta realizada en 2001 reveló que solo una cuarta parte de sus administradores contribuían a ella. Un número similar de gerentes desconocían la existencia del sistema. Además, si bien las «revisiones del equipo rojo» —revisiones periódicas del progreso realizadas por los gerentes más experimentados de la NASA— resultaron invaluables en los primeros proyectos de FBC, la NASA realizó menos de estas evaluaciones en misiones posteriores. Como consecuencia, la transferencia de aprendizaje en toda la organización se vio afectada.

Finalmente, la NASA cayó presa del «aprendizaje supersticioso», la suposición de que hay más que extraer de misiones fallidas que de misiones exitosas. Sin embargo, en el desafiante clima de la exploración espacial, la diferencia entre lo que hace que una misión tenga éxito y otra fracase puede ser sutil. No hay razón para creer que el éxito indica un proceso impecable, mientras que el fracaso es el resultado de malas prácticas atroces. Por ejemplo, se podrían haber cometido tantos errores en la célebre misión Pathfinder de 1997 como en la fallida misión Polar Lander de 1999. Pero la NASA nunca lo sabrá. Al no realizar postmortems detallados sobre sus misiones exitosas, la agencia espacial perdió la oportunidad de identificar problemas (y soluciones) que podrían haber ayudado a evitar fracasos posteriores.

No hay razón para creer que el éxito indica un proceso impecable, mientras que el fracaso es el resultado de malas prácticas atroces.

La costosa experiencia de la NASA con FBC contiene lecciones importantes para cualquier organización que lleve a cabo una iniciativa de cambio, ya sea una mejora de procesos, una reestructuración o un cambio fundamental en la misión o la cultura:

• Determina de antemano qué comentarios necesitarás sobre el progreso de una iniciativa y cuándo la recibirás.
• No subas el listón del rendimiento hasta que estés seguro de que la organización puede obstáculo en su posición actual. Usa los comentarios de tus primeros esfuerzos para determinar cuánto subir (o bajar) el listón.

• Implementar programas de gestión del conocimiento para capturar todo el aprendizaje importante que se produce durante la iniciativa. Diseñar sistemas y procesos para transferir conocimientos explícitos e implícitos.
• Exorciza el aprendizaje supersticioso de la organización. Institucionalizar las postmortems de los proyectos. Cuando un proyecto tenga éxito, averigüe por qué. Y averigüe qué errores se cometieron que han provocado el fracaso.

— Escrito por Alan MacCormack