METODOLOGÍAS TRADICIONALES DE LA GESTIÓN DE PROYECTOS



Documentos relacionados
Plan de Evaluación. Parcial I...20% Taller I... 5% Parcial II...20% Taller II...5% Parcial III...20% Exposición...10% Proyecto...15% Asistencia...

GANTT, PERT y CPM. Figura 5.3: Carta GANTT 3.

Escuela Politécnica Superior. Planificación y Control de Proyectos. Capítulo 11. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014 / 15 PROYECTOS

Investigación de operaciones 6.6. Planeación, programación y control de proyectos

ADM-OPERACIONES: PERT - CPM

ADMINISTRACION DE PROYECTOS

Planificación, Programación y Control de Proyectos

El objetivo principal del presente curso es proporcionar a sus alumnos los conocimientos y las herramientas básicas para la gestión de proyectos.

Gestión de proyectos

Metodología básica de gestión de proyectos. Octubre de 2003

CAPÍTULO II MARCO TEÓRICO ADMNISTRACIÓN DE PROYECTOS CON CPM

TEMA 4: TÉCNICAS DE PLANIFICACIÓN DE PROYECTOS

Unidad III. Planificación del proyecto de software

Diagrama de GANTT. Cómo crear un diagrama de GANTT

"Diseño, construcción e implementación de modelos matemáticos para el control automatizado de inventarios

Licenciatura en CONTADURIA. Tema: APLICACIÓN GENERAL DEL CPM

SÍNTESIS Y PERSPECTIVAS

Implementando un ERP La Gestión del Cambio

RIESGO Y PROBABILIDAD

Elementos requeridos para crearlos (ejemplo: el compilador)

CMMI (Capability Maturity Model Integrated)

Diagrama de Gantt. Diagrama de Flujo. Lic. Javier Céspedes Mata, M.E.

Diseño orientado al flujo de datos

Campos de tareas. Costo real (campo de tareas) Duración real (campo de tareas) Fin real (campo de tareas)

Planificación, Gestión y Desarrollo de Proyectos

Administración de proyectos. Organizar, planificar y programar los proyectos de software

6.5 Desarrollo del Cronograma

Unidad II: Análisis de Redes

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

Desarrollo de la estrategia a seguir para. un Sistema de Gestión de la Energía. Instalaciones Industriales

CAPÍTULO 3. HERRAMIENTA DE SOFTWARE DE PLANEACIÓN DE

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

Project Ing. Christian Ovalle

4. Herramientas Administrativas de Mantenimiento

CAPITULO I. Introducción. En la actualidad, las empresas están tomando un papel activo en cuanto al uso de sistemas y

EL PROCESO DE BENCHMARKING

12.1 Planificar las Compras y Adquisiciones

TECNICAS DE CONTROL Y LA INFORMACION

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

Supply Chain Management LOGISTICA - LIC. MSC JOSE MARCO QUIROZ MIHAIC 1

Firma: Fecha: Marzo de 2008

SEGUIMIENTO Y CONTROL DE PROYECTOS MÉTODO P.E.R.T. REVISADO Y ACTUALIZADO - ADDFORMACION

Unidad 1. Fundamentos en Gestión de Riesgos

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Unidad VI: Supervisión y Revisión del proyecto

Tecnología de la Información. Administración de Recursos Informáticos

Administración de proyectos de desarrollo de software

Planeación del Proyecto de Software:

Taller MS Project. Federación Metropolitana de Municipalidades FEMETROM

Traducción del. Our ref:


Empresa Financiera Herramientas de SW Servicios

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Guía de Planificación Estratégica de la Informática Educativa

Administración de Centros Informáticos. Prof. Jhoan M. Chourio UNESR

Orientación acerca de los requisitos de documentación de la Norma ISO 9001:2000

CÓMO MEJORAR LA GESTIÓN DE SERVICIOS TI USANDO MEJORES PRÁCTICAS?

ADMINISTRACIÓN DE PROYECTOS

I. Información General del Procedimiento

Tecnologías para una Educación de Calidad Cierre de Brecha Digital Estándar de Coordinación Informática Ámbito de Mantenimiento.

M.T.I. Arturo López Saldiña

Metodologías Ágiles Desde una Perspectiva de Project Management. Fernando Contreras Velásquez Project Management & Engineering Services.

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

ADMINISTRACIÓN DE PROYECTOS

Este documento proporciona la secuencia de pasos necesarios para la construcción de un Diagrama de Flujo.

Patrones de software y refactorización de código

Normas chilenas de la serie ISO 9000

LIBRO: ADMINISTRACIÓN EXITOSA DE PROYECTOS

Introducción a la Firma Electrónica en MIDAS

Ministerio de Planificación Nacional y Política Económica

FASES DEL PROCESO DE RESOLUCIÓN DE PROBLEMAS

CURSO- TALLER MICROSOFT PROJECT 2010 NIVEL INTRODUCCION MANAGEMENT CONSULTORES CURSO DE INTRODUCION A LA ADMINISTRACION Y DIRECCION DE PROYECTOS CON

Una estructura conceptual para medir la efectividad de la administración

Prácticas PGSI. Práctica 4. Gestión de las Cargas de Trabajo de los Recursos y Delimitaciones de Tareas

LOGISTICA D E COMPRAS

Guía de Apoyo Project Professional

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008

Interoperabilidad de Fieldbus

CAPÍTULO IV METODOLOGÍA PARA EL CONTROL DE INVENTARIOS. En este capítulo se presenta los pasos que se siguieron para la elaboración de un sistema de

Norma ISO 14001: 2015

Modificación y parametrización del modulo de Solicitudes (Request) en el ERP/CRM Compiere.

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

Gestión y Desarrollo de Requisitos en Proyectos Software

UN RECORRIDO POR LA FAMILIA ISO

Laboratorio Informática

Procedimiento de Sistemas de Información

Propuesta de Capacitación. Capacitación Introductoria Para La Administración y/o Control de Proyectos Con el software MS-PROJECT

PRODUCTIVIDAD DE PROYECTOS DE DESARROLLO DE SOFTWARE: FACTORES DETERMINANTES E INDICADORES

PREPARADO POR: FECHA DE EMISIÓN: FECHA DE VALIDACIÓN:

Soluciones Informáticas para Teoría de Restricciones (TOC)

Procesos Críticos en el Desarrollo de Software

SIG ANALISIS DE SEGURIDAD EN EL TRABAJO

3. Procedimiento administrativo para la realización de auditorías a sistemas de medición de la calidad del aire.

Cómo gestionar proyectos en condiciones de riesgo

ADMINISTRACION Y ADMINISTRADORES

CONCEPTOS GENERALES SOBRE SEGURIDAD INFORMATICA

4. Programación Paralela

Qué es Scrum? Basado en el texto Explicando Scrum a mi abuela de Jorge Serrano - MVP Visual Developer - Visual Basic

Curso. Introducción a la Administracion de Proyectos

Transcripción:

METODOLOGÍAS TRADICIONALES DE LA GESTIÓN DE PROYECTOS Mg. Emigdio Alfaro 1 CONTENIDO I. DEFINICIONES BÁSICAS. II. III. IV. CARACTERÍSTICAS DE UN PROYECTO. EL PROCESO DE LA ADMINISTRACIÓN DE PROYECTOS. METODOLOGÍAS ACADÉMICAS DE LA GESTIÓN DE PROYECTOS. V. FUENTES DE INFORMACIÓN. 2

I. DEFINICIONES BÁSICAS PROYECTO Es un conjunto de actividades interrelacionadas y no repetitivas, que están orientadas al logro de metas específicas y que poseen un inicio y un fin claramente establecidos. 3 I. DEFINICIONES BÁSICAS PROJECT MANAGEMENT Es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para cubrir las necesidades o superar las expectativas de los grupos de poder de la organización con respecto a este. 4

I. DEFINICIONES BÁSICAS PROJECT MANAGEMENT Esto implica balancear las demandas de: Alcances, tiempo, costo y calidad. Balancear las diferentes necesidades y expectativas. Captar requerimientos identificados y no identificados. Cuando se habla de Program Managment, Project Management y Task Management se está refiriendo en la práctica a lo mismo. 5 II. CARACTERÍSTICAS DE UN PROYECTO 1. Los proyectos tienen un objetivo de tres dimensiones. Este objetivo acopla: especificaciones de rendimiento, programación de tiempo y costo presupuestado. Esto se conoce como la triple restricción. Esta presenta a su vez tres tipos de problemas: A. Problemas de Rendimiento B. Problemas de Tiempo C. Problemas de Costos 6

II. CARACTERÍSTICAS DE UN PROYECTO A. Problemas de Rendimiento Inadecuada comunicación entre el contratista y el cliente, ya que por lo general tienen diferentes percepciones de las especificaciones o no hablan el mismo lenguaje. Supuestos optimistas y ambiciosos por ambas partes. El contratista puede hacer un mal diseño del trabajo o cometer errores en la ejecución del proyecto. 7 II. CARACTERÍSTICAS DE UN PROYECTO B. Problemas de Tiempo Se da por lo general cuando se pierde el balance de la triple restricción. Especificaciones no pedidas cambian la planificación original. Los recursos no están disponibles cuando se requieren. Un proyecto tiene nuevos requerimientos no establecidos en el planteamiento original. 8

II. CARACTERÍSTICAS DE UN PROYECTO C. Problemas de Costos La negociación contractual es deficiente. Muchas veces se opta por un contratista más barato aunque nos ofrezca un bien o servicio de menor calidad, lo cual repercute a la larga en mayores costos. Prácticamente se tiene que competir para poder conseguir autorizaciones y por ello no se elabora un presupuesto adecuado. Las estimaciones de costos optimistas que no reflejan las ineficiencias que ocurrirán en la planificación. 9 II. CARACTERÍSTICAS DE UN PROYECTO C. Problemas de Costos Inadecuado sistema de administración de costos. Se da muy rara vez. El tiempo se excede del plan original. Nuevas especificaciones originan mayores costos adicionales. 10

II. CARACTERÍSTICAS DE UN PROYECTO 2. Unicidad. Cada proyecto es único porque este ocurre una sola vez, tiene una duración e involucra un grupo de personas distinto en un instante dado. 11 II. CARACTERÍSTICAS DE UN PROYECTO 3. Manejo de Recursos. Los proyectos acoplan recursos llamados personas y cosas. Muchos de los recursos están sólo marginalmente bajo el control efectivo del líder de proyecto. Esta persona debe organizar los recursos humanos para tomar ventaja de los recursos físicos disponibles con el fin de acoplarlos a las metas técnicas de rendimiento iniciales del proyecto. 12

II. CARACTERÍSTICAS DE UN PROYECTO 4. Se desarrollan dentro de una organización. Cada organización tiene múltiples propósitos en un momento dado; es por ello que está compuesta de muchos individuos con habilidades, intereses, personalidades e impredecibles diversos. Por ello es que el líder de un proyecto está a menudo perturbado por las muchas otras direcciones que la organización maneja. Estas múltiples direcciones originan que existan muchos proyectos desarrollándose de manera simultánea. 13 II. CARACTERÍSTICAS DE UN PROYECTO 5. Otros Aspectos: Su Origen. El tipo o clase de proyecto debe estar claramente definido desde el inicio. El Producto o Resultado Finaltangible que logra. Su Patrocinio. El patrocinador de un proyecto puede ser una empresa privada, una organización gubernamental, etc; logrando con esto un comportamiento distinto. Tamaño. Indica las proporciones del proyecto. 14

III. EL PROCESO DE LA ADMINISTRACIÓN DE PROYECTOS 1. Definir las metas del proyecto 2. Planificar como Ud. y su equipo lograrán satisfacer la triple restricción. El plan depende de la mezcla de recursos humanos y materiales a ser usados. 3. Liderar el proyecto, guiando a los recursos humanos subordinados y otros (incluyendo subcontratados) para el logro efectivo de las metas del proyecto. 15 III. EL PROCESO DE LA ADMINISTRACIÓN DE PROYECTOS 4. Monitorear el trabajo del proyecto. Notar como difiere la ejecución del proyecto del plan inicial para tomar una acción correctiva (replanificar o cambiar una meta del proyecto, con la consecuente necesidad de reacomodar los recursos). 5. Completar el proyecto, asegurándose de que el resultado final esté acorde con la actual especificación de requerimientos. 16

IV. METODOLOGÍAS ACADÉMICAS DE LA GESTIÓN DE PROYECTOS 1. DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES. 2. DESARROLLO HISTÓRICO DE LAS METODOLOGÍAS DE ADMINISTRACIÓN DE. 3. RESUMEN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS BASADA EN REDES. 4. RESTRICCIONES DE RECURSOS EN LA PROGRAMACION DE UN PROYECTO. 17 IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES El diagrama de redes es esencialmente una consecuencia del diagrama de barras que fue propuesto por Gantt en el contexto de los requerimientos para la Primera Guerra Mundial. El gráfico de barras está diseñado primariamente para controlar el elemento tiempo. 18

IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES Los pasos para preparar un gráfico de barras son: 1. Analizar el proyecto. 2. Dividir el proyecto en un número razonable de actividades a ser programadas. 3. Estimar el tiempo requerido para la ejecución de cada actividad. 4. Colocar las actividades en orden secuencial de tiempo, tomando en cuenta los requerimientos de ciertas actividades (algunas actividades deben ser ejecutadas secuencialmente y otras simultáneamente). 5. Si una fecha de fin es especificada, el diagrama es ajustado hasta que la restricción es satisfecha. 19 IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACIÓN DE REDES La primera ventaja del gráfico de barras es que la planificación, la programación y el progreso del proyecto pueden ser mostrados gráficamente. Pese a esta gran ventaja, los gráficos de barras no tienen mucho éxito en proyectos muy complejos o largos por las siguientes razones: 20

IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACIÓN DE REDES 1. La planificación y programación están consideradas simultáneamente. 2. La simplicidad del gráfico de barras evita mostrar suficiente detalle para habilitar la detección a tiempo de las demoras en la programación de las actividades con tiempos de duración relativamente largos. 21 IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES 3. El gráfico de barras no muestra explícitamente las relaciones de dependencia entre las actividades. Es muy dificultoso imputar los efectos de las demoras en el proyecto a actividades individuales. 4. El gráfico de barras es esencialmente un procedimiento gráfico manual, difícil de mantener para proyectos largos y tiene una tendencia a desactualizarse rápidamente y perder utilidad. 22

IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES Las gráficas más comunes de la planificación de proyectos son: 1. Gráficas de barras de Gantt. 2. Diagramas de redes de proyectos. 3. Redes de proyectos con escala de tiempo. 23 IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES A B C D E 1. Gráficas de barras de Gantt 0 1 2 3 4 5 6 7 8 9 10 t 24

IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES 2. Diagrama de Redes de Proyectos A 1 B 2 C 0 D 3 E 4 H 6 F 5 G 25 IV.1 DESARROLLO DEL CONCEPTO DE PLANIFICACION DE REDES 3. Red de Proyectos con escala de tiempo 0 F A B 6 1 2 D C 4 E G 5 H 3 7 0 1 2 3 4 5 t 26

IV.2 DESARROLLO HISTÓRICO DE LAS El desarrollo de los computadores digitales y los lenguajes de programación dieron las bases para el desarrollo de la Metodología de Administración de Proyectos basadas en redes. 27 IV.2 DESARROLLO HISTÓRICO DE LAS EVOLUCIÓN 1. HARMONIGRAPH 2. PERT 3. PERT STATISTICAL APPROACH 4. CPM 5. PERT/CPM 6. MÉTODO DE POTENCIALES 7. GERT: Q-GERT, R-GERT, P-GERT. 8. VERT 28

IV.2 DESARROLLO HISTÓRICO DE LAS 1. HARMONIGRAPH 1931. Karol Adamieki inventó el Harmonigraph. En este gráfico, las columnas estaban ordenadas, por eso las predecesoras de cualquier actividad se encontraban siempre a la izquierda. Cada columna de actividad contenía un desplazamiento movible cuya longitud era proporcional al tiempo de duración estimada de la actividad y su escala de tiempo denotaba el inicio y fin de su programación. 29 IV.2 DESARROLLO HISTÓRICO DE LAS 1. HARMONIGRAPH 25 años después fue reinventado este método (en USA y Gran Bretaña), ya en la era de los sistemas de computadoras. Se añadió el elemento esencial: un procedimiento gráfico estricto para añadir, tabular y aproximar aritméticamente el proceso de planificación. 1957. La Sección de Investigación de Operaciones de la Central Electricity Generating Board (Gran Bretaña) investigó el problema de las plantas de generación eléctrica. Encontraron una técnica que consistía esencialmente en la identificación de la mas larga e irreductible secuencia de eventos. Este término fue acortado después a la mayor secuencia y 30 corresponde a lo que llamamos RUTA CRÍTICA.

IV.2 DESARROLLO HISTÓRICO DE LAS 1. HARMONIGRAPH Aplicaciones experimentales de esta metodología entre los años 1958 y 1960 resultaron en reducciones muy impresionantes de 42% y los tiempos promedios previos bajaron un 32%. Mientras se realizaba este estudio en Gran Bretaña, dos desarrollos similares tuvieron lugar en USA. Estos fueron los llamados PERT y CPM. 31 IV.2 DESARROLLO HISTÓRICO DE LAS 2. PERT El desarrollo de PERT se inició cuando la armada fue enfrentada con el reto de producir sistemas de misiles Polaris en tiempo record en 1958. Muchos estudios indicaron que los proyectos tenían incrementos notables en los costos y tiempos de duración. Los proyectos militares indicaron un aumento de 2 a 3 veces el presupuesto original y los tiempos de duración se habían incrementado en un 40% a 50%. Los proyectos comerciales indicaron incrementos de costos de mas de 70% e incrementos de duración de mas de 40%. 32

IV.2 DESARROLLO HISTÓRICO DE LAS 2. PERT Mientras que mucha gente sentía que las estimaciones originales debieron ser muy optimistas para poder lograr los contratos, una razón más importante para estas fallas era lo poco adecuado de las técnicas de control, planificación y administración de proyectos para el caso de proyectos complejos y largos. 33 IV.2 DESARROLLO HISTÓRICO DE LAS 2. PERT Era necesario un mejor método. Para enfrentar este reto, se reunió un equipo de investigación con representantes de Lockhead Aircraft Corporation (contratista principal de Polaris), la Navy Special Projects Office y la firma de consultores de Booz, Allen y Hamilton. Este proyecto de investigación fue designado como PERT, Program Evaluation Research Task. Desde aquella época a la fecha vino a ser Project Evaluation and Review Technique. Este equipo de investigación evolucionó el sistema PERT a partir de una consideración de técnicas tales como Balance de Línea, Gráficas de Gantt y distintos reportes de sistemas. 34

IV.2 DESARROLLO HISTÓRICO DE LAS 2. PERT El tiempo fue lo esencial en el programa Polaris, por eso el equipo de investigación se concentró en la planificación y control de este elemento del programa. Entonces, el PERT se convertía en un apropiado método para programar y controlar proyectos de investigación y desarrollo y otros, compuestos principalmente de actividades cuyos tiempos de duración actuales están sujetos a variaciones debido al riesgo. 35 IV.2 DESARROLLO HISTÓRICO DE LAS 3. PERT STATISTICAL APPROACH Un acoplamiento mayor es el procedimiento estadístico PERT, que involucra la utilización de la teoría de la probabilidad a la toma de decisiones gerenciales. Los sistemas de programación a la fecha estaban basados en la idea de un tiempo preparado para cada tarea. 36

IV.2 DESARROLLO HISTÓRICO DE LAS 3. PERT STATISTICAL APPROACH La ventaja de la aproximación estadística del PERT, desarrollado originalmente por D. G. Malcolm y otros, es que ofrece un método para calcular la variación debido al riesgo en cada actividad, permitiendo calcular fechas de programación y finalmente usar las bases de la teoría de la probabilidad para calcular la probabilidad de terminar un proyecto en la fecha programada o antes. Añadiendo la información del riesgo en cada actividad, es posible analizar las consecuencias y el costo de expeditar un proyecto en diversas maneras para poder planificar mejor el resultado del proyecto. 37 IV.2 DESARROLLO HISTÓRICO DE LAS 3. PERT STATISTICAL APPROACH PERT permite controlar la fase de administración del proyecto con varias formas de reportes periódicos. El trabajo del equipo de investigación original de PERT ha sido extendido a las áreas de planificación y control de costos, así como a las áreas de rendimiento o calidad del producto. 38

IV.2 DESARROLLO HISTÓRICO DE LAS 4. CPM CPM (Critical Path Method) surgió de un trabajo conducido en Febrero de 1956 por la dupont Company and Remington Rand Univac. El objetivo del equipo de investigación del CPM fue deteminar como reducir al máximo el tiempo requerido para ejecutar un trabajo de acondicionamiento, mantenimiento y construcción de una planta. 39 IV.2 DESARROLLO HISTÓRICO DE LAS 4. CPM En esencia estaban interesados en determinar la mezcla óptima de tiempo de duración y costo del proyecto. El objetivo era determinar la duración del proyecto que minimice la suma de costos directos e indirectos. 40

IV.2 DESARROLLO HISTÓRICO DE LAS 4. CPM Las actividades comprendidas en este tipo de proyecto están caracterizadas por una cantidad de variación relativa pequeña, comparada con las actividades del programa Polaris. A diferencia de PERT, CPM maneja tiempos de rendimiento de actividad de manera determinística y tiene como elemento principal la capacidad de lograr una programación del proyecto que minimice los costos totales del proyecto. 41 IV.2 DESARROLLO HISTÓRICO DE LAS 5. PERT/CPM Los equipos iniciales de PERT y CPM no sabían de la existencia del otro hasta 1959, cuando se influenciaron mutuamente. Al final ambos equipos obtuvieron un resultado similar al Harmonygraphcon la adición de resultados tabulados por computadora que dan los tiempos de inicio, fin y retardo de cada actividad y la necesidad de ordenar los resultados en una variedad de formas para diferentes usos. 42

IV.2 DESARROLLO HISTÓRICO DE LAS 5. PERT/CPM El sofisticado algoritmo de optimización Time Cost Trade Off de CPM y la probabilidad de reunir elemento planificado de PERT realmente jugaron un rol mucho menor en las aplicaciones actuales. A mediados de los años 60, muchas de las agencias de gobierno de USA requerían el uso de los suplementos de control de costos del CPM, además de los requerimientos del PERT; por ello, desarrollaron programas de cómputo que los generalizaban, naciendo así el PERT/CPM. 43 IV.2 DESARROLLO HISTÓRICO DE LAS 6. MÉTODO DE POTENCIALES Por la época de investigación del CPM, tuvo lugar en Francia el desarrollo del Método de Potenciales. Está basado en una lógica de red, la cual restringe el inicio de una actividad al retraso de una cantidad de tiempo especificada después del inicio de una actividad predecesora. En tal sentido, este fue el precursor del desarrollo de los diagramas de precedencia que tuvieron lugar en USA en los años 60. 44

IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT Los diagramas de nodos y flechas están basados en una lógica de red determinística. Esto quiere decir, que cada ruta de la red es parte necesaria del proyecto; no existen rutas opcionales o alternativas. No obstante, sabemos que en muchos tipos de proyectos existe algo de incertidumbre con respecto a ajustar actividades que serán incluídas. 45 IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT En proyectos de investigación en particular, muchos diferentes resultados del proyecto podrían darse dependiendo de los resultados de ciertas cadenas de actividades. Una red que muestra sólo un plan con un solo resultado posible no representaría adecuadamente la naturaleza real del proyecto. 46

IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT La flexibilidad deseada aquí es llamada Ramificación Probabilística, donde sólo una de muchas actividades sucesoras es realizada. Otra importante deficiencia de los esquemas de redes básicos es que no permiten incorporar ciclos en las redes. 47 IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT El diagrama generalizado que permite incluir ciclos y ramificaciones probabilísticas es llamado GERT (Graphical Evaluation and Review Technique) y fue desarrollado por Alan Pritsker. 48

IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT Las primeras actividades de investigacion en GERT fueron ejecutadas en la Rand Corporation mientras desarrollaban procedimientos para automatizar equipos de verificación para el Apolo Program. 49 IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT: Q-GERT Pritsker trabajó luego con muchos grupos dirigiendo el programa llamado Q-GERT. Este programa añadió los costos al análisis usual de tiempos de las redes. Arisawa y Elmaghraby modelaron costos considerando costos fijos y variables que incrementaban en el tiempo para cada actividad del proyecto. 50

IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT: P-GERT Fue desarrollado por Pritsker para manipular la notación del diagrama de nodos. 51 IV.2 DESARROLLO HISTÓRICO DE LAS 7. GERT: R-GERT Hebert desarrolló el programa llamado R-GERT que da los resultados básicos de una simulación de redes de PERT con la consideración de restricciones de recursos. El programa da los tiempos temprano/tardío de inicio/fin e índices críticos para cada actividad del proyecto, con la condición de que una actividad no debe ser iniciada hasta que los recursos requeridos para la actividad estén disponibles. 52

IV.2 DESARROLLO HISTÓRICO DE LAS 8. VERT Moeller y Digman desarrollaronvert, Venture Evaluation and Review Technique. Es una técnica de simulación computacional de redes matemáticas, diseñada para determinar los riesgos involucrados en la organización de una nueva operación y en la planificación, control y monitoreo de recursos, y toda evaluación de proyectos, programas y sistemas en marcha. 53 IV.2 DESARROLLO HISTÓRICO DE LAS 8. VERT Involucra mas funciones de interacción con el usuario que GERT y es quizás, una evolución lógica para abarcar los parámetros de tiempo, costo y calidad. 54

IV.3 RESUMEN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS BASADA EN REDES La metodología de administración de proyectos basada en redes es un procedimiento dinámico de control y planificación. Consta de los siguientes pasos: 55 IV.3 RESUMEN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS BASADA EN REDES 1. PLANIFICACIÓN DEL PROYECTO. Las actividades y su correspondiente dependencia tecnológica son definidas explícitamente en la forma de diagramas de redes. Los métodos alternativos de redes usan flechas, nodos y diagramas de precedencia. Este es el paso más importante en el procedimiento PERT/CPM. Se debe tener mucho cuidado al hacerlo 2. ESTIMACIONES DE TIEMPO Y RECURSOS. Las estimaciones de tiempo de duración de las actividades de un proyecto son muy diversas, primando sobre todo la experiencia y las capacidades y habilidades de los recursos involucrados. Posteriormente se verá esto con detalle. 56

IV.3 RESUMEN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS BASADA EN REDES 3. PROGRAMACIÓN BÁSICA. Los cálculos básicos de programación dan los tiempos temprano y tardío permisibles para comenzar o finalizar cada actividad y podemos identificar la ruta crítica a través de la red e indicar el retraso de tiempo permisible asociado con las rutas no críticas. 4. MEZCLA ADECUADA DE TIEMPO Y COSTO. Este problema está dirigido a calcular un programación de actividades del proyecto que considere explícitamente tanto los costos directos como los costos indirectos y minimice la suma de estos. 57 IV.3 RESUMEN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS BASADA EN REDES 5. PROGRAMACIÓN DE RECURSOS. Si se hace una inadecuada programación de recursos, se hará una inadecuada programación del proyecto entero. Por ejemplo, si tenemos recursos con poca capacidad o si estos recursos no van a estar disponibles en un momento dado, esto puede llevar a reprogramaciones de las tareas hasta lograr una combinación adecuada. 58

IV.3 RESUMEN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS BASADA EN REDES 6. CONTROL DEL PROYECTO. Cuando se ha terminado la planificación y programación del proyecto, ya está preparado el formato final para poder ser usado en el control del proyecto. El proyecto es controlado verificando lo avanzado contra lo programado, asignando y programando los recursos, y analizando los efectos de las demoras. Cuando son requeridos mayores cambios, la red es revisada y es calculada una nueva programación considerando el tiempo y los costos. Esto significa que debemos planificar el proyecto optimizando la relación costo tiempo. La red de tuta crítica provee una forma muy útil para el control de costos a través de la ejecución del proyecto. 59 Especificaciones Iniciales del Proyecto (1) Diagrama de redes mostrando el plan de trabajo y restricciones tecnológicas (2) Estimaciones de duración de cada actividad individual y recursos necesarios Modificaciones de tiempo, costo, rendimiento y restricciones de recursos (3) Cálculos básicos de la Ruta Crítica FASE DE PLANIFICACION (7) Administración, replanificación y reubicación de recursos No (4) Resolución de restricciones de tiempo y recursos No Es satisfactorio el actual plan de proyecto? (6) Reportes de estado periódicos: tiempos transcurridos, avance, recursos invertidos, dinero invertido, etc. Sí (5) Plan de Implementación Aceptable FASE DE CONTROL 60

IV.4 RESTRICCIONES DE RECURSOS EN LA PROGRAMACION DE UN PROYECTO Las restricciones de recursos de un proyecto provocan: Reducción los períodos programados con poca actividad. Que los retardos dependan de las relaciones con actividades precedentes y recursos limitados. Que los retardos dependan también de la resolución de conflictos por las prioridades de uso sobre los recursos limitados. La ruta crítica en la programación de un recurso con capacidad restringida no debe ser la misma cadena de actividades contínuas que ocurren con recursos ilimitados. 61 IV.4 RESTRICCIONES DE RECURSOS EN LA PROGRAMACION DE UN PROYECTO Los problemas mencionados se dan dentro de un proyecto cuando programamos tareas que se realizarán tanto de manera consecutiva como paralela para un mismo recurso. En el primer caso (programación consecutiva) el retraso en una actividad origina una demora en la actividad posterior que depende de esta, y la programación paralela de las actividades conlleva a que forsozamente se realice una reprogramación, ya que una persona sólo puede realizar una tarea en un instante del tiempo. 62

IV.4 RESTRICCIONES DE RECURSOS EN LA PROGRAMACION DE UN PROYECTO Esta situación descrita es mucho más crítica en entornos multiproyectos. Pese a que en los libros se mencionan estos problemas y se advierte de las consecuencias de obviar esto en la planificación, recién desde la aparición del concepto de Cadena Crítica es cuando se ataca el problema desde sus bases, lo cual será explicado en la siguiente sesión. 63 V. FUENTES DE INFORMACIÓN Project Management with CPM, PERT and Precedence Diagramming. Autores: Joseph Moder, Cecil Phillips y Edward Davis. Third Edition 1983. 64