stringtranslate.com

Programa de Evaluación y Revisión Técnica

Diagrama de red PERT para un proyecto de siete meses con cinco hitos (del 10 al 50) y seis actividades (de la A a la 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 , la cual fue diseñada para analizar y representar las tareas involucradas en la realización de un proyecto determinado .

PERT fue desarrollado originalmente por Charles F. Clark para la Armada de los Estados Unidos en 1958; se usa 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, e identificar el tiempo mínimo necesario para completar el proyecto total. Incorpora incertidumbre al permitir programar un proyecto sin conocer con precisión los detalles y duraciones de todas las actividades. Está más orientado a eventos que a inicio y 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 no rutinarios, complejos, únicos y de muy gran escala, 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 llegar a 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 costos 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 distintas, el El término PERT se aplica cada vez más a toda la programación de rutas críticas". [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 inauguración de los Juegos de 1968. [5] Este modelo de proyecto fue el primero de su tipo, un resurgimiento de la gestión científica de Frederick Taylor y posteriormente perfeccionado por Henry Ford ( fordismo ). El CPM de DuPont se inventó aproximadamente al mismo tiempo que PERT.

Informe resumido PERT Fase 2 , 1958

Inicialmente, PERT significaba Tarea de investigación de evaluación de programas, pero en 1959 se le cambió el nombre. [4] Se había hecho público en 1958 en dos publicaciones del Departamento de la Marina de los EE. UU., tituladas Program Evaluación 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 Rama 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. Él explicó:

A través de 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 rango de tiempo necesario para completar cada actividad entre dos eventos sucesivos. Dichas expectativas de tiempo incluyen estimaciones del "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 las perspectivas de cumplimiento de objetivos en tiempo; resalta las señales de peligro que requieren decisiones de gestión; revela y define tanto la meticulosidad 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 de decisión, antes de la decisión. [8]

Guía PERT para uso administrativo , junio de 1963

Diez años después de la introducción de 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 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 creación de redes completas; la estructura de desglose del trabajo se introdujo formalmente como el primer elemento de análisis en la realización de PERT/CPM básico". [10]

Terminología

Eventos y actividades

En un diagrama PERT, el componente principal es el evento , con conexiones a sus eventos predecesores y sucesores conocidos.

Además de los eventos, PERT también realiza un seguimiento de actividades y subactividades:

Tiempo

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

Herramientas administrativas

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 el que deben completarse. El orden puede ser fácil de registrar para algunas tareas (p. ej., al construir una casa, el terreno debe nivelarse antes de poder colocar los cimientos) pero difícil para otras (hay dos áreas que deben nivelarse, pero solo hay suficientes áreas). topadoras para hacer uno). Además, las estimaciones de tiempo suelen reflejar el tiempo normal y 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 la A a la 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 usando 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.

Un diagrama de Gantt creado con Microsoft Project (MSP). Tenga en cuenta (1) el camino crítico 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 horario, algunas barras en el Los diagramas de Gantt son más largos si abarcan un fin de semana.
Un diagrama de Gantt creado con OmniPlan . Tenga en cuenta (1) la ruta crítica está resaltada, (2) la holgura no se indica específicamente en la tarea 5 (d), aunque se puede observar en las tareas 3 y 7 (byf), (3) ya que los fines de semana se indican con una delgada línea vertical y no ocupan espacio adicional en el calendario laboral, las barras en el diagrama de Gantt no son más largas ni más cortas cuando se trasladan o no a un fin de semana.

Siguiente paso: crear un diagrama de red a mano o utilizando un software de diagramas

Se puede crear un diagrama de red a mano o utilizando un software de diagramas. Hay dos tipos de diagramas de red, actividad en flecha ( AOA ) y actividad en nodo ( AON ). La actividad en los diagramas de nodos suele ser más fácil 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 tiene una actividad predecesora ( a y b en este ejemplo) y las conecta con una flecha desde el 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 aparece 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 b y c . La actividad f tiene d como actividad predecesora, por lo que se dibuja una flecha que conecta las actividades. Asimismo, se dibuja una flecha de e a g . Dado que no hay actividades que vengan después de f o g , se recomienda (pero nuevamente no es obligatorio) conectarlas a un nodo etiquetado como final .

Un diagrama de red creado con Microsoft Project (MSP). Tenga en cuenta que la ruta crítica está en rojo.
Se puede utilizar un nodo como este para mostrar el nombre de la actividad, la duración, ES, EF, LS, LF y slack.

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

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

Para determinar esta información se supone que se dan las actividades y tiempos normales de duración. 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, 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 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 eventualmente mostrará si hay actividades que tienen holgura . El LF se define como el LS mínimo de todas las actividades sucesoras, a menos que la actividad sea la última, 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).

Siguiente 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 . El camino crítico es el que tarda más en completarse. Para determinar los tiempos de las rutas, agregue 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 dos maneras: holgura = LF − EF o holgura = LS − ES. Las actividades que se encuentran en el camino crítico tienen una holgura de cero (0).

El camino crítico es aceg y el tiempo crítico es 19,51 días hábiles. 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 los tiempos esperados (T E ). La ruta crítica ahora es adf y el tiempo crítico es de 22 días hábiles. 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 sucedan, ahora se puede determinar la holgura para cada actividad.

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

Un diagrama de red completo creado con Microsoft Visio . Tenga en cuenta que la ruta crítica está en rojo.

Evitar bucles

Dependiendo de las capacidades de la fase de entrada de datos del algoritmo de ruta crítica, es posible crear un bucle, como A -> B -> C -> A. Esto puede hacer que los algoritmos simples se repitan indefinidamente. Aunque es posible "marcar" los nodos que han sido visitados y luego borrar las "marcas" al finalizar el proceso, un mecanismo mucho más simple implica calcular el total de todas las duraciones de las actividades. Si se encuentra un EF 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 enlace problemático.

Como herramienta de programación de proyectos

Ventajas

Desventajas

Incertidumbre en la programación del proyecto

Durante la ejecución de un proyecto, un proyecto de la vida real nunca se ejecutará exactamente como se planeó debido a la incertidumbre. Esto puede deberse a la ambigüedad resultante de estimaciones subjetivas que son 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 la incertidumbre del cronograma. Esta inexactitud puede ser lo suficientemente grande como para 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 llama 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 interrupciones que no pueden ser absorbidas por el programa de referencia.

Ver también

Referencias

  1. ^ ab Kelley, James E.; Walker, Morgan R.; Sayer, John S. (febrero de 1989). "Los orígenes del CPM: una historia personal". Gestión de proyectos . 3 (2). Instituto de Gestión de Proyectos: 18 . Consultado el 20 de marzo de 2024 .
  2. ^ abcdef Kerzner 2009.
  3. ^ a b C Brennan, Maribeth; PERT y CPM: una bibliografía seleccionada , Consejo de Bibliotecarios de Planificación, Monticello (IL), 1968, p. 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", Investigación de Operaciones , 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. 49. Consultado el 1 de noviembre de 2010. (en inglés y francés).
  6. ^ Departamento de la Marina de EE. UU., Tarea de investigación de evaluación de programas, informe resumido, fase 1, Imprenta del gobierno, Washington (DC), 1958
  7. ^ Departamento de la Marina de EE. UU., Tarea de investigación de evaluación de programas, informe resumido, fase 2, Imprenta del gobierno, Washington (DC), 1958
  8. ^ Willard Fazar citado en: Stauber, B. Ralph; Douty, Harry M.; Fazar, Willard; Jordania, 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. ^ Cocinero, Desmond L.; Técnica de evaluación y revisión de programas , 1966, p. 12
  10. ^ Maynard, Harold Bright , Manual de administración de empresas, 1967, pág. 17

Otras lecturas

  • Instituto de Gestión de Proyectos (2013). Una guía para los conocimientos sobre gestión de proyectos (5ª ed.). Instituto de manejo proyectos. ISBN 978-1-935589-67-9.
  • Klastorin, Ted (2003). Gestión de proyectos: herramientas y compensaciones (3ª ed.). Wiley. ISBN 978-0-471-41384-4.
  • Kerzner, Harold (2009). Gestión de proyectos: un enfoque sistémico para la planificación, programación y control (10ª ed.). 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.
  • Molinero, Robert W. (1963). Control de programación, costos y ganancias con PERT: una guía completa para la gestió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 . Prensa de la Universidad de Harvard. ISBN 0674682254.

enlaces externos