Gestion de Proyectos Basados en El PMBOK - Manual

(1)

Gestión de

Proyectos

basados en el

PMBOK

(2)

Gestión de Proyectos basados en el PMBOK

(3)

1

01.Proyectos Fallidos y

Culminados.

Tópicos de la Sección

• Un estudio del éxito y las fallas de los proyectos • Razones por las cuales fallan los Proyectos • Razones por las cuales culminan los Proyectos • Proyectos de TI: ¿Qué los hace diferentes?

Ejercicios

(4)

4

Un estudio del éxito y las fallas de los proyectos

El Standish Group encontró:

Año Exitosos Cambiados/ Culminados Fallidos 2008 34% 51% 15% 2006 28% 49% 23% 2004 26% 46% 28% 2002 27% 33% 40% 2000 16% 53% 31% Definiciones:

 Exitosos: Proyecto se completó en tiempo, en presupuesto, y según especificaciones (características y funcionalidad).

 Cambiados/Culminados: Proyecto fue completado y operativos, pero fue sobre el presupuesto, tarde, y/o no satisfizo todas las especificaciones originales (características y funcionalidad).

 Fallidos: el proyecto fue cancelado antes de culminado o nunca fue implementado.

Figura 1: Un estudio de el éxito y las fallas de los proyectos

Casi todo el mundo ha formado parte de un proyecto que ha fallado, si es debido a requisitos no cumplidos, los excesos de costos u objetivos fuera de calendario. En el último decenio, los estudios y una pionera investigación en la industria han intentado cuantificar los fracasos de los proyectos. En el 1995, el Standish Group publicó el estudio fracaso de los proyectos conocido como "Informe sobre el CAOS". El Informe fue con base en los resultados de una encuesta realizada con varios ejecutivos a través de múltiples e importantes segmentos de la industria: financiera, salud, manufactura, servicios, seguros, comercio minorista, etc. Puso de manifiesto el éxito de los proyectos y la falta de estadísticas, así como las razones de fracaso de los proyectos. La figura 1 muestra algunos de los resultados. Basados sobre los resultados de esta investigación, se puede concluir que en el mejor de los casos, aproximadamente 3 de cada 10 proyectos son considerados exitosos, mientras que el 66 por ciento se puede considerar "sin éxito" (o no impugnado). Imagine no sólo el impacto que esta tendencia tiene sobre la credibilidad de la organización en la ejecución de proyectos, sino también lo que es más importante, cómo el éxito del proyecto contribuye a la línea inferior de la organización.

Como los líderes de proyectos, es imprescindible para que Ud. pueda aislar las razones de fracaso y se apalanque en las mejores prácticas en la gestión de proyectos para mejorar su éxito global.

(5)

Razones por las que un Proyecto Fracase



Planificación inadecuada



Falta de control



Inexistencia o falta de apoyo a la gestión superior



Pobre planificación de los riesgos



Falta de apoyo a los usuarios finales



Comunicaciones muy pobres



Plazos de entregas no cumplidos



Expectativas no realistas

Figura 2: Razones por las que falla un proyecto Aunque los estudios de El Standish Group han demostrado que el éxito de los proyectos ha mejorado en los últimos diez años, todavía hay mucha oportunidad de mejora.

El primer paso para solucionar un problema es identificar que existe. El próximo paso es identificar y comprender la causa del problema, o en este caso, la causa del fracaso del proyecto.

Las opiniones difieren ligeramente de las razones por lo cual los proyectos no son exitosos. Sin embargo, la mayoría de las razones caen en la misma categoría. Los factores más comunes identificados para las fallas de los proyectos están listados en la Figura 2.

Varios de estos factores se explican con más detalle a continuación:

• Planificación inadecuada: Esto no incluye una clara comprensión de la trayectoria crítica, un plan incompleta (aportes concretos, actividades, o tareas desaparecidos desde el plan), y falta de recursos (no identificado, no proceden, o no capaz).

• Falta de control: la falta de control puede incluir métodos pobres en calidad, control de cambios inexistentes o no implementados, no estalación de costos, y una pobre o inadecuada gerencia de proyectos.

• Inexistencia o falta de apoyo de la gestión superior: Sin apoyo a la gestión superior, los elementos del tradicional triangulo de restricciones; limitación de alcance, tiempo y costos pueden ser repercutido negativamente. Al mismo tiempo, directores de proyecto deben basarse en la Gerencia superior para dirigir las prioridades de los recursos de la organización.

• Pobre planificación de riesgos: Ambos, los conocidos desconocidos o desconocidos conocidos pueden impactar adversamente al proyecto. Una buena planificación de riesgos, temprana y acorde ayudara a minimizar la exposición del proyecto a las amenazas de no cumplimiento.

• Falta de apoyo a los usuarios finales: incluso si el proyecto se cumple en tiempo y compromisos presupuestarios, puede quedarse corto en cuanto a las necesidades o expectativas de los usuarios.

Además de lo explicado anteriormente, las razones más comunes para las fallas de Proyectos de TI son las siguientes:

• Comunicaciones deficientes • Tiempos de entrega no cumplidos • Expectativas no realísticas

(6)

6

Razones de Éxito en los Proyectos



Soporte ejecutivo y reuniones organizacionales



Definiciones del proyecto, objetivos del negocio y requerimientos claros.



Equipo eficaz y una estructura de apoyo capaz de adaptarse apropiadamente

al proyecto



Plan practico y expectativas cumplidas



Roles y responsabilidades claras



Participación de recursos calificados, incluyendo gerentes de proyectos

experimentados



Manejo adecuado de riesgo y métodos de control de calidad



Control de cambios integrado, incluyendo alcances, tiempos y costos



Comunicaciones efectivas



Metodología del proyecto estándar, consistente y práctica.

Figura 3: Razones de Exito en los Proyectos

La tasa actual de proyectos fracasados puede indicar que la industria enfrenta un enorme desafío. La buena noticia es que la integración de las mejores prácticas en gestión de proyectos puede desempeñar un papel importante en mejorar la ejecución de proyectos exitosos de la industria.

El hecho es que el éxito de los proyectos comparte muchas de las mismas características. Según numerosas investigaciones y resultados del estudio, los factores más críticos en mejorar el éxito de los proyectos serán las que se muestran en la figura 3.

(7)

¿Proyectos de TI: Qué los hace diferentes?

Figure 4: Proyectos de TI: Qué los hace Diferentes?

La gestión Proyecto es una amplia disciplina que abarca muchas industrias y muchos tipos de organizaciones, incluidas las empresas, organizaciones, y los organismos gubernamentales. Sus elementos fundamentales tanto como un arte y una ciencia son comunes en todas las industrias.

Fundamentalmente en el último cuarto de siglo, la gestión de proyectos de TI se ha convertido en una industria en sí mismo. Como resultado, muchos equipos de los proyectos y organizaciones creen que TI debe tener un conjunto único de herramientas y técnicas de gestión de proyectos para ejecutarlos. Es importante distinguir que no es que las herramientas y técnicas son diferentes, sino la naturaleza de los proyectos de TI que hacen que los proyectos de TI sean únicos.

Los proyectos de TI deben lidiar con el ciclo corto de vida de la tecnología, la rápida ejecución y las necesidades de desarrollo, y el tiempo-a-las demandas del mercado que exceden los de otras industrias. Aunque las herramientas y técnicas de gestión de proyectos son las mismas, deben aplicarse de una manera diferente en el entorno de TI.

_{Ejecución y Desarrollo, muy Rápido}

Ciclo de Vida de la Tecnología, Corto

(8)

8

Comparación de las características de Proyectos de TI y no TI

Componentes del Proyecto Proyectos No TI Proyectos de TI

Proyectos No integrada con la mayoria de las funciones del negocio

Generalmente vinculados con los procesos de negocios y los sistemas de las organizaciones Estructura del Proyecto A menudo Aislados Generalmente múltiples proyectos

con interdependencias

Alcances Bien definidos Menos definidos y sujetos a cambios

Control de cambios Bien definidos Procesos de control de cambios definidos, difíciles de seguir

Protagonistas Pocos; faciles de identificar Mas; mas dificiles de identificar Equipo de Trabajo Mejor personas críticas en

conjuntos; media en otros; más generalistas

Mejor disponibilidad de las personas; normalmente especialistas

Proyectos grandes Dividido en organizaciones o establecidas en unidades aisladas

Localizadas por especialidades o riesgos, a traves de lineas organizacionales Riesgo Mas facil de identificar;

gestionado muy pobremente pero usualmente con menos impacto negativo

No es faqcil de identificar; muy pobremente pero usualmente con muy alto impacto

Documentacion De pobre a justa Moderadamente buena, pero muy poco aplicada Lecciones aprendidad De pobre a justa Pobre

Estimaciones de tiempo y procura

Buena Pobre

Figura 5: Comparación de las características de Proyectos de TI y no TI

La tabla mostrada en la Figura 5 detalla las características de Proyectos de TI y no TI.1

1. Taylor, James. Managing Information Technology Projects: Applying Project Management

Strategies to Software, Hardware, and Integration Initiatives. (American Management Associa- tion,

(9)

Gestión de Proyectos basados en el PMBOK 9

2

02.Fundamentos de Gerencia de

Proyectos.

Tópicos de la sección

• Logística del curso • Introducción • Diseño del Curso

• Gerencia de Proyecto básica

• Ciclo de vida de la Gerencia de proyectos

• Áreas de conocimientos de la Gerencia de Proyectos • El triangulo de restricciones de la Gerencia de proyectos • Organización de los proyectos

Ejercicio

(10)

10

Introducción



Nombre



Posición, departamento, compañía u organización



Experiencia como gerente de proyecto



Tipos de Proyectos en los cuales han trabajado



Objetivos de aprendizaje: que quieres aprender esta semana?



Ejemplos personales de Proyectos culminados y fallidos

Figura 7: Introduccion Después de la presentación del instructor, deberá presentarse e indicar los puntos de arriba, al público del curso.

(11)

11

Diseño del Curso

Fundamentos de Gerencia de proyectos Fase Conceptual

Iniciación Fase de Planificación

Definición de alcances del proyecto, gerencia de tiempos y de programación, gerencia de control de costos, gerencia de comunicaciones

Fase de Diseño

Gerencia de riesgos, procura y Metodología de PM Fase de Desarrollo y Prueba

Controlando y gerenciando los cambios, control de aseguramiento de la calidad Fase de Cierre

Cierre de fase y del proyecto

Figura 8: Diseño del Curso No es realista esperar que usted pueda absorber todos los elementos de las mejores prácticas en gestión de proyectos en un curso de cuatro días. Puede, sin embargo, aprender los elementos fundamentales para aumentar su propio éxito en la entrega del proyecto centrándose en las prácticas más críticas.

Este curso está diseñado para presentarles estos elementos críticos de una manera que pueden ser prácticamente integrado como iniciativas en su trabajo diario. Como tal, este curso se ha diseñado para presentar las unidades de aprendizaje en paralelo con las fases estándares del ciclo de vida de los proyectos.

En estos cuatro días, nos concentraremos en lo siguiente: • Fundamentos de Gerencia de Proyectos • Fase conceptual

- Iniciación del proyecto • Fase de Planificación

- Definición de los alcances del proyecto - Gestión y programación de tiempo - Planificación de los recursos - Gerencia y control de costos - Gerencia de comunicaciones • Fase de Diseño

- Gerencia de riesgos del proyecto - Adquisición y Procura

- Metodologías de Gerencia de proyecto • Fase de desarrollo y pruebas

- Gerencia de control de cambios - Aseguramiento y control de calidad • Fase de cierre

- Cierre de fase y del proyecto

El curso está estructurado para promover el aprendizaje mediante la incorporación de ejercicios y practicas guiadas por el instructor. Las lecciones aprendidas en todo este curso son destinadas a que le permitan aplicar directamente las iniciativas de gestión a sus proyectos diarios.

(12)

12

Gerencia de Proyectos Básica

¿Qué es un Proyecto?

Según el PMBOK:

Proyecto: Temporal, único, de elaboración progresiva.

Operaciones: en curso, repetitivo; no fija todos los criterios

Un proyecto crea entregables únicos, los cuales pueden incluir productos, servicios

y/o resultados.

La gerencia de Proyectos es la aplicación de conocimientos, herramientas, destrezas y técnicas a las actividades del proyecto para

cumplir los requerimientos planteados.

Figura 9: Qué es un Proyecto? Cuerpo de Conocimiento de Gestión de Proyectos (PMBOK Guía) define un proyecto como "un emprendimiento temporal para crear un producto único, servicio, o un resultado". 2

Hay algunos de los rasgos principales que distinguen un proyecto de una iniciativa operativa. Un proyecto es único, que incluye un inicio temporal y una fecha final, y que implica la elaboración gradual, es decir, que se desarrolla en medidas y sigue en incrementos. Las Operaciones, por otro lado, son indicativas de las iniciativas actuales y repetitivas de la organización.

El propósito principal de un proyecto es hacer o aplicar los cambios dentro de la organización, típicamente para llevar la organización hacia el logro de sus objetivos estratégicos. La salida de un proyecto está representada por entregables, que puede venir en forma de productos, servicios o resultados.

La gestión de Proyecto es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de los proyectos que son necesarias para satisfacer las necesidades de los mismos. La gestión de Proyecto son tanto un arte como una ciencia, y es una creciente disciplina de gestión en todas las industrias.

2. Project Management Institute, A Guide to the Project Management Body of Knowledge:

(13)

13 Programa

Proyectos vs. Programas

Project A Project B Project C Project D

Un programa es "un grupo de proyectos administrados en

forma coordinada para obtener beneficios y control no

disponibles desde la gestión individualmente." — PMBOK

Figure 10: Project vs. Program Según el PMBOK, un programa es "un grupo de proyectos administrados en forma coordinada para obtener beneficios y controlar no dispone de su gestión individualmente”.3

Pensando en términos de organización, la jerarquía dentro de la corporación sería la siguiente: 1. Plan Estratégico

2. Programa 3. Proyecto

Un programa, sin embargo, podría incluir también las operaciones en curso, tales como un programa para facturación. En este caso, un gerente de programa puede ser responsable de las distintas versiones del producto y actualizaciones y la coordinación de las múltiples versiones durante un período de tiempo.

También es importante señalar que los programas pueden incluir elementos de trabajo fuera del alcance de un proyecto concreto dentro del programa. Por ejemplo, un programa que implementa vídeo inalámbrico para la fuerza de ventas puede ser dependiente de la capacidad de otro departamento para actualizar la red inalámbrica. El actualizar la red inalámbrica, aunque es una pieza integrante proyecto de video de las redes inalámbricas, está fuera del alcance del programa.

(14)

14

Ciclo de Vida de la Gerencia de Proyectos

Grupo de Proceso Inicio Grupo de Planificación

Grupo de proceso Ejecución

Grupo de Proceso Cierre

_IPECC

Figure 11: Ciclo de Vida de la Gestión de proyectos En la práctica general de gerencia de Proyectos, hay cinco procesos identificados que conforman el ciclo de vida de la gerencia de Proyectos. Estos grupos de procesos, conocidos como IPECC, incluyen:

• Iniciación: Reconocer o autorizar el proyecto o programa o la fase

• Planificación: Proceso envuelto con las definiciones y refinamientos de los objetivos y la determinación de como poder alcanzar los objetivos del proyecto

• Ejecución: obtener la labor que ha sido identificados durante el proceso de planificación mediante la coordinación de los recursos necesarios, tanto humanos como capital

• Control: Medición del desempeño de las iniciativas de ejecución, identificando las varianzas del plan, y la incorporación de medidas correctivas que sean necesarias para llevar el proyecto en seguimiento

• Cierre: Formalmente reconocer el final de un proyecto o fase, aceptar el proyecto o fase, y que esta, el proyecto o fase sea llevada a una conclusión ordenada

(15)

15

El Ciclo de Vida del Proyecto vs. El Ciclo de Vida de la

Gerencia del Proyecto

Proyecto Desarrollo de Sistema

Diseño Codigo Prueba Entrenam Implement.

Inicio Planific. Inicio Planific. Inicio Planific. Inicio Planific. Inicio Planific. Ejecución

Ejecución

Ejecución Control Control Control Control

Control

Cierre Cierre Cierre Cierre

Cierre

Figure 12: Ciclo de Vida de un Proyecto vs Ciclo de Vida de Gerencia de Proyectos

Es importante el distinguir entre el ciclo de vida de un proyecto y el ciclo de vida de la gestión del proyecto. No son iguales.

El ciclo de vida del proyecto puede variar dependiendo del tipo de proyecto a entregarse. El ciclo de vida del proyecto describe lo que se necesita para hacer el trabajo necesario para el producto o servicio del proyecto. Para un proyecto de TI, tales como desarrollo de software, la vida del proyecto puede consistir de etapas tales como el diseño, programación, ensayos, capacitación y aplicación.

Al mismo tiempo, la gestión del ciclo de vida del proyecto es iterativa y se presentará en cada ciclo de vida de las fases del proyecto. La gestión de Proyecto es la disciplina que coordina la integración de estos ciclos de vida.

(16)

16

IPECC y el Ciclo de Vida del Producto

Fase Primaria

Fase Desarrollo de Producto

Desarrollo de un producto

Inalámbrico PDA

Inicio Proceso Control Proceso Planific. Proceso Ejecución Proceso Fase Siguiente

Fase Prueba de Mercado

Cierre Proceso Inicio Proceso Control Proceso Planific. Proceso Ejecución Proceso Cierre Proceso

Figure 13: IPECC y el ciclo de vida del producto Un entorno de desarrollo de un producto, tales como el desarrollo y la introducción de un nuevo dispositivo inalámbrica PDA, pueden ilustrar cómo la gestión del ciclo de vida del proyecto, o IPECC, es iterativo en un proyecto o en el ciclo de vida de un producto (ver figura 13).

Aplicacion del Mundo Real

El proceso de ciclo de vida de Gerencia de Proyectos no es lineal, y ellos pueden en algunos casos, ocurrir concurrentemente.

(17)

17

IPECC y el Ciclo de Vida de Proyectos en TI

Fase primaria

Compra de equipos

Proyecto Desarrollo de

una red de Datos

Inicio Proceso Control Proceso Planific. Proceso Ejecución Proceso Fase Siguiente

Configuracion y prueba de Hardware

Cierre Proceso Inicio Proceso Control Proceso Planific. Proceso Ejecución Proceso Cierre Proceso

USA _{Figure 14: IPECC y el ciclo de vida del producto}

La Figura 14 es un ejemplo elemental de la relación entre el proceso de gestión de grupos de proyecto estándar (IPECC) y un ciclo de vida de un proyecto de TI. Aunque esta foto muestra una relación "serial" entre las dos fases, es importante señalar que algunos de los procesos de

proyectos en una fase pueden ejecutarse concurrentemente con los de otro.

En este ejemplo, configuración de hardware y las actividades de pruebas pueden no tener que esperar hasta que sean adquiridos todos los equipos y circuitos; el equipo del proyecto puede comenzar a configurar el hardware una vez es entregado.

(18)

18

Áreas de Conocimientos en la Gestión de Proyectos



Gestión de Integración de Proyectos



Gestión de Alcances de Proyectos



Gestión del Tiempo en Proyectos



Gestión de Costos del Proyecto



Gestión de Calidad del Proyecto



Gestión de Recursos humanos del Proyecto



Gestión de Comunicaciones del Proyecto



Gestión del Riesgo en el Proyecto



Gestión de Procura en el Proyecto

Figura 15: Áreas de Conocimientos en la Gestión de Proyectos El PMI (Project Management Institute) ha identificado nueve áreas básicas del conocimiento de la gestión de proyecto que se utilizan para describir la disciplina en términos de componente de procesos, prácticas, insumos, herramientas y técnicas, y los productos. Estas nueve áreas, que sirven de marco para la gestión del proyecto, son las siguientes:

• Gestión de Integración de Proyectos: Coordinación de los elementos varios de un proyecto • Gestión de Alcances de Proyectos: Asegurarse que lo que se ha solicitado o convenido sea

lo que se entregue

• Gestión del Tiempo en Proyectos: Asegurarse que el proyecto se cumpla en los tiempos acordado

• Gestión del Costo en Proyectos: Asegurarse que el proyecto se complete satisfactoriamente dentro de los costos establecidos

• Gestión de Calidad del Proyecto: Asegurarse y garantizar que el proyecto y sus productos o servicios asociados satisfacen las necesidades que han sido acordadas

• Gestión de Recursos Humanos del Proyecto: Garantizar que las personas que trabajan en el proyecto se utilizan más eficazmente

• Gestión de Comunicaciones del Proyecto: Asegurar que la información sobre el proyecto es generada, recolectada, difundida, almacenada, y dispuesta de una manera adecuada y oportuna

• Gestión de Riesgo del Proyecto: Garantizar que las amenazas potenciales son identificadas y analizadas y que son planificadas las estrategias de respuesta adecuadas, implementadas, y controladas

• Gestión de Procura del Proyecto: Garantizar que los bienes y servicios que se requiere provienen de fuera de la organización

(19)

19

Triple Limitaciones de la Gestión de Proyectos

Calidad

Alcances

Figure 16: Triple Limitación de la Gestión de Proyectos El término limitación está asociado con límites que son impuestas sobre un proyecto. Normalmente, las limitaciones caen dentro de las siguientes categorías:

• Tiempo: Calendario

• Costos: Recursos, ambos humanos y capital

• Alcances: Elementos de trabajo producidos como parte del proyecto

El modelo de triple limitación, que se muestra en Figura 16 ilustra que cada una de estas limitaciones está interrelacionadas, y una no puede ser cambiada sin afectar uno o más de los otros. El adagio "Usted puede tener una buena, rápido, o barata — elegir cualquiera de las dos" es tan cierto en la gestión de proyectos como en cualquier otra cosa.

En gestión de los proyectos de TI por ejemplo, aumentar las características y la funcionalidad de un programa de software, o el alcance, requerirá ajustes al presupuesto del proyecto, o al costo y/o el tiempo de entrega.

Aplicaciones del Mundo Real

Es importante entender que hay otras zonas de limitación que no deben olvidarse, especialmente en un proyecto de TI. Los estándares de seguridad informática son un área importante que podría no ser tan evidentes y deben ser examinados cuidadosamente durante la planificación de proyectos. Algunas otras áreas incluyen estándares de software de la empresa, proveedores preferidos, y tecnologías nuevas o no probadas.

(20)

20

Organizaciones de los Proyectos

Una de las principales influencias sobre un proyecto es la estructura organizacional. En la gestión del proyecto, hay tres tipos diferentes de estructuras organizativas, cada una definida por la autoridad o el poder dado al gerente del proyecto. Estas estructuras organizacionales son las siguientes:

• Organización Funcional • Organización Proyectizada • Organización Matricial

Organización Funcional

El poder reside en el gerente funcional

Gerente General Funcional Gerente Funcional Gerente Funcional Gerente Funcional Gerente Funcional Gerente

Staff Staff Staff Staff Staff

* Las cajas sombreadas representan personal trabajando en un proyecto.

Figura 17: Organización Funcional La más antigua estructura organizacional es la estructura funcional. Los Proyectos son típicamente organizados y administrados dentro de los confines de una organización funcional, o silo. Las ventajas inherentes a este tipo de organización son que proporciona una estructura familiar y una carrera definida claramente, y los empleados son típicamente expertos en sus respectivas áreas funcionales. Algunas desventajas son que los cargos en el trabajo son difíciles de cambiar, los proyectos compiten por los mismos recursos, el gerente de proyecto no tiene autoridad, y no está claramente definida la gestión del gerente de proyecto.

(21)

21

Organización Proyectizada

El poder reside en el Gerente de Proyectos Gerente General

Proyectos Gerente Proyectos Gerente Proyectos Gerente Proyectos Gerente Proyectos Gerente

Figure 18: Organización Proyectizada En la organización proyectizada, el director del proyecto tiene la autoridad final, y el proyecto en sí es el principal foco de la organización. Los miembros del equipo están dedicados al proyecto, y ellos informan al gerente del proyecto.

Las ventajas de este tipo de organización incluyen un enfoque claro sobre el proyecto, lealtad al proyecto, y comunicaciones eficaces de los proyectos. Algunas desventajas incluyen la falta de seguridad laboral para los miembros del equipo cuando el proyecto termina, duplicidad de funciones y las instalaciones y un uso menos eficiente de los recursos

Esta estructura es más común en consultoría y ambientes de servicio profesional, tales como firmas contables y bufetes de abogados.

(22)

22

Organización Matricial

El poder reside en ambos: el gerente funcional y el gerente de proyectos Gerente General Funcional Gerente Funcional Gerente Funcional Gerente Funcional Gerente Funcional Gerente

Proyectos

Gerente Staff Staff Staff Staff

Figura 19: Organización Matricial

El propósito de la organización matricial es maximizar las ventajas de ambas, las estructuras funcionales y proyectizadas. En la organización matricial, los empleados informan a los gerentes funcionales en el nivel organizacional, y a su vez ellos le reportan al gerente del proyecto para los propósitos del proyecto.

El gerente funcional supervisa la labor operacional del empleado y se encarga de cuidar la labor administrativa de ese trabajador. Una vez las necesidades de recursos del proyecto están determinadas, el director del proyecto los solicita del gerente funcional y negocia para el uso de esos recursos.

Las ventajas de una organización matriz incluyen objetivos visibles, un mayor apoyo de los administradores funcionales, una mayor flexibilidad y seguridad al empleado en la continuidad de empleo aun finalizada la realización del proyecto. Algunas desventajas inherentes son que los empleados reportan a múltiples supervisores, la complejidad en la organización es mayor, y las distintas prioridades de la gestión pueden entrar en conflicto con el proyecto, causando que los recursos del proyecto puedan ser sacados en distintas direcciones.

Esta estructura es cada vez más común hoy día y es cada vez más típica en los entorno de gestión de proyectos.

(23)

23

Habilidades y Títulos del Gerente de Proyectos

Matrix Organizacion Proyectos estructura caracteristicas Funcional Matriz Debil Matriz Balanceada Matriz Fuerte Proyectizada Autoridad del Gerente de Proyectos Pequeña o ninguna Limitada Baja a moderada Moderada a alta Alta a casi total

Rol del Gerente de Proyectos

Tiempo Parcial

Tiempo Parcial Tiempo Completo

Tiempo Completo

Titulos comunes para el rol de Gerente de Proyectos Proyect coordinator/ Proyectos lider Proyect coordinator/ Proyectos lider/ Proyectos expeditor Proyectos Gerente/ Proyectos officer Proyectos Gerente/ Program Gerente Proyectos Gerente/ Program Gerente

Figura 20: Gerente de Proyectos Características y Titulos

Esta tabla resume el nivel de autoridad del gerente de proyecto como típicamente se refiere a las distintas estructuras organizacionales de los proyectos. Usted también puede notar que la organización matricial puede descomponerse en tres niveles diferentes. Esos niveles son débiles, equilibrado, y fuerte.

(24)

(25)

3

03.Iniciación del Proyecto.

Tópicos de la Sección

• Introducción al inicio del Proyecto • Elementos del Inicio del Proyecto

Ejercicios

• Desarrollo de un Caso de Negocio • Identificando los Participantes • Creación del Minicharter del Proyecto

(26)

26

Introducción al inicio del Proyecto

En este punto del proyecto:



La probabilidad de finalización del proyecto es menor



La influencia de los colaboradores es alta



El riesgo está en un máximo



Los costos esperados están muy bajos

Figure 21: Introducción al inicio del Proyecto La iniciación es el primer paso en el proceso de gestión del proyecto, y es el proceso de autorizar oficialmente un nuevo proyecto o continuar un proyecto en una próxima etapa. En este punto, la organización está comprometiendo oficialmente recursos para el proyecto. Las características del proyecto en esta etapa se enumeran en Figura 21.

Elementos de la Iniciación del Proyecto



Selección del proyecto

y

priorización



Desarrollo de un caso de negocio



Análisis e identificación de los colaboradores



Carta del

Proyecto, asignación del gerente del proyecto



Objetivos



Limitaciones y Restricciones

Figura 22: Elementos de Iniciación del Proyecto

Hay varias actividades que constituyen la iniciación de los proyectos. Normalmente, los elementos claves de esta iniciativa incluyen los que se mencionan en la figura 22.

(27)

Selección del proyecto y priorización

Métodos de selección de

Proyectos:

Optimizaciones obligatorias

Medidas Beneficiarias

Alineaciones estratégicas

Criterios de priorización de

proyectos:

Regulaciones y legalidades

Comparación de entidades

Modelo de Puntuación ponderada

Figura 23: Seleccion y Priorizacion de Proyectos Hay cantidades finitas de tiempo y recursos que puede aplicarse a un conjunto de proyectos. En otras palabras, estas organizaciones necesitan priorizar cuando se harán los trabajos. Cómo funciona una organización sin seleccionar los proyectos a realizar? Cuáles son los criterios utilizados para determinar qué proyectos hay que hacer primero?

Algunos métodos de selección estándar de proyectos incluyen:

• Optimización restringida: Este método usa modelos matemáticos y simulación informática. Tipos incluyen programación lineal y algoritmos no dinámicos. • Medición de beneficios: Este método utiliza métodos comparativos, modelos establecidos, beneficio de las contribuciones, o modelos económicos. Algunos ejemplos incluyen evaluaciones entre pares, BCR (relación costo beneficio), período de amortización, y VAN (valor presente neto).

• Alineamiento estratégico: Con este método, los proyectos son en última instancia seleccionados sobre la base de cómo alinearlos con el plan estratégico de la organización. Los proyectos que señale la organización más cerca de lograr los objetivos declarados serán ponderados más que aquellos que no.

Una vez que es seleccionada la cartera de proyectos, la organización debe determinar qué proyectos va a realizar primero.

Algunos factores para determinar la prioridad del proyecto incluyen:

• Reglamentarias y legal: Estos son los proyectos obligatorios, sobre la base de requisitos legales y reglamentarios. Algunos ejemplos son proyectos impulsados por Sarbanes-Oxley o HIPPA (Seguros de Salud Transportabilidad y rendición de cuentas Ley de 1996).

• Por comparación de entidades: Esta es una forma rápida y sencilla de comparar múltiples proyectos cabeza-a-cabeza. La comparación de entidades permite determinar la prioridad del proyecto.

• Modelo de puntuación Ponderado: Un modelo de puntuación ponderada toma en cuenta múltiples criterios para calcular el valor del proyecto a la organización. El valor de cada criterio se multiplica por un sistema de ponderación elegida por la organización, y todos los valores se suman para determinar la puntuación total del proyecto. El proyecto con el valor más alto en consecuencia es prioridad.

(28)

28

Desarrollo de Caso de Negocio

 Descripción del proyecto

 Estados actuales y futuros

 Contexto

 Necesidades del negocio

 Beneficios del proyecto

 Implicaciones Tecnológicas

 Costos del proyecto

 Alternativas y recomendaciones

 Entregables y calendarios destinos

 Criterios de satisfacción

 Aceptación (cierre)

Figura 24:Desarrollo de Caso de Negocio

Un caso de negocio sirve como base para que un proyecto pueda describir el problema del negocio o la oportunidad, soluciones alternativas, y el análisis costo beneficio. Además, ayuda a la organización seleccionar la solución preferida a ser entregados por un proyecto.

Los elementos centrales de un caso de negocio para un proyecto incluyen: • Descripción del Proyecto: Qué propone el proyecto?

• Estado actual: Cómo se hacen las cosas actualmente a las que se refiere el proyecto? • Estado Futuro: Después de completar este proyecto, cómo se harán las cosas? Cuáles

procesos cambiarán?

• Contexto: Que historial llevo a la realización de este proyecto?

• Necesidades del Negocio: Por qué hacer este proyecto para el negocio? Cuáles son los beneficios de hacer este proyecto en lugar de otro?

• Beneficios del Proyecto: Cómo este proyecto apoyara los objetivos de la organización empresarial? Que clientes solicitan este proyecto? Qué factores impulsan este

proyecto? Cuáles son otras empresas en el mercado que están haciendo actividades relacionadas con este proyecto? Cómo este proyecto ayudara a su empresa a permanecer delante de la competencia?

• Implicaciones Tecnológicas: Cómo este proyecto impactará tecnológicamente a los sistemas actuales? Es un nuevo sistema? Cuál es la arquitectura preliminar de este sistema?

• Costos del Proyecto: Cuánto costará este proyecto? Considere temas para costos tales como hardware, software, honorarios de consulta y la mano de obra. Cuál es el costo beneficio de hacer este proyecto?

• Alternativas y recomendaciones: Qué podría hacer para satisfacer esa necesidad? Por qué es esta la alternativa más recomendada?

• Entregables y Calendarios de entrega: Qué se producirá como parte del proyecto, y cuando se entregarán?

• Criterios de Satisfacción: Cuáles son las maneras que Ud. Conoce para medir los objetivos pedidos por el patrocinante?

• Aceptación (cierre): Está el segmento clave de patrocinantes o clientes de acuerdo con el caso de negocios presentado? De ser así, pueden ellos autorizar la ejecución del proyecto con una aceptación formal.

(29)

29

Inf

luen

cia

Análisis de los Impulsores

Notas

El equipo de proyecto debe considerar tanto la influencia y la importancia de los impulsores en el éxito del proyecto.

Alta Mantenerlo Satisfecho Gestionar atentamente Baja Monitorear (mínimo esfuerzo) Mantener Informado Alta Importancia

Figura 25: Análisis de los Impulsores Un impulsor es una persona u organización que pueden ser afectados, ya sea positiva o negativamente, por la ejecución o la entrega de un proyecto. Los impulsores pueden estar involucrados activa o pasivamente con el proyecto, y pueden incluir a las personas o grupos como clientes, el público, organizaciones de entrega, o patrocinadores. Pueden ejercer diversos niveles de influencia sobre el proyecto y sus respectivos aportes. Los impulsores del proyecto pueden y deben tener influencia significativa sobre un proyecto. Por lo tanto, el nivel de influencia del impulsor afecta como deben abordarse ciertos elementos del proyecto. Los dirigentes del proyecto deben tener una buena comprensión de los niveles de tolerancia de los interesados a fin de atender adecuadamente los riesgos y a dar prioridad a la importancia de las necesidades de los interesados en el cómo se relacionan con el éxito del proyecto.

(30)

30

Project Charter

Los componentes del Project Charter incluyen

:

o Título del Proyecto

o Antecedentes

o Gerente del Proyecto (debe ser asignado en este momento, si no lo han

hecho)

o Necesidades del negocio y beneficios del proyecto

o Objetivos (SMART)

o Alcances

o Entregables

o Consideraciones claves (suposiciones, restricciones, riesgos)

o Criterios de Satisfaccion

o Firmas

Figura 26: Project Charter El Project Charter es el documento oficial escrito reconociendo la existencia de un proyecto. El Project Charter sirve como la autorización oficial para comenzar el proyecto. El Project Charter debería ser emitido por un gerente fuera del proyecto y a un nivel adecuado a las necesidades del proyecto. En otras palabras, el proyecto necesita estar representado por un impulsor que promueve y apoya las razones para que el proyecto en primer lugar, exista.

Los principales componentes de un Project Charter se incluyen en la figura 26.

Objetivos

Tipos de Objetivos:



Negocio



Proyecto

Figura 27: Objetivos Hay dos tipos de objetivos que un equipo de proyecto debe considerar cuando está entregando un proyecto. Estos incluyen lo siguiente:

• Objetivos del Negocio: Estos son a menudo no medible dentro de la vida del proyecto, pero ellos representan los beneficios para el negocio u organización derivados del proyecto.

• Objetivos del Proyecto: Estos objetivos representan la definición de lo que el proyecto cumplirá. Todos los objetivos del proyecto deben ser medibles y

perfectamente realizables dentro de la vida del proyecto. Estos serán definidos entre el equipo del proyecto y los principales interesados.

(31)

31

Criterios para los Objetivos del Proyecto (SMART)



e S pecíficos



M edíbles



A cordados



R ealístas



entregados

a

T iempo

_{Figura 28: SMART Criterios para los Objetivos del} Proyecto

Una directriz útil y técnica para definir los objetivos del proyecto es la técnica de criterios SMART. Bajo la técnica SMART, cada objetivo debe ser específico, medible, acordado, realista y entregado a plazo.

Restricciones y Suposiciones

Restricciones:



Modelo Triple de restricciones: Alcances, tiempos, y costos



Locaciones, tecnología, recursos y estándares

Suposiciones:



Representan áreas de incertidumbre



Requieren más información



Son

vinculados a riesgos

Figure 29: Restricciones y Suposiciones Una restricción es cualquier obstáculo que afectará el rendimiento del proyecto o la

programación de una actividad. Ejemplos de restricciones incluyen: • Modelo Triple de restricciones: Alcances, tiempos, y costos • Otras restricciones: Locaciones, tecnología, recursos y estándares

Un suposición es algo que debe considerarse real, cierto, para algunos de los fines de la planificación. Las suposiciones deben revisarse y revalidarse o bien probada como falsas en la ejecución del proyecto.

Recomendación

Las suposiciones representan áreas de incertidumbre, necesitan más información, y son a menudo vinculados a riesgos.

(32)

(33)

33

4

04.Definición de los Alcances del Proyecto.

Tópicos de la Sección

• Visión general de los Alcances

• Requerimientos: Definiciones y Recolección • Estructura de Descomposición del Trabajo

Ejercicio

(34)

34

Visión Del Alcance

Alcance es "la suma de los productos, servicios, y los resultados

que se generan de un proyecto.

Tipos de alcances:

Alcances del

Producto

Alcances del

Proyecto

El alcance está basado en la información contenida en el project charter,

descripciones del producto, y las restricciones y suposiciones.

Figura 30: Visión del Alcance Según el PMBOK, el alcance es "la suma de los productos, servicios, y los resultados que se generan de un proyecto."4

En otras palabras, el alcance responde a los “qué " relacionadas con el proyecto, tales como qué estamos produciendo y qué trabajo debe ser llevado a cabo para entregar el producto o servicio del proyecto?

Cuándo determinar y definir el alcance del proyecto, es importante distinguir entre los siguientes tipos de alcance:

• Alcance del producto: Este se refiere a las características y funciones del producto o servicio producido por el proyecto. El alcance del producto generalmente se describe en detalle en artefactos como la documentación de los requerimientos.

• Alcance del Proyecto: Este se refiere a la labor que se requiere para producir el producto o servicio con los acuerdos de características y funciones. El alcance del proyecto está representado en los documentos tales como la EDT (Estructura de Descomposición del Trabajo).

Al describir alcance, que es una buena práctica para distinguir entre lo que está incluido y lo que no está incluido. Cualquier requerimiento no incluido en la descripción del alcance está fuera del ámbito del proyecto. Por ejemplo, si su alcance del proyecto es instalar capacidades de red inalámbrica de datos garantizados sobre todos los equipos portátiles de la empresa, la capacitación del usuario final puede no ser incluidas en el ámbito de las responsabilidades de su equipo. Por lo tanto, cualquier referencia a su alcance debería describir que las iniciativas de formación no son parte del proyecto.

Nota

Cualquier cosa no incluida en el ámbito descripción está fuera del ámbito del proyecto.

4. Project Management Institute, A Guide to the Project Management Body of Knowledge:

(35)

35

Declaración de Alcances

Notas

Una buena declaración de alcance refleja una carta de proyecto

Bien-escrita y debería incluir información relacionada a:



Justificación del Proyecto



Productos del Proyecto



Objetivos del Proyecto



Entregables del Proyecto

Figure 31: Definición de Alcances El documento de declaración de alcance es el que justifica el proyecto, los productos, los objetivos y aportes a utilizar como base para las decisiones a futuro sobre el proyecto. La declaración de alcance no es tan detallada como el plan general del proyecto, pero contiene suficientes detalles que establece todos los trabajos necesarios para completar con éxito el proyecto.

(36)

36

Requerimientos: Definiciones y Recolección

Tipos de requerimientos en los Proyectos:



Funcionales



Técnicos

Herramientas de recolección, técnicas y mecanismos:



Entrevistas



Encuestas



Información de la Industria y otros comercios



Sesiones JAD y JAR



Información

Histórica

Figure 32: Requirements: Defining and Gathering Algunos estudios concluyen que más de la mitad de los errores en un proyecto proceden de mala definición y requisitos de documentación. La prisa a las necesidades del mercado así como las limitaciones técnicas e incógnitas pueden ser factores que contribuyen a las principales causas para estos errores.

En muchos casos, los equipos de proyecto podrían centrarse sobre los requisitos asociados con la función o el diseño técnico del proyecto, pero no tanto. Es importante que el equipo del proyecto y los documentos permitan distinguir entre ambos tipos de requisitos. Los tipos de requerimientos incluyen:

• Las necesidades funcionales: Estas son características, rasgos, y las funciones que el producto debe tener para proporcionar la capacidad necesaria requerida por el usuario final o cliente. Estas son las cosas que un producto debe hacer. Por ejemplo, el

dispositivo XYZ debe permitir que el usuario pueda enviar mensajes de texto usando el formato T9 sobre el teclado numérico.

• Requisitos Técnicos: un requisito técnico es una propiedad, tales como una calidad, un atributo, o un estándar, que un producto debe tener o contener. Por ejemplo, el dispositivo XYZ debe cumplir todas las normas actuales CTIA y prestar el contenido en formato MIME

Las herramientas útiles, técnicas y mecanismos para reunir requisitos son las siguientes: • Entrevistas

• Encuestas

• Industria e información comercial

• JAR (requisitos de requerimientos de aplicación) períodos de sesiones • JAD (requisitos de diseño de aplicación) períodos de sesiones

(37)

Estructura de Descomposición del Trabajo

Proyecto Desarrollo de Software

1.0 2.0 3.0 4.0 5.0

Design Programs Testing Training Implementation

Logical Design _Executable _{Unit Testing} End User Install

Diagram _1.1 _2.1 _3.1 Training _4.1 Procedures _5.1

Detailed Design API _{System Testing} _{User Guide} Implementation

Document _1.2 Module 2.2 3.2 4.2 Scripts 5.2

TI Security Compliance 1.3 Prototype 2.3 Integration Testing 3.3 Train the Trainers 4.3 Deployment Schedule 5.3 Database Design 1.4 Code Doc. 2.4 Acceptance

Testing 3.4 Support Training

4.4 Change Control Ticket 5.4 Communications Design 1.5 Database 2.5 Test Scripts 3.5 Change Control Procedures 4.5 Sign-Off / Acceptance 5.5

Figure 33: Estructura desagregada de Trabajo El EDT es un grupo de entregables de los componentes del proyecto que organiza y define el alcance total del proyecto. Una sesión EDT es una técnica poderosa para la descomposición del alcance de un proyecto.

Nota

Debido a que sirve como base para la planificación de proyectos, la EDT puede ser la herramienta más importante de gestión de proyecto para cualquier proyecto.

Diccionario EDT

Una vez desarrollado la EDT, el equipo de proyecto debe crear un diccionario de EDT. Un diccionario EDT es un documento que describe cada elemento de la EDT con más detalle. El propósito de este documento es servir como un instrumento de referencia para los interesados, para dar a conocer descripciones adicionales de los componentes que conforman el proyecto. El sistema de numeración ilustrado en la figura 33 (por ejemplo, 4,1 Usuario final de prueba) es un ejemplo de cómo una EDT puede referir al lector a una sección particular del diccionario EDT. Al igual que otros documentos de planificación de los proyectos, la EDT debe actualizarse periódicamente para reflejar el alcance del proyecto.

(38)

38

Entregables

Entregables, Sub-Entregables, y Paquetes de Trabajos

Nombre del Proyecto

Sub-entregables

Paquetes de Trabajo

Figure 34: Entregables, Sub-Entregables, y Paquetes de Trabajo La EDT tiene muchos niveles, incluido el propio proyecto, entregables, sub-entregables, y los paquetes de trabajo. Los paquetes de trabajo constituyen el desglose lógico más bajo de cualquier ejecutable, o algo, que será producido como parte del proyecto. Los paquetes de trabajo es el nivel más bajo que un director de proyecto debe gestionar en cualquier proyecto. Las actividades específicas y tareas relacionadas con la producción del paquete de trabajo deben ser administradas por miembros del equipo.

Nota

Los paquetes de trabajo son el nivel más bajo que un director de proyecto debe gestionar en cualquier proyecto.

(39)

5

05.Gestión del Tiempo y Programación.

Tópicos de la Sección

• Descomposición en el tiempo • Diagramas de Redes

Ejercicios

• Descomponer el trabajo en Actividades • Secuenciando las Actividades

• Estimando la Duración de las Actividades • Usando Diagramas de Redes

(40)

Gestión de Proyectos basados en el PMBOK 40 Desarrolle el curriculum Escriba Contenidos Reserve

locaciones Envie boletines _{de clases}

Descomposición en el Tiempo

Desglose de Actividades

Entrenamientos

Entrenam /Internos Entrenam/Externos

Entrene Facilitad. Registre agendas Ordene refrigerios

Asegure salones

Figure 35: Descomposición en el tiempo Una vez que se han identificado los aportes específicos y los resultados esperados del proyecto, el equipo debe identificar la secuencia, y estimar la duración de las actividades necesarias para producirlos.

La descomposición del tiempo es tanto como la descomposición de los alcances, salvo que se ocupa de las actividades o acciones necesarias para producir los paquetes de trabajo y, finalmente, los

entregables.

La última salida de la descomposición del tiempo es una amplia lista de actividad.

Definición de Actividades



Fuentes de definición de actividades comunes:



Entrevistas con los expertos



Información Histórica



Tormentas de ideas

Figure 36: Definicion de actividades Las técnicas y mecanismos utilizados para definir las actividades de un proyecto son similares a los utilizados en la descomposición del alcance del proyecto. Las técnicas más notables incluyen:

• Entrevistas con los Expertos: Pregunte a los expertos, o aquellos con experiencia en proyectos similares.

• Información Histórica: Refiérase a los proyectos anteriores dentro de la organización o industria. Esta información puede encontrarse dentro de la base de conocimientos de la organización o mediante el comercio de bases de datos.

• Tormenta de ideas: Reúna a los miembros del equipo para definir las actividades como grupo.

Determine audiencia a entrenar

Determine necesidades Cree graficos Determine los _horarios

(41)

Secuenciando las Actividades

Dependencias de las Relaciones

Llegaron los equipos

Instalar equipos

Fin a Comienzo (FS)

_Completar

pruebas finales Obtener firmas Doc. tecnicos requerimientos Comienza el diseño

Fin a Fin (FF)

Comienzo a

comienzo (SS)

Nuevo router activado Viejo router removido

Comienzo a Fin (SF)

Figure 37: Secuencias de Actividades Una vez que las actividades del proyecto se han identificado, deben colocarse en el orden lógico en el que deben ocurrir. Este proceso se refiere como secuencia de actividades.

El orden de las actividades o tareas puede basarse en uno de los cuatro tipos de relaciones de dependencia como se muestra a continuación:

• FS (fin-a-comienzo): Una tarea debe finalizar antes de que la próxima comience. • SS (comienzo-a-comienzo): Una tarea puede comenzar conjuntamente con la siguiente. • FF (fin-a-fin): Una tarea puede finalizar conjuntamente con la siguiente

(42)

42

Estimación de las Duraciones de las Actividades



Técnicas Comunes de Estimación de Duración de las Actividades:



Juicio del Experto



Tormenta de Ideas



Estimación Análoga e Información Histórica



CPM (método del camino critico)



Método Delphi



Método PERT



Monte Carlo

Figure 38: Estimación de las Duraciones en las Actividades

Las técnicas más comunes y los mecanismos para la estimación de la duración de las actividades del proyecto incluyen:

• Juicio del Experto: Pregúntele a los expertos o a aquellos que tengan experiencia en Proyectos similares.

• Tormenta de Ideas: Reúna a los miembros del equipo para definir las actividades como grupo.

• Estimación Análoga e Información Histórica: Refiérase a los proyectos anteriores dentro de la organización o industria. Esta información puede encontrarse dentro de la base de conocimientos de la organización o mediante el comercio de bases de datos.

• CPM (método del camino critico): Este método es utilizado para calcular el

principio teórico comienzo y fin más temprano y comienzo y fin más tardío para todas las actividades previstas. Este proceso no considera las limitaciones de recursos. • Método Delphi: Este es un método anónimo en que los expertos sobre el tema son

estudiados a fin de lograr un consenso sobre estimaciones. Un facilitador utiliza un cuestionario para solicitar ideas acerca de las actividades importantes del proyecto. El facilitador luego resume las ideas y las hace llegar a los expertos para hacer más comentarios. Aunque puede tomar unas rondas para llegar a un consenso, este proceso reduce parcialidad e impide una persona de tener influencia en todo el proceso.

(43)

•Método PERT: Esta es una fórmula matemática utilizada para considerar el mejor caso (optimista), el peor caso (pesimista), y probablemente estimaciones para llegar a un promedio ponderado estimado (véase Figura 39).

Notas

PERT = Técnica de revisión de la evaluación de

programas (Program evaluation review technique)

Variables de la Formula:

• P = Pesimista

• O = Optimista

• ML = Más Probable

PERT estimado = P + O + 4ML 6 Desviación Estándar = P - O 6 Figure 39: PERT Tecnica • Monte Carlo: Montecarlo: Esta es una técnica en la que se

utiliza una modelación de computador compleja para determinar valores. Las distribuciones Probabilísticas de posibles duraciones son utilizadas para calcular posibles fechas de finalización.

(44)

Gestión de Proyectos basados en el PMBOK 44 Recruit Staff G Dur ES LS Await Delivery F Dur ES LS Carry Out Wk

H Dur ES LS Stage Equip.

I Dur ES LS Open Store N Dur ES LS Organize Open.

K Dur ES LS

Diagrama de Red

Método Hacia Adelante

Decide Staff

B Dur ES LS Order Equip.

E Dur ES LS

Define Req Locate Site Plan Work Install Equip. Test Equip.

A Dur

C Dur

D Dur

J Dur

M Dur

0 LS

ES LS

ES LS Ejemplo de Proyecto Implementacion de una red TI en una nueva oficina Organize Press. L Dur ES LS

Figure 40: Diagramas de Red El diagrama de red proporciona una representación gráfica de las actividades del proyecto, cómo están ordenadas, y sus respectivas dependencias. Lo más importante, el diagrama de red ilustra el camino crítico del proyecto.

Dos principales tipos de diagramas de red son comúnmente utilizados en la industria informática. Ellos incluyen:

• AON (actividad-en-nodo): También conocido como el PDM (método de diagramas de precedencia)

• AOA (actividad-en-flechas): También conocido como el método de diagramas de flechas

El método AON es el que se usara en este curso. Un ejemplo del método de diagramación AON se muestra en la Figura 40.

Camino Crítico

El camino crítico es el tiempo más largo obtenido en camino mediante el diagrama de red, y determina el menor tiempo para completar el proyecto. Agregando juntos, el tiempo para completar todas las actividades de la ruta crítica, se determinará la fecha más pronta de finalización del proyecto.

Nota

Las actividades a lo largo del camino crítico tendrán una holgura de cero días .

El camino crítico es importante porque ayuda al gerente del proyecto a determinar cuáles actividades deben ser observadas más estrechamente a fin de cumplir la finalización en fecha del proyecto. Cualquier demora en una actividad de la ruta crítica intrínsecamente retrasa la

finalización del proyecto. El equipo de proyecto deberá hacer hasta trabajo extra en algún momento o en algún otro lugar dentro del proyecto a fin de llevar el proyecto a la culminación en fecha prevista.

(45)

Recruit Staff G 4 3 LS Await Delivery F 3 5 LS Carry Out Wk

H 5 6 LS Open Store N 1 15 LS Organize Press. L 2 9 LS Stage Equip.

I Dur ES LS

La holgura contenida entre las actividades del camino no critico, ofrece al gerente de proyectos posibilidades para ajustar los recursos y así concentrarse en las actividades más críticas, es decir, aquellas que forman la ruta crítica.

Comienzo mas Temprano

Decide Staff

B 1 2 LS Order Equip.

E 1 4 LS

Define Req Locate Site Plan Work Install Equip. Test Equip.

A 2

C 2

D 2

J 1

M 2 0 LS

2 LS

4 LS

12 LS

13 LS Proyecto Ejemplo: Implementacion de una red TI en una nueva oficina Organize Open.

K 3 6 LS

Paso Hacia adelante para determinar ES

Figure 41: Comienzo mas temprano

Para encontrar el camino crítico a través de la red del proyecto, se toman en cuenta solo las actividades que tienen cero holgura, o negligentes. La holgura es la diferencia entre el LS (fecha de inicio tardía) de una actividad y el ES (fecha de inicio temprano).

Paso Hacia Adelante

El Paso Hacia Adelante por la red le permite calcular el valor ES (fecha de inicio temprano) para cada actividad.

La fórmula para calcular ES es:

ES(SUCC) = ES(CURR) + DUR(CURR)