ANÁLISIS COMPARATIVO DE ENFOQUES PARA LA DETERMINACIÓN DE LA CRITICIDAD RELATIVA DE LAS TAREAS DE UN PROYECTO

Francisco A. RIVERAp, Alfonso DURÁN

Escuela Politécnica Superior. Universidad Carlos III de Madrid

 

 

RESUMEN

La criticidad relativa de las tareas de un proyecto tiene consecuencias de gestión. El esfuerzo y los recursos dedicados a las tareas críticas deben ser mayores que a las no críticas. La determinación de las tareas críticas en proyectos que sólo tienen restricciones tecnológicas es relativamente sencilla. El conjunto de tareas consideradas críticas en un proyecto con limitación de recursos depende de decisiones arbitrarias: elecciones del método de programación y del enfoque de criticidad. En esta ponencia se analizan los enfoques propuestos para determinar la criticidad de las tareas en proyectos con recursos limitados y se pone de manifiesto cómo, para el mismo programa, estos enfoques pueden proporcionar resultados muy diferentes. Los gestores deben conocer la arbitrariedad de la determinación de las tareas críticas en proyectos con recursos limitados y deben intentar saber cómo realizan los cálculos los programas de ordenador que utilizan.

1. CAMINO CRÍTICO

El número de tareas de un proyecto hace difícil prestar a todas ellas el mismo grado de atención. La criticidad relativa permite concentrar más esfuerzo y recursos en las tareas consideradas más importantes. El conjunto de tareas críticas en proyectos que sólo tienen restricciones tecnológicas se denomina camino crítico (Critical Path). Este camino puede definirse sin ambigüedad y es relativamente sencillo de calcular. En la Figura 1 se encuentra el programa de duración mínima del ejemplo utilizado en esta ponencia. Se trata de un proyecto con cuatro tareas (A, B C y D; a y b son ficticias). Su programa de duración mínima tiene dos caminos críticos (A-B y D), señalados en negrita en el grafo y en gris en el diagrama de Gantt.

Figura 1. Programación de duración mínima

2. PROGRAMACIÓN CON RECURSOS LIMITADOS

En el ejemplo propuesto, cada tarea requiere una unidad de recurso R por unidad de tiempo y la disponibilidad de R es de dos unidades por unidad de tiempo. La programación de duración mínima de la Figura 1 no cumple las limitaciones de recursos, porque requiere tres unidades de R durante dos unidades de tiempo. El programa con recursos limitados de este ejemplo se ha establecido con un heurístico en paralelo cuyo único criterio de prioridad es holgura total creciente.

La consideración de una tarea como crítica en un proyecto con limitación de recursos depende de decisiones arbitrarias: elecciones del método de programación con recursos limitados y del enfoque de criticidad. En esta ponencia, todos los enfoques de criticidad propuestos se aplican al mismo programa con recursos limitados, para poner de manifiesto la influencia del enfoque.

Una primera aproximación a la determinación de las tareas críticas de un programa con recursos limitados consiste en adoptar las fechas del heurístico aplicado como fechas más tempranas, y calcular las fechas más tardías con la lógica empleada cuando sólo hay restricciones tecnológicas. La versión 4 de Microsoft Project utiliza esta aproximación. Una aproximación intuitiva (Woodworth, 1989) consiste en aumentar la duración de cada tarea (o retrasarla) una unidad de tiempo y ver si condiciona la fecha programada de fin del proyecto. Con estas dos aproximaciones se obtiene que la única tarea crítica es C (Figura 2).

Figura 2. Tareas críticas (Microsoft Project 4; Woodworth, 1989)

3. SECUENCIA CRÍTICA

Wiest (1964) definió la secuencia crítica (Critical Sequence) como el concepto equivalente al camino crítico para proyectos con recursos limitados. Esta secuencia tiene, en general, subconjuntos de tareas vinculadas por restricciones tecnológicas y subconjuntos de tareas que requieren el mismo recurso. La secuencia crítica está formada por las tareas que ocupan la misma posición en dos programas, uno con las tareas programadas lo antes posible y otro con las tareas lo más tarde posible.

El programa con las tareas situadas lo antes posible resulta de la aplicación del heurístico (zona superior de la Figura 3). Wiest (1964) propone que el programa asociado con las tareas situadas lo más tarde posible se determine desplazando las tareas hacia la derecha. Este desplazamiento se hace unidad de tiempo a unidad de tiempo, y los criterios jerárquicos de elección de las tareas a desplazar son: mayor fecha de fin más temprana; mayor fecha de comienzo más tardía, calculada si se mueve hacia la derecha únicamente la tarea considerada; menor número de recursos. Las tareas B y D empatan con el primer criterio (su fecha de fin más temprana es 8). La fecha de comienzo más tardía de B es 4 y de la D es 2, si sólo se mueve una tarea. Por tanto, se desplaza B y después A (no hay recursos suficientes para desplazar D). El programa con las tareas situadas lo más tarde posible está en la zona inferior de la Figura 3. La secuencia crítica que resulta de la comparación de los dos programas es D-C.

Figura 3. Secuencia crítica (Wiest, 1964)

Raz y Marshall (1996) y Woodworth y Shanahan (1988) también consideran críticas las tareas que ocupan las mismas posiciones en dos programas de estas características (con las tareas programadas lo antes y lo más tarde posible).

El método propuesto por Raz y Marshall (1996) tiene cinco pasos. El primero es el programa con las tareas lo antes posible (resultado del heurístico aplicado, zona superior de la Figura 4). En el paso 2 se acepta la fecha de fin del heurístico. En el paso 3 se desplazan todas las tareas hacia la derecha, sin tener en cuenta la limitación de recursos (zona central de la Figura 4). En el paso 4 se desplazan algunas tareas hacia la izquierda, para resolver los posibles problemas de recursos del paso 3. Estos autores proponen que se desplacen, en primer lugar, las tareas con menor fecha de fin en el programa del paso 1. En este ejemplo, hay un empate entre B y D. El paso 5 es el programa con las tareas programadas lo más tarde posible (zona inferior de la Figura 4). Con este método, las tareas críticas del ejemplo pueden ser A-B-C ó D-C, según cómo se resuelva el empate entre B y D.

Figura 4. Tareas críticas (Raz y Marshall, 1996)

Woodworth y Shanahan (1988) proponen un método para calcular la secuencia crítica cuando hay más de un recurso, una unidad disponible de cada uno y las tareas requieren una o ninguna unidad de los recursos. En el cálculo del programa con las tareas lo más tarde posible se calcula la fecha de comienzo más tardía de la última tarea (C) y se asigna como fecha de fin más tardía de la tarea anterior que utiliza el mismo recurso (B ó D). Si la fecha de comienzo más temprana de la última tarea coincide con la fecha de fin más temprana de la anterior, ésta pertenece a la secuencia crítica. La aplicación de este algoritmo lleva a dos secuencias críticas A-B-C y D-C, es decir, todas las tareas pertenecen a alguna secuencia crítica.

4. TRANSFORMACIÓN DEL PROYECTO ORIGINAL

Hay enfoques que transforman el proyecto original, añadiendo restricciones que se tratan como restricciones tecnológicas, de modo que los cálculos puedan hacerse con la misma lógica que cuando no hay limitación de recursos.

Bowers (1995) propone la utilización de enlaces de recursos, que actúan como restricciones tecnológicas a efectos de cálculos de fechas más tardías y de holguras. En el ejemplo propuesto, el enlace de recursos está entre las tareas B y C, y es equivalente a la restricción de que C no puede empezar hasta que no acabe B. Con este enfoque, las tareas críticas son A-B-C (Figura 5).

Figura 5. Tareas críticas (Bowers, 1995)

Para evitar los caminos críticos discontinuos de la versión 4 (Figura 2), la versión 98 de Microsoft Project trata al tiempo que se retrasa una tarea por falta de recursos (que denominada Retraso por redistribución) como una restricción tecnológica, para el cálculo de fechas más tardías y holguras. En este caso, la restricción es que la tarea C no puede empezar hasta pasadas seis unidades de tiempo del fin de A, y el camino crítico que proporciona este programa es A-C (zona inferior de la Figura 6).

Figura 6. Caminos críticos (Microsoft Project 98)

5. CADENA CRÍTICA

Goldratt (1997) propuso una filosofía de gestión de proyectos denominada cadena crítica (Critical Chain), que incluye aspectos de gestión de recursos humanos, de programación de proyectos y de gestión de la incertidumbre. La definición de cadena crítica propuesta por Goldratt (1997, página 215) como la cadena más larga de pasos dependientes, teniendo en cuenta tanto restricciones tecnológicas como limitaciones de recursos, ha hecho resurgir el interés por la determinación de las tareas críticas en estos entornos. La denominación de cadena crítica se aplica por extensión a toda la filosofía, que cuestiona la forma de estimar la duración de las tareas, intenta reducir el trabajo en curso del proyecto y tiene mecanismos explícitos de gestión de la incertidumbre, materializados en elementos de tiempo denominados buffers, situados en puntos claves del proyecto. Los proyectos que siguen esta filosofía tienen sus tareas programadas lo más tarde posible. Las tareas que forman la cadena crítica son las que no pueden adelantarse (Newbold, 1998, página 85).

Los autores de esta escuela de pensamiento proporcionan ejemplos sencillos de determinación de cadenas críticas, pero no algoritmos detallados para realizar los cálculos, porque su orientación no es matemática ni algorítmica, sino de gestión. Goldratt (1997, página 216) afirma que es un error esforzarse en obtener respuestas precisas cuando los datos no son exactos, y que las respuestas que pretenden ser más precisas que la incertidumbre del problema, no son mejores respuestas.

CONCLUSIONES

La determinación de las tareas críticas en proyectos con restricciones tecnológicas y limitación de recursos no supone únicamente una mayor cantidad de cálculos respecto a proyectos sin recursos limitados, sino que plantea problemas de definición. En esta ponencia se incluyen los distintos enfoques de criticidad propuestos y se aplican al mismo programa con recursos limitados. Los resultados obtenidos con estos enfoques son dispares, como puede verse en el resumen de la Tabla 1. En la primera columna están los caminos críticos del programa de duración mínima; en las siguientes columnas están las tareas consideradas críticas, para el mismo programa con recursos limitados, según el enfoque adoptado.

Tabla 1. Tareas críticas del ejemplo según el enfoque de criticidad

Caminos críticos

MS Project 4 Woodworth, 89

Wiest, 64

Raz y Marshall, 96

Woodworth y Shanahan, 88

Bowers, 95

Microsoft Project 98

A-B

y D

C

D-C

A-B-C

ó D-C

A-B-C

y D-C

A-B-C

A-C

La determinación de las tareas críticas no es una cuestión formal, sino que tiene implicaciones de gestión, puesto que los esfuerzos y los recursos se concentran en las tareas con mayor importancia relativa. En consecuencia, los gestores deben conocer la arbitrariedad de la determinación de las tareas críticas en proyectos con recursos limitados, es decir, no deben considerar que algunas tareas son críticas de forma natural, y deben intentar saber cómo hacen los cálculos los programas de ordenador que utilizan, puesto que sus resultados pueden condicionar la gestión.

REFERENCIAS

Bowers, J.A. (1995). Criticality in Resource Constrained Networks. Journal of the Operational Research Society, vol. 46, no. 1, pp. 80-91.

Goldratt, Eliyahu M. (1997). Critical Chain. The North River Press.

Newbold, Robert C. (1998). Project Management in the Fast Lane. Applying the Theory of Constraints. St. Lucie Press.

Raz, Tzvi; Marshall, Bob (1996). Effect of resource constraints on float calculations in project networks. International Journal of Project Management, vol. 14, no. 4, pp. 241-248.

Wiest, Jerome D. (1964). Some properties of schedules for large projects with limited resources. Operations Research, vol. 12, no. 3, pp. 395-418.

Woodworth, B.M.; Shanahan, S. (1988). Identifying the critical sequence in a resource constrained project. International Journal of Project Management, vol. 6, no. 2, pp. 89-96.

Woodworth, B.M. (1989). Is Resource-Constrained Project Management Software Reliable? Cost Engineering, vol. 31, no. 7; pp. 7-11.

CORRESPONDENCIA

Francisco Antonio Rivera. farivera@ing.uc3m.es

Escuela Técnica Superior. Universidad Carlos III de Madrid

Avenida de la Universidad, 30. 28911 Leganés (Madrid)