14 noviembre 2007

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.

7 comentarios:

  1. Hola Diego. No deberias ser tan provocador.
    Es una cuestión muy básica pero tal vez a alguno de tus lectores le sirva para conocer las singularidades del mundo de las holguras.
    Ségún la ortodoxia al retrasar la terminación de una actividad crítica se retrasa la terminación del proyecto (espero que hasta aquí estemos de acuerdo).
    Bien, veamos la actividad T1 del sudoku de anónimo: su holgura total es nula, ergo es crítica, pero... si la actividad T1 termina un día más tarde de lo previsto (el 16)... ¡el proyecto sigue durando lo mismo, 114 días!
    ¿Expediente X? Noor, simples anomalías de los vínculos SS.
    Conclusión T1 no es crítica; solo son críticos sus primeros 10 días. Una vez damos cumplimiento al vínculo SS-5 y la actividad T2 empieza podemos "olvidarnos" de los cinco días restantes de T1. A no ser, claro, que alguna actividad sucesora necesite de la terminación de T1 para su comienzo o su terminación, en cuyo caso el error del programador sería no haber incluido este vínculo FS con T1. Riesgos de utilizar vínculos SS cuando la naturaleza del vínculo entre dos actividades es FS. Cuidado, no es oro todo lo que reluce.
    Saludos.

    ResponderEliminar
  2. ¡Ups! Es lo que tiene comentar a altas horas de la madrugada. El vínculo de T1 y T2 no es SS. No obstante la anomalía es la misma.

    Para ilustrar lo de los vínculos SS suponed que T3 no existe en el proyecto. La ruta crítica pasaría por T4. Y ahora fijaros en T2: su holgura es nula y en cambio si se retrasa su terminación durante la ejecución el proyecto no se retrasa. CQD.

    ResponderEliminar
  3. Muy cierto Eduardo. Eliminando t3, el problema está en el backward-pass, pues cuando, en el paso de t4 a t2, calculamos el tiempo de finalización más tardío de t2 a partir del de inicio más tardío de t4, debido a que la relación es de comienzo a comienzo, lo hacemos calculando primero el de inicio más tardío de t2, y luego le sumamos su duración para hallar el de finalización más tardío. En este último paso es donde se produce la debilidad del algoritmo, pues en realidad, por no tener ninguna delimitación de fin, este tiempo debería ser el de la propia finalización del proyecto.

    ResponderEliminar
  4. Ahhhh, como extraño las mascleta y mi paso por Valencia...Bueno lo del SUDOKU salio por casualidad; Un PDM/CPM como el propuesto solo apunta a lo que Diego afirma:" cuando mas simple sea la red...mas fácil sera llevar el control".
    Aunque el tema de las holguras me resulta de una utilidad magistral, se desprenden de situaciones como las del SUDOKU y no simpre es claro como calcularlas cuando no se comprende el forward pass y el backward pass.

    Discutiremos tus resultados en nuestra siguiente reunión de proyectos.
    (de paso, tu traducción de la programación ganada nos viene al pelo :) ya mas de uno se ha convencido de lo útil que resulta

    Gracias Diego,
    del anonimo...un fiel lector del blog

    ResponderEliminar
  5. Me alegra verte por aquí de nuevo. Luego, releyendo la entrada, apercibí que su tono jocoso pudiera ser interpretado sobre tu comentario y no sobre el tema en sí, que era mi intención. Pero veo que tu sentido del humor está en forma. La verdad es que la clave está en los cálculos que se realizan en ambos sentidos de la red. Y es curioso como los paquetes de software no contemplan casos como el que planteó Eduardo. Imagino que el algoritmo original junto con las definiciones de tiempos tempranos y tardíos, cuando se hizo en su momento, sólo tenía en cuenta relaciones del tipo “fin a fin”, donde claramente se cumple la propiedad por la que la diferencia entre tiempos tardíos y tempranos, tanto de inicio como de finalización, es la misma e igual a la holgura total. La extensión que se hizo posteriormente en el método de diagramación por precedencias (PDM), y la entrada de nuevos tipos de interrelaciones, muestra que hay que revisar y modificar el algoritmo (la propiedad anterior deja de cumplirse, por ejemplo). Lo curiosos es que, al parecer, los desarrolladores de los paquetes de software parecen utilizar un algoritmo anticuado. Por eso prefiero siempre desconfiar de los juicios categóricos del tipo “se demuestra que…” o “esto es así porque lo dice…”. No hay nada como mirar que hay detrás de las cosas.

    ResponderEliminar
  6. Hola Diego. En un comentario anterior dijiste "En este último paso es donde se produce la debilidad del algoritmo, pues en realidad, por no tener ninguna delimitación de fin, este tiempo debería ser el de la propia finalización del proyecto."

    No estoy de acuerdo contigo en lo de la debilidad del algoritmo. Mas bien se trata de debilidad del programador. Si el final de la actividad T2 (la que envía el vínculo SS) no es requisito para que pueda empezar ninguna otra actividad significa que en esa ruta T2 es actividad final (un vagón de cola si usamos el simil de un tren). Por tanto, si el programador del proyecto le reconoce su condición de actividad final vinculandola con el hito final del proyecto conseguirá que cuando el proyecto esté en progreso y la actividad T2 haya comenzado, ésta se comporte como le corresponde y tomará como Tiempo Mas Tarde de Terminar TMTT el último día del proyecto. Antes no ocurrirá eso por aquello de que una actividad se realiza sin solución de continuidad.

    O tal vez sea al revés porque a estas horas ya no sé lo que me escribo... zzz

    Piénsalo, por favor, y lo discutimos cuando luzca un poco más de Sol.

    ResponderEliminar
  7. Sí Eduardo. Estoy de acuerdo. Por debilidad del algoritmo no quería referirme al proceso lógico en sí sino a su diseño (humano). Y sí, uniendo t2 a un hito final (t11 por ejemplo) conseguimos que su tiempo de finalización tardío coincida con el del finalización del proyecto como debe ser.

    A pesar de la oscuridad de la madrugada has estado lúcido. Yo he necesitado un poco del calor tímido del despunte del sol para desempolvar el ejemplo :-)

    ResponderEliminar

Nota: solo los miembros de este blog pueden publicar comentarios.