LECCIN

Programacin Temporal. Recursos y Tareas.

Contenidos
3.1 Introduccin 3.1.1 Objetivos 3.2 Los diagramas Gantt 3.2.1 Antecedentes histricos 3.2.2 Principios bsicos 3.3 Los grafos PERT 3.3.1 Antecedentes histricos 3.3.2 Principios bsicos 3.4 Los Diagramas de Precedencias 3.5 La programacin y el coste 3.5.1 El problema del plazo y el coste 3.6 La programacin y los recursos 3.6.1 El problema de los recursos limitados 3.6.2 La nivelacin de recursos 3.6.3 La asignacin de recursos 3.7 Otras estrategias de programacin 3.7.1 Introduccin 3.7.2 Variabilidad y cadenas de tareas 3.7.3 Mrgenes de seguridad 3.7.4 Reduccin de mrgenes en cada tarea y protectores de cadena. 3.8 Cadena Crtica 3.9 Conclusiones 3.9.1 Lecturas recomendadas 3.9.2 Preguntas abiertas 3.9.3 Supuestos

Bibliografa

3.1 Introduccin
3.1.1 Objetivos
Objetivos de la leccin Tras esta leccin, el alumno conocer: 1. Cules son las tcnicas de expresin del cronograma ms comnmente utilizadas en la direccin de plazos. 2. 3. 4. 5. Los antecedentes histricos de las mismas y sus principios bsicos. Cmo construir un diagrama de Gantt y un Diagrama de Precedencias. Cundo resulta ms ventajosa la utilizacin de un mtodo u otro. Los distintos tipos de enlaces y relaciones de precedencia que aparecen entre las distintas actividades del cronograma. 6. 7. 8. Cmo resolver solapamientos y desplazamientos. Cmo calcular los distintos tipos de holgura y su significado. Cmo determinar las fechas de comienzo y de finalizacin tempranas y tardas de las actividades del cronograma. 9. El efecto que tiene sobre el coste la reduccin del plazo, y viceversa.

10. El significado del coste unitario de reduccin y las posibles causas que determinan su signo. 11. Las reglas que determinan el mnimo coste en la reduccin de la duracin de las actividades del cronograma. 12. El contexto de la programacin de proyectos con recursos limitados. 13. El efecto del cronograma sobre la utilizacin de los recursos. 14. Las ventajas de un perfil de utilizacin de recursos nivelado. 15. El algoritmo de BurgessKillebrew para la nivelacin de recursos. 16. Otras tcnicas de programacin: consideracin de la restriccin temporal y de recursos (mtodo de la cadena crtica).

3.2 Los diagramas Gantt

3.2.1 Antecedentes histricos
Desde la introduccin de la mquina de vapor y el advenimiento de la revolucin industrial, comienza el inters por la programacin y secuenciacin de las tareas productivas a fin a conseguir una mayor eficiencia. As, ya en 1760 Perronet estudi los tiempos necesarios para la fabricacin de alfileres. Sin embargo, no es hasta el siglo XIX cuando Frederick W. Taylor inicia sus estudios de sistematizacin de mtodos y tiempos, presentando en 1895 los resultados del estudio a la ASME (American Society of Mechanical Engineers). El conjunto de estos estudios podran bien ser considerados como los fundamentos de los sistemas organizativos de los sistemas productivos en la industria. Posteriormente, discpulos suyos continan con estos trabajos y as, en 1909, Gilbreth publica su trabajo sobre la colocacin de ladrillos, para interesarse posteriormente por el anlisis de los movimientos, publicando en 1917 Aplicaciones del estudio de movimientos. Otro de sus discpulos, Henry Gantt (18611919) seal que un proceso lo forma una combinacin de operaciones. Esta observacin le condujo a desarrollar mtodos grficos que permitan visualizar la simultaneidad y secuenciacin de las operaciones.

Figura 3.1: Diagrama de Gantt que muestra los plazos de realizacin de varias actividades

3.2.2 Principios bsicos

La forma ms intuitiva de representacin grfica de la planificacin son los diagramas de barras. Los diagramas de barras son muy utilizados en proyectos porque proporcionan una representacin fcil de entender por personas de procedencia muy diferente, pero aportando simultneamente datos precisos. La forma bsica de un diagrama de barras consiste en una lista de actividades en el lado izquierdo, cada una de las cuales tiene asociada una barra horizontal de longitud proporcional a su duracin. Dentro de estos diagramas destacan los diagramas de hitos y, especialmente, el diagrama de Gantt. Utiliza la base normal de un calendario con barras para cada actividad, tal como se ve en la figura 3.1. Sobre el Gantt suelen marcarse los hitos.

Tipos de relaciones entre actividades Una vez que se ha definido la estructura de descomposicin del proyecto (EDP) y se han dado valores a las duraciones de las diferentes actividades, es el momento de introducir las dependencias entre actividades. La figura 3.2 muestra los principales tipos de enlaces: INICIOINICIO Las dos actividades debern comenzar simultneamente (por ejemplo, la tarea trabajos pintura slo puede iniciarse una vez iniciada la tarea montar andamio). FINFIN Las actividades implicadas debern terminar simultneamente (por ejemplo, la tarea desmontar andamio slo puede terminarse una vez finalizada la tarea trabajos de pintura). FININICIO Es el ms habitual e indica que la actividad actual deber esperar a que termine la predecesora, pues probablemente sus resultados sern parte del material de partida de sta (por ejemplo, la tarea instalar equipo slo puede iniciarse una vez terminada la tarea reparar equipo). INICIOFIN Esta vinculacin permite el cierre del ciclo, indicando que no puede finalizar una actividad sin que comience la siguiente (por ejemplo, la tarea puesta en servicio slo puede terminarse una vez iniciada la tarea aceptacin).

Figura 3.2: Tipos de enlaces entre actividades

Ventajas e inconvenientes La utilizacin de los diagramas de Gantt proporciona grandes ventajas siempre que se sepa cuando se deben usar y cuando deben verse relegados por otras alternativas de representacin. A continuacin se comentan las ventajas e inconvenientes del mtodo.

Ventajas Es una representacin fcil de comprender. Los elementos de representacin son simples y su interpretacin es inmediata.

 Sirve de base para la planificacin de recursos. Como veremos en los apartados correspondientes a la nivelacin de recursos, el diagrama de Gantt permite perfilar de forma sencilla la utilizacin de los recursos y su evolucin a lo largo del ciclo de vida del proyecto. Muestra el progreso de las actividades de forma clara y simple. Junto con la planificacin, el Gantt tambin puede ser utilizado para el seguimiento del progreso del proyecto. En general, se asume que existe relacin directa entre porcentaje completo y duracin restante. Por ejemplo, cuando una actividad de cuatro das est completa al 50 %, la duracin restante es dos das. As, en la figura 3.3, se ha marcado a modo de ejemplo el desarrollo de cada una de las tareas con un rectngulo verde en el interior de cada una de ellas. En esa figura, se observa cmo al terminar el quinto perodo la actividad a est totalmente terminada, la b est en plazo, la c va ms avanzada de lo que le correspondera y la d va retrasada. Se puede apreciar la holgura. En el diagrama de la figura 3.1 se pueden apreciar de forma muy evidente las relaciones existentes entre actividades. As mismo se comprueba que la duracin total del proyecto ser de 12 periodos. De igual forma se comprueba que existen unas actividades (A C, D, F y H), para las que cualquier aumento de su duracin, o un retraso en la fecha de comienzo supondra un retraso en la duracin total del proyecto. Por el contrario, existen otras actividades (B, E, G, e I) en las que este retraso no sera tan crtico 1 . Las actividades A, C, D, F y H forman lo que se denominar posteriormente camino crtico.

Figura 3.3: Diagrama de Gantt mostrando el progreso de los trabajos.

Inconvenientes Tamao. A medida que el proyecto crece, este mtodo se muestra menos aplicable. En general no se recomienda su utilizacin para proyectos con ms de 200 actividades. Incertidumbre. El mtodo no es adecuado para observar sobre l la variacin de la duracin de las actividades.

1 As, por ejemplo, las actividades B y E podran alargar su duracin una unidad temporal sin afectar a la duracin total.

Muchos de estos problemas se resuelven con la utilizacin conjunta de los diagramas de Gantt con un mtodo ms complejo como, por ejemplo, los Diagramas de Precedencia grafos PERT.

3.3 Los grafos PERT

3.3.1 Antecedentes histricos
Desde su aparicin, en el ao 1958, las modernas tcnicas de programacin y control de proyectos se han aplicado con xito a campos muy diversos, tales como explotaciones de recursos naturales, construcciones de barcos o aviones, proyectos de ingeniera civil, introduccin en el mercado de un nuevo producto, puesta en rbita de satlites, edicin y lanzamiento de libros, instalacin y puesta a punto de computadores, etc. El mtodo PERT (Program Evaluation and Review Technique) y el mtodo CPM (Critical Path Method) constituyen las dos tcnicas pioneras en el campo de la moderna programacin y control de proyectos. Tanto el PERT como el CPM hicieron su aparicin aproximadamente en la misma poca (1958). Aunque estas dos tcnicas se gestaron a partir de investigaciones totalmente independientes, en sus formas esenciales son idnticas, existiendo slo ligeras diferencias en sus aspectos formales y de notacin. El desarrollo del mtodo PERT se inici en 1957, cuando la Marina de los Estados Unidos se enfrent a los tremendos problemas de coordinacin y control que surgieron en la realizacin del proyecto de submarinos atmicos armados con proyectiles Polaris. Aparte de los problemas tcnicos y cientficos propios de un proyecto de estas caractersticas, surgieron los problemas referentes a la coordinacin y al control del mismo. En este proyecto, la Marina de los Estados Unidos deba mantener relacin con 250 contratistas directos, con ms de 9.000 subcontratistas, adems de con un nmero elevado de agencias gubernamentales, todo lo cual supona la coordinacin de una gran cantidad de recursos y esfuerzos humanos. Los responsables del proyecto vieron enseguida que las tcnicas de planificacin y control de que podan disponer resultaban insuficientes para aplicarlas con xito a un proyecto de esta envergadura. Prcticamente, el nico mtodo de planificacin y control de proyectos que exista en esa poca era el diagrama de barras de Gantt 2 . Ante la imposibilidad de programar el proyecto Polaris por medio de un diagrama de Gantt y sobre todo ante la enormidad de la estructura de control y seguimiento que significaba, la Marina de los Estados Unidos decidi emprender una investigacin con objeto de obtener una nueva tcnica ms perfeccionada de programacin y control de proyectos. De esta manera, bajo iniciativa del almirante W.F. Raborn, se constituy en 1958 un equipo investigador formado por personal tcnico de la Oficina de Proyectos Especiales de la Marina, de la empresa de material aeronutico Lockheed y de la empresa de Ingenieros Consultores Booz, Allen y Hamilton. El proyecto de investigacin se design con el nombre de PERT (Program Evaluation and Research Task). Cuando apareci el primer informe interno en la Marina sobre este proyecto se le design con el nuevo nombre de Program Evaluation and Review Technique, que tambin corresponde a las siglas PERT y que no ha experimentado ningn cambio hasta nuestros das.

2 Curiosamente, Henry L. Gantt desarroll su sistema de planificacin tambin dentro del marco de las necesidades militares durante la primera Guerra Mundial, con objeto de establecer racionalmente los programas de aprovisionamiento de municiones.

En septiembre de 1969, la revista Operations research public, en su nmero de septiembre, un artculo realizado por D. C. Malcolm, J. H. Roseboom, C. E. Clark y W. Fazar (miembros del equipo investigador patrocinado por la Marina). Este artculo constituy el primer trabajo publicado sobre el mtodo PERT. La aplicacin del mtodo PERT [7, 11, 10, 1] a la programacin y al control del proyecto Polaris constituy un enorme xito 3 que supuso una rpida difusin del nuevo mtodo de planificacin al campo comercial e industrial. Paralelamente, en 1957, la empresa E.I. Du Pont quiso desarrollar un mtodo que le permitiera programar y controlar los proyectos de mantenimiento en sus plantas de fabricacin. Con este objeto, Morgan R. Walker, de la divisin de Ingeniera de la Dupont y James E. Kelley, que trabajaba en el Remington RandUnivac, desarrollaron el mtodo de planificacin de proyectos conocido por CPM o mtodo del camino crtico. Si bien el mtodo CPM fue concebido un ao antes, se puede considerar que ambas tcnicas son similares y responden a un problema similar que se plantea en mbitos muy distintos. En el primer caso CPM surge en el mbito civil para optimizar proyectos con una cierta dosis de repetibilidad y donde la estimacin de la duracin de las actividades individuales no es un problema excesivo, sindolo en cambio la duracin total de las mismas (por este motivo se realiza utilizando experiencias previas). Por el contrario el segundo caso, el mtodo PERT surge en un entorno militar de desarrollo de nuevos productos con elevadas dosis de riesgo tanto en la estimacin de las duraciones de las actividades como en las funcionalidades, por lo que aqu s que la estimacin de las duraciones de las actividades individuales supona un aspecto significativo y, de hecho, la metodologa desarrollada para estimarlas ha supuesto un hito relevante del propio mtodo (por este motivo se realiza utilizando tcnicas estadsticas). Durante los aos siguientes al nacimiento del PERT y del CPM han surgido una serie de mtodos de programacin y control de proyectos que amplan y perfeccionan las tcnicas originales. Entre estas nuevas tcnicas cabe citar un mtodo dual del PERT, original del matemtico francs Bernard Roy, que se conoce con el nombre de mtodo de los potenciales o mtodo de Roy. Se han introducido tambin visiones probabilistas de estos mtodos tendentes a plantear la probabilidad de finalizacin del proyecto en un determinado plazo, as como la confianza de alcanzar un determinado nivel de calidad, o de empleo de recursos. La construccin del grafo PERT puede resultar ms o menos difcil en funcin de las distintas relaciones que el grafo deba satisfacer. En la construccin de la red, una flecha representa una actividad, indicando la direccin de progreso del proyecto. Las relaciones de precedencia entre las distintas actividades se introducen definiendo los nodos que representan sucesos. Consideremos a modo de ejemplo las relaciones expresadas en la figura 3.4. Para satisfacer las relaciones, en la construccin del grafo se ha debido introducir una actividad adicional inexistente que recibe el nombre de ficticia. La actividad ficticia anterior no consumir tiempo ni recursos, pues su introduccin tan slo sirve para el propsito de reflejar con fidelidad las prelaciones establecidas; nicamente es un enlace lgico que nos permite reflejar formalmente las relaciones existentes entre las diferentes actividades que constituyen el proyecto.

La duracin prevista inicialmente era de cinco aos. Su coordinacin mediante grafos PERT logr que se desarrollara en slo tres.

Figura 3.4. Ejemplo representacin PERT con una actividad ficticia.

3.4 Los Diagramas de Precedencias

En los Diagramas de precedencias los nodos representan las actividades y los arcos las relaciones de precedencia (AON: Activity-on-Node). La ventaja fundamental del diagrama de precedencias es que no necesita utilizar actividades ficticias, que pueden ser necesarias en el diagrama de flechas, lo que facilita la definicin y comprensin de la secuencia, requiriendo un menor nmero de actividades para definir un proyecto. El diagrama de precedencias se utiliza generalmente en los programas de ordenador actuales para planificacin de proyectos que permiten combinar los cuatro tipos posibles de relaciones de precedencias (Final - Final: FF; Final - Comienzo: FC; Comienzo - Comienzo: CC y Comienzo - Final: CF) a las que se les puede asignar una duracin. Los ejercicios de la asignatura se realizarn utilizando este mtodo, por lo que para ilustrar su realizacin, se resolver un ejercicio a modo de ejemplo.

Actividad

Predecesoras

Duracin (semanas)

A B C D E F G

A A, B C, E, D F

5 3 8 7 7 4 5

Tabla 3.1. Ejemplo Como se ha dicho, en este caso las flechas se utilizan para representar las relaciones de precedencia y los nodos para representar las actividades. En esta red no se necesita utilizar actividades ficticias y es muy simple de representar.

Se deben de tener en cuenta las siguientes reglas: 1. 2. 3. 4. 5. Todos los nodos, a excepcin del nodo final, deben tener al menos un sucesor. Todos los nodos, a excepcin del nodo inicial, deben tener al menos un predecesor. Slo debe haber un nodo inicial y un nodo final. Todas las flechas deben tener un nodo inicial y un nodo final. Una flecha especifica slo una relacin de precedencia; su longitud es independiente de la duracin de las actividades que conecta. 6. No se permite la existencia de bucles cerrados en la red. Implicara la existencia de una sucesora que a su vez depende de la predecesora, lo cual no es posible. Para calcular los tiempos ms tempranos se realiza lo que se conoce como la pasada hacia adelante y para calcular los tiempos ms tardos la pasada hacia atrs.

ES=0/EF=5 A(5)

ES=5/EF=13 C(8)

ES=0/EF=3

ES=5/EF=12 D(7)

ES=13/EF=17 F(4)

ES=17/EF=22 G(5)

Comienzo

B(3)

Final

ES=0/EF=7 E(7)

Figura 3.5. Representacin Diagrama de Precedencias. Clculo de los tiempos ms tempranos de comienzo (ES) y de finalizacin (EF). Pasada hacia adelante.

Clculo de los tiempos ms tempranos de comienzo (ES) y finalizacin (EF): ES(K) = max [EF (J) : siendo J cualquier predecesora de la actividad K] EF(K) = ES (K) + L(K) donde L(K) es la duracin de la actividad K Clculo de los tiempos ms tardos de comienzo y finalizacin: Para finalizar el proyecto lo antes posible, el tiempo ms tardo de finalizacin (LF) de la ltima actividad se hace coincidir con el tiempo ms temprano de finalizacin (EF) calculado anteriormente y utilizando las siguientes frmulas: LF (K) = min [LS (J) : siendo J cualquier sucesora de K] LS (K) = LF (K) L (K)

ES=0/EF=5 LS=0/LF=5 A(5)

ES=5/EF=13 LS=5/LF=13 C(8)

ES=0/EF=3 LS=3/LF=6

ES=5/EF=12 LS=6/LF=13 D(7)

ES=13/EF=17 LS=13/LF=17 F(4)

ES=17/EF=22 LS=17/LF=22 G(5)

Comienzo

B(3)

Final

ES=0/EF=7 LS=6/LF=13 E(7)

Figura 3.6. Representacin Diagrama de Precedencias. Clculo de los tiempos ms tardos de comienzo (LS) y de finalizacin (LF). Pasada hacia atrs.

Clculo de las holguras de las actividades: La verdadera importancia de los tiempos temprano y tardo reside en que constituyen la base para el clculo de las holguras, que son la pieza fundamental en todo el proceso de anlisis.

Existen dos tipos principales de holguras:

Holgura total de una actividad La holgura total de una cierta actividad A, que representaremos por HT , se define como el tiempo que resulta de restar al tiempo tardo de comienzo (o finalizacin) el tiempo temprano de comienzo (o finalizacin) de la actividad, es decir: HT = LS ES HT = LF EF

La holgura total de una actividad nos indica el nmero de unidades de tiempo en que puede retrasarse la realizacin de la actividad con respecto al tiempo previsto, de manera que la duracin del proyecto no experimente ningn retraso. Es muy importante tener en cuenta que si una actividad A consume la totalidad o parte de su holgura total, este hecho puede producir una disminucin en la holgura total de la actividad siguiente. Aquellas actividades cuya holgura total sea cero se denominan actividades crticas. Los caminos desde el nodo inicio del proyecto al nodo fin del proyecto formados por las actividades crticas reciben el nombre de caminos crticos (en el ejemplo el camino compuesto por las actividades A, C, F y G) y resultan esenciales para efectuar el control del proyecto. En efecto, el responsable del proyecto deber extremar la vigilancia de estas actividades crticas, pues un retraso en la realizacin de cualquiera de ellas producir un retraso en la finalizacin del proyecto. Por otra parte, el responsable del control del proyecto no debe desatender a las actividades no crticas, pues un retraso excesivo en su ejecucin puede llegar a convertirlas en crticas, cambiando la estructura del camino crtico del grafo.

10

Holgura libre de una actividad La holgura libre de una cierta actividad K, que representaremos por HL, se define como el tiempo que resulta de restar el menor de los comienzos tempranos de las actividades sucesoras menos la finalizacin temprana de la actividad, es decir: HL (K)= min [ES (J) : J sucesora de K ] EF (K)

La holgura libre de una actividad nos indica la cantidad de tiempo disponible despus de haber realizado la actividad, si todas las actividades del proyecto han comenzado en sus tiempos tempranos. Es decir, la holgura libre representa la parte de la holgura total que puede ser consumida sin perjudicar a las siguientes actividades. El retraso de una actividad que tenga holgura total pero no holgura libre, reduce la holgura de otras actividades del proyecto. En la tabla 3.2. se presentan las duraciones de las actividades y los cuatro tiempos calculados para cada una de ellas as como las holguras.

Actividad A B C D E F G

L(K) 5 3 8 7 7 4 5

ES 0 0 5 5 0 13 17

EF 5 3 13 12 7 17 22

LF 5 6 13 13 13 17 22

LS 0 3 5 6 6 13 17

HT 0 3 0 1 6 0 0

HL 0 2 0 1 6 0 0

Tabla 3.2. Cuatro tiempos y holguras de las actividades del ejemplo desarrollado.

Las actividades con holgura total nula pertenecen al camino crtico. La duracin total del proyecto vendr dada por la suma de las duraciones de las actividades que componen el camino crtico. Cualquier reduccin que se pretenda en el plazo de ejecucin, se deber intentar actuando en primer lugar sobre las duraciones de las actividades que constituyen el camino crtico. La reduccin del plazo se puede obtener mediante diversos mtodos, entre los que se incluyen los siguientes: Reduccin del alcance del proyecto. Asignacin de ms recursos (p.e. crashing). Realizacin de actividades en paralelo (fast tracking). Acortar las actividades que pertenecen al camino crtico. Acortar las actividades que estn al comienzo del proyecto.

11

Acortar las actividades ms largas. Acortar las actividades que tienen menor dificultad. Incrementar el nmero de horas de trabajo por da. El seguimiento del plazo en la ejecucin del proyecto pasar igualmente en primer lugar por la

vigilancia y control de los plazos de las actividades que constituyen el camino crtico. Se pueden identificar en la red "asas" del camino crtico, formadas por actividades encadenadas con igual holgura, que constituyen caminos subcrticos. Las de aquellos caminos subcrticos con menor holgura debern ser objeto de atencin semejante a las del camino crtico, por el riesgo de que un retraso en stas las convierta en crticas.

3.5 La programacin y el coste

3.5.1 El problema del plazo y el coste
La duracin de una actividad se comporta como una variable aleatoria. Esto quiere decir que, dentro de un contexto determinado y para los parmetros que son vlidos en dicho contexto, esta duracin puede tomar valores mayores o menores. Sin embargo, a parte de las naturales oscilaciones respecto a un valor central debidas a fenmenos aleatorios que podramos considerar debidas a perturbaciones, el equipo de direccin de proyectos debera disponer de medios eficaces para alterar el curso que, por natura, seguira el desarrollo de las actividades. Por lo general, estas medidas conducen a una reduccin del plazo necesario para ejecutar una tarea, habitualmente mediante: La mejora de los procesos productivos Aplicar procesos de calidad refinada permite evitar retrasos debidos a prdidas de tiempo innecesarias o a reprocesos. La mejora del perfil de los recursos aplicados en el desarrollo de las actividades La utilizacin de los recursos ms idneos permite una mayor eficacia en el desempeo de los trabajos. Un cambio en el grado de utilizacin de los recursos Con frecuencia, la modificacin del nmero de recursos empleados acelera su ejecucin. La modificacin puede suponer un aumento, con lo que se pretende acelerar una actividad cuya lentitud se deba a la falta de recursos; o puede ser tambin un decremento, con lo que se pretende evitar obstculos en la comunicacin y coordinacin de la actividad.

3.6 La programacin y los recursos

3.6.1 El problema de los recursos limitados
En efecto, supongamos que en un proyecto de explotacin de un determinado recurso, dos de las actividades, la C y la D, puedan ejecutarse simultneamente con unos tiempos de cinco y siete das respectivamente. Imaginemos que para el clculo de los tiempos anteriores no se han tomado en cuenta que se va a emplear un solo equipo disponible, por lo que las actividades C y D no podrn ejecutarse simultneamente 4 , aunque as

4 Supongamos que slo disponemos de uno de estos equipos y que su capacidad se agota al ser empleado en una actividad.

12

nos los indique el grafo de relaciones. En este caso, el recurso equipo automtico juega un papel condicionante en la programacin, pues originar un retraso en la ejecucin de al menos una de las actividades. El hecho de que las tcnicas de programacin expuestas se basen en el supuesto de que los recursos se encuentran disponibles en cantidades ilimitadas supone una clara debilidad de estos mtodos, por lo que se hace necesario adaptarlos a este nuevo contexto. La necesidad de esta adaptacin fue observada rpidamente por los estudiosos del tema. As, en el ao 1962 se publicaron los primeros trabajos en los que se pretende situar a los mtodos modernos de programacin y control de proyectos en un contexto de recursos limitados. Dentro del contexto general de los recursos limitados existen dos problemas claramente diferenciados: la nivelacin y la asignacin de recursos. Los mtodos de nivelacin de recursos, en lneas generales, pretenden: Que la duracin del proyecto no exceda de la prevista; es decir, la duracin dada por el camino crtico. Que los consumos de los diferentes tipos de recursos, durante el perodo de ejecucin del proyecto sean lo ms uniformes posible. La situacin ptima, a la que en la mayor parte de los casos no podr llegar, es aquella en la que el consumo de cada uno de los recursos coincida exactamente en cada uno de los perodos de tiempo en los que se ejecuta el proyecto. Por otra parte, los mtodos de asignacin de recursos pretenden minimizar la duracin del proyecto, de forma que en ninguno de los perodos de tiempo en los que se ejecuta el proyecto, el consumo de algn recurso supere a las disponibilidades existentes del mismo. Ntese que esa correccin puede significar un incremento de la duracin sobre la inicialmente identificada en el camino crtico, incluso ste puede cambiar como consecuencia de la reconsideracin de las limitaciones impuestas por los recursos limitados.

3.6.2 La nivelacin de recursos

El problema de nivelar los recursos surge cuando el consumo que de ellos se hace a lo largo del proyecto no es uniforme. Si, por ejemplo, consideramos obreros, puede que al principio del proyecto se necesiten 30, luego 15, luego 5, luego 25 y por ltimo 5. El no hacer un consumo uniforme de los recursos plantea problemas. En este caso la empresa objeto del estudio necesitar disponer de 30 obreros, de los cuales slo estarn trabajando todos en el primer periodo de tiempo. Si la distribucin de recursos se hubiera realizado de forma ms uniforme, por ejemplo 15 obreros a lo largo de todo el proyecto, el reparto de trabajo estara ms optimizado: se reduciran los tiempos de espera como consecuencia de la disminucin de recursos ociosos, y se obtendra un dimensionamiento ptimo del nmero de trabajadores necesario en el proyecto. La nivelacin de recursos consiste en hacer una redistribucin de las tareas sin que afecte a la duracin total del proyecto. Ante la dificultad de aplicar mtodos exactos en la resolucin de los problemas de nivelacin y de asignacin de recursos han surgido una serie de algoritmos heursticos que resuelven, aunque de una manera aproximada, los problemas anteriormente planteados. Estos algoritmos heursticos no aseguran el hallazgo de un ptimo, pero s de un subptimo, reduciendo considerablemente el trabajo de clculo. En la mayor parte de las aplicaciones reales, este subptimo proporciona una aproximacin suficiente. En este apartado vamos a presentar un algoritmo de nivelacin de recursos, el de Burgess Killebrew[3], que siendo uno de los algoritmos pioneros en este campo, est considerado tambin como uno

13

de los ms eficientes. Sin entrar en una discusin matemtica del algoritmo, nos vamos a limitar a explicar su mecnica operativa, apoyndonos para ello en la nivelacin del recurso mano de obra del proyecto de un proyecto ficticio cuyos datos bsicos recogemos en la tabla 3.3.

Tabla 3.3: Datos del ejemplo de nivelacin

La realizacin de las actividades de este proyecto tiene asociada la carga de recursos que se muestra en la figura 3.7.

Figura 3.7. Representacin Diagrama de Precedencias sobre diagrama Gantt del ejemplo.

Como se puede ver la utilizacin de recursos no es todo lo uniforme que sera deseable. El nivel de utilizacin ptimo sera 15 recursos en cada periodo:

La aplicacin del algoritmo se efecta en las fases que describimos seguidamente.

14

Fase 1 Nos fijamos en el calendario de ejecucin del proyecto, buscando la actividad no crtica que tenga la fecha temprana de finalizacin ms avanzada. En esta actividad se retrasa su finalizacin unidad por unidad de tiempo, de acuerdo con lo que permite su holgura5 . Se elegir como fecha ms temprana de finalizacin de la actividad la que haga mnima la suma de los cuadrados de las cargas. As, en nuestro ejemplo, comenzaremos por analizar la actividad E, pues es la que posee la fecha temprana de finalizacin ms avanzada. Como la holgura total de esta actividad es de 1 semana, retrasaremos su finalizacin en una semana, comprobando la repercusin que tiene esta accin en la suma de los cuadrados de las cargas. Como dicha suma se reduce, conviene retrasar la ejecucin de la actividad E en una semana. La nivelacin parcial que hemos conseguido con esta primera iteracin queda reflejada en el diagrama de cargas. Despus de aplicar el algoritmo el diagrama de Gantt resultante se muestra en la figura 3.8.

Figura 3.8. Representacin diagrama Gantt del ejemplo con la actividad E desplazada una unidad temporal.

Fase 2 Entre todas las actividades no crticas, excluida la actividad que hayamos estudiado en la primera fase, se vuelve a elegir la que tenga la fecha temprana de finalizacin ms avanzada. Una vez encontrada esta actividad, se le aplica el mismo tratamiento que el descrito en la primera fase. En este caso retrasamos la tarea G primero un periodo y despus otro (figura 3.9 y 3.10). El movimiento que ms nos interesa es retrasar la duracin de la tarea en 2 unidades de tiempo, con lo que se obtiene una suma del cuadrado de las cargas de 3100. Seguidamente continuaremos el proceso hasta

5 Aunque el algoritmo lo apliquemos utilizando la holgura total de una actividad, tambin es posible utilizar su holgura libre: un retraso
equivalente a la holgura total de una actividad no afecta a la duracin del proyecto, pero s a la holgura total de las actividades siguientes; mientras que, un retraso equivalente a la holgura libre no afecta ni a la duracin del proyecto ni a la holgura total disponible de las actividades siguientes.

15

llegar a la actividad que posea una fecha temprana de finalizacin ms retrasada, aplicndole el mismo tratamiento. Cuando dos o ms actividades tengan la misma fecha temprana de finalizacin, se actuar prioritariamente sobre la actividad cuya holgura permita un retraso mayor en su finalizacin.

Figura 3.9. Representacin diagrama Gantt del ejemplo con la actividad G desplazada una unidad temporal.

Figura 3.10. Representacin diagrama Gantt del ejemplo con la actividad G desplazada dos unidades temporales.

As en nuestro ejemplo, una vez analizada la actividad G, pasaramos a estudiar la actividad I, pues de entre las actividades no crticas restantes es la que posee la fecha temprana de finalizacin ms avanzada. Como la holgura total disponible de esta actividad es de diez semanas, retrasamos su finalizacin primero en una semana y despus en otra y otra, etc, comprobando la repercusin que tiene esta accin en la suma de los cuadrados de las cargas Obviamente, conviene retrasar la ejecucin de la actividad I en diez periodos, pues de esta forma la suma de los cuadrados de las cargas desciende a 2700 unidades (figura 3.11).

16

Figura 3.11. Representacin diagrama Gantt del ejemplo con la actividad I desplazada diez unidades temporales.

Fase 3 Una vez analizada la actividad con una fecha temprana de finalizacin ms retrasada, se vuelve a iniciar un nuevo ciclo de iteraciones. El proceso de clculo se detendr cuando, finalizado un ciclo, no resulte posible disminuir la suma de los cuadrados de las cargas. En nuestro ejemplo ha bastado efectuar un primer ciclo de iteraciones para llegar al alisado ptimo. Aunque el algoritmo lo hemos aplicado a un calendario de ejecucin del proyecto basado en las fechas tempranas, puede aplicarse de igual forma a un calendario que est basado en las fechas tardas. En ambos casos, como es lgico, se llega a la misma solucin, aunque el nmero de ciclos e iteraciones puede cambiar. Es conveniente tener en cuenta que nunca sabremos si hemos llegado a una solucin ptima, excepto en aquellos casos en los que se alcanza un alisado ptimo. Una de las ventajas que presenta este algoritmo es el de ser factible de procesar en ordenador, lo cual permite su aplicacin a proyectos complejos. Uno de sus principales inconvenientes es el de estar pensado fundamentalmente para la nivelacin de un nico 6 recurso. Otros procedimientos heursticos han sido propuestos por Galbreath[5], Wiest y Levy[14], Moder et al.[8], Ciobanu[4], Newmann y Morlock[9], si bien todos ellos referidos a casos simplificados o bien apoyndose en tcnicas de reglas de priorizacin. Otras tcnicas heursticas para problemas modificados de nivelacin con duraciones de actividades dependientes del uso de recursos, o uso de recursos dependiente del tiempo, se han propuesto por Leachman[6], Seibert y Evans[12], Takamoto et al.[13], etc., si bien ninguno de estos estudios desarrollan casos experimentales con ms de 20 tareas. Recientemente se han propuesto tcnicas heursticas para nivelar recursos con desplazamientos mximos entre tareas adems de valores mnimos en esos desplazamientos[2].

6 Para el caso de nivelacin simultnea de varios recursos resulta bastante til el algoritmo MultiShip MultiShop.

17

Esto se puede emplear para modelar una gran variedad de situaciones como fechas de finalizacin de proyectos o de actividades individuales, solapamiento total o parcial de actividades, problemas con recursos dependientes del tiempo, as como problemas de lanzamiento de rdenes de fabricacin.

3.6.3 La asignacin de recursos

La asignacin de recursos es un problema parecido al de nivelacin pero con algunas particularidades. El problema surge cuando, segn la planificacin del proyecto, en alguna etapa del proyecto el nivel de utilizacin de recursos tericos supera a los disponibles realmente. Entonces hay que ajustar la planificacin de las tareas de forma que en cada periodo de tiempo no se utilicen ms recursos que los existentes, retrasando la realizacin de ciertas tareas. Puede ocurrir incluso que el retraso de estas tareas origine una mayor duracin del proyecto. A partir de los datos de entrada (relacin de tareas, dependencias entre ellas, duracin y recursos que utilizan) se construir un cuadro similar al 3.1. En la primera fila se representan los diferentes periodos de tiempo dentro del proyecto. Inmediatamente debajo se anota la cantidad de recursos disponibles en cada periodo. Lo normal es que el nmero de recursos disponible sea uniforme a lo largo de todo el proyecto. Debajo se anotar la lista de todas las tareas que son candidatas a ejecutarse en ese periodo de tiempo, escribiendo entre parntesis al lado de cada tarea su holgura. Estos candidatos sern ordenados por prioridad para seleccionar qu tareas sern ejecutadas en ese periodo de tiempo. Esta ordenacin se realizar en primer lugar respetando las dependencias marcadas para las tareas. Siempre que se respeten las dependencias originales las tareas con mayor prioridad para ejecutarse en el periodo actual sern aquellas con una menor holgura, y en caso de igualdad las que tengan menor duracin. Al lado de cada tarea se anotarn los recursos que consumir su ejecucin en ese periodo de tiempo.

Cuadro 3.1. Plantilla para desarrollar el algoritmo de asignacin de recursos.

Atendiendo a la ordenacin anterior se seleccionarn las tareas a ejecutar en el periodo de tiempo. Para programar las tareas se ir cogiendo por orden de prioridad mientras la suma de recursos que consumen

18

sea menor o igual a los recursos de que se dispone en ese periodo. Se supone que las tareas son indivisibles 7 , por lo que una vez que se programa el comienzo de una tarea, si esta no finaliza en este periodo de tiempo, automticamente es programada tambin en los periodos siguientes hasta que termina. Las tareas que no puedan ser programadas pasan automticamente a ser candidatas en el prximo periodo de tiempo, decrementando su holgura. Este proceso se repetir hasta que sean programadas todas las tareas. Veamos la aplicacin del algoritmo con el ejemplo cuyos datos recoge la tabla 3.4. Supongamos que el recurso que queremos asignar es el de mano de obra, y que en cada periodo no podemos disponer de ms de 4 personas. Si analizamos cual es el consumo actual de recursos que se est realizando obtenemos el perfil que aparece recogido en la tabla 3.5. Se puede observar que en los periodos 2 y 4 se est superando el nmero de recursos existentes, por lo que debemos aplicar el algoritmo para asignacin de recursos (tabla 3.6).

Tabla 3.4. Datos del ejemplo correspondiente al algoritmo de asignacin.

Tabla 3.5. Evolucin original de la utilizacin de los recursos del proyecto del ejemplo..

7 La razn fundamental surge de que son los recursos los que construyen los entregables y su agrupacin temporal forma las tareas. Si
una actividad puede ser dividida es porque el trabajo de sus recursos asociados es segmentable y nada impedira entonces considerar cada segmento como una tarea independiente con vinculacin fincomienzo respecto de la anterior, lo que reduce el problema al caso aqu estudiado.

19

Tabla 3.6. Desarrollo del algoritmo de asignacin sobre los datos del ejemplo.

En este caso la solucin obtenida no ve retrasada la duracin del proyecto, que sigue siendo de 10 unidades de tiempo, pero podra haber ocurrido que el proyecto sufriera un retraso motivado por la insuficiencia de recursos.

3.7 Otras estrategias de programacin

3.7.1 Introduccin
Tradicionalmente se ha relacionado la baja adecuacin de las tcnicas de programacin clsicas con la realidad de las empresas y equipos que desarrollan proyectos. Aceptando el teorema central del lmite se puede suponer que la densidad de probabilidad de n tareas (variables aleatorias) independientes era una variable aleatoria cuya duracin promedio es la suma de las duraciones promedio de cada actividad de la cadena. Lo que resulta relevante es comprender lo que significa en el contexto del proyecto esa idea de independencia, y que supone: Que los recursos trabajan siempre a pleno rendimiento y que los recursos se encuentran siempre disponibles para arrancar una tarea en cuanto es posible desde el punto de vista de la planificacin. Esto supone aceptar compromisos desde el punto de vista de la planificacin de la organizacin. Resulta clave comprender que si los recursos no son capaces de mantener la secuencia de generacin de productos como se estableca en el plan de proyecto, esto podra, incluso aunque los desarrolladores de la organizacin estn completamente volcados en cada tarea, generar retrasos del orden del 60 o el 70 %. As, debemos ser conscientes de crear un modelo que sea compatible con las restricciones que la realidad nos impondr, de ah la conveniencia de crear planes de proyecto realistas. Evidentemente estos planes deben ser complementados con la actuacin del director de proyecto que, de un modo proactivo, debe estar pensando constantemente en su sistema, planificar sus acciones cuidadosamente, actuar, dar a sus sistemas tiempo suficiente para reaccionar, evaluar la respuesta antes de revisar su planificacin y volver a actuar sobre el sistema.

20

Este criterio que, aqu expuesto, parece razonable acaba transformndose en la realidad diaria en una imagen de poca actividad que puede ser recriminada por poco activa y que usualmente es difcil de concienciar a los superiores que responde a una adecuada estrategia operativa. Existen tambin mecanismos perturbadores, como los intentos de alterar los planes de proyecto planteados por los equipos de proyecto, con expresiones del tipo Esto no es aceptable, Es excesivamente largo ... en los odos de los directores de proyecto que, practicados de modo regular, conducen a una autocensura arbitraria en los planes de proyecto que, ya de partida se identifican como intiles para la prediccin como era su funcin, pasando a convertirse en algo decorativo, pues se han suprimido pruebas, reducido injustificadamente ensayos, eliminado ciclos de rediseo, etc. Incluso a veces, para obtener la aprobacin de la alta direccin de la organizacin se presentan planes de proyecto cuyas estimaciones para la duracin de las tareas no incluyen protecciones para las mismas, lo que suele provocar situaciones de conflicto. El conflicto surge entre la direccin de la organizacin que desea reducir las estimaciones de las tareas del equipo de proyecto y la necesidad de esa direccin de aceptar el plan de proyecto elaborado. Para evitar el fracaso se debe proponer una fecha de entrega competitiva al cliente. Para conseguir esto se tiene que forzar al equipo de proyecto para que recorten las estimaciones de las tareas, eliminando as intervalos de proteccin innecesarios. Por el contrario se debe mantener el compromiso del equipo de proyecto con el xito del proyecto por lo que se debe aceptar el plan de proyecto propuesto. El conflicto se resolvera si la estimacin inicial por parte del equipo de proyecto ya lleve incluida la reduccin consciente de los plazos en cada tarea, lo que permitira que esa estimacin fuese aceptada directamente por la direccin de la organizacin. Obviamente se traslada la problemtica de la negociacin al terreno con el cliente, pues ahora se trata de establecer un mecanismo de sinceridad y prximo a la realidad en esa relacin que evite esquemas de especulacin/ engao en la relacin con el cliente. Las ventajas seran globales, pues estos planes de proyecto seran realistas y se podrn emplear como herramientas de prediccin a travs del ciclo de vida del proyecto. Este aspecto no solo es positivo sino que tambin resulta positivamente sostenible en el tiempo, pues el equipo de proyecto recupera, paradjicamente, mucho ms control sobre el mismo. Por su parte estos efectos resultan positivos para los clientes en la medida en que este proveedor pasa a situarse como un proveedor de calidad y fiable. Incluso los suministradores pueden percibir una imagen de mayor lealtad pues las tcnicas de especulacin/ engao no son ya tan necesarias. Quizs el punto complejo en el razonamiento es motivar a los equipos de proyecto a que reduzcan de un modo fiable las duraciones de las tareas. Una tcnica podra ser pedir a cada desarrollador de cada tarea la identificacin inicial y final de cada tarea, a la vista del error que se haya cometido se podr aplicar un factor corrector en cada tarea. Este proceso debe ser mantenido en el tiempo para que sea realmente efectivo e implicar al desarrollador, que ahora ser consciente no solo de la estimacin inicial, sino tambin del desarrollo real, lo que solo puede conducir a mejorar la capacidad de estimacin.

3.7.2 Variabilidad y cadenas de tareas

Existe un amplio campo de conocimiento referido a vas efectivas para examinar y gestionar la variabilidad en las prestaciones de los productos. Este campo fue iniciado por Shewhart[12] y a l han contribuido de modo significativo Deming[6], Crosby[5] y Juran[10]. En este sentido las aportaciones realizadas por

21

fabricantes japoneses para gestionar la configuracin de sus productos son legendarias, y han sido imitadas por otras compaas tanto americanas como europeas. Gracias a las aportaciones de Taguchi[13] existe una estrategia de diseo que permite manejar la variabilidad, ya que no puede ser eliminada. Esta estrategia se conoce con el nombre de Diseo Robusto[7]. A pesar de todo, este esfuerzo se ha dirigido exclusivamente al producto y no a los proyectos que desarrollan estos productos, a pesar de que las tareas (unidades elementales que producen productos) son variables en s mismas, incluso en rdenes de magnitud que superan al de los componentes del producto de peor calidad del proyecto. As, mientras nuestra capacidad para estimar y gestionar la configuracin del producto es muy elevada, nuestra capacidad para estimar y gestionar la variabilidad en nuestros proyectos es ineficiente y primitiva. Si por ejemplo, preguntamos a un desarrollador que estime la duracin incluso de la ms simple de las tareas, obtendremos un rango y no una simple estimacin. En este sentido es fascinante como algunos directores de proyecto, en reuniones de trabajo, pueden predecir que un proyecto formado por varios cientos de tareas terminar en determinada fecha. Tambin son sorprendentes las excusas que aparecen despus. La duracin de cada tarea, independientemente de lo pequea que sea, de lo repetible que parezca, etc., es una variable aleatoria, lo que significa que dos repeticiones de la misma tarea nunca tendrn la misma duracin. Como cualquier variable aleatoria, puede ser estimada mediante la funcin esperanza matemtica de la distribucin de probabilidad. En la figura 3.12 se puede observar una forma bastante esperable de densidad de probabilidad de la duracin de una tarea.

Figura 3.12: Posible funcin densidad de probabilidad de una actividad: Ley de Weibull(k = 2 , _ = 3) .

Sin embargo, esta distribucin, aunque coherente con la experiencia y por ello razonable, desafortunadamente es desconocida e imposible de determinar. Esto es as porque cuando se planifica esta tarea, en general, es de modo nico y no hay repeticin posible (es la primera y nica copia del producto, lo que inhabilita su repeticin), por lo que no podr ser repetido y no se podr inferir su distribucin. Desde un punto de vista de modelizacin, imaginemos que aceptamos una distribucin tipo como la anterior y la utilizamos para plantear un plan de lanzamiento de tareas. Si suponemos el menor valor posible de duracin con probabilidad mayor de 0, supone un plan muy agresivo y probablemente imposible para el

22

proyecto. Evidentemente, como herramienta de prediccin, este plan resultar intil para dar soporte al equipo de proyecto, exponiendo al cliente y al proyecto a un riesgo absoluto e inaceptable. Podramos representar las tareas por su duracin con garanta de, al menos, un 90% de confianza de terminar en ese perodo. En este caso la duda vendra si el cliente puede soportar planes de proyecto tan largos y plazos tan dilatados para la entrega de los productos del proyecto. Probablemente, ese enfoque resultara inaceptable, de modo que es muy posible no poder representar tareas con estimaciones tan conservadoras de duracin. A la vista de esto una estimacin promedio para la tarea parece una buena decisin. Afortunadamente la estimacin promedio es un buen estimador no sesgado de la distribucin de probabilidad de duracin, dentro de un plan de proyecto. El problema es que como no tenemos mltiples realizaciones, es difcil estimar la densidad de probabilidad. Si pudiramos eliminar todas las causas de la variabilidad en la duracin de la tarea, la ausencia de tal variabilidad nos permitira hacer predicciones increblemente exactas con respecto a las fechas de la terminacin de nuestros proyectos. Pero, como no podemos eliminar las causas de variabilidad, tenemos que afrontar nuestra necesidad de estimar la duracin del proyecto y sta requiere que estimemos la duracin de las tareas individuales. Las estimaciones de la duracin media de la tarea proporcionadas por los activos de nuestras organizaciones son las mejores que podemos esperar adquirir, para poder construir planes de proyecto factibles. La variabilidad en la duracin de casi todas las tareas de desarrollo de producto son altas, a pesar del sincero esfuerzo del desarrollador para estimar de un modo preciso la duracin de la tarea son realmente muchas las situaciones que pueden producirse, incluso a los desarrolladores ms expertos y que dilatan la duracin inicial de la tarea en un factor de dos o incluso de tres. Adems los proyectos se sustituyen bsicamente por secuencias de tareas (cadenas de tareas) que son responsables de la duracin del proyecto y componen tambin su variabilidad. Para comprender este concepto basta observar la Figura 3.13:

23

Figura 3.13: Mecanismo de proteccin de cada tarea en la cadena para proteger el conjunto. [Tomado de http://www.pdinstitute.com]

Aqu se ve cmo un proyecto con una tarea (parte a de la figura) estimada en duracin en 10 unidades de tiempo y con ley exponencial negativa y desviacin estndar de 5 das genera despus de 1000 simulaciones una distribucin frecuencial como la indicada. En la parte b se extiende la simulacin al caso de un proyecto formado por dos tareas secuenciadas, cuatro en el caso c y ocho en el caso d. Si bien las duraciones medias se mantienen en sus estimaciones (ntese que las distribuciones son sesgadas por lo que la moda y la media no coinciden), es decir en la suma de las medias de las tareas elementales que constituyen la cadena, las variabilidades no se conservan, sino que, de hecho, siguen el teorema central del lmite, y crecen con la raz de la suma de las variabilidades individuales al cuadrado, es decir, 5, 7.07, 10, 14.14 das en cada caso respectivamente.

Figura 3.14: Ejemplo de cmo la cadena de tareas fija la duracin y AUMENTA la variabilidad. [Tomado de http://www.pdinstitute.com ]

Esta reflexin nos indica claramente que, dado que no podemos reducir el efecto adverso que la variabilidad crea, especialmente su capacidad de incrementarse a lo largo de la cadena de actividades,

24

debemos tratar de dirigir en el sentido de limitar esa variabilidad para reducir su impacto cara al cliente. Obviamente que el beneficio directo es tanto para el cliente como para la propia organizacin que mejora en su percepcin de seriedad y prestigio. Un mtodo para proteger al cliente de los efectos de esta variabilidad podra ser asegurar la finalizacin en plazo de cada tarea individual, para lo que se puede tratar de proteger cada tarea en el proyecto asignndole una holgura temporal y despus, aplicando una tcnica de seguimiento por hitos o mtodo similar, tratar de asegurar esos plazos de ejecucin. Esta tcnica que es ampliamente utilizada en el desarrollo de los proyectos en la vida real tiene un handicap asumido pero relevante, y es que el proteger cada actividad con una confianza del 90% supone un coste temporal muy significativo, lo que puede poner en duda la competitividad real de una organizacin que aplique esta estrategia. Paradjicamente esta es la situacin usual, si bien pocas veces se es consciente de ello de un modo explcito. El mtodo para reducir el riesgo de retraso en la entrega a cliente de los productos establecidos en el proyecto puede ser minorado introduciendo MARGENES de SEGURIDAD de PROYECTO, es decir, proponer un plazo de finalizacin que garantice una confianza de finalizacin determinada [dependiente de los costes de penalizacin y rebaja]. El inconveniente tradicional de esta poltica es que genera una estimacin de plazo de entrega claramente no competitiva y que, por tanto, raramente se aplica. La ventaja del mtodo de la cadena crtica (o de la teora de las restricciones que se presenta en el apartado siguiente) es que permite incluir esta posibilidad en la medida en que se apunta una estrategia para reducir la estimacin de cada tarea y para eliminar la proteccin individual a favor de una proteccin colectiva.

Un ejemplo ilustrativo elemental Supongamos un proyecto definido por las siguientes secuencias de actividades, estructuradas en tres cadenas: En la Figura 3.16 puede observarse la aplicacin de la simulacin de Montecarlo para una de las tareas estndar definidas en el proyecto ejemplo de Figura 3.15.

Figura 3.15: Proyecto ejemplo con tres cadenas de 8,4 y 4 tareas en cada una de 10 unidades de tiempo de duracin, y ley beta(3,8).

25

Figura 3.16: Ejemplo de duracin simulada 10000 veces para una tarea genrica.

Los estadsticos bsicos de la distribucin emprica son: Aplicando la simulacin ahora a una de las cadenas de 4 tareas elementales encadenadas tendremos, considerando que comienzan en tiempo 30 unidades ver Figura 3.15- (ntese la correccin del teorema central del lmite ya con 4 tareas, es decir la media sera 4*10+30=70 unidades de tiempo). Para el caso de la cadena de 8 tareas elementales tendremos:

Cuadro 3.2: Estadsticos Bsicos

Figura 3.17: Simulacin MonteCarlo de la duracin de las 4 tareas de una cadena.

26

Figura 3.18: Distribucin de duraciones para la cadena de 8 tareas

Se observa que, en media, la teora se mantiene pues las duraciones medias de las cadenas de 4 tareas son 70,49 unidades de tiempo y para la de ocho 80,85 unidades.

Efecto de las cadenas de tareas En nuestra particular configuracin, dado que tenemos dos cadenas de cuatro actividades que en media finalizan en el tiempo 70 y otro tramo de cadena con siete tareas que dan paso a una tarea de montaje conjunto, parece una cuestin relevante estimar cuando puede comenzar el montaje, especialmente si se deben comprometer recursos para esa actividad. Para calcularlo lo que se puede realizar es la simulacin de Montecarlo pero teniendo cuidado para cada instancia de evaluar el mximo de la finalizacin de la sptima tarea de la cadena de ocho y de las dos cadenas de cuatro, este efecto del mximo significa an en el caso de estas funciones beta de variacin tan reducida un retraso sobre la estimacin inicial determinista basado en la media. Como fcilmente se puede ver, los estadsticos de esta distribucin son los que se presentan en el cuadro 3.3.: Es decir, si la media de la cadena principal informaba que la tarea 8 poda comenzar en tiempo 70, vemos que el considerar los diferentes caminos nos indica con un 50% de probabilidad que no podr comenzar antes del tiempo 76,92 o sea 77. De modo anlogo si calculamos el tiempo previsto de finalizacin tendremos los presentados en el cuadro 3.4.

27

Figura 3.19: Simulacin de la fecha de comienzo de la actividad de montaje (tarea 8).

Cuadro 3.3: Estadsticos Bsicos al comienzo de la ltima tarea.

Figura 3.20: Distribucin de la duracin total teniendo en cuenta el efecto unin de subcadenas.

Cuadro 3.4: Estadsticos Bsicos de duracin total del proyecto.

O sea con una desviacin estndar de 11,4 unidades tiempo. En resumen el efecto de dependencia creado como consecuencia del sincronismo entre las tres cadenas ha supuesto de modo efectivo la aparicin

28

de una tarea virtual de 7 unidades de tiempo. Fijmonos que esto supone de facto que la probabilidad de terminacin segn el modelo determinista que se establecera en 80 unidades temporales tendra una probabilidad del 36% de producirse (dos sobre tres posibilidad de retrasarse), y pueden producirse valores an ms bajos. Este breve ejemplo demuestra que el empleo de las tcnicas clsicas es el camino ms directo a que nosotros mismos pongamos los medios para nuestro propio fracaso. Es decir, es preciso contemplar los aspectos de ingeniera concurrente (cada una de las tres cadenas), en el contexto de un plan de proyecto que tenga en cuenta estas peculiaridades. En nuestro caso particular la solucin resulta evidente, sin ms que lanzar las tareas de las dos cadenas de cuatro tareas al principio del proyecto de modo que aseguremos su no interferencia en la tarea de montaje. Este principio de lanzamiento temprano, por lo dems bastante arraigado en la mentalidad del director del proyecto, no siempre es posible (recordemos que las estrategias de nivelacin tienden a retrasar tareas, no se quiere acumular material producido que se contabiliza como stock, etc.), y lo que es peor no existen guas precisas que indiquen cunto tiempo deben adelantarse esas subcadenas. No debemos perder de vista tampoco que, en general existen otros problemas operativos asociados a las organizaciones funcionando por proyectos. En efecto, en estas organizaciones es usual que existan varios proyectos con bastantes tareas sin predecesor que podran ser iniciadas, pero una poltica de lanzamiento tan pronto como sea posible de cada tarea de cada proyecto en curso puede abocar a un estrangulamiento de recursos en los prximos periodos, es decir a no ser capaces de desarrollar la montaa de trabajo en curso, lo que a la postre se convierte en una limitacin o conflicto adicional. Es decir, causara ms problemas que ventajas.

3.7.3 Mrgenes de seguridad

En esta situacin una medida conservadora propondra justamente ese comienzo anticipado de las subcadenas y la creacin de unos mrgenes de seguridad tanto en el proyecto total como en los finales de cadenas de tareas intermedias:

Figura 3.21: Propuesta de Mrgenes de Seguridad del mtodo de la Cadena Crtica.

29

En la Figura 3.21 se puede visualizar la propuesta de mrgenes de proteccin que se plantean. Es cierto que en proyectos reales la situacin empeora en la medida en que existen muchas ms cadenas paralelas, etc., pero el principio sigue siendo vlido e ilustra cmo puede la organizacin gestionar el tiempo de sus proyectos. Ahora bien, en honor a la verdad, es preciso reconocer que tradicionalmente la creacin de mrgenes de seguridad (que no son sino dar cabida a la expresin estadstica de incertidumbre), no suelen ser bien comprendidos por los directivos de las organizaciones cegados por la idea de reducir los plazos al lmite. Tampoco se suele comprender bien el concepto de recurso ocioso que se puede generar como consecuencia de estos mrgenes, pues se piensa que se estn despilfarrando recursos. Es preciso argumentar adecuadamente estos puntos para establecer que no son despilfarros sino tcnicas adecuadas de direccin de proyecto y que deben ser observados en el conjunto del proyecto, donde se diferencia el tiempo de los recursos.

3.7.4 Reduccin de mrgenes en cada tarea y protectores de cadena.

En el apartado anterior hemos visto cmo la creacin de mrgenes de seguridad o de proteccin en el final de cada subcadena e incluso en el proyecto en su conjunto resultaba una adecuada tcnica de actuacin en la generacin de planes de proyecto, acompaado con las otras medidas de focalizacin de cada recurso en una nica tarea, control del avance por el propio recurso y retroalimentacin de la evolucin frente a la estimacin, etc. Ahora debemos plantearnos que esos mrgenes no pueden concebirse adicionalmente a los ya establecidos en cada tarea. Lo razonable sera alcanzar la situacin ideal en la que cada recurso se estime de modo razonable pero sin la adicin intrnseca de los mrgenes de seguridad a nivel de tarea, pero si esto no es factible y cara a la creacin del plan de proyecto an es posible adoptar algunas medidas, como sera que para cadena de actividades, una vez obtenidas las estimaciones de su duracin (suponemos que con proteccin), se tratara de separar lo que es estimacin de duracin probable de lo que es margen de seguridad para absorber variabilidad, acumular las duraciones de las tareas sin esos mrgenes y prever su planificacin con esa temporalidad, acumulando las protecciones al final de la cadena. Despus se tratara de estimar si esos mrgenes se podran reducir. El aspecto de determinar la duracin que de un modo realista debera tener el margen de seguridad de la cadena de tareas es un asunto para nada menor.

3.8 Cadena Crtica

Como hemos visto en la gestin de proyectos interactan dos limitaciones: tiempo y recursos. Al mismo tiempo, en gestin de proyectos se dan dos fenmenos que alargan el plazo del proyecto: la multitarea y la acumulacin de retrasos. La multitarea es especialmente grave en entornos multiproyectos, pues los recursos ejecutan parcialmente las actividades en los diferentes proyectos, sin terminar ninguna, alargando el tiempo necesario para realizar cada actividad. La teora de restricciones (TOC 8 ), es una filosofa de gestin de organizaciones desarrollada por el fsico israel Dr. Eliyahu M. Goldratt[8]. La TOC asume que el comportamiento organizacional debe estar alineado con la meta de la organizacin, y que slo unos pocos

8 Theory of constraints.

30

recursos, funciones o polticas limitan la ganancia de la misma, de la misma forma que la resistencia de una cadena est limitada por su eslabn ms dbil. La TOC utiliza las mismas herramientas que se utilizan en la ciencia para identificar las limitaciones de las organizaciones, de esta forma, la TOC ha desarrollado varias aplicaciones para afrontar las necesidades de la organizacin dependiendo de dnde reside la restriccin. Debemos recordar en este punto, que un aspecto clave para la concepcin y el desarrollo del proyecto era el plan de proyecto, y que un plan de proyecto vlido y creble no slo es necesario en el arranque del proyecto sino tambin durante todas las fases del desarrollo del mismo, guiando el desarrollo del proyecto a un final feliz, a pesar de las dificultades que se generan por la incertidumbre y la variabilidad del propio proceso. Como se deca, el plan de proyecto no es ni ms ni menos que un modelo para el grupo de recursos y su trabajo, tal modelo debe procurar capturar los aspectos esenciales de comportamiento del proyecto, pero siendo conscientes de lo que realmente es significativo para el modelo. Para comprender cmo se podran construir planes de proyecto vlidos podemos pensar en el componente ms elemental del proyecto, la tarea. Desde las tareas elementales pasaremos a cadenas de tareas, de forma que no nos enfocaremos en la tarea en si misma, sino en los aspectos de variabilidad de stas. Como hemos visto en los anteriores apartados este mtodo se basa en determinar la cadena ms larga de tareas en el proyecto para tratar de prevenir que esta cadena se haga ms larga de lo realmente preciso. En este sentido los mrgenes aadidos a las subcadenas de esta cadena tienen por misin proteger a esta cadena ms larga de retrasos derivados de incertidumbre en las cadenas de tareas ms cortas. Es decir, para decidir dnde colocar mrgenes de proteccin en subcadenas es preciso determinar cul es la cadena ms larga y que debe ser protegida. El mtodo para encontrar la cadena crtica de tareas parte de una red convencional sin mrgenes de proteccin; despus se colocan todas las tareas lo ms tarde posible sin violar ninguna precedencia de las establecidas, al igual que se opera en la nivelacin de recursos, de hecho la motivacin es igual que en aquel caso, es decir, reducir la carga de trabajo en la organizacin que adems puede contribuir a minorar la necesidad de trabajo simultneo entre tareas por parte de los recursos. Asimismo reducimos la necesidad de rehacer trabajos ya realizados por haber comenzado demasiado pronto y haber variado especificaciones, mejorado el conocimiento de los recursos sobre el proyecto, etc. La razn final para retrasar las tareas es que permite facilitar la identificacin de la cadena crtica. El tercer paso para identificar la cadena crtica es eliminar las ocurrencias de cuellos de botella derivados de la insuficiencia de recursos (si dos tareas que tienen que ir simultneamente dependen del mismo nico recurso, esto deber ser identificado y corregido, si queremos construir un plan de proyecto realista y til para realizar simulaciones y comparaciones). Los mecanismos para eliminar estos cuellos de botella pueden ser variados, pero en general supone comenzar por el final de la red y en orden inverso para detectar sobreconsumos de recursos, cuando estos se den y para reducir esa demanda se puede desplazar hacia el principio esa secuencia de tareas (buscando aquel movimiento que genere menor incremento de duracin en la red). Es preciso destacar que los movimientos pueden afectar a toda o a una parte de una cadena, claro, siempre sin violar las prelaciones definidas. En este punto, es decir, cuando al menos inicialmente no hay excesivo consumo de recursos y todas las tareas han sido encajadas en el tiempo desde su configuracin ms tarda se puede definir la cadena crtica de tareas como: la secuencia de tareas que, en esta configuracin, impiden la reduccin del perodo de

31

ejecucin del proyecto. Es decir, hay que recordar que las limitaciones provienen de las relaciones de precedencia, las limitaciones en el consumo de recursos y las cadenas de tareas. En el caso que nos ocupa la limitacin proviene de Gr10/Blue 30/Blue 15/ Red 15, como se indica en la Figura 3.23.

Figura 3.22: Ejemplo de operaciones para separar recursos excedidos en cada instante. Se supone coloreada la demanda de cada recurso. [Tomado de http://www.pdinstitute.com].

Figura 3.23: Diferencias entre la seleccin de tareas PERT/CPM y CADENA CR-TICA. [Tomado de http://www.pdinstitute.com].

32

Una vez identificadas las tareas que pertenecen a la cadena crtica se puede pensar en definir los mrgenes de seguridad, sin ms que establecer los nodos de unin e introducir esos mrgenes. En el plano operativo cabe indicar que una de las ms importantes ventajas de este mtodo es que reduce de modo significativo la necesidad de replanificar el proyecto y aporta estabilidad a la expectativa de demanda de recursos, lo que mejora lateralmente la operativa de los directores funcionales de la organizacin y la de los recursos en s mismos. Adicionalmente el mtodo propone un margen global para el proyecto, al final del mismo y orientado a proteger la fecha de entrega de los productos al cliente.

3.9 Conclusiones
3.9.1 Puntos tratados
Se describen en primer lugar los diagramas de Gantt. Tras una somera introduccin en la que se comentan los antecedentes histricos de esta tcnica de expresin del cronograma, se presentan sus principios bsicos. Se describen los elementos de que consta un diagrama Gantt y se proporciona una primera introduccin a los diferentes tipos de enlaces que pueden presentarse entre tareas. A continuacin se relatan las ventajas e inconvenientes que conlleva la utilizacin de estos diagramas en distintos contextos. Seguidamente, se describen los diagramas PERT. Siguiendo el mismo esquema, se proporciona una somera introduccin en la que se comentan los orgenes de esta tcnica. A continuacin se realiza as mismo una descripcin de los Diagramas de Precedencias; tras lo cual, se presentan sus principios bsicos. Se detallan los elementos constitutivos de estos Diagramas y el distinto significado de los conceptos que conlleva su uso. Se explica el significado de los tiempos tempranos, tardos y de las distintas holguras, proporcionando, en base a un ejemplo, detalles acerca del procedimiento a seguir para su clculo. Conociendo estos conceptos nada impide avanzar un paso ms y comprender el significado, importancia y mtodo de clculo del calendario de ejecucin del proyecto. Se explica en este apartado el significado de las fechas de comienzo y finalizacin tempranas y tardas, as como tambin se pone de relevancia la ventajosa perspectiva que el diagrama de Gantt proporciona sobre este calendario. Despus se progresa para estudiar el efecto que sobre el coste tiene la reduccin del plazo y viceversa, como la reduccin de plazos conlleva un cambio en el coste estimado del proyecto. A continuacin se presenta el problema que presenta la realizacin de proyectos en el contexto de recursos limitados y como, a pesar de que las tcnicas hasta ahora vistas no haban entrado a tratar la influencia de estos aspectos en sus desarrollos, s parece conveniente reparar ahora esa falta y complementar lo visto con la introduccin de estas consideraciones. Se comienza pues planteando el escenario de los recursos limitados. A partir de un proyecto sencillo a modo de ejemplo se determina el perfil de utilizacin de recursos asociado a la configuracin inicial del cronograma. En la presente leccin se han presentado las tcnicas ms comnmente utilizadas en la expresin del cronograma del proyecto: los diagramas de Gantt y el Diagrama de Precedencias. Tambin se han incorporado tcnicas y conceptos ms avanzados para la gestin del tiempo del proyecto (como la teora de la cadena crtica).

33

3.9.2 Conceptos de nueva introduccin o ampliados

Diagrama de red Diagrama de barras o de Gantt Grafo PERT / CPM Diagrama de precedencias Tiempos ms temprano de comienzo y de finalizacin de una actividad Tiempos ms tardo de comienzo y de finalizacin de una actividad Holgura total y libre de una actividad Actividades crticas Camino crtico Calendario de actividades Nivelacin de recursos Algoritmo de BurgessKillebrew Perfil de evolucin de la utilizacin de recursos Sobrecarga de un recurso Asignacin de recursos Cadena crtica

3.9.3 Preguntas abiertas Pregunta 1

Establezca cules son las principales diferencias entre el mtodo PERT y el CPM. Solucin: La principal diferencia entre los dos mtodos se encuentra en la forma de establecer la duracin de las actividades. En el mtodo PERT se establece utilizando mtodos estadsticos (duracin pesimista, ms probable y optimista) y en el mtodo CPM se establece por mtodos deterministas, en base a la experiencia.

Pregunta 2
En la siguiente tabla de precedencias se recogen las actividades precisas para desarrollar cierto proyecto.

Actividades A B C D E

Predecesoras A, B C

Duracin 10 20 8 15 10

34

F G H I J K L M

D D F,G E I H I J,K,L

8 12 22 10 10 4 8 10

En base a esta informacin se pide: 1) 2) 3) 4) Construir el Diagrama de Precedencias que cumple con las relaciones anteriormente definidas Determinar el camino crtico y su duracin Holgura y libre de las actividades A, B, C y L Una vez comenzado el proyecto se constata que la actividad G en lugar de durar 12 semanas ha durado 15 afecta a la finalizacin del proyecto? Cmo? cambia el camino crtico?

Referencias
[1] BENDICHO JOVEN, J. P. Manual de Planificacin y Programacin Para Obras Pblicas y Construccin: Camino Crtico (PERT/CPM). Editorial Rueda, 1999. [2] BRINKMANN, K., and NEWMANN, K. Heuristic procedures for resource constrained project. Journal of Decision Systems 5 (1996), 129155. [3] BURGESS, A., and KILLEBREW, J. Variation in activity level on a cyclical arrow. Journal of Industrial Engineering 13 (1962), 7683. [4] CIOBANU, G. A multiproject programming model with resource levelling. Economic Computation and Economic Cybernetics Studies and Research 3 (1972), 6168. [5] GALBREATH, R. Computer program for levelling resource usage. Journal of the Construction Division 91 (1965), 107124. [6] LEACHMAN, R. Multiple resource levelling in construction systems through variation ofactivity intensities. Naval Research Logistics Quarterly 39 (187-198), 1983. [7] MATEOS-PERERA, J. La Programacin en la Construccin (2a Edicin). El PERT en versin completa. Editorial Bellisco, 2003. [8] MODER, J., PHILIPS, C., and DAVIS, E. Project management with CPM, PERT and precedence diagramming. Van Nostrand Reinhold, 1968. [9] NEWMANN, K., and MORLOCK, M. Operations Research. Hanser, Mnchen, 1993. [10] ORDIERES MER, J. B. Programacin de Proyectos. Servicio de Publicaciones de la Universidad de La Rioja, 1999. [11] ROMERO LPEZ, C. Tcnicas de Programacin y Control de Proyectos. Editorial Pirmide, 2002.

35

[12] SEIBERT, J., and EVANS, G. Time constrained resource levelling. Journal of Construction Engineering and Management 117 (1991), 503520. [13] TAKAMOTO, M., YAMADA, N., KOBAYASHI, Y., and NONAKA, H. Zero-one quadratic programming algorithm for resource leveling in multi-projectmulti-resource scheduling. Decision Sciences 6 (1995), 525 540. [14] WIEST, J., and LEVY, F. A management guide to PERT/CPM. Prentice-Hall. Englewood Cliffs, NJ, 1969.

36