Jose María González López
Project manager y Fundador de Habilis Software http://www.habilissoftware.com/
Continúa la serie de artículos que forman el decálogo para hundir proyectos no sin antes referenciar la 6ª parte del mismo:
Torpedo 8. El cronograma
"Los proyectos con cronogramas y presupuestos realistas nunca se aprueban."
Anónimo
... Y esto es algo que es toda una realidad. No es la primera vez que se desencadena todo un despliegue de ingeniería y logística para la estimación y elaboración de un buen cronograma, realista, equilibrado, lógico y luego resulta que no se aprueba por razones que nada tienen que ver con la ingeniería o con la eficacia (normalmente, razones económicas). Paradójicamente, cuando un proyecto recae en retrasos o sobre costes, casi con toda seguridad, es un problema que se arrastra desde su planificación en cronograma (teniendo en cuenta, claro, que las bases para la realización de un cronograma son parte del mismo), siendo una de las razones más habituales la falta de visión realista en la estimación y en la construcción.
Un buen cronograma incluye todos los procesos requeridos para asegurar la terminación de un proyecto a tiempo. Es por ello que, antes de poder crearlo, tenemos que tener a nuestra disposición una descripción completa de todas las tareas a realizar y del esfuerzo necesario para cada una de ellas (que mejor que una EDT para esto). En este punto hay que recordar los esfuerzos que habremos realizado durante la elaboración de la EDT del proyecto (Ver 3ª parte del decálogo), porque dichos esfuerzos empezarán a dar sus primeros frutos ahora, al construir el cronograma.
¿Qué creéis que nos va a ocurrir si empleamos la información que, hábilmente, hemos ido tergiversando durante nuestra labor de sabotaje en el proyecto?... Pues muy fácil, que el cronograma que resultará será tan inútil como los esfuerzos por lograr que éste deje de serlo. Hay que tener siempre en mente que el cronograma es una abstracción de las estimaciones específicas de cada una de las tareas que se han identificado. Obviamente, si logramos una identificación de tareas ambigua y una estimación pobre de las mismas, tendremos mucho camino recorrido en crear el llamado "toilet-Schedule" (Premio para quien averigüe su verdadera utilidad).
Para comenzar ya partimos de la EDT de la 3ª parte del decálogo, esto es, una definición de tareas incompleta, poco real, superficial quizás y pobremente definida. En este punto nos deberíamos de haber esforzado en que las estimaciones no sean reales y que las tareas a realizar no sean todo lo completas que deberían. Este documento es nuestra EBDT (Estructura BOMBA de Desglose de Tareas). Si quisiéramos ser mínimamente eficaces, ya podríamos empezar a elaborar diagramas de red estructurando así las tareas en un orden lógico pero, como queremos ser poco eficaces, pasaremos directamente a trabajar con Project o con la herramienta que tengamos para definir el diagrama de Gantt. Digo esto porque los diagramas de red ofrecen una visión de dependencia estrictamente funcional que no se ve influida por interferencias relativas al tiempo de ejecución o a los recursos disponibles y ofrecen una visión global del flujo operativo en el proyecto, algo que viene muy bien para comprobar que vamos a hacer lo correcto y en la secuencia correcta. Obviamente, si prescindimos de esta herramienta dificultaremos un poco más la visión global del proyecto y la detección de posibles cuellos de botella y rutas críticas en las que centrar los recursos.
Dado que las tareas son realizadas por el capital humano de nuestro proyecto, también es necesario asegurar la IN-DISPONIBILIDAD de cada uno de los integrantes del proyecto teniendo en cuenta el calendario de cada uno de ellos. Si, has leído bien: IN-DISPONIBILIDAD. Si nuestro proyecto utiliza capital humano ya existente y que, probablemente, ya tiene su propio calendario, es importantísimo conocerlo y asegurar así que, cuando tenga que participar en nuestro proyecto, NO tenga tiempo para ello.... De esta brillante manera lograrás gestionar la in-disponibilidad de este recurso en tu proyecto y dilapidarlo un poco más. Me refiero a situaciones como:
(Conversación telefónica)
PM: Bueno, bueno, bueno, Manuel, por fin hablamos en persona... A ver, te comento: tal y como te dije por email hace tres meses, en dos días comienzas a prestar servicio en el proyecto XXX. Estamos muy ilusionados con tu incorporación al proyecto porque vas a jugar un papel importantísimo en la...
Manuel: Espera, espera... ¿En dos días dices?... Pero si ya estoy asignado a un proyecto y además fuera del país, ¿Has hablado con mi director?
PM: ...mmm... si... Iba en copia...
Éste tipo de gestión no es conveniente ni eficaz realizarla con recursos clave en nuestro proyecto ya que sería demasiado obvia nuestra ineptitud. Es mejor practicarla con recursos (y no necesariamente humanos) que pueden ser fácilmente obviados pero que incorporan su migaja de retraso al proyecto (calendarios de accesibilidad a determinadas infraestructuras, instaladores cualificados, aprovisionamiento de determinados recursos de arquitectura, recursos de diseño, etc...). En este punto te ayudará una buena (o mala, según se quiera entender) identificación de partes interesadas (ver Parte 1ª del decálogo).
Recuerda siempre que las cosas pequeñas, los detalles no incluidos, aquello que se puede ignorar con facilidad son lastres magníficos para un proyecto. Con esta filosofía en mente, obvia incluir, por ejemplo, los espacios de tiempo para las reuniones periódicas de seguimiento, o los días necesarios para las implementaciones en los distintos entornos, tiempos para pruebas y test, tiempos destinados a tareas formativas, tiempos relativos a procesos de auditorías (¿olvidaste identificar a los responsables de IT que disponen de las normas de puesta en producción?...UPS!)...
Igualmente, todos los esfuerzos que hemos realizado en la gestión de riesgos comenzarán a dar fruto ahora. ¿Pasa algo si no incluyo las posibles contingencias de tiempo a mi cronograma?...No, no pasa nada. Si hay problemas ya meteremos más gente a resolverlos... (¿Os suena? También hay una frase acuñada para estas 'soluciones' y es: nueve mujeres embarazadas no hacen un bebe en un solo mes).
Quiero tranquilizarte con respeto a la aplicación de determinadas técnicas y herramientas como la cadena crítica o la compresión de cronograma. En particular, la primera de ellas, goza de gran fama por su eficacia en el cumplimiento del cronograma. Tranquilo, no te pongas nervioso si alguien te los menciona. Estos inventos chinos no podrán resolver la ineficacia de nuestro cronograma mientras la base de la que parte permanezca inalterable y corrupta.
Un último apunte antes de cerrar. Ten en cuenta que, a medida que el proyecto avance y comience a hundirse, es MUY posible que tu nombre salga a relucir como culpable de la situación. Hay que intentar que esto suceda lo más tarde posible. Si bien es casi inevitable que todo patrón se hunda con su barco, es nuestro deber y obligación como saboteadores profesionales que no nos pillen hasta el final.
Nota: El autor del presente artículo no se responsabiliza del mal uso de la información aquí recogida ni del hecho científico probado de que, en determinados cerebros, la psicología inversa no funciona...