|
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)
|