La planificación temporal es una etapa clave en la gestión de proyectos, así como en la cuantificación de los riesgos. Como paso previo ya se habló en el primer capítulo de la necesidad de definir el alcance, así como las tareas, organizadas en las EDT, instrumento que facilitará la estimación de los recursos y el tiempo. Una vez dispongamos de esta información, será posible definir la planificación temporal tentativa, ya que esta variará con total seguridad según transcurra el proyecto.
En departamentos u organizaciones con poca cultura en la gestión de proyectos, la figura del Project Manager se siente razonablemente cómodo realizando planificaciones poco rigurosas pero, en un gran número de ocasiones, estas naufragarán una vez se botan en el intemperante mar de del día a día. Las principales razones de esos fracasos se pueden resumir en pocos puntos:
La planificación de proyectos no es una disciplina fácil. El Project Manager debe tener en cuenta un sinfín de tareas, recursos, relaciones lógicas y restricciones en cuenta de una manera rigurosa, y no siempre se tienen las herramientas necesarias.
La información para conformar un plan de proyecto viene de diferentes fuentes, habitualmente de equipos o subcontratas que no tienen en cuenta o no están familiarizados con la labor del Project Manager. El Project Manager requiere ciertas habilidades innatas, tales como ser un experto comunicador, e incluso un gran persuasor, necesaria para lidiar con todos los implicados que pueden no tener el plan de proyecto en cuestión como una prioridad propia.
Desde el cliente o jerarquías superiores, se suele insistir en objetivos difícilmente alcanzables. Esto provoca que el Project Manager diseñe planes que no se ajustan a los recursos disponibles, aunque “el papel lo soporta todo”…
A la hora de confeccionar un plan de proyecto se requiere exigencia y precisión. El profundizar hasta los niveles más bajos de proyecto es la única manera de garantizar que el plan propuesto será realista, creíble y realizable.
Es un gran reto elaborar un plan con el nivel de detalle necesario, y mantenerlo actualizado correctamente, a pesar de la presión a la que se ven sometidos los Project Managers. Obtener todo la información detalla y digerirla para posteriormente crear el plan de proyecto no está al alcance de cualquier miembro de una organización. En ocasiones es de gran utilidad que los Project Manager tengan bagaje en los niveles más elementales del proyecto, para poder realizar su cometido de manera satisfactoria. Un
74
ejemplo podría ser el desarrollo de software, en los que un Project Manager que ha pasado por el desarrollo y posteriormente el análisis, podrá ofrecer cualitativa y cuantitativamente mejores iniciativas desde su experiencia.
Una estrecha relación con los implicados se torna como algo fundamental, ya que las personas de los grupos implicados disponen de valiosa información para planificar y monitorizar el transcurso del proyecto. Esta información va desde la identificación de las tareas principales, como la relación entre ellas, a los recursos requeridos o restricciones establecidas. A menudo esta relación no es fácil de gestionar, ya que los implicados tienden a centrase en sus cometidos, y creen que el invertir el tiempo en reportar al Project Manager es algo secundario. La correcta gestión de un proyecto requiere que todos los implicados estén al tanto del desarrollo, ya que el propio transcurso puede afectarles directamente.
El Project Manager tienen como unos de los principales problemas los intereses derivados de la consecución del proyecto, como pudieran ser comerciales, estratégicos o regulatorios. Este tipo de intereses lleva a las directivas, clientes u otros implicados en el proyecto a proponer e insistir en fechas e hitos fuera de un alcance razonable. En estos casos la labor del Project Manager se ve muy degradada, ya que la máxima con la que se acostumbra a trabajar es “esto es todo el tiempo del que disponemos”. En estas situaciones se tiende a sobre-solapar actividades, no respetando las relaciones lógicas o restricciones establecidas. Este problema también puede conducir a la creación de estrategias de contingencia por encima de los recursos disponibles, creando de nuevo un frente de confrontación cuando las otras partes (departamentos, clientes, directiva,…) demandan la puesta en marcha de las mismas.
Los planes de proyecto, así como sus lógicas a simular, requieren de su actualización mediante la periódica revisión de los diferentes parámetros que lo conforman, según se vayan sucediendo las tareas y demás fenómenos del proyecto. La comparación del plan inicial con el plan final una vez se ha completado el proyecto puede ayudar a mejorar los procesos internos, depurar las responsabilidades fijadas por la organización, o valorar cláusulas de penalización, entre otros.
5.1.1 La lógica de un plan de proyecto
La lógica de un proyecto conforma un modelo dinámico, el cual se nutre de multitud de valores aleatorios según las distribuciones de probabilidad establecidas en el modelo de proyecto. Este reúne todas las tareas requeridas, sus relaciones lógicas, condiciones y restricciones existentes. El plan no se puede basar meramente en una serie de fechas en las que se especifique el momento en que se realizarán las acciones, sino que se trata del sistema dinámico de información que producirá esas fechas, así como otra serie de resultados de interés que iremos estudiando.
75 Todos los implicados en un proyecto, desde el Project Manager, pasando por todo el equipo de trabajo, hasta el cliente (o beneficiario de la consecución del proyecto), estarán de acuerdo en la necesidad de un plan de proyecto elaborado. Estos planes de proyecto, plasmados en una lógica que los simule, permiten predecir las fechas de finalización de hitos importantes a lo largo del plan. También, el potencial de una simulación veraz permitirá gestionar competencias diarias, pudiendo dimensionar los recursos disponibles de manera eficiente y registrar el estatus de los diferentes elementos que conforman el proyecto. El nivel de detalle que se puede llegar a obtener con una buena simulación permite a los Project Managers abordar maneras alternativas para llegar a tiempo, por ejemplo, a un hito que previsiblemente pueda retrasarse o en organizar un recursos escaso eficientemente.
Las lógicas de los planes de proyecto que se provee al simulador están basadas en las dependencias establecidas, expuestas en el Apéndice C. A lo largo del documento expondremos las lógicas de los ejemplos mediante un diagrama de Gantt realizado con el software Microsoft Project TM como el ejemplo siguiente:
Figura 27. Ejemplo de Diagrama de Gantt donde se muestra la planificación temporal
En estos diagramas mostraremos la lógica de los planes, es decir, las tareas que los conforman, sus dependencias lógicas, restricciones entre ellas e hitos establecidos. También se incluye los parámetros de las distribuciones de duración de las tareas, e información determinísticas, como cada una de las fechas de la planificación o el coste de cada una de las tareas.
La creación de una lógica para la planificación temporal ha de ser una actividad bien conformada para que sea capaz predecir correctamente las fechas de finalización o el camino crítico, sin importar la alteración de la duración, relaciones o eventos entre tareas. Para ello, es fundamental seguir las reglas de la correcta definición de una lógica, y no caer en los frecuentes abusos en su construcción, que no permitirán aprovechar todo el potencial de una simulación Monte Carlo. No será posible realizar una simulación veraz de un plan de proyecto si este contiene errores en su lógica, ya que impedirá tener un modelo verdaderamente robusto. De manera resumida, los abusos más comunes son:
No preservar una completa y robusta relación entre todas las tareas del proyecto. La existencia de actividades mal relacionadas (o no relacionadas en absoluto) con sus predecesores o antecesores es de absoluta necesidad para preservar el dinamismo requerido, sino se sesgarán los resultados de las simulaciones.
76
Usar restricciones temporales inflexibles del tipo No finalizar después del (NFDD), para ajustar a fechas inverosímiles derivadas de exigencias externas, o cláusulas de contratos. Estas condiciones provocarán importantes problemas cuando las duraciones de las tareas no se mantengan según lo establecido en el plan inicial, creando la necesidad de incluir nuevas restricciones que alejarán aún más el plan de la realidad.
Usar en exceso retrasos para modelar ciertos fenómenos. Es legítimo su uso para simular un tiempo de espera, como pudiera ser el fraguado del hormigón en una obra, pero es erróneo usarlo para tratar de encuadrar elementos del plan.
No tener en cuenta los recursos necesario para la consecución de las actividades. Con el objeto de comprimir el máximo la planificación temporal, es común pasar por alto los recursos necesarios para desarrollar cada actividad, por lo que nos podemos encontrar con un plan con excelentes tiempos, pero irrealizable.
Aunque la construcción correcta de la lógica podría parecer algo básico, tanto por su importancia en la obtención de resultados como por los habituales abusos observados en la experiencia profesional, se ha creído oportuno profundizar en este tema en el Apéndice C.
Una vez tenemos sentadas las bases de lo que se requiere para tener disponible la lógica de la planificación temporal, pasaremos a estudiar cómo afecta el riesgo de manera cuantitativa. En este proceso, iremos ampliando la visión sobre el riesgo, y en cómo es posible incluir funcionalidades al simulador para ayudar al Project Manager en su gestión.