Volver sanos y salvos

Antes de convertirse en un famoso profesor de gestión de empresas en la Escuela de Harvard, Jai Jaikumar era un alumno brillante en uno de los Institutos de Tecnología de élite de la India, un escalador experimentado y líder de expediciones a los macizos del Himalaya. En una de éstas, pasada la hora planeada para volver al campamento base, seducidos por alcanzar la cumbre, perdió a todos sus hombres en el descenso cuando se derrumbó una cornisa de piedra y hielo. Sólo se salvó Jai, recogido días después por un pastor y su familia (1).

No soy escalador, pero he usado ésta y otras historias de montaña en los cursos de gestión de proyectos. Me gusta también poner a los estudiantes el impresionante documental Everest (2), que incluye una de las primeras apariciones mediáticas de Araceli Segarra. Los autores y practicantes de Project management solemos discutir las causas de los éxitos y fracasos de las expediciones al Himalaya. El Himalaya parece la metáfora perfecta de la profesión: una meta clara, un líder confiable, un buen plan, montañeros experimentados y bien organizados, una ejecución cuidadosa y sujeta al plan y unos procesos de gestión adecuados deberían conducir al éxito. O no.

Para mí, sin embargo, lo que más me interesa de Jai Jaikumar y de otras expediciones fracasadas son dos cuestiones que se suelen pasar de largo, dos consideraciones casi morales, si se me permite. La primera es una reflexión sobre el objetivo: ¿es el objetivo alcanzar la cumbre o regresar vivos? La segunda, relacionada con la anterior, es: ¿cuándo se debe matar un proyecto y retirarse a tiempo?

Los directores de proyectos y la mayor parte de los equipos, lo he dicho algunas veces, somos gente entrenada y motivada para hacer, no para no hacer o retirarnos; nos seduce culminar hitos y alcanzar el objetivo, de algún modo cueste lo que cueste. En un libro de hace unos años presentábamos una lista de causas que aconsejan valorar o decidir lo que llamábamos el “cierre abrupto” de un trabajo (3), un “proyecto abortado” lo llaman algunos.

El profesor Michael Roberto ha estudiado, a partir de las experiencias de escalada, los procesos psicológicos individuales y de grupo que conducen al fracaso de toda clase de proyectos empresariales y tecnológicos: el exceso de confianza, la fe ciega, el entusiasmo colectivo, lo que los montañeros llaman la “summit fever” (la fiebre de la cima), que lleva a exagerar el progreso (real o potencial) y minimizar los problemas y riesgos (4).

(Hay un escenario peor: acabar el proyecto es más frustrante cuando, enormemente satisfechos con nuestro trabajo, el cliente ya no hará nada con él, cuando te has quedado sin cliente y rodeado de enemigos, y en ocasiones ni cobrarás las facturas. Lo he vivido.)

La profesora Isabelle Royes ha analizado también estos fracasos. Su consejo: desconfiar de los entusiastas, establecer signos de alarma, contratar un cenizo en el equipo (aquel pesimista crónico que nos avisará de todo lo que está saliendo mal y puede salir peor), establecer un plan de salida… y un jefe de proyecto que se ocupe de la salida (lo que no podrá ni sabrá hacer el que nos llevaba hacia la cima) (5).  Y hacerlo lo antes posible: “Si darle fin fuera ya el fin, más valdría darle fin pronto” (6).

Porque, al final del día, el objetivo del proyecto, creo yo, es regresar sanos y salvos para empezar (ojalá) otro nuevo.

Notas:

1. Squire R, Vickers-Willis S, Wilson H (2000): “A fall before rising: The story of Jai Jaikumar”. Harvard Business School. Caso 9-600-047.
2. http://www.everestfilm.com/
3. Rodríguez JR, García Mínguez J, Lamarca Orozco I. (2007): Gestión de Proyectos Informáticos: Métodos, Herramientas y Casos (Editorial UOC).
4. Roberto MA (2002): “Lessons from the Everest: The Interaction of Cognitive Bias, Psychological Safety and System Complexity”. California Management Review, Vol. 45, 1:136-158.
5. Royes I (2003). “Why Bad Projects are So Hard to Kill”. Harvard Business Review, Febrero.
6. Hoy tengo día shakespeariano. La cita es del primer acto, escena 7 de Macbeth, un mal jefe de proyecto. Uso la nueva versión en español de Angel-Luis Pujalte, muy bella, en Libros del Zorro Rojo (2012), aunque la versión de Pujalte ya se publicó baratita en Espasa Calpe hace años.

4 Comments

  1. Como siempre un artículo estupendo José Ramón……y lleno de verdades!

    Reply
  2. Hola Belen, que nombre bonito.
    Gracias como siempre por tus comentarios.
    Voy a proponer a Dani, Josep y Jordi que te hagan presidenta del club de fans del blog de los Estudios.
    Un abrazo

    Reply
  3. He llegado a este artículo a colación de una PEC de los estudios de Inteligencia de Negocio y Big Data y realmente me ha encantado. Enhorabuena por el mismo.

    Reply
    • Gracias, José Antonio. La verdad es que este es de mis preferidos, jeje.

      Reply

Trackbacks/Pingbacks

  1. Bitacoras.com - Información Bitacoras.com... Valora en Bitacoras.com: Antes de convertirse en un famoso profesor de gestión de empresas en la Escuela…
  2. Rescatar un proyecto | iNFoRMáTiCa++ - [...] veces, lo mejor que podemos hacer con un proyecto fallido es matarlo cuanto antes y regresar “sanos y salvos”.…
  3. Estar alerta, reconocer los problemas y avisar lo antes posible | iNFoRMáTiCa++ - [...] de software, que usan las tablas clásicas de Boehm sobre el coste de los cambios). Esto incluye matar el proyecto,…

Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Leer entrada anterior
Ágil

En nuestros primeros blogs de gestión de proyectos empezamos, como casi todo el mundo, por los chistes, los fracasos y...

Cerrar