stringtranslate.com

Técnica de evaluación y revisión de programas

Diagrama de red PERT para un proyecto de siete meses con cinco hitos (10 a 50) y seis actividades (A a F).

La técnica de evaluación y revisión de programas ( PERT ) es una herramienta estadística utilizada en la gestión de proyectos , que fue diseñada para analizar y representar las tareas involucradas en la finalización de un proyecto determinado .

El PERT fue desarrollado originalmente por Charles E. Clark para la Marina de los Estados Unidos en 1958; se utiliza comúnmente junto con el método de la ruta crítica (CPM), que también se introdujo en 1958. [1]

Descripción general

PERT es un método para analizar las tareas involucradas en la finalización de un proyecto, especialmente el tiempo necesario para completar cada tarea, y para identificar el tiempo mínimo necesario para completar el proyecto total. Incorpora la incertidumbre al hacer posible programar un proyecto sin conocer con precisión los detalles y la duración de todas las actividades. Está más orientado a los eventos que al inicio y la finalización, y se utiliza más para proyectos donde el tiempo es la principal limitación en lugar del costo. Se aplica a proyectos de infraestructura complejos, no rutinarios, de muy gran escala y únicos, así como a proyectos de I+D .

PERT ofrece una herramienta de gestión, [2] : 497  que se basa "en diagramas de flechas y nodos de actividades y eventos : las flechas representan las actividades o el trabajo necesario para alcanzar los eventos o nodos que indican cada fase completada del proyecto total". [3]

PERT y CPM son herramientas complementarias, porque "CPM emplea una estimación de tiempo y una estimación de costo para cada actividad; PERT puede utilizar tres estimaciones de tiempo (optimista, esperada y pesimista) y ningún costo para cada actividad. Aunque estas son diferencias claras, el término PERT se aplica cada vez más a toda la programación de ruta crítica". [3]

Historia

PERT se desarrolló principalmente para simplificar la planificación y programación de proyectos grandes y complejos. Fue desarrollado para la Oficina de Proyectos Especiales de la Marina de los EE. UU. para apoyar el proyecto del submarino nuclear Polaris de la Marina de los EE. UU. [4] Encontró aplicaciones en toda la industria. Un ejemplo temprano son los Juegos Olímpicos de Invierno de 1968 en Grenoble , que utilizaron PERT desde 1965 hasta la apertura de los Juegos de 1968. [5] Este modelo de proyecto fue el primero de su tipo, un renacimiento de la gestión científica de Frederick Taylor y luego refinado por Henry Ford ( fordismo ). El CPM de DuPont se inventó aproximadamente al mismo tiempo que PERT.

Informe resumido de PERT, fase 2 , 1958

Inicialmente PERT significaba Program Evaluation Research Task, pero en 1959 cambió de nombre. [4] Se había hecho público en 1958 en dos publicaciones del Departamento de la Marina de los EE. UU., tituladas Program Evaluation Research Task, Summary Report, Phase 1. [6] y Phase 2. [7] ambas escritas principalmente por Charles F. Clark. [1] En un artículo de 1959 en The American Statistician , Willard Fazar , Jefe de la División de Evaluación de Programas, Oficina de Proyectos Especiales, Marina de los EE. UU., dio una descripción detallada de los conceptos principales de PERT. Explicó:

Mediante una computadora electrónica, la técnica PERT procesa datos que representan los principales logros finitos (eventos) esenciales para alcanzar los objetivos finales; la interdependencia de esos eventos; y estimaciones del tiempo y el rango de tiempo necesario para completar cada actividad entre dos eventos sucesivos. Tales expectativas de tiempo incluyen estimaciones de "tiempo más probable", "tiempo optimista" y "tiempo pesimista" para cada actividad. La técnica es una herramienta de control de gestión que evalúa la perspectiva de cumplir los objetivos a tiempo; destaca las señales de peligro que requieren decisiones de gestión; revela y define tanto la metódica como la holgura en el plan de flujo o la red de actividades secuenciales que deben realizarse para cumplir los objetivos; compara las expectativas actuales con las fechas de finalización programadas y calcula la probabilidad de cumplir con las fechas programadas; y simula los efectos de las opciones para la decisión, antes de la decisión. [8]

Guía PERT para uso gerencial , junio de 1963

Diez años después de la introducción del PERT, la bibliotecaria estadounidense Maribeth Brennan compiló una bibliografía seleccionada con alrededor de 150 publicaciones sobre PERT y CPM, todas publicadas entre 1958 y 1968. [3]

Para la subdivisión de las unidades de trabajo en PERT [9] se desarrolló otra herramienta: la Estructura de Desglose del Trabajo . La Estructura de Desglose del Trabajo proporciona "un marco para la interconexión completa, la Estructura de Desglose del Trabajo se introdujo formalmente como el primer elemento de análisis para llevar a cabo PERT/CPM básico". [10]

Terminología

Eventos y actividades

En un diagrama PERT, el bloque de construcción principal es el evento , con conexiones con sus eventos predecesores y sucesores conocidos.

Además de los eventos, PERT también rastrea actividades y subactividades:

Tiempo

PERT define cuatro tipos de tiempo necesarios para realizar una actividad:

Herramientas de gestión

PERT proporciona una serie de herramientas para la gestión con determinación de conceptos, tales como:

Implementación

El primer paso para programar el proyecto es determinar las tareas que requiere el proyecto y el orden en que deben completarse. El orden puede ser fácil de registrar para algunas tareas (por ejemplo, cuando se construye una casa, se debe nivelar el terreno antes de poder colocar los cimientos) mientras que es difícil para otras (hay dos áreas que necesitan nivelarse, pero solo hay suficientes excavadoras para hacer una). Además, las estimaciones de tiempo generalmente reflejan el tiempo normal, sin prisas. Muchas veces, el tiempo requerido para ejecutar la tarea se puede reducir por un costo adicional o una reducción en la calidad.

Ejemplo

En el siguiente ejemplo hay siete tareas, etiquetadas de A a G. Algunas tareas se pueden realizar simultáneamente ( A y B ), mientras que otras no se pueden realizar hasta que se complete la tarea predecesora ( C no puede comenzar hasta que se complete A ). Además, cada tarea tiene tres estimaciones de tiempo: la estimación de tiempo optimista ( o ), la estimación de tiempo más probable o normal ( m ) y la estimación de tiempo pesimista ( p ). El tiempo esperado ( te ) se calcula utilizando la fórmula ( o + 4 m + p ) ÷ 6. [2] : 512–513 

Una vez completado este paso, se puede dibujar un diagrama de Gantt o un diagrama de red.

Diagrama de Gantt creado con Microsoft Project (MSP). Nótese que (1) la ruta crítica está en rojo, (2) la holgura son las líneas negras conectadas a actividades no críticas, (3) dado que el sábado y el domingo no son días laborables y, por lo tanto, están excluidos del cronograma, algunas barras del diagrama de Gantt son más largas si abarcan un fin de semana.
Diagrama de Gantt creado con OmniPlan . Nótese que (1) la ruta crítica está resaltada, (2) el margen de tiempo no está indicado específicamente en la tarea 5 (d), aunque se puede observar en las tareas 3 y 7 (b y f), (3) dado que los fines de semana se indican con una línea vertical delgada y no ocupan espacio adicional en el calendario laboral, las barras en el diagrama de Gantt no son más largas o más cortas cuando se trasladan o no a un fin de semana.

Próximo paso: crear un diagrama de red a mano o mediante un software de diagramas

Un diagrama de red se puede crear a mano o utilizando un software de diagramas. Hay dos tipos de diagramas de red, actividad en flecha ( AOA ) y actividad en nodo ( AON ). Los diagramas de actividad en nodo son generalmente más fáciles de crear e interpretar. Para crear un diagrama AON, se recomienda (pero no es obligatorio) comenzar con un nodo llamado inicio . Esta "actividad" tiene una duración de cero (0). Luego, dibuja cada actividad que no tenga una actividad predecesora ( a y b en este ejemplo) y conéctalas con una flecha desde inicio hasta cada nodo. A continuación, dado que tanto c como d enumeran a como actividad predecesora, sus nodos se dibujan con flechas que provienen de a . La actividad e se enumera con b y c como actividades predecesoras, por lo que el nodo e se dibuja con flechas que provienen tanto de b como de c , lo que significa que e no puede comenzar hasta que se hayan completado tanto b como c . La actividad f tiene a d como actividad predecesora, por lo que se dibuja una flecha que conecta las actividades. Del mismo modo, se dibuja una flecha de e a g . Dado que no hay actividades que vengan después de f o g , se recomienda (aunque nuevamente no es obligatorio) conectarlas a un nodo etiquetado como finish .

Diagrama de red creado con Microsoft Project (MSP). Observe que la ruta crítica está en rojo.
Un nodo como este se puede usar para mostrar el nombre de la actividad, la duración, ES, EF, LS, LF y la holgura.

Por sí solo, el diagrama de red que se muestra arriba no ofrece mucha más información que un diagrama de Gantt; sin embargo, se puede ampliar para mostrar más información. La información que se muestra con más frecuencia es la siguiente:

  1. El nombre de la actividad
  2. El tiempo de duración esperado
  3. La hora de inicio temprana (ES)
  4. La hora de finalización anticipada (EF)
  5. La hora de inicio tardía (LS)
  6. El tiempo de finalización tardía (LF)
  7. La holgura

Para determinar esta información se supone que se dan las actividades y los tiempos de duración normales. El primer paso es determinar el ES y el EF. El ES se define como el EF máximo de todas las actividades predecesoras, a menos que la actividad en cuestión sea la primera actividad, para la cual el ES es cero (0). El EF es el ES más la duración de la tarea (EF = ES + duración).

Salvo que se produzcan acontecimientos imprevistos , el proyecto debería tardar 19,51 días laborables en completarse. El siguiente paso es determinar el inicio tardío (LS) y el final tardío (LF) de cada actividad. Esto mostrará eventualmente si hay actividades que tienen holgura . La LF se define como el LS mínimo de todas las actividades sucesoras, a menos que la actividad sea la última actividad, para la cual el LF es igual al EF. El LS es el LF menos la duración de la tarea (LS = LF − duración).

Próximo paso, determinación de la ruta crítica y posible holgura

El siguiente paso es determinar la ruta crítica y si alguna actividad tiene holgura . La ruta crítica es la ruta que tarda más en completarse. Para determinar los tiempos de la ruta, sume las duraciones de las tareas para todas las rutas disponibles. Las actividades que tienen holgura se pueden retrasar sin cambiar el tiempo total del proyecto. La holgura se calcula de una de dos maneras: holgura = LF − EF o holgura = LS − ES. Las actividades que están en la ruta crítica tienen una holgura de cero (0).

La ruta crítica es aceg y el tiempo crítico es 19,51 días laborables. Es importante tener en cuenta que puede haber más de una ruta crítica (en un proyecto más complejo que este ejemplo) o que la ruta crítica puede cambiar. Por ejemplo, digamos que las actividades d y f tardan sus tiempos pesimistas (b) en completarse en lugar de sus tiempos esperados (TE ) . La ruta crítica ahora es adf y el tiempo crítico es 22 días laborables. Por otro lado, si la actividad c se puede reducir a un día laborable, el tiempo de ruta para aceg se reduce a 15,34 días laborables, que es ligeramente menor que el tiempo de la nueva ruta crítica, beg (15,67 días laborables).

Suponiendo que estos escenarios no ocurran, ahora se puede determinar la holgura para cada actividad.

Por lo tanto, la actividad b puede retrasarse casi 4 días hábiles sin retrasar el proyecto. Asimismo, la actividad d o la actividad f pueden retrasarse 4,68 días hábiles sin retrasar el proyecto (o alternativamente, d y f pueden retrasarse 2,34 días hábiles cada una).

Diagrama de red completo creado con Microsoft Visio . Observe que la ruta crítica está en rojo.

Evitar bucles

Según las capacidades de la fase de entrada de datos del algoritmo de ruta crítica, puede ser posible crear un bucle, como A -> B -> C -> A. Esto puede hacer que algoritmos simples se repitan indefinidamente. Aunque es posible "marcar" los nodos que se han visitado y luego borrar las "marcas" al finalizar el proceso, un mecanismo mucho más simple implica calcular el total de duraciones de todas las actividades. Si se encuentra un FE mayor que el total, se debe terminar el cálculo. Vale la pena guardar las identidades de la docena de nodos visitados más recientemente para ayudar a identificar el vínculo problemático.

Como herramienta de programación de proyectos

Ventajas

Desventajas

Incertidumbre en la programación de proyectos

Durante la ejecución de un proyecto, un proyecto real nunca se ejecutará exactamente como se planeó debido a la incertidumbre. Esto puede deberse a la ambigüedad resultante de estimaciones subjetivas propensas a errores humanos o puede ser el resultado de la variabilidad que surge de eventos o riesgos inesperados. La razón principal por la que PERT puede proporcionar información inexacta sobre el tiempo de finalización del proyecto se debe a esta incertidumbre del cronograma. Esta inexactitud puede ser lo suficientemente grande como para hacer que dichas estimaciones no sean útiles.

Un método posible para maximizar la solidez de la solución es incluir la seguridad en el cronograma de referencia para absorber las interrupciones. Esto se denomina programación proactiva ; sin embargo, permitir todas las posibles interrupciones sería muy lento y no podría adaptarse al cronograma de referencia. Un segundo enfoque, denominado programación reactiva , define un procedimiento para reaccionar ante las interrupciones que no pueden ser absorbidas por el cronograma de referencia.

Véase también

Referencias

  1. ^ ab Kelley, James E.; Walker, Morgan R.; Sayer, John S. (febrero de 1989). "Los orígenes de CPM: una historia personal". Gestión de proyectos . 3 (2). Project Management Institute: 18 . Consultado el 20 de marzo de 2024 .
  2. ^abcdef Kerzner 2009.
  3. ^ abc Brennan, Maribeth; PERT y CPM: una bibliografía seleccionada , Consejo de Bibliotecarios de Planificación, Monticello (IL), 1968, pág. 1
  4. ^ ab Malcolm, Donald G.; Roseboom, John H.; Clark, Charles E.; Fazar, Willard ; "Aplicación de una técnica para la evaluación de programas de investigación y desarrollo", Operations Research , vol. 7, núm. 5, septiembre-octubre de 1959, págs. 646-669
  5. ^ Informe oficial de los Juegos Olímpicos de Invierno de 1968, pág. 49. Consultado el 1 de noviembre de 2010. (en inglés y francés)
  6. ^ Departamento de la Marina de los EE. UU., Tarea de investigación de evaluación de programas, Informe resumido, Fase 1, Oficina de Imprenta del Gobierno, Washington (DC), 1958
  7. ^ Departamento de la Marina de los EE. UU., Tarea de investigación de evaluación de programas, Informe resumido, Fase 2, Oficina de Imprenta del Gobierno, Washington (DC), 1958
  8. ^ Willard Fazar citado en: Stauber, B. Ralph; Douty, Harry M.; Fazar, Willard; Jordan, Richard H.; Weinfeld, William; y Manvel, Allen D.; "Actividades estadísticas federales", The American Statistician , 13(2): 9–12 (abril de 1959), págs. 9–12
  9. ^ Cook, Desmond L.; Técnica de evaluación y revisión de programas , 1966, pág. 12
  10. ^ Maynard, Harold Bright , Manual de administración de empresas, 1967, pág. 17

Lectura adicional

  • Project Management Institute (2013). Guía de los fundamentos de la dirección de proyectos (5.ª edición). Project Management Institute. ISBN 978-1-935589-67-9.
  • Klastorin, Ted (2003). Gestión de proyectos: herramientas y ventajas y desventajas (3.ª ed.). Wiley. ISBN 978-0-471-41384-4.
  • Kerzner, Harold (2009). Gestión de proyectos: un enfoque sistemático para la planificación, programación y control (10.ª edición). Wiley. ISBN 978-0-470-27870-3.
  • Milosevic, Dragan Z. (2003). Caja de herramientas de gestión de proyectos: herramientas y técnicas para el director de proyectos en ejercicio . Wiley. ISBN 978-0-471-20822-8.
  • Miller, Robert W. (1963). Control de cronogramas, costos y ganancias con PERT: una guía completa para la administración de programas . McGraw-Hill. ISBN 9780070419940.
  • Sapolsky, Harvey M. (1971). El desarrollo del sistema Polaris: éxito burocrático y programático en el gobierno . Harvard University Press. ISBN 0674682254.

Enlaces externos