06 noviembre 2007

Festival de holguras

El otro día, hablando con alguien que está preparando el examen para obtener la certificación PMP del PMI -¿festival de acrónimos también?-, salió el tema de las holguras. Que si hay que distinguir entre la holgura libre y la total, que si las holguras negativas, etc. Escuchándolo me acordaba de un amigo que tiene un loro que podría recitar dos capítulos del PMBOK sin respirar. La dirección de proyectos es, ante todo, una disciplina estrictamente fenomenológica, así que, pasando de las definiciones aisladas, aunque tan necesarias para la certificación, vayamos a las trincheras y veamos qué es en realidad eso de tanta holgura –en realidad si se comprende un aspecto físico no hay que memorizar nada. Consideremos el ejemplo de la figura 1.


La columna “Margen de demora total” corresponde a la holgura total (o la holgura de toda la vida, para entendernos). A su vez, esta holgura está representada en el diagrama de Gantt de la derecha mediante una barra más estrecha de color gris que se prolonga a partir de la fecha de finalización de las tareas –sólo se manifiesta en las tareas no críticas porque sólo en éstas es diferente de cero y positiva –hasta aquí, nada nuevo que brille bajo el sol. La columna “Demora permisible” corresponde a la holgura libre. ¿Y qué es lo que vemos? Pues que en los caminos no críticos es nula en todas sus tareas excepto en la última, caso en el que, además, coincide con la holgura total. ¿Qué ocurre? Pues que, mientras que la holgura total, la de toda la vida, se define como el intervalo de tiempo en que puede demorarse una tarea sin demorar el plazo del proyecto, a alguien se le ocurrió complicar la vida de los estudiantes de la disciplina, y de los aspirantes a PMP, definiendo la holgura libre como el intervalo de tiempo en que puede demorarse una tarea sin demorar el inicio de alguna de sus sucesoras. De algo hay que hablar en el café.

En realidad, y bromas aparte, el ejemplo de la figura 1 es un caso muy particular, aunque bastante común, en el que todas las tareas se planifican para que comiencen lo más temprano que les sea posible. Imaginemos que, por la razón que sea, la tarea E se programa con una limitación de comienzo de no comenzar antes del día 14. El cronograma queda como el de la figura 2.


Tanto su holgura libre como total se han reducido en un día. Además, su predecesora –la tarea D- ha pasado de no tener holgura libre a tener un día, que es el tiempo que debe transcurrir para que pueda demorar su sucesora, como reza la definición. Sin embargo, su holgura total sigue siendo de cuatro días, que es el margen que tiene para no demorar el plazo del proyecto. Hasta aquí, una ilustración trivial del concepto. Ahora veamos algunas curiosidades con las que nos podemos encontrar en la vida real cuando jugamos a los cronogramas. ¿A nadie le ha ocurrido que, aparentemente, el cronograma de su proyecto se ha convertido en el río Guadiana? ¿Aparece y desaparece? Si utilizáis diferentes calendarios para tareas diferentes, y estos calendarios tienen diferentes periodos laborables, ojo avizor; podríais guadianizar vuestro cronograma. Veámoslo con el mismo ejemplo trivial. En las dos figuras anteriores podemos ver que se ha utilizado un mismo calendario para todas las tareas –el denominado “Estándar” en la columna “Calendario de tareas”. Este calendario tiene los sábados y domingos definidos como no laborables, por lo que dichos días no computan a la hora de calcular las fechas de finalización e inicio de las tareas a partir de sus duraciones. Supongamos que cambiamos de opinión y decidimos que en la tarea B se puede trabajar sábados y domingos. Para reflejar esto, asignamos el calendario “7 Días” –que tiene los sábados y domingos definidos como laborables. El resultado se muestra en la figura 3.


Vemos como la fecha de finalización de la tarea B se ha reducido en dos días al permitirle trabajar durante el sábado y el domingo. Además, por ser B una tarea crítica, la duración del proyecto se ha reducido también en dos días, así como todas las holguras respecto a la figura 1. Hasta aquí nada extraño. Pero, emocionados por los resultados, le damos ritmo al tambor de la galera y decidimos que en la tarea C también se puede trabajar sábados y domingos. Los resultados quedan reflejados en la figura 4.


Y aquí es donde viene la guadianización del camino crítico que, aparentemente, no aflora hasta la tarea F – las tareas A, B y C, que antes eran críticas, ahora, según MS-Project, no lo son y pasan a tener holgura total. ¿Por qué? La clave la encontramos en las tareas C y F. La tarea C que, con el calendario “Estándar” finalizaba un lunes, como se muestra en la figura 3, pasa a acabar un sábado al aplicarle el calendario “7 Días”, como se muestra en la figura 4. Por el contrario, la tarea F, que comenzaba un martes, no puede comenzar un domingo, inmediatamente después de finalizar su predecesora C, porque su calendario lo impide. En consecuencia, comienza un lunes –que es lo antes posible que puede- dejando una holgura total de un día a la tarea C y todas las críticas precedentes. Asimismo, la duración del proyecto sólo se ha podido reducir en un día. Por lo que respecta a las holguras libres –columna “Demora permisible”-, las de las tareas A y B son cero como debe ser según la definición de marras, aunque algo extraño sucede con la de la tarea C. Según MS-Project su holgura libre es cero, pero si atendemos a la definición debería ser de un día, que es el margen que tiene para no demorar su predecesora, que es F.

Hay que ir con cuidado con los paquetes de software porque en algunos criterios sutiles como éste, pueden diferir entre ellos y entre las definiciones de la ortodoxia imperante. En la figura 5 muestro el mismo ejemplo realizado con el paquete Open Plan de Deltek, quienes sí han seguido la ortodoxia imperante y calculan la holgura libre de la tarea C para dar el valor de un día.


Pero, además, observamos otra diferencia significativa. Las tareas A, B, C que se guadianizaban en el ejemplo realizado con MS-Project, siguen apareciendo en la figura 5 coloreadas con el color rojo que suele caracterizar las tareas críticas –aunque también vemos de forma manifiesta su holgura. ¡Una tarea crítica con holgura! ¡Anatema! Bueno, todo depende del nivel de integrismo con que se mire… Personalmente me gusta mucho este criterio porque no me hacer perder el rastro de tareas que son potencialmente críticas pero no son debido a la aparición de holguras por diferencias entre calendarios. En algunos entornos se suele llamar a este tipo de tareas críticas de control –aunque no es importante para certificarse.

Esta situación es muy normal que se produzca cuando se trabaja con diferentes calendarios –hecho que tampoco es extraño en algunos sectores como el industrial, basta con que en una fase del proyecto se trabaje con turnos diferentes a la de otra fase, lo que puede suponer más o menos horas de trabajo a realizar al día en las tareas, o que se trabaje o no sábados, etc. Y lo interesante es que la situación puede ir cambiando a medida que se va reprogramando el cronograma, con lo que donde afloraba el camino crítico ya no aflora y viceversa. Por ejemplo, basta con que la tarea C del ejemplo de la figura 5 finalice dos días antes de lo previsto –un jueves- para que su sucesora F ya pueda comenzar inmediatamente después de ella, volviendo a desparecer su holgura total y restableciéndose el camino crítico.

No olvidemos tampoco que, además de que hay que saber utilizarlos con cabeza, hay qué conocer qué conceptos de gestión de proyectos hay detrás de los paquetes de software. Desafortunadamente, en esta era de la TI, no es muy infrecuente que la primera toma de contacto que tienen muchos profesionales que se introducen en la Dirección de Proyectos es precisamente a través de estos paquetes. Y eso puede originar malas interpretaciones, malos hábitos y llegar incluso a ser peligroso. Los paquetes de software, como los medicamentos, deberían:
1) ser prescritos por una cabeza bien amueblada,
2) ser utilizados con precaución, y
3) no dejarse al alcance de los niños.

Y para finalizar, damas y caballeros, venida de los confines más allá del cero –redoble de tambor- que mejor que despedirnos con ¡la holgura negativa! Si creíais que lo peor que puede suceder en un proyecto es ir a piñón fijo, sin espacio para la respiración, sois unos optimistas. Aún se puede ir a rebufo y vivir de prestado como el que vive con una hipoteca a cuestas. Bueno, en realidad es una cuestión de relatividad. Consideremos otra vez el ejemplo de la figura 1. Los paquetes de software permiten trabajar con diferentes criterios a la hora de fijar las fechas de inicio y finalización de las tareas de un cronograma. Como hemos dicho anteriormente, lo más habitual es tratarlas de forma flexible para que sea el propio algoritmo de creación de una red de tareas quien las calcule en base a sus interrelaciones y con el criterio, por ejemplo, de que comiencen lo antes posible. Aunque también ofrecen otras posibilidades para delimitar esas fechas, como por ejemplo la de asignare una fecha predeterminada y fija. Si hacemos esto con el hito H2, y la duración de la tarea pasa de dos días a tres, ocurre lo que se muestra en la figura 6.


El hito H2 que marca el fin del proyecto no se ha movido al quedar anclado a su fecha fija. Además, todas las tareas críticas, que aunque sí se han desplazado, han pasado a tener una holgura de menos un día, que no es más que un recordatorio de hay que recuperar un día en alguna de ellas para recobrar el plazo original del proyecto. La holgura negativa es como un préstamo de tiempo que nos ha hecho el proyecto. Préstamo que hay que devolver si queremos finalizar el proyecto según el plazo previsto.

Acabamos de verdad con dos noticias. Una buena y una mala. La buena es que el préstamo se devuelve sin intereses. La mala es que si especula con la burbuja holguraria, le puede estallar en la cara.