Proyectos que Matan (parte ii)

Jefe de Proyecto de un proyecto Caníbal

Los proyectos caníbal suelen engullir a más de un Jefe de Proyecto. Tras dos capitanes (Project Managers) pasados por la quilla, la percepción sobre el proyecto suele cambiar y existe una imagen clara del mismo. A estas alturas todos conocen la naturaleza hostil del proyecto y su fama le precede. Los empleados de la organización se hacen a  un lado, son ya sonadas las broncas del cliente y la gente rechaza directamente el integrarse como parte del equipo de proyecto.

 

Empezar  el proyecto sin tener firmado el contrato definitivo con el cliente suele ser embrión de proyectos Caníbal. Podemos pensar que esto es así porque evidentemente, de mala fe intentarán introducir nuevo alcance una vez que la empresa haya invertido recursos en arrancar el proyecto. Sin embargo esa no debe ser la mayor preocupación del Project Manager ya que negociar ese tipo de términos suele estar fuera de su alcance y debe ser el departamento comercial el que se encargue de negociar ese tipo de asuntos (con el soporte necesario por parte del Project Manager, por supuesto)

El problema real de esta situación suele venir por las decisiones que debemos tomar en el arranque del proyecto que pueden influir en el diseño de la solución o en el modelo de gestión que debemos adoptar. Si el contrato no está firmado, inherentemente tendremos una indefinición de alcance. Incluso los flecos más pequeños que queden por cerrar pueden impactar en el diseño global de manera que nos veamos obligados a rehacer parte del trabajo en etapas intermedias del proyecto.

Los párrafos anteriores nos lleva a comentar otra característica de los proyectos Caníbal, que es el desconocimiento real del alcance del mismo. En proyectos de este tipo es común escuchar frases del tipo “llevamos un año en el proyecto y aún seguimos descubriendo cosas que tenemos que hacer…” Este tipo de frases siempre denotan una falta de conocimiento del alcance real del proyecto.

A menudo el contrato es voluminoso, escrito en diferentes documentos o incluso inexistente; que el alcance real del proyecto no ha sido descubierto en su totalidad. Y esto es así porque además de los grandes objetivos del proyecto, normalmente conocidos por todos y aventados a los cuatro vientos en la organización, existen multitud de detalles minúsculos sin los cuales el proyecto no podrá nunca darse por concluido. Por tanto, a veces, a un proyecto caníbal se le identifica por no tener definido el alcance en un documento específico del proyecto acordado y revisado con el cliente, basado en el contrato; Se suele hacer referencia a los contratos y las actas de reunión con el cliente pero nunca se ha traducido el  contrato en lenguaje del proyecto.

Una buena práctica que da resultados positivos es montar un workshop con la parte comercial para explicar a todos los miembros del proyecto el alcance real del contrato. Esto dará visión al equipo visión de la parte comercial, y completará la visión que se tenga del alcance del proyecto. Con el equipo Core del proyecto, se puede repetir este taller, pero organizando sesiones en las que cada uno de los integrantes explique una parte del contrato al resto de miembros.

Conclusión: La primera fuente de requisitos de un proyecto es el pliego, acompañado de la oferta. Cuanto más extenso es el pliego mejor: más detalles tendremos para identificar el alcance del proyecto.

Proyectos que Matan (parte i)

Saturno Devorando a un Hijo: Francisco de Goya

Hay proyectos caníbal, proyectos que matan, proyectos crueles y feroces que destruyen todo aquello que se cruza en su camino. 

Estos proyectos son como un Dios Maya: necesitan sangre fresca, tantos recursos asignes, tantos recursos quedarán absorbidos por un proyecto titánico y desmedido que arrasará todo lo que haya a su paso. Sin embargo, los proyectos que devoran hombres tienen una serie de características comunes que iremos desgranando a lo largo de diferentes post.

Estas características nos deben alertar de que la gestión de estos proyectos necesita de unas grandes habilidades políticas, una capacidad de liderazgo indiscutible y un temple y resistencia al stress a prueba de balas ya que el Project Manager va a tener que explicar un montón de cosas en foros muy diferentes y ante audiencia poco amigable.

Cuando nace un proyecto Caníbal, todos quieren participar en él. Se trata de proyectos con mucha visibilidad, en los cuales se puede obtener gran reconocimiento y experiencia profesional. Es más, a las primeras señales de zozobra, muchos son los que se presentarán voluntarios para tomar los mandos de la nave y reconducirla a buen puerto. Incluso cuando las cosas siguen yendo mal, no faltan voluntarios para reconducir la situación y hacerse cargo de la nave. 

Es normal que tras el primer project Manager sacrificado en aras de hacer ver al cliente que este proyecto se va a conducir con mano firme, que se llame a una consultora especializada en Project Management para que haga un análisis y reflote el barco. Todo son parabienes, pero raramente nadie se para a atender las recomendaciones de los esforzados consultores. Finalmente estos consultores defienden ante el cliente una serie de mejoras  que se deben implementar, todos quedan más o menos conformes y todo vuelve a empezar, asegurando que estos aguerridos consultores se van a quedar para ayudar a reflotar el barco, montando e integrando una oficina de proyectos ad-hoc para el proyecto que ayudará a gestionar la globalidad del proyecto.



Otra característica de los proyectos Caníbal suele ser su tamaño. El tamaño normalmente implica multitud de recursos, y cuantas más personas sean necesarias, mayor es el esfuerzo de comunicación que hay que hacer para coordinar los equipos. Habitualmente los proyectos Caníbal implican a multitud de personas y departamentos. De esta manera los recursos involucrados tienen  diferentes objetivos, a veces contrapuestos.

Como primera conclusión: Los proyectos caníbal adolecen de un correcto modelo de comunicación y coordinación. Este sin embargo no es fruto del proyecto en sí, sino de una incorrecta gestión de las comunicaciones del proyecto.

(To be continued...)

Post Mortem: Benditas Lecciones Aprendidas (ii)

Serpiente Uróboros,

"Aprendemos de la experiencia que los hombres nunca aprenden nada de la experiencia"
George Bernard Shaw, escritor

La recopilación y estudio de las Lecciones aprendidas son posiblemente las actividades a las que menor tiempo se dedican en la vida de un proyecto. Las organizaciones deben gestionar correctamente el conocimiento que poseen y la redacción de unas buenas lecciones aprendidas de cada proyecto que se ejecuta debería ser valorado al mismo nivel que la ejecución exitosa del mismo. 

Si no son entendibles y reutilizables, no hay otra causa que una compilación defectuosa de las mismas, y si la explotación de la información y del repositorio no es ágil y correcto, es por una mala gestión del conocimiento por parte de la compañía. En ambos casos, se trata de lagunas que favorecen la repetición de errores. 

Normalmente no se leen ni se investigan en los momentos previos al arranque de los proyectos porque no aportan un valor claro o están redactadas con obviedades, y como no aportan nada, se consideran algo vacío y carente de valor por lo que no perdemos el tiempo en redactar correctamente las de los proyectos que estamos entregando. Esa es la serpiente uróboros, símbolo del esfuerzo eterno e inútil.

Aunque bien es cierto que una de las aplicaciones de las lecciones aprendidas es usarlas para que la organización aprenda, al final la organización no suele aprender demasiado de estos análisis pues existe una gran dificultad para poder explotar esta información de manera adecuada cuando queremos hacerlo, bien sea por las herramientas que tenemos para acceder a la información (bases de datos generalmente), o por lo difícil que resulta el encontrar algo útil en una capeta compartida en red sin invertir una cantidad de tiempo enorme.

Sin embargo, cuando invertimos el tiempo correcto en recopilar de manera adecuada las experiencias, fallos y aciertos del proyecto, para los involucrados, releer estos documentos suele ser una manera de volver a revivir ciertas situaciones y hacer que nuestra memoria recupere detalles que de otra manera se nos hubieran pasado por alto. Y si el ejercicio es correcto, sirve a otros Jefes de Proyecto que se encuentren ante proyectos similares.

Y lo cuento por propia experiencia. 

Post Mortem: Benditas Lecciones Aprendidas (i)

Fuente: Mike Licht, NotionsCapital.com

Las organizaciones deben gestionar correctamente el conocimiento que poseen y la redacción de unas buenas lecciones aprendidas de cada proyecto que se ejecuta debería ser valorado al mismo nivel que la ejecución exitosa del mismo. Con todo, posiblemente la recopilación y estudio de las Lecciones Aprendidas sean las actividades a las que menor tiempo se dedican en la vida de un proyecto.

 Hace unos meses tuve que participar en una oferta para la implantación de una Oficina de Gestión de Proyectos (PMO). Se trataba de una oficina para el control de proyectos de despliegue de Red de comunicaciones.

El caso es que tras leer la escueta (pero sospechosamente detallada) RFP se me agolparon cantidad de ideas que plasmar en la oferta. Esta PMO era muy similar en funciones y dimensión a otra en la que estuve involucrado durante 15 meses, y toda esa experiencia había que explotarla de la manera más oportuna. No obstante los plazos para responder a la oferta eran muy ajustados y la oferta tenía que ser muy condensada, resumiendo sólo la información justa y necesaria.

Acudiendo a la máxima de que lo mejor era tirar de la experiencia tal y como se ha vivido, acudí a los análisis postmortem que guardo de todos los proyectos en los que me he visto involucrado. Experiencias anteriores me han demostrado que son útiles y el tiempo invertido en su elaboración es altamente beneficioso por las siguientes razones:

1. Una vez casi finalizado el proyecto, tenemos la foto completa y podemos analizar las consecuencias de nuestras acciones y decisiones.
2. Tenemos tiempo para recapacitar y reflexionar, algo que en la vorágine del proyecto no siempre es posible hacer.
3. al afrontar su elaboración desde un punto de vista constructivo, somos capaces de establecer elementos de éxito y elementos a evitar en el futuro.
4. Nos quedamos con las grandes lecciones y riesgos, que generalmente no suelen estar directamente relacionadas con el alma mater del proyecto

Aunque bien es cierto que una de las aplicaciones y objetivos de las lecciones aprendidas es que la organización aprenda, al final la organización no suele aprender demasiado de estos análisis pues existe una gran dificultad para poder explotar esta información de manera adecuada cuando queremos hacerlo, bien sea por las herramientas que tenemos para acceder a la información (bases de datos generalmente), o por lo difícil que resulta el encontrar algo útil en una capeta compartida en red sin invertir una cantidad de tiempo enorme. Sin embargo, para los involucrados, releer estos documentos suele ser una manera de volver a revivir ciertas situaciones y hacer que nuestra memoria recupere detalles que de otra manera se nos hubieran pasado por alto.

Desde luego que la lectura de las lecciones aprendidas no fue determinante para exponer elementos nuevos ni ninguna idea trascendental en lo que es la gestión y las actividades propias de la Oficina, pero sí sirvió para dar visión del negocio y trasfondo de aquellos elementos en los que hay que hacer foco, identificar aquellas prácticas que no dieron resultado o que no generan un valor específico y que en las lecciones aprendidas estaban recogidas, junto a sus posibles alternativas futuras. Permitió pasar de la teoría a la implantación práctica y redactar la propuesta en un tiempo récord, focalizando y listando los riesgos posibles, remarcando prácticas a llevar a cabo para conseguir ciertos objetivos, e intentar reconducir expectativas desde la fase de ofertación para evitar conflictos futuros con el cliente.

Y lo mejor de todo, ganamos la oferta.