A Sudoku for Project Managers

Gran comentario el realizado por Don Anónimo en el anuncio anterior. Y una buena excusa para profundizar en el submundo que subyace al cálculo del camino crítico y las holguras de un proyecto. Si he pillado bien la tabla que muestra, el cronograma al que se refiere es el de la figura 0 (pinchar sobre las figuras para ampliarlas).


En principio, no existe ninguna razón por la que no debamos fiarnos de los resultados que ofrecen los paquetes de software para el cálculo del camino crítico y las holguras del proyecto. Ni tampoco existe ninguna razón por la que tengamos que hacerlo a mano, ya que nuestra labor no es divertirnos con ello, sino llevar un proyecto. Ahora bien, todo profesional de los proyectos debería haber hecho, al menos, un cálculo a mano en su vida, aunque sólo sea para aprehender los conceptos y mecanismos que hay por detrás, saber sus condiciones de uso y aplicación, y juzgar cuándo y cómo deber ser utilizado. Así que el problema lanzado por nuestro comentarista anónimo es una buena excusa para hacer uno aquí.

Para ello vamos a construir un diagrama de red utilizando el método de diagramación por precedencias (PDM de sus siglas en inglés), en el que los nodos de la red corresponderán a las tareas y sus uniones las interrelaciones lógicas entre ellas. Los nodos de tarea vendrán representados por la caja mostrada en la imagen de la izquierda. Los conceptos mostrados son los estándares del método del camino crítico. Como recordatorio, tengamos presente que la diferencia entre los tiempos de finalización y de inicio, tanto tempranos como tardíos, es igual a la duración de la tarea; y la diferencia entre los tiempos tardíos y tempranos, tanto de inicio como de finalización, es igual a la holgura total. Así pues, el diagrama de red del proyecto correspondiente al cronograma de la figura 0, es el que se muestra en la figura 1.


El siguiente paso consiste en hallar los tiempos de inicio y finalización tempranos, lo que se conoce como el forward-pass. Para ello comenzamos con la primera actividad de la red, a la que asignamos la bandera de salida, que consiste en adjudicarle el instante cero como tiempo de inicio más temprano. A partir de ahí se calcula su tiempo de finalización más temprano como el de inicio más temprano mas la duración de la tarea. Cuando pasamos de una tarea a su sucesora, el tiempo de inicio más temprano de esta última coincidirá con el de finalización más temprano de su predecesora, sumando o restando el decalaje que lleve la relación de precedencia. Veamos algunos ejemplos:

• La relación lógica entre la t1 y t2 indica que t2 no puede comenzar hasta 5 días antes de que haya finalizado t1. Por tanto, si el tiempo de finalización más temprano de t1 es 15 (ver figura 2), el de inicio más temprano de t2 será 10.


• La relación lógica entre t2 y t4 indica que t4 no puede comenzar antes de que hayan transcurrido 10 días depuse de haber comenzado t2. Por tanto, si el tiempo de inicio más temprano de t2 es 10, el de inicio más temprano de t4 será 20.

Esto funciona muy bien cuando una tarea sólo tiene una predecesora. Pero, ¿qué ocurre cuando tiene más de una? Obviamente, no podrá comenzar hasta que haya finalizado la última de todas. En la figura 2 vemos el caso en las tareas t6 y t10. En ambos casos, su tiempo de inicio más temprano es el mayor valor de los tiempos de finalización más tempranos correspondientes a sus respectivas predecesoras. El resultado de este paso, el forward-pass –es decir, recorrer la red de izquierda a derecha o hacia delante-, se muestra en la figura 2.


Una vez hallados los tiempos de inicio y finalización más tempranos, estamos en disposición de hallar los tiempos de inicio y finalización más tardíos, lo que se conoce como el backward-pass. Es decir, ahora recorremos la red en sentido inverso, hacia atrás. Y para ello, comenzamos con la última actividad de la red, la que tiene la bandera de meta. Obviamente, el tiempo de finalización más tardío del proyecto debe coincidir con el de inicio más tardío, el proyecto debe tener un plazo único. Por lo tanto, el tiempo de finalización más tardío de t10 será 144. Y de ahí, su tiempo de inicio más tardío será igual al de finalización más tardío menos su duración, igual a 114. Cuando pasamos a sus predecesoras, éstas deberán finalizar como muy tarde cuando su sucesora comience como muy tarde. Es decir, el tiempo de finalización más tardío de t7, t8 y t9 será 114. Nuevamente, como en un caso parecido en el paso anterior, esto funciona bien cuando una tarea sólo tiene una sucesora. Cuando tiene más de una sucesora, como el caso de la tarea t6, el cálculo es algo más, sólo algo, complejo. El resultado para t6 se muestra en la figura 3.


Vemos que t6 tiene como sucesoras a t7, t8 y t9, cuyos tiempos de inicio más tardíos son 89, 99 y 96, respectivamente. El tiempo de finalización más tardío de t6 se ha calculado en 94. ¿Cómo sale este número? Bueno, antes que nada es importante remarcar que, si las relaciones lógicas hubieran sido del tipo más común de fin a comienzo sin decalaje, el resultado hubiera sido el menor de todos –es decir, 89- ya que como muy tarde debe finalizar para cuando, como muy tarde, vaya a comenzar la que antes vaya a comenzar de todas sus sucesoras –esto parece un trabalenguas, pero es lo que hay, mil palabras valen menos que una imagen, y en algunos casos incluso menos que la tinta que se emplea en imprimirlas, pobrecito Wittgenstein. Pero en el caso que nos ocupa, las relaciones lógicas son algo más, un poquito más que algo, complejas. Lo que quiero decir es que el cálculo no es directo como en el caso en que hubieran sido del tipo fin a comienzo sin decalaje. Veamos los cálculos:

• Relación t7-t6: es una del tipo comienzo a comienzo con un decalaje de 20 días. Eso quiere decir que t6 debe comenzar como muy tarde 20 días antes del comienzo tardío de t7, esto es en el día 76. Como su duración es de 38 días, su tiempo de finalización más tardío es de 114.


• Relación t8-t6: es una del tipo fin a comienzo con un decalaje de 5 días. Eso quiere decir que t6 debe finalizar como muy tarde 5 días antes del comienzo tardío de t8, esto es el día 94.


• Relación t9-t6: es una del tipo fin a comienzo con un decalaje de -5 días. Eso quiere decir que t6 debe finalizar como muy tarde 5 días después del comienzo tardío de t9, esto es el día 94.

Así pues, tenemos que los posibles tiempos de finalización más tardíos de t6 son 114, 94 y 94, respectivamente. De todos ellos el que más limita es el de 94. El resultado se muestra en la figura 3. Un cálculo similar se realiza en el caso de t2, que tiene como sucesoras t3 y t4. El resultado se muestra en la figura 4.


Aquí tenemos:

• Relación t3-t2: es una del tipo fin a comienzo sin decalaje. Eso quiere decir que t2 debe finalizar como muy tarde en el comienzo tardío de t3, esto es el día 30.


• Relación t4-t2: es una del tipo comienzo a comienzo con un decalaje de 10 días. Eso quiere decir que t2 debe comenzar como muy tarde 10 días antes del comienzo tardío de t4, esto es el día 13. Por tanto su tiempo de finalización más tardío será 33.

Y los posibles tiempos de finalización más tardía de t2 son 30 y 33, respectivamente. Nuevamente nos quedamos con el menor: 30. El resultado, ya completo, de este paso, el backward-pass, –es decir, recorrer la red de derecha a izquierda o hacia atrás-, se muestra en la figura 5.


Una comprobación que podemos hacer de que hay un error, es que el tiempo de inicio más tardío de la primera actividad no coincida con el de inicio más temprano, que deben ser igual a cero. Que coincidan no asegura que no haya algún error, aunque si no coinciden es un indicio claro de que algo está mal.

Ahora, tan sólo nos resta calcular las holguras totales. Recordemos que la holgura total viene dada por la diferencia entre los tiempos tardíos y tempranos, tanto de inicio como de finalización. Así pues, cada tiempo en color rojo de la caja-nodo de tarea menos su respectivo tiempo en color verde, y vecino superior, nos debe dar la holgura -otra forma de testar posibles errores es que ambas restas no coincidan. El resultado se muestra en la figura 6.


Y aquí acaba nuestro Sudoku. Toda esta mascletà fallera que se ha disparado hasta aquí es lo que los paquetes de software hacen en un visto y no visto, tanto para diez tareas como para diez mil. Si a nuestro comentarista anónimo se le estuviera pasando por la cabeza lanzar un Sudoku de estos con diez mil tareas, ni tan siquiera dos órdenes de magnitud menos, con la carne de gallina y los pelos de punta que se me ponen, le rogaría que no lo hiciera, no me gustaría cerrar el blog antes de hora ;-)

Ahora, para finalizar, me gustaría extraer una moraleja de todo esto. Huelga decir que, aunque hacer un cálculo de estos a mano es algo que debería hacerse una vez en la vida, nadie se pone a hacerlo cuando se arrastra por la trinchera bajo la lluvia de cascotes del proyecto. Para eso está el software. Además, a pesar de la multitud de posibilidades que ofrecen los tipos de relaciones lógicas y los decalajes, y que el software lo soporte todo, no hay que complicarse la vida. Cuanto más simple sea la red de actividades, mejor, más intuitiva será y más fácil realizar el seguimiento del proyecto. Cualquier aspecto técnico de estos puede llegar a distraer la atención del objetivo último de un director de proyecto, que es el de alcanzar los objetivos del proyecto que se trae entre manos. Así que ojo con ello. Por otro lado, hay que tener en cuenta la naturaleza determinista del método del camino crítico debido a la unicidad de las estimaciones. Un camino crítico es crítico hasta que deja de ser crítico, y las holguras pueden bailar al ritmo de una tarantella. Los escépticos pueden encontrar más opiniones desmitificadoras aquí, y en sus referencias. Otra cosa es lo que el jefe de proyecto haga en su tiempo libre. Si se ha cansado ya de los Sudokus, las sopas de letras y los crucigramas, puede pasar el rato resolviendo problemas como el que hemos tratado en este anuncio. De hecho ahí va una idea para emprendedores, el FLOATFINDER, que consiste en un puzzle como el de la figura 1 que hay que resolver hasta llegar a la solución de la figura 6.

Post Scriptum al Festival de Holguras y Happy End

Según el comentario de Eduardo al anuncio anterior “Festival de holguras”, si no he entendido mal, se puede hacer que MS-Project muestre la holgura libre “correcta” –recordemos la diferencia que había entre las figuras 4 y 5- mediante un pequeño truco: sustituir el calendario asignado al proyecto, que en el ejemplo 4, según ha intuido Eduardo, era el “Estándar”, por el “7 Días”. El resultado de hacer esa operación se muestra en la figura 7.


Donde ahora sí se observa que la tarea C tiene una holgura libre de un día –ver columna “Demora permisible”- según rezaría su definición.

Bueno, pues parece que el dramático idilio de la tarea C con MS-Project tiene un final feliz, después de todo :-). Gracias Eduardo por el apunte.

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.