Las pequeñas mentiras que nos contamos los jefes de proyecto

31 agosto, 2011

El interesante post de mi colega (y sin embargo amigo) Robert Clarisó que publicó hace algunas semanas en esta mismo blog me ha hecho pensar sobre algunas cosas de las que nos contamos los jefes de proyecto y programas, y de las que les contamos a nuestros colaboradores, incluidos, por supuesto, los estudiantes que nos sufren.

Mis pensamientos son un poco largos y no sé si útiles, de manera que los partiré en varios trozos y amenizaré con algunas webs divertidas, de manera que el que quiera puede cambiar a cosas de mayor provecho.
Robert explica su experiencia fascinante en el museo Vasamuseet, de Estocolmo, una preciosidad dedicada a un empeño tan caro y complejo como inútil y fallido, el barco de guerra más grande y sofisticado del mundo (Parece, por cierto, un sueño catalán: los catalanes «celebramos» una derrota en el día de la patria).

Y sostiene Robert seguidamente todas las razones, de libro, por las que el proyecto fracasó: objetivos y alcance ambiciosos, poco definidos y cambiantes; falta de liderazgo o el peor de los liderazgos posibles (¡el del rey!), falta de pruebas, etc.

Si la literatura sobre gestión de proyectos es amplia, aún lo es más la literatura sobre proyectos fallidos, empezando por todos los libros y películas escritos sobre las expediciones fracasadas al Everest. Una organización bien lucrativa publica anualmente el «informe del caos» (llamado ahora ya el «manifiesto del caos»), muy criticado en la literatura profesional y científica, por diversas razones, pero probablemente la referencia más leída y escuchada, al menos entre el público norteamericano.

Según los informes del Standish Group, a partir de entrevistas con CIOs (Chief Information Officers, responsables de organización y sistemas) y CEOs (Chief Executive Officers, primeros ejecutivos, o sea Consejeros Delegados o Directores Generales), más o menos dos tercios de los proyectos fallan, o sea acaban por encima del tiempo, del presupuesto o lejos de los requerimientos funcionales de los usuarios. Fallan mucho (un tercio), o más o menos (otro tercio). Un tercio alcanza sus objetivos. ¡Bien!
Para más o menos tranquilidad de los ingenieros, las razones son principalmente organizativas: cosas que el cliente debe hacer y no hace, u organización y gestión del proyecto. ¡Uf!, qué alivio.

¿Habéis asistido alguna vez a reuniones de revisión de proyectos y programas? Es una experiencia fascinante. Más o menos un 80% de los proyectos tienen un fantástico semáforo verde, menos de un 20% un semáforo amarillo y apenas dos o tres un semáforo rojo. Es frecuente pactar por adelantado los resultados entre los diferentes departamentos, y se consideran exitosos proyectos que hace tiempo dejaron de estar en funcionamiento, por coste y/o tiempo.

Recientemente, algunas organizaciones han descubierto el problema. El sistema de semáforos no funciona, debe cambiarse. O quizás las métricas. O las reglas con que medimos el éxito de la gestión de proyectos.

¿Hablamos de todo ésto y sobre los jefes de proyecto un poco (sólo un poco) más en serio?

(Visited 284 times, 1 visits today)
Autor / Autora
José Ramón Rodríguez
Profesor de Dirección de Sistemas de Información, Gestión de Proyectos y Business Intelligence de los Estudios de Informática, Multimedia y Telecomunicación de la UOC y consultor de empresas independiente.
Comentarios
Miguel Angel Bueno2 septiembre, 2011 a las 4:54 pm

Tal vez los jefes de proyecto deberían leer a Dilbert para ser un poco más… digamos, realistas. O tal vez debería ser lectura obligada en la Universidad. El caso es que opino que los proyectos fallan porque la gente que participa no hace su trabajo, bien porque no quieran (unos pocos, los pasotas) o bien porque no saben (la mayoría).
Un proyecto no tiene únicamente una parte técnica, también hay una parte de planificación, gestión, evaluación, control de calidad… Todo eso no pueden ser compartimentos estancos, como en algunas organizaciones que conozco. Tienen que estar estrechamente entrelazadas o cada departamento barrerá para su casa sin preocuparle lo más mínimo lo que les suceda a los otros: «Lo nuestro ya está. Lo otro es cosa suya, que se espabilen…» he oído decir más de una vez.
Y llevar el control de todo eso es lo que menos se sabe hacer, porque hay aptitudes que no se pueden enseñar: o se es de una determinada manera, o como mucho puedes apuntarte a carísimos cursos y másters que te dan una retahíla de recetas más o menos experimentadas, pero que luego chocan de frente con la realidad de cada proyecto concreto. Y creedme, sé de lo que hablo porque lo he visto.
Hace muchos años, cuando yo empezaba en esto de la informática, hice un curso de análisis. El profe era jefe de no sé qué de la SEAT. Un lujo. Después de varios meses de estudiar lo que se movía por entonces en ese campo, el último día, como despedida nos espetó: «Pero recordad que las únicas herramientas que realmente necesitaréis para hacer un buen análisis son papel, lápiz y goma, mucha goma». Veinte años después yo también lo creo, y lo aplico. Eso implica pensar, pensar mucho.
Creo fírmemento que en esto de la gestión de proyectos lo que se necesita no son grandes estrategias ni metodologías rimbombantes ni herramientas fantásticas (y carísimas), sino sencillamente sentido común (a ser posible, mucho), pararse a pensar bien las cosas, tener en cuenta las consecuencias de lo que se hace y de lo que no se hace, y finalmente tener la suficiente valentía como para decir «no» cuando se deba decir «no». Eso es un líder, no un jefe, que son dos cosas distintas.
En fin, como véis, yo también sé enrollarme.
Saludos.
Miguel Ángel Bueno
mabs@galeon.com

Responder
jose-ramon rodriguez9 septiembre, 2011 a las 10:10 am

Hola, Miguel Angel, gracias por tu comentario.
Pozí, que dicen algunos, mucho sentido común, algunas herramientas básicas y un tipo de diálogo con los usuarios y sus jefes que a los «técnicos» nos suele fallar.
Me he propuesto en las próximas semanas hacen algunos otros posts sobre estos temas: cuáles son las conclusiones de los «informes del caos» y cómo interpretarlas; cuáles son las fortalezas y debilidades de las metodologías «potentes», tipo PMBOK; qué pueden aportar otras visiones, tipo Agile, sobre todo en el tipo de proyectos que hacemos ahora.
Un saludo

Responder
Deja un comentario