Manual para la gestión de proyectos - Actividades Formativas, Diapositivas de Gestión de Proyectos

¡Descarga Manual para la gestión de proyectos - Actividades Formativas y más Diapositivas en PDF de Gestión de Proyectos solo en Docsity!

Manual

para la gestión de proyectos

Psicóloga consultora

Pilar Montoya Molina

Universidad de Almería

Servicio de Organización y Racionalización Administrativa

Actividades

Formativas

1. LA GESTIÓN DE PROYECTOS

Si les preguntamos a varios profesionales experimentados cuál es su objetivo fundamental al ejecutar un proyecto, casi todos responderán: “¡Hacer ese trabajo!” Ése es el credo universal del profesional de proyectos. Y si les damos algunos momentos más para reflexionar sobre el tema, probablemente ampliarán así su respuesta: “Mi objetivo básico es hacer el trabajo dentro del plazo fijado, dentro del presupuesto y según las especificaciones”.

La gran mayoría de los especialistas en proyectos identifica estas tres condiciones como importantes parámetros de proceso de dirección por proyecto, y por eso se le ha dado un nombre al conjunto: la triple limitación. Esas limitaciones constituyen el punto focal de la atención y la energía del especialista en proyectos. El jefe de proyecto está dirigido a llevar a cabo un proyecto lo más eficazmente posible teniendo en cuenta las limitaciones de tiempo, dinero (y los recursos que con él se pueden comprar) y especificaciones.

A lo largo de los años se fue elaborando todo un completo juego de herramientas para que los gestores de proyecto puedan hacer frente a la triple limitación.

Para encarar la restricción impuesta por el tiempo, los especialistas en proyectos establecen plazos y trabajan con horarios y agendas. Cuentan para ello con ciertas refinadas herramientas de planificación asistida por ordenador: por ejemplo, PERT/CMP, GERT y VERT.

Las limitaciones económicas se manejan por medio de presupuestos. En primer lugar, se hacen estimaciones de cuánto costará el proyecto. Una vez que el proyecto está en marcha, se controla constantemente el presupuesto, para ver si los costes se les están yendo de las manos a los responsables. Con dinero se compran recursos, y los managers de proyecto han desarrollado varias herramientas para manejar los recurso materiales y humanos: por ejemplo, diagramas de cantidad de recursos, diagramas de recursos Gantt, diagramas de responsabilidad lineal.

De las tres limitaciones básicas, la más difícil de manejar es la de las especificaciones. Las especificaciones describen cómo debe ser el producto de nuestro proyecto y qué debe hacer. Por ejemplo, si estamos construyendo un bote, una especificación que tal vez tendríamos que respetar sería que el bote tuviera 5 metros de largo. Si estamos diseñando un programa de procesamiento de textos, tal vez tendríamos que luchar con una especificación que establece que los usuarios deben poder usar el sistema con sólo tres días de entrenamiento.

El problema de las especificaciones es que son notoriamente difíciles de establecer y de controlar. No basta, por ejemplo, con que las especificaciones definan un producto técnicamente superior; también deben estar dirigidas a satisfacer a los clientes, aun cuando ello resulte una suboptimización del nivel técnico.

3. EL CICLO DE VIDA DEL PROYECTO

Los proyectos tienen comienzo, medio y fin. Este dato puede parecer evidente, pero si se trabaja en gestión de proyectos, el momento del ciclo vital en que se encuentra será de la mayor importancia, ya que influirá sobre lo que deberá hacer y sobre las opciones que se le presentarán.

Hay diversas maneras de considerar el ciclo vital del proyecto. Una de las más comunes estima que se divide en cuatro grandes fases: concepción del proyecto, planificación, implementación y finalización. En las ciencias de la información es muy usado el enfoque que establece seis fases: reconocimiento de las necesidades, definición de los requerimientos, diseño del sistema, implementación, verificación y mantenimiento.

El ciclo vital de proyecto

Nivel de recurso (por ejemplo, Euros)

Tiempo

Figura 1

Nivel de recurso (por ejemplo, Euros)

Tiempo

Figura 2

La Figura 1 presenta un enfoque gráfico del ciclo vital de proyecto. Esta figura muestra que, a lo largo de su vida, los proyectos consumen diversos niveles de recursos (por ejemplo, dinero, gente, materiales).

En la Figura 1 el proyecto se acelera rápidamente y se desacelera con lentitud. Esto podría ilustrar un típico proyecto de investigación de mercado, donde hay una gran cantidad de actividad inicial, como recolección de datos de los consumidores por medio de cuestionarios y entrevistas. Una vez reunidos los datos, el consumo de recurso baja gradualmente, a medida que se analizan los datos y se redactan las conclusiones. En la Figura 2, por el contrario, se observa un incremento gradual de la actividad, hasta que el proyecto llega a su cima, y luego un rápido final. Esto suele ocurrir con los proyectos de investigación científica, en los que una parte importante del tiempo total suele estar dedicada a formular hipótesis de trabajo, diseñar un experimento, poner a punto equipamiento, etcétera. La actividad del proyecto alcanza un pico cuando el experimento ha sido efectivamente realizado y se han observado los datos resultantes.

Independientemente de cómo se considere el ciclo vital, el punto más importante para tener en cuenta es que a lo largo de su vida todo proyecto es dinámico, es un organismo en continuo desenvolvimiento.

Dinámica del ciclo de vida del proyecto

Necesidades

Selección del proyecto

Planificación del proyecto

Implementación del proyecto

Control del proyecto

Evaluación Evaluación Evaluación

Terminación

Figura 3

B. PLANIFICACIÓN

El plan es un mapa de ruta que nos indica cómo ir de un punto a otro. La planificación se desarrolla especialmente para el proyecto. Al comienzo, es común tener un preplán informal, es decir, una idea general de lo que el proyecto demandaría, si resolviéramos emprenderlo. Estos preplanes pueden asumir formas diversas. Por ejemplo, una propuesta es, en cierto modo, un preplán, ya que traza un mapa de ruta para el proyecto. De la misma manera, los estudios de viabilidad, el estudio de casos y los análisis competitivos son, de alguna forma, preplanes.

Todas estas herramientas de trabajo desempeñan algún papel en la selección de proyectos, porque les sirven a quienes toman las decisiones para hacerse una idea de lo que implicará el proyecto y de cuáles serán los beneficios que reportará. Por ende, la selección del proyecto se basa, en gran parte, sobro estos preplanes.

Una vez que hemos decidido apoyar un proyecto, empieza una detallada planificación formal. Se identifican los hitos del proyecto, y se fijan las tareas y su interdependencia. Hay muchísimas herramientas para ayudar al jefe de proyecto a diseñar el plan formal: estructuras de iniciación de los trabajos, diagramas de Gantt, diagramas de red, diagramas de asignación de recurso, diagramas de cantidad de recursos, diagramas de responsabilidad, distribuciones de costes acumulativos, etcétera.

A medida que el proyecto avanza, el plan puede sufrir continuas modificaciones, que reflejarán las circunstancias imprevistas que se presenten y las respuestas que se les dé. Rara vez los planes de proyecto son formulaciones estáticas de cómo deben ser las cosas; son, por el contrario, instrumentos dinámicos que le permiten al equipo del proyecto manejar el cambio ordenadamente. De hecho, es preciso señalar que todos los planes son, en alguna medida, suposiciones. Los buenos planes son buenas suposiciones; los malos planes son malas suposiciones. Lo importante es darse cuenta de que, aun con buenos planes, cada vez que se tropiece con el mundo real habrá que modificar el plan.

C. EJECUCIÓN O IMPLEMENTACIÓN

Una vez diseñado el plan formal, estamos en condiciones de desarrollar el proyecto.

En cierto sentido, la ejecución está en el corazón mismo de todo proyecto, ya que implica hacer las cosas que hay que hacer (tal como se las ha formulado en el plan del proyecto) a fin de producir algo que satisfaga las necesidades de los usuarios.

La manera de implementar el proyecto depende de su naturaleza específica. En un proyecto de construcción, se echan los cimientos, se levantan andamios, etcétera. En un proyecto de desarrollo de una droga, se prueban los nuevos componentes, primero en el laboratorio y después clínicamente. En un proyecto de investigación de mercado se miden las actitudes de los clientes por medio de cuestionarios y entrevistas.

D. CONTROL

A medida que se implementa el proyecto, sus jefes controlan continuamente el progreso. Examinan lo que se hizo hasta ese momento, estudian una vez más el plan y luego determinan si hay discrepancias importantes entre ambas cosas. En gestión de proyecto, esas discrepancias son llamadas variaciones.

En gestión de proyectos hay por lo menos una certeza absoluta: que habrá variaciones. No hemos llegado aún a dominar el campo de la predicción hasta el punto de tener una idea precisa de lo que esconde el futuro; y mientras el futuro siga siendo nebuloso a causa de la incertidumbre, nuestros planes de proyecto serán imperfectos. Es preciso no olvidar que el plan es una suposición, una conjetura. Por lo tanto, al controlar un proyecto, la pregunta que hay que formular no es: “¿Tenemos variaciones?” sino: “¿Las variaciones que tenemos son aceptablemente pequeñas?”

Ahora bien, los niveles de variaciones estimados como aceptables son determinados al iniciar el proyecto.

Para el proceso de control es fundamental la recolección y el análisis de los datos sobre el progreso de proyecto. Una vez que disponen de esa información, los jefes de proyecto pueden seguir diversos cursos de acción. Por ejemplo, si su programa se está deslizando de manera inaceptable, pueden decidir acelerar ciertas tareas críticas, dedicándoles más recursos. Si descubren que para determinada serie de tareas el equipo ha gastado un presupuesto 40 por ciento menor que el planteado, tal vez decidan investigar esa variación, ya que el menor gasto indica que no se ha estado realizando el trabajo o que se le ha recortado demasiado.

E. EVALUACIÓN

Todo proyecto atraviesa diversas evaluaciones: evaluaciones técnicas, como, por ejemplo, las revisiones preliminares del diseño (RPD) [preliminary design reviews (PDR)] y las revisiones críticas del diseño (RCD) [critical design reviews (CDR)], las apreciaciones del personal, las revisiones el MBO (management by objectives) y las auditorías.

Al igual que el control, la evaluación cumple una importante función de realimentación. Sin embargo, entre evaluación y control hay varias diferencias importantes.

El control implica una continua verificación de la marcha del proyecto, mientras que la evaluación sólo significa la realización de exámenes periódicos.

El control se concentra sobre los detalles de lo que está ocurriendo en el proyecto, mientras que la evaluación se ocupa más bien del panorama general.

Las actividades de control son responsabilidad del jefe de proyecto, mientras que las evaluaciones son realizadas por un individuo o un grupo que no trabaja directamente en el proyecto (a fin de mantener la objetividad).

Principales consecuencias de la evaluación intermedia

¿Estamos alcanzando nuestros objetivos básicos?

No Sí

¿Nuestros objetivos básicos todavía son válidos?

¿Nuestros objetivos básicos todavía son válidos?

No Sí No Sí

Adaptar el proyecto para alcanzar los objetivos

Continuar con el proyecto

¿Queremos cambiar nuestros objetivos básicos?

¿Queremos cambiar nuestros objetivos básicos?

No Sí No Sí

Cambiar los objetivos y continuar con el proyecto

Cambiar los objetivos y continuar con el proyecto

Terminar el proyecto

Terminar el proyecto

Figura 3.1.

Evidentemente, la evaluación al final del proyecto no tendrá influencia sobre el curso futuro del proyecto, ya que éste ha concluido. El papel fundamental de la evaluación al final del proyecto es servir como ejercicio para verificar lo aprendido. Aplicando ese conocimiento a otros proyectos, podremos aprovechar lo que hemos aprendido, tanto de nuestros aciertos como de nuestros errores.

Lamentablemente, las evaluaciones suelen ser poco eficaces, ya que intimidan a las personas que son evaluadas. Y, en realidad, la evaluación contiene una suerte de amenaza, destinada precisamente a hacer aflorar los problemas.

Lo importe, sin embargo, no es identificar a las personas problemáticas, que deben ser sancionadas, sino identificar los problemas mientras todavía son pequeños y manejables, antes de que se conviertan en monstruos y hagan estragos en nuestro proyecto.

Es frecuente que las personas evaluadas se formulen una serie de preguntas, aunque no se atrevan a enunciarlas en voz alta: ¿Quién eligió a los evaluadores? ¿Son competentes? ¿Qué instrucciones tienen? ¿Conocen el contexto en el que se desarrolla el proyecto? ¿Quién los evaluará a ellos? Para que las evaluaciones sean eficaces, es preciso reducir al mínimo posible el nivel de amenaza que contienen.

F. TERMINACIÓN

Todos los proyectos tienen un final. A veces ese final es abrupto y prematuro, como cuando se aborta a poco de haberlo iniciado. No obstante, es de desear que el proyecto tenga una muerte natural. De todos modos, cuando los proyectos terminan, las responsabilidades del jefe del proyecto continúan: hay que realizar diversas tareas finales. La índole de esas tareas depende del carácter del proyecto. Si se usó equipamiento, es preciso tenerlo en cuenta y, si es posible, destinarlo a nuevos usos. Asimismo, hay que asignar nuevas tareas a los miembros del equipo de proyecto cuando se trata de un proyecto contratado, hay que determinar si los productos satisfacen los términos del contrato. A veces, se escriben informes finales y se logra el contacto con los usuarios para determinar si están satisfechos con los productos.

De inmediato aparece la cuestión del mantenimiento. Después de diseñar y poner en marcha un sistema, hay que mantenerlo. El mantenimiento puede asumir formas diversas, eliminación de fallas, ampliación, integración con otros sistemas, verificación periódica del sistema para determinar si está funcionando correctamente. El mantenimiento de los sistemas es muy importante. Se ha estimado, por ejemplo, que entre 60 y 70 por ciento del coste del ciclo vital de los sistemas de computación se dedica a mantenimiento (Boehm, 1987).

Si bien el mantenimiento tiene una importancia decisiva, no está incluido en el ciclo vital del proyecto. Y hay una buena razón. Como se recordará, los proyectos son tareas que se cumplen dentro de un tiempo finito. Tienen un principio y un fin claramente definidos. El mantenimiento, en cambio es permanente y de duración indefinida. Un acto específico de mantenimiento (por ejemplo, la revisión de la política de compras de la empresa) puede ser considerado como proyecto, pero en realidad es un emprendimiento separado y diferente del proyecto inicial que produjo la política de compras original.

Costes (^) Coste no repetitivo (de implementación) Coste repetitivo (de operación)

Tiempo del aprendizaje

Tiempo

Gráfico 4

5. EL PLAN DEL PROYECTO

Un plan de proyecto es básicamente un mapa de ruta que nos informa cómo trasladarnos desde A hasta B. Por lo general, consideramos que el plan es el punto de partida de un proyecto: un comienzo, una guía para los desarrollos futuros. No obstante, es importante reconocer que un plan es consecuencia de un gran esfuerzo. El plan surge gradualmente, a medida que se definen las necesidades, se especifican los requerimientos, se hacen predicciones acerca del futuro y se estiman los recursos disponibles. Sólo después de que éstas y otras cuestiones han sido meditadas, comprendidas, clarificadas, desmenuzadas, reelaboradas y nuevamente clarificadas, podremos trazar finalmente un plan que nos sirva como mapa de carreteras. Por lo general, los planes son tridimensionales.

Se concentran en el tiempo, el dinero y los recursos humanos y materiales. A lo largo del tiempo se han elaborado instrumentos de planificación para las tres dimensiones.

La dimensión temporal se maneja por medio de agendas. Existe una amplia gama de instrumentos (algunos sofisticados, otros simples) para la elaboración de agendas y horarios. Estos instrumentos nos permiten determinar cuándo deben comenzar las diferentes tareas, cuándo se alcanzarán ciertas metas, etcétera. En este sentido analizaremos dos de las herramientas de programación más conocidas: los diagramas de Gantt y las redes de programación.

La dimensión del dinero se maneja por medio de presupuestos que nos muestran cómo se distribuirán los fondos de nuestro proyecto. La necesidad de elaborar presupuestos es una realidad universal en las organizaciones (sean privadas, públicas, académicas o sin fines de lucro) se esfuerza especialmente por confeccionar buenos presupuestos. Si bien hay principios universales que sustentan la buena práctica de la elaboración de presupuestos, la manera específica de formularlos varía considerablemente de una organización a otra. La confección de un presupuesto es algo muy personal, que refleja la filosofía, las actitudes y las estructuras de la organización.

La dimensión de los recursos humanos y materiales se ocupa de la mejor manera de asignar nuestros limitados recursos en un proyecto. Existen muchas herramientas para realizar la asignación de recursos. Entre ellos destacan los gráficos de Gantt de recurso, las hojas de cálculo de recursos, las matrices de recurso y los gráficos de cantidad de recursos.

5.1. ¿CUÁNTO DEBEMOS PLANIFICAR Y CONTROLAR?

Cuando una persona acomete la planificación o el diseño de la metodología de control de un proyecto, tarde o temprano debe formularse la siguiente pregunta: “¿Cuánto debemos planificar y controlar?” No hay una respuesta óptima para esta pregunta. A primera vista, parecería que simplemente tendríamos que planificar mucho, a fin de minimizar la incertidumbre del proyecto y controlarlo totalmente. Tendemos entonces a expresar nuestra idea en frases como las siguientes: “Toda planificación es poca” y “Un proyecto con controles débiles es un proyecto fuera de control”.

Lamentablemente, la planificación y el control tienen un coste. La siguiente fórmula expresa bien la relación entre los costes del proyecto y los costes de la planificación: Costes del proyecto = Coste de producción + Costes administrativos.

Lo que esta fórmula expresa es que los incrementos en los costes de la planificación y el control (es decir, los costes administrativos) elevan los costes totales del proyecto. La fórmula ilustra también el hecho de que los incrementos en los costes de planificación y control significan que estamos gastando proporciones cada vez menores de nuestro presupuesto en actividades directamente productivas.

¿Qué proporción del presupuesto del proyecto debe dedicarse a los costes de planificación y control? ¿El 10 por ciento? ¿El 20 por ciento? ¿El 50 por ciento? ¿Más? La respuesta que demos a esta pregunta estará vinculada con una serie de factores importantes:

Complejidad del proyecto. Tamaño del proyecto. Nivel de incertidumbre. Requerimientos organizacionales.

5.2. INSTRUMENTOS DE PLANIFICACIÓN Y CONTROL: EL PLAN

Gran parte del trabajo de planificación consiste en determinar la relación de las diferentes tareas entre sí y luego programar esas tareas a fin de que el proyecto pueda ser realizado de manera eficiente y lógica. A lo largo de los años se fueron elaborando muchos instrumentos de trabajo que han convertido a esta tarea casi en una rutina. Existen tres instrumentos de trabajo que satisfacen prácticamente todas las necesidades para programar cualquier proyecto, desde el más simple hasta el más complejo, el diagrama de Gantt y la red de planificación.

La Figura 6 no es más que una variante de un diagrama o gráfico de barras. Leyendo los datos del tiempo en el eje horizontal, podemos conocer las fechas que se han planificado para iniciar y dar término a las diferentes tareas. Cuando se agregan las fechas reales de iniciación y finalización, el diagrama de Gantt es útil también para el control del proyecto. Luego podemos comparar visualmente nuestro plan con los datos reales, y eso nos permitirá determinar la magnitud de la variación en el organigrama que tengamos en nuestro proyecto.

En la Figura 5, por ejemplo, vemos que nuestro proyecto está atrasado desde el comienzo mismo, cuando la Tarea 1 empieza más tarde que lo planeado. Nótese que la duración real de la Tarea 1 es igual a la duración planeada, de modo que el deslizamiento del organigrama para esta tarea se explica íntegramente por el hecho de que empezó tarde. En el caso de la Tarea 2, es evidente que esta tarea no sólo empezó tarde, sino que su realización se demoró más que lo planeado. Aquí el desplazamiento del organigrama responde tanto a un inicio tardío como a una realización demorada, que alargó la duración de la tarea.

La Figura 6 presenta un enfoque distinto del diagrama de Gantt. Los hechos básicos son idénticos a los que aparecen en el gráfico de barras, pero se presentan de un modo diferente. En este enfoque alternativo, los datos específicos están representados en forma de triángulos: triángulos con el vértice hacia arriba para las fechas de inicio y triángulos con vértice hacia abajo para las fechas de finalización: las fechas planeadas están representadas con triángulos blancos y las fechas reales, con triángulos sombreados.

Si se comparan los dos diagramas de las Figuras 5 y 6, se advertirá que ambos expresan lo mismo. También en el caso de la Figura 6, vemos que la tarea 1 empieza y termina tarde, pero que la duración de esa tarea es la que se planificó. La Tarea 2 empieza tarde, se prolonga más de lo planeado y termina muy tarde.

Los diagramas de Gantt se usan mucho para la planificación y el control de los organigramas en proyecto. Muchos directores de proyecto los usan sin saber siquiera que esos diagramas tienen un nombre especial. Su popularidad reside en su simplicidad. Es fácil construirlos y es fácil comprenderlos. No hace falta ningún entrenamiento especial para aprender a usarlos ni tampoco se requiere un equipamiento complejo para construirlos: sólo una hoja de papel para diagramas, un lápiz y una regla. Estos diagramas son especialmente útiles para examinar la variación del organigrama, ya que transmiten dramáticamente todo deslizamiento del proyecto.

5.2.2. Red de organigrama de PERT/CMP.

La principal desventaja de los diagramas de Gantt es que, si bien representan las fechas de iniciación y de terminación de las tareas, no muestran las consecuencias generales de las modificaciones del organigrama en cada tarea específica. Es decir, el diagrama de Gantt contempla las tareas como si fueran actividades independientes, no tiene en cuenta que están interrelacionadas.

A fines de la década del ’50, se desarrollaron simultáneamente dos técnicas que permiten a los grupos de trabajo de un proyecto examinar las consecuencias que tiene sobre el organigrama general del proyecto la modificación de las fechas de iniciación y de terminación. Una de las técnicas, desarrollada para el programa del misil Polaris, fue llamada PERT (Program Evaluation and Review Technique). La otra, desarrollada por DuPont fue llamada Método del Camino Crítico (CPM). Ambos métodos se basan en diagramas de flujo que parecen similares, pero que contienen un enfoque diferente de los cálculos del organigrama.

A lo largo de los años se han dedicado muchísimas horas a discutir los méritos de un método sobre el otro. Pero actualmente se establecen cada vez menos distinciones entre ambos. De hecho, en el software de planificación de los microordenadores que se ha hecho popular, surgió un híbrido ampliamente aceptado, el PERT/CMP, que aprovecha las mejores características de cada uno de los dos métodos.

5.2.2.1. Cómo construir una red PERT/CMP

El primer paso para construir una red PERT/CMP consiste en crear una estructura de análisis de trabajo (Work Breakdown Sructure) (WBS) para el proyecto. La Tabla 7 muestra una WBS muy simple para un proyecto que consiste en prepararse para un picnic.

Estructura de división el trabajo para el proyecto de realización de un picnic (Tabla 7)

Tarea Duración Agentes

1. Comienzo 0
2. Preparar té helado 15 Jorge
3. Preparar emparedados 10 Marta
4. Preparar fruta 2 Marta
5. Preparar canasta 2 Marta
6. Acondicionar mantas 2 Jorge
7. Acondicionar aparejos deportivos

3 Marta

8. Cargar el auto 4 Jorge
9. Cargar gasolina 6 Jorge
10. Trasladarse al lugar del picni 20 Marta
11. Fin 0

2

Actividad en red de Nodo PERT/CPM – En diagrama de NODO

15

Preparar té

helado

Acondicionarmantas (Jorge)

Comienzo

4

2

Prepararcanasta(Marta)

Cargar el auto

(Jorge)

6

Llenar eldepósito^ (Jorge)

20

Dirigirse al lugar del pinic

(Marta)

Fin

10

Preparar emparedados

(Marta)

2

Preparar fruta

(Marta)

3

Clave:

Acondicionar

aparejosdeportivos

Sendero crítico

Figura 8

Cálculo del retardo

Tarea

Inicio temprano

Inicio tardío

Retardo

Preparar té helado

Preparar emparedados

Preparar fruta

Preparar canasta

Acondicionar mantas

Acondicionar aparejos deportivos

Cargar el coche

Llenar el depósito

Dirigirse al lugar del picnic

Figura 9

5.2.2.2. El camino crítico

Hay un concepto de la mayor importancia para poder comprender lo que es una red PERT/CMP: el concepto de camino crítico.

El camino crítico es una red de planificación, es la vía que requiere más tiempo para ser recorrida. En la Figura 8 consideremos los dos caminos que nos llevan desde “Empezar” hasta “Preparar canasta”. Se requieren quince minutos para completar el recorrido superior “Preparar té helado”, mientras que el camino inferior, que se compone de dos tareas (“Preparar emparedados” y “Preparar fruta”), puede completarse en doce minutos.

Teniendo en cuenta el diseño de la red, el tiempo más largo que puede transcurrir entre “Empezar” y “Preparar canasta” es quince minutos. Esto significa que el camino o recorrido inferior tiene incorporado tres minutos de retraso.

Como el camino crítico es siempre el más largo, no tiene retraso alguno. De hecho, si se produce un deslizamiento del organigrama a lo largo del camino crítico, ese deslizamiento se reflejará en el proyecto en general. Así, si para ser completada, una tarea en el camino crítico requiere tres minutos más de lo que se previó, el organigrama general del proyecto se atrasará tres minutos. Es esta característica del camino crítico (su inflexibilidad con respecto al deslizamiento del organigrama) la que le ha dado el nombre.

Como las actividades que no se inscriben en el camino crítico permiten cierto retraso, pueden tolerar cierto retraso del organigrama.

En la figura 8 el camino crítico para el proyecto está representado por una línea gruesa. Para descubrir el tiempo necesario para completar el proyecto, bastará con que sumemos los tiempos parciales que se requieren para realizar cada una de las tareas que figuran en el camino crítico. En nuestro ejemplo, el tiempo necesario para realizar todo el proyecto es 50 minutos (15 + 2 + 3

• 4 + 6 + 20).