Gestion de Proyectos Basados en El PMBOK - Manual

Gestión de Proyectos basados en el PMBOK


2


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 •

No hay ejercicios en esta sección

3


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.

4


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

5


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.

6


¿Proyectos de TI: Qué los hace diferentes? Ciclo de Vida de la Tecnología, Corto Ejecución y Desarrollo, muy Rápido

Rápida entrada en el Mercado 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.

7


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

Riesgo

Mas facil de identificar; gestionado muy pobremente pero usualmente con menos impacto negativo

Localizadas por especialidades o riesgos, a traves de lineas organizacionales 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, 2004), 6. 8


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

•

Concepto de creación de un proyecto

Ejercicio

9


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.

10


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. 11


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: PMBOK Guide, 3rd edition (Pennsylvania: Project Management Institute, Inc., 2004), 5.

12


Proyectos vs. Programas Programa

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.

3.

Ibid, 368. 13


Ciclo de Vida de la Gerencia de Proyectos

Grupo de Proceso Inicio

Grupo de Planificación

Grupo de proceso Ejecución

IPECC

Grupo de Proceso Cierre

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:

14

•

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


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

Proyecto Desarrollo de Sistema

Diseño

Codigo

Prueba

Inicio

Inicio

Inicio

Inicio

Planific.

Planific.

Planific.

Planific.

Ejecución

Ejecución

Ejecución

Ejecución

Ejecución

Control

Control

Control

Control

Control

Cierre

Cierre

Cierre

Cierre

Cierre

Inicio Planific.

Entrenam

Implement.

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.

15


IPECC y el Ciclo de Vida del Producto Desarrollo de un producto Inalámbrico PDA

Fase Primaria Fase Desarrollo de Producto Planific. Proceso

Inicio Proceso

Fase Siguiente Control Proceso

Fase Prueba de Mercado

Ejecución Proceso

Cierre Proceso

Planific. Proceso

Inicio Proceso Control Proceso

Ejecución Proceso Cierre Proceso

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

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. .

16


IPECC y el Ciclo de Vida de Proyectos en TI

Fase primaria Compra de equipos

Proyecto Desarrollo de una red de Datos

Planific. Proceso


Ejecución Proceso

Fase Siguiente Configuracion y prueba de Hardware

Cierre Proceso

Planific. Proceso


Ejecución Proceso Cierre Proceso

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) 2000 Edition ©2000 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 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.

17


Á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:

18

•

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 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

que

el

proyecto

se

complete


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.

19


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

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Funcional Gerente

* 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. Esta estructura es muy común en ambientes de manufactura.

20


Organización Proyectizada

El poder reside en el Gerente de Proyectos

Proyectos Gerente

Proyectos Gerente

Gerente General

Proyectos Gerente

Proyectos Gerente

Proyectos Gerente

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff


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.

.

21


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

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Staff

Proyectos Gerente

Staff

Staff

Staff

Staff

Funcional Gerente


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.

22


Habilidades y Títulos del Gerente de Proyectos

Matrix Organizacion estructura Proyectos caracteristicas

Funcional

Autoridad del Gerente de Proyectos

Pequeña o ninguna

Rol del Gerente de Proyectos

Titulos comunes para el rol de Gerente de Proyectos

Tiempo Parcial

Proyect coordinator/ Proyectos lider

Matriz Debil Limitada

Tiempo Parcial

Proyect coordinator/ Proyectos lider/ Proyectos expeditor

Matriz Balanceada

Matriz Fuerte

Proyectizada

Baja a moderada

Moderada a alta

Alta a casi total

Tiempo Completo

Tiempo Completo

Tiempo Completo

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.

23


24

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


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.

26


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. 27


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:

28

•

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.


Notas

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

Influencia

Alta Mantenerlo Satisfecho

Monitorear (mínimo esfuerzo)

Gestionar atentamente

Mantener Informado

Alta

Baja

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.

29


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:

30

•

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.


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.

31


32


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

•

Determinar la Estructura de Descomposición del Trabajo

Ejercicio

33


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: PMBOK Guide, 3rd edition (Pennsylvania: Project Management Institute, Inc., 2004), 375. 34


Notas

Declaración de Alcances 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.

35


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:

36

•

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

•

Información histórica referencial


Estructura de Descomposición del Trabajo Proyecto Desarrollo de Software 2.0

1.0

Design

3.0

Programs

Logical Design

API

Document 1.2 TI Security Compliance 1.3

Module

System Testing

Prototype 2.3

Integration Testing 3.3

Code Doc. 2.4

Acceptance Testing 3.4

Database 2.5

Test Scripts 3.5

Database Design 1.4 Communications Design 1.5

Training

Install 4.1

Procedures 5.1 Implementation

User Guide

3.2

2.2

Implementation

End User 3.1

2.1

Detailed Design

Training

Unit Testing

Executable

Diagram 1.1

5.0

4.0

Testing

4.2

Train the Trainers 4.3

Support Training 4.4 Change Control Procedures 4.5

Scripts

5.2

Deployment Schedule 5.3 Change Control Ticket 5.4 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.

37


Entregables, Sub-Entregables, y Paquetes de Trabajos Entregables 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.

38

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


Descomposición en el Tiempo Desglose de Actividades Entrenamientos Entrenam /Internos

Determine audiencia a entrenar Cree graficos

Entrene Facilitad.

Determine necesidades Determine los horarios Registre agendas

Entrenam/Externos

Desarrolle el curriculum

Escriba Contenidos

Reserve locaciones

Envie boletines de clases

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:

40

•

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.


Secuenciando las Actividades Dependencias de las Relaciones Llegaron los equipos

Instalar equipos

Fin a Comienzo (FS)

Doc. tecnicos requerimientos

Comienza el diseño

Comienzo a comienzo (SS)

Completar pruebas finales

Obtener firmas

Fin a Fin (FF) 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

•

SF (comienzo-a-fin): Una tarea debe comenzar para que la siguiente termine.

41


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:

42

•

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.


•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.

43


Diagrama de Red Método Hacia Adelante Recruit Staff

Decide Staff B

Dur

ES

LS

Define Req

Locate Site

E

Dur LS

Plan Work

Dur LS

Await Delivery

Order Equip.

ES

G ES

Carry Out Wk

F

Dur

ES

LS

Stage Equip.

Install Equip.

Test Equip.

Open Store

A

Dur

C

Dur

D

Dur

H

Dur

I

Dur

J

Dur

M

Dur

N

Dur

0

LS

ES

LS

ES

LS

ES

LS

ES

LS

ES

LS

ES

LS

ES

LS

Ejemplo de Proyecto Implementacion de una red TI en una nueva oficina

Organize Open.

Organize Press.

K

Dur

L

Dur

ES

LS

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. 44


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 Recruit Staff Decide Staff B

1

2

LS

Locate Site

4

3

LS

Await Delivery Order Equip.

Define Req

G

E

1

4

LS

Plan Work

Carry Out Wk

F

3

5

LS

Stage Equip.

Install Equip.

Test Equip.

Open Store

A

2

C

2

D

2

H

5

I

Dur

J

1

M

2

N

1

0

LS

2

LS

4

LS

6

LS

ES

LS

12

LS

13

LS

15

LS

Proyecto Ejemplo: Implementacion de una red TI en una nueva oficina

Organize Open.

Organize Press.

K

3

L

2

6

LS

9

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) donde CURR = actividad actual, y SUCC = actividad sucesora

45


Fecha más Tardía 6

6

Decide Staff

Recruit Staff

B

1

G

4

2

8

3

9

3

3

Order Equip.

Await Delivery

F

E

1

3

5

4

7

8

0

0

0

0

Define Req

Locate Site

Plan Work

Carry Out Wk

Holgura

0 Stage Equip.

0

0

0

Install Equip.

Test Equip.

Open Store

A

2

C

2

D

2

H

5

I

1

J

1

M

2

N

1

0

0

2

2

4

4

6

6

11

11

12

12

13

13

15

15

Proyecto: Implementación de una red TI en una nueva oficina

Camino Critico

4 Organize Open.

4 Organize Press.

K

3

L

2

6

10

9

13

Paso Hacia Atras Para Determinar Comienzo Mas Tardio Figure 42: Fecha más Tardía

Paso Hacia Atras El Paso Hacia Atras a traves de la red permite calcular el valor LS para cada actividad. La fórmula para calcular LS es: LS(PRED) = LS(CURR)–DUR(PRED) donde CURR = actividad actual, y PRED = actividad predecesora

Holgura Una vez determinados los valores de ES y LS, la holgura para cada actividad se puede determinar con la siguiente fórmula: Holgura (CURR) = LS (CURR)–ES(CURR) donde CURR = actividad actual

46


6 06.Planificación de los Recursos. Tópicos de la Sección •

Identificación de los Recursos del Proyecto

•

Gestión de los Recursos

•

Restricciones de los Recursos

•

Identificar los requerimientos de los Recursos

•

Creación de un Calendario de Recursos

Ejercicio

47


Identificación de los Recursos Requeridos El objetivo de la planificación de recursos es desarrollar funciones y responsabilidades para el proyecto, que se basan en la labor a realizarse para entregar los productos o servicios del proyecto. El director del proyecto es responsable de crear las funciones y responsabilidades de los miembros del equipo. Las funciones del proyecto se refieren a quién hace qué sobre el proyecto, mientras que las responsabilidades se refieren a quien decide qué en relación con el proyecto. Las funciones y responsabilidades deben estar estrechamente alineadas con la definición del alcance del proyecto. Las herramientas útiles para comunicar y gestionar las funciones y responsabilidades de un equipo de proyectos incluyen matriz de funciones y responsabilidades, o R & R, y la matriz asignación de recursos, o RAM

Matriz de Roles y Responsabilidades

Figure 43: Matriz de Roles y Responsabilidades

La matriz de funciones y responsabilidades describe las funciones y responsabilidades específicas de cada miembro del equipo. Proporciona una referencia textual útil para el equipo del proyecto y los asociados interesados.

48


Matriz de Asignación de Recursos Versión PARIS Persona Persona A B

Clave: P: A: R: I: S:

Tarea A

Participante Responsable Revisor requerido Entrada requerida Firma requerida

A

Tarea B Tarea C

S

Persona D

I

S

R

S

A

A

Tarea D Tarea E

Persona C

S

P

S

P

R

A

A

Figure 44: Matriz de Asignación de Recursos

La matriz asignación de recursos es una representación gráfica de los miembros del equipo los cuales son responsables de alguna labor específica. Esta herramienta no muestra cuando se debe hacer el trabajo. Existen algunas variantes de la matriz de asignación de recursos, las cuales incluyen lo siguiente: •

SCARI: Cierre, consultado, responsable, responsabilidad, informado

•

PARIS: Participante, responsable, revisor requerido, entrada requerida, cierre

•

CIRANO: Crear, entradas, revisores, aprobados, notificados, propietarios

Una versión de la matriz PARIS se muestra en la Figura 44.

Gestión del Staff

25 20 16 15

Mar

6

Abr

5

8

Feb

10

12

Ene

Equivalencia del grupo a Tiempo Completo

Calendario de Recursos

Meses Figura 45: Calendario de recurso

49


Un plan de gestión personal es muy similar a un cronograma de proyecto, salvo que se ocupa de la programación de la gente versus tareas. El calendario de los recursos es una herramienta útil para ilustrar cuando la gente está realizando y ha finalizado tareas de un proyecto. Esta herramienta es beneficiosa durante la planificación de proyectos, y también sirve como un medio para que el director del proyecto pueda comunicarse con los administradores funcionales. Los calendarios de recursos le dicen a los administradores funcionales cuando serán necesarios sus recursos para satisfacer las necesidades de los proyectos. Los calendario de recursos pueden establecerse como un histograma, como en la Figura 45, o en un formato hoja de cálculo. El nivel de detalle de los calendarios de los recursos puede variar dependiendo del tamaño, alcance o la complejidad del proyecto.

Calendario de un Recurso para un Equipo de Trabajo

40

32

30

12 Sem 4

Sem 3

10

16

Sem 2

20

24

Sem 1

Horas por semana

50*

Patricia Marcano Arquitecto de Seguridad de TI Figure 46: Calendario de Recurso para un miembro del grupo

Los calendarios de recursos también pueden ser utilizados para ilustrar la asignación prevista a un miembro específico del equipo en un proyecto. Particularmente en un estilo de organización matricial, un director de proyecto puede comunicarse efectivamente la cantidad aproximada de tiempo necesario de un recurso para un proyecto. Este es un ejemplo de las horas requeridas por semana, pero esta herramienta puede ser utilizada para describir horas por día, días por mes, etc. Un gerente de recursos será probablemente más susceptible a proporcionar un recurso clave cuando tiene una idea aproximada de La cantidad de tiempo que se tomara el recurso para realizar la tarea.

50


Restricciones en los Recursos Estructura Organizacional Trato Colectivo Preferencias del grupo de Proyecto Expectativas de asignación del grupo Tecnología y complejidad Figure 47: Restricciones de los Recursos

Un hecho en la gestión de proyectos es que los recursos de la organización son finitos. Ninguna organización puede hacer todo para todos. Tiempo y prioridad son limitaciones inherentes en cualquier proyecto. Una restricción es algo que limita las opciones o la capacidad del equipo para entregar un proyecto con éxito. Algunas restricciones específicas al grupo deben considerar lo siguiente: •

Estructura organizacional: La estructura de la organización, la mayor parte, predefine la fortaleza de la función de la gerente del proyecto. Por ejemplo, una estructura matricial sólida da generalmente el gerente de proyectos más poder que una estructura matricial débil.

•

Acuerdos de negociación colectiva: Un grupo de empleados organizados, tales como un sindicato, puede requerir relaciones de informes específicos, los cuales deben tenerse en cuenta. Aunque no es tan común en la industria informática como en otras industrias, la proliferación de subcontratación de organizaciones externas bajo convenios colectivos puede afectar el equipo del proyecto.

•

Preferencias del equipo del proyecto: Las preferencias del equipo pueden ser un obstáculo si los miembros del equipo prefieren una cierta estructura porque son más cómodas con ella o porque han tenido éxito con ella en el pasado. En el entorno de trabajo, los miembros del equipo pueden sentirse más cómodos si participan en un diseño de una red de datos versus un proyecto de desarrollo de software.

•

Logros en las asignaciones de funcionarios: La organización del equipo estará influenciada por la capacidad de los miembros del equipo.

•

Tecnología y complejidad: La tecnología elegida para ser empleada en un proyecto puede tener un impacto negativo sobre el éxito del proyecto, especialmente si es una nueva tecnología.

51


52

7 07.Control y Gestión de Costos. Tópicos de la Sección •

Técnicas de Estimación de Costos

•

Tipos de Estimaciones

•

Controlando y Gestionando los Costos

•

Desarrollando un Proyecto de Estimación de Costos

Ejercicio


Técnicas de Estimación de Costos Técnicas comunes de estimación: Análogas Paramétricas

Hacia Abajo

Hacia Arriba

Otras técnicas de estimación:

Delphi PERT Figura 48: Técnicas de Estimación de Costos

Estimar los gastos para los proyectos es muy similar a estimar los tiempos de un proyecto; tampoco es una ciencia exacta. Sin embargo, los equipos del proyecto deben intentar dar estimaciones tan precisas como sea posible. Algunas técnicas comunes de estimación de costos incluyen lo siguiente: •

Análogas: en ocasiones se refieren a un análisis como de arriba-abajo, las estimaciones análogas son realizadas utilizando la información obtenida mediante indicaciones de expertos o utilizando los datos de proyectos anteriores con características similares. Esta es una de las formas más rápidas y menos costosas para elaborar estimaciones, y se puede hacer en la tarea, la actividad, los ejecutables o por niveles de proyectos. Las estimaciones Análogas son más precisas cuando el proyecto anterior es similar al proyecto actual.

•

Modelado Paramétrico: La modelación Paramétrica es otra forma de análisis de arriba hacia abajo. En esta técnica, los parámetros, o características del proyecto, se utilizan para calcular costos totales. Algunos ejemplos comunes de estimaciones paramétricas incluyen los gastos por pie cuadrado en la construcción, los costos por milla en la construcción de carreteras, y los costos por líneas de código en TI. Esta técnica puede producir estimaciones más precisas que la técnica de estimación análoga, pero las estimaciones son más costosas para la producción.

•

Estimaciones Descendentes: Implica estimar el costo para cada paquete de trabajo o actividad en la WBS y luego añadir todas las estimaciones juntas para conseguir el costo estimado del proyecto. Con este método se debe empezar con los detalles y trabajar su camino hasta el final. Es mejor a realizar los recursos que realmente hacen el trabajo para crear las estimaciones. Esta técnica es más útil cuando el resultado deseado es un proyecto o una referencia de estimación más definitiva. Esta técnica es difícil de utilizar en las etapas tempranas del proyecto, como en la iniciación de proyecto, porque los detalles necesitados no son típicamente todavía no conocidos.

Las técnicas de estimación Delphi y PERT, que son utilizadas para estimar las duraciones de las actividades, también son útiles para estimar los gastos. Estas técnicas pueden ayudar al equipo de proyecto a refinar y producir estimaciones más exactas de los gastos.

54


Tipos de Estimaciones Tipo de Estimacion Magnitud del pedido

Presupuesto

Definitivo

Rango de Exactitud

Fase

-25% to +75%

Iniciacion

-10% to +25%

Planificacion

-5% to +10%

Planificacion Figure 49: Tipos de Estimacion

El monto, disponibilidad y el acceso a información detallada puede afectar la exactitud de las estimaciones. Debido a esto, es útil para proporcionar estimaciones de costos en diversos niveles de confianza. Hay tres tipos de estimaciones de los costos que deben ser consideradas durante las distintas fases del proyecto. Ellas incluyen: •

Orden de magnitud: Generalmente desarrollados durante la fase de iniciación, esta estimación debe abarcar un rango desde - 25 a + 75 por ciento a Nivel de los costos reales.

•

Presupuesto: Un pronta estimación de la planificación, este tipo suele oscilar entre – 10 por ciento a +25 por ciento de los costos reales de los proyectos.

•

Definitivas: En la culminación de la planificación de proyectos, pueden ser desarrollados una estimación clara, desde — 5 por ciento a +10 por ciento de los gastos reales.

55


Gestión de Contingencia y Reservas La reserva de contingencia (el presupuesto): el juego de fijar el tiempo o el dinero para direccionar el riesgo específico: Tomar en consideración los riesgos de dirección no identificado fácilmente "Conocidos desconocidos” Controlados por el gerente del proyecto PMI recomienda el 10% del costo total del proyecto Controlado por la dirección o alguien encima del director de proyecto Figure 50: Gestión de Contingencia y Reservas

A menudo, los presupuestos de los proyectos están aprobados y asignados basados simplemente en las estimaciones de gastos desarrolladas durante la fase de planificación. Aunque estas estimaciones de los trabajos representan la mayoría de los costos del proyecto, ellos deben incluir dos nuevos elementos de costo: las reservas para imprevistos y la gestión de reservas. Ambos, gestión de imprevistos y reserva de presupuestos representan el dinero destinado a tratar con eventos de riesgo conocidos y desconocidos. Las reservas de contingencia son típicamente controladas por el director del proyecto y se determina utilizando EMV (Valor monetario de Crédito). La gestión de reservas normalmente están controladas por alguien más en las filas de la organización que el director del proyecto y están diseñados para hacer frente a los eventos "desconocidos" que puede afectar el proyecto. Un margen general para la reserva de gestión está entre 10 y 15 por ciento de los costos estimados del proyecto.

Nota El presupuesto total del proyecto debería incluir las estimaciones de trabajo, presupuesto de contingencia, y gestión de reserva.

56


Gestión y Control de Costos Análisis del Valor Ganado El análisis EV (ganado valor) es una técnica que ayuda a evaluar la magnitud de cualquier variación en costo o calendario que pueden afectar la ejecución del proyecto. Los datos provenientes del análisis EV, puede utilizarse efectivamente para vigilar y controlar los gastos del proyecto. Las fórmulas estándares de análisis EV se incluyen en la Figura 51. Nombre

Formula

Descripcion

Variacion de Costo

CV = EV – AC

donde: CV = variación de costo EV= valor Ganado AC = costo actual

Variacion programada

SV = EV – PV

donde: SV = variación programada PV = valor planificado

Indice de comportamiento de Costo CPI = EV ÷ AC

donde: CPI = Indice de comportamiento de Costo

Indice de comportamiento programado

SPI = EV ÷ PV

donde: SPI = Indice de comportamiento programado

Estimacion a la completacion (formula 1)

EAC = BAC ÷ CPI

donde: EAC = Estimacion a la completacion BAC = presupuesto a la completacion


EAC = AC + ETC

donde: EAC = Estimacion a la completacion


EAC = AC + BAC - EV

donde: EAC = Estimacion a la completacion BAC = budget a la completacion

Variacion a la completacion

VAC = BAC – EAC

donde: VAC = Variación a la completacion

Estimacion a completar

ETC = EAC – AC

donde: ETC = Estimacion a completar

Figura 51: Analisis del valor Ganado

•

AC (Costo real): Representante de lo que el proyecto ha gastado en un punto específico en el tiempo o la fecha. Esta es la suma de todos los costes acumulados.

•

EV (Crédito Valor): El valor de los proyectos terminados trabajar en un determinado tiempo o fecha. 57


•

PV (Valor Previsto): La cantidad que el proyecto debería haber gastado en un punto específico en el tiempo o a la fecha.

•

CAPV (presupuesto en complemento): El costo total esperado que se gasta en el proyecto. Este es el costo original o estimación de referencia para el proyecto.

•

CV (Diferencia Costo): La diferencia entre la labor realizada (EV) y lo que se ha gastado en este punto (CA).

•

SV (Variación de programa): la diferencia entre los (EV) terminados de trabajo yLo que debe haber sido terminado a este punto (PV).

•

IPC (el índice de eficiencia de costo): mide la eficiencia del proyecto cuando se relaciona con el presupuesto. En relación con dólares, mide cuántos centavos del regreso por cada dólar se ha gastado en un momento determinado.

•

SPI (el índice de rendimiento de programa): las medidas que el progreso en un por ciento de la tarifa originalmente planeó terminar en un momento en particular.

•

EAC (Estimacion en Completacion) (fórmula1): un pronóstico que representa el coste final proyectado actual del proyecto sobre la base del (IPC) de eficiencia de gasto actual. Esta fórmula es use si las tasas de gasto son Estimaciones a seguir.

•

EAC (Estimacion en Completacion) (fórmula2): un pronóstico que representa el coste final proyectado actual del proyecto. Esta fórmula es usada si las Estimaciones originales o la base para Estimaciones son inexactas o han cambiado (por ejemplo, las tasas por hora para programadores contratados son más que las Estimaciones originales).

•

EAC (Estimacion en Completacion) (fórmula3): un pronóstico que representa el coste final proyectado del proyecto. Esta fórmula es usada cuando hay Variaciónes atípicas que son propensas a ocurrir otra vez (por ejemplo, el equipo de proyecto pre-paga recursos de configuración de equipo físico en lugar de pagarlos con el tiempo originalmente planificada).

•

VAC (Variación en Completacion): la diferencia entre el presupuesto original o de punto de partida (BAC) y el Estimacion en completacion (EAC). La diferencia retrata cuánto sobre o bajo el presupuesto el proyecto ha terminado (o terminara se debe usar como una proyección).

•

ETC (Estimacion para completar): la cantidad de dinero necesaria para terminar el proyecto sobre la base de la eficiencia de gasto actual del proyecto.

Controlando y Gestionando los Costos: Análisis de Valor Ganado Su patrocinador del proyecto, James Strickland, los ha convocado a una reunión de gestión ejecutiva de emergencia. El objetivo de esta reunión es examinar el portafolio de proyecto de la organización y determinar qué proyectos (si cualquier) debe terminarse, suspenderse, o la continuación del actual progreso basados contra los planes originales. El Sr. Strickland ha solicitado que usted, el director del proyecto, recopile datos precisos sobre el Proyecto Sistema Monitoreo Remoto; progresos del calendario, condición, y las previsiones. Usted utilizará la técnica de EVA (análisis de valor ganado) para proveer al patrocinador esta información.

58


Los datos actuales del proyecto se muestran en la tabla:

Entregables

Estimacion de Duración

Estimacion de Gastos Estado

Desarrollo de estación de base de casa

2 Meses

$80,000

100%

Configuración de equipo físico

.5 Mes

$20,000

100%

Programador interfaz de aplicación

1 Mes

$35,000

100%

1.5 Mes

$75,000

50%

Procesador de transacción de base de datos

1 Mes

$40,000

10%

Material de entrenamiento

.5 Mes

$15,000

0%

Infraestructura de soporte

.5 Mes

$25,000

40%

7 Meses

$290,000

Software de observación

Figure 52: Datos actuales Sistema de Monitoreo Remoto

Usted está en el 5 mes en un proyecto de 7 meses y ha gastado $160.000 en este punto. El Sr. Strickland desea saber si su proyecto está actualmente en fecha y en presupuesto. Además, Strickland desea determinar si el proyecto se pronostica para cumplir las estimaciones de tiempo y del costo actual Basado en la data actual del proyecto, cuál sería: •

BAC (presupuesto a la completacion):

•

EV (Valor Ganado):

•

PV (Valor Planificado):

•

AC (Costo Actual):

•

CV (Variaciones de Costo):

•

SV (Variación Programada):

•

CPI (Indice de comportamiento de Costo):

•

SPI (Índice De Rendimiento De Programa):

•

EAC (Estimacion al Completar):

•

VAC (Variación al Completar):

•

ETC (Estimacion a Completar):

Una hora despues de envíada esta información a Sr. Strickland, usted recibe una llamada telefónica de Oro Wilson que le alerta que él encontró el valor de $30.000 de las facturas del contratista que no se han procesado en el plan contable. Consecuentemente, la información que usted proporcionó al Sr. Strickland no es exacta. Usted debe revisar sus datos del informe y llevarlos al Sr. Strickland CUANTO ANTES. Recalcule la información de EVA basada en esta revelación.

59


Incorporando los $30,000 de las facturas del contratista, cuales seran los valores de:

60

•

BAC (presupuesto a la completacion): _________________

•

EV (Valor Ganado): _________________

•

PV (Valor Planificado): ______________

•

AC (Costo Actual): __________________

•

CV (Variaciones de Costo): ___________

•

SV (Variación Programada): ___________

•

CPI (Indice de comportamiento de Costo): _____________

•

SPI (Índice De Rendimiento De Programa): ____________

•

EAC (Estimacion al Completar): _______________

•

VAC (Variación al Completar): ________________

•

ETC (Estimacion a Completar): ________________


8 08.Gestión de Comunicaciones.

Temas de la Sección •

Gestión de las expectativas del grupo

•

Consideraciones para la comunicación eficaz

•

Plan de dirección de comunicación

•

Informe de Status del Proyecto

•

Crear un plan de dirección de comunicación

•

Preparar un informe de status del proyecto

Ejercicio

61


Gestión de las Expectativas de los Involucrados ¿Cuáles expectativas necesitan ser gestionadas? Patrocinador del Proyecto Clientes y usuarios finales Gestión de Alta Gerencia Gerentes de otros Proyectos Equipo de Proyecto

Figura 53: Gestión de las Expectativas de los Involucrados

La gestión de comunicaciones es uno de los aspectos más importantes de la gestión del proyecto. La gestión eficaz de las comunicaciones de un proyecto implica el manejo adecuado de información, incluyendo la generación adecuada y oportuna, recolección, distribución, almacenamiento y la presentación de información sobre el proyecto. Las formas de comunicación pueden incluir requisitos, programaciones de actividades, informes, o problemas en el proyecto. El éxito del proyecto se medirá por reuniones con los interesados (ver si se cumplen las expectativas). Además de ver que el costo, el tiempo, y el alcance (requisitos de un proyecto) se cumplen, el director del proyecto debe administrar eficazmente las comunicaciones con los interesados. El Project Management Institute sostiene que 90 por ciento de tiempo del supervisor de un proyecto es típicamente gastado en comunicaciones con los interesados. Los interesados claves que deben participar activamente en el proceso de comunicaciones del proyecto están enumerados en la figura 53.

62


Consideraciones para la Comunicación Eficaz Para todos los proyectos, las siguientes variables tienen que ser Consideradas cuidadosamente: Tipos de comunicación Barreras y realces Líneas de comunicación Formularios y propiedad Medios de comunicación y métodos de distribución Equipos International y virtuales Prácticas de reunión efectivas Figura 54: Consideraciones para la Comunicación Eficaz

La comunicación efectiva en un proyecto es más que sólo anfitriones de reuniones y distribuir correos electrónicos. En el medio ambiente de los proyectos, un director de proyecto debe considerar muchas variables a fin de mejorar la comunicación. Algunas consideraciones clave son las siguientes: •

Tipos de comunicación: Investigación, informativos y persuasivo

•

Obstáculos y potencias: El ruido y la distancia, percepciones, credibilidad del remitente, limitaciones en la transmisión, culturas, traducción y complejidades técnicas

•

Líneas de comunicación: Número de personas o grupos que deben ser informados

•

Formas y conveniencia: Escrita, tanto formal como informal y verbales, tanto formal como informal

•

Medios de comunicación y métodos de distribución: papel, e-mail, presentaciones, Internet, intranet y teléfono

•

Los equipos virtuales e Internacionales: Los miembros del equipo del Proyecto no siempre se encuentran en el mismo lugar, especialmente con equipos o proyectos de subcontratación mundiales

•

Prácticas de reunión eficaz: Agendas pre programadas, expectativas y responsabilidades, preparación, temas de acción, resumen o minutos, y seguimiento

63


Líneas de Comunicación El número líneas comunicación define por formula:

de de se la

N x (N - 1) 2 donde N es el número de personas comunicándose. Figure 55: Líneas de Comunicación

Cuanto más personas están sobre un proyecto, es más grande el número de enlaces de comunicación. Esto añade la complejidad y el coste al proyecto, y puede disminuir la velocidad del proceso de comunicación potencialmente. Los modelos de red de Comunicación, tales como el modelo en la Figura 55, fueron creados para explicar la relación entre el número de personas y el número de interacciones necesarios. El número de enlaces de comunicación aumenta rápidamente al momento que usted agrega más gente. El número de enlaces de comunicación es definido por la fórmula [N × (N-1) ] ÷ 2, donde N es el número de personas a comunicarse. Por ejemplo, si hay 5 personas en la red, el rendimiento es (5 × 4) ÷ 2, o 10 vínculos de comunicación, o canales, que deben mantenerse. Si hay 10 personas en la red, debe mantenerse 45 vínculos de comunicación.

64


Formas de Comunicación Tipo

Formal

Escrita

Documentos firmados, documentos técnicos o complejos, culturales

Verbal

Presentaciones, discursos

Informal

E-mails, notas

Conversaciones, reuniones

Figure 56: Formas de Comunicacion

Las comunicaciones con los interesados del proyecto pueden lograrse verbalmente o por escrito, y pueden ser formales o informales. El desafío para el equipo del proyecto es seleccionar la forma apropiada al transferir información a los interesados. Cada forma tiene sus ventajas. La comunicación verbal es típicamente más rápida, más fácil, y menos complicado que la comunicación escrita. Sin embargo, la comunicación escrita permite más detalle a la organización, especialmente cuando se está entregando información técnica.

65


Gestión del Plan de Comunicaciones Elementos de un plan de comunicaciones: Procesar y Recolectar Información Plan de Distribución Descripción de la Información Distribución Programada Medios de Acceso Procesos de Mantenimiento y Actualización Figure 57: Gestión del Plan de Comunicaciones

El director de proyecto es responsable de crear el plan de dirección de comunicación. Este plan incluye una explicación de cómo recolectar, guardar y modificar el material de proyecto escrito existente. Incluye una lista de las clases de información necesarias, los miembros de equipo responsables de distribuir la información, y las instrucciones de porque cómo y cuándo será distribuida la información. El plan de comunicación se hace una parte del plan de proyecto. La comunicación es crítica para el éxito de todos proyectos; sin embargo, las necesidades de información y los métodos de comunicación usados variarán por proyecto y deberán ser documentados. Los elementos claves de un plan de comunicación incluyen lo siguiente:

66

•

Procesos de recolección y de almacenado de la información del proyecto

•

Plan de distribución que bosqueja las formas de la comunicación y los respectivos receptores

•

Descripción de la información

•

Programa para la distribución

•

Medios para acceder a la información

•

Procesos para actualizar y mantener la información


Reporte de Estatus del Proyecto Los elementos fundamentales de un reporte incluyen: Entregables ‹ Progresos o logros desde el informe previo ‹ Estatus del proyecto completo ‹ Actividades planificadas para los próximos reportes

Hitos Problemas críticos y Riesgos Estatus financiero y forecasts Planes de acción y próximos pasos Figure 58: Reporte de Estatus del Proyecto

Diseñar y repartir un informe de estado de proyecto es uno de los desafíos más comunes para un equipo de proyecto, especialmente en el ambiente de campo. Los diferentes grupos colaboradores quieren presentar la información en maneras diferentes. Por consiguiente, es imperativo que el equipo de proyecto de una idea general de los patrones y los procedimientos para su elaboración evidentemente a comienzos del proyecto. Los informes de proyecto pueden incluir elementos diferentes, depender del tamaño y alcance del proyecto tanto como sobre la cultura de la organización. Un informe simple de status del proyecto eficaz, debe incluir los elementos indicados en la lista de la figura58.

67


68


9 09.Gestión de Riesgo del Proyecto. Temas de la Sección •

Elementos esenciales de la prevención de siniestros de proyecto

•

Orígenes de riesgo para los proyectos de TI

•

Tolerancia de riesgo de grupo de colaboradores

•

Identificación de riesgo

•

Clasificación de riesgo

•

Disparadores de riesgo

•

Estrategias de respuesta de riesgo

•

Determinar los riesgos de un proyecto

•

Determinar las estrategias de respuesta de riesgo

Ejercicio

69


Lo Esencial en la Gestión de Riesgo de Proyecto

Figure 59: Lo Esencial en la Gestión de Riesgo de Proyecto

La prevención de siniestros inadecuada o inexistente es una de las principales causas para el fracaso de proyecto. A menudo, los jefes de proyecto no promueven un ambiente que tiene previsto el, identificar, analizar, direccionar o controlar los eventos que alejan un proyecto de la meta apropiadamente. A veces, estos eventos imprevistos (los riesgos) terminan prematura y totalmente los proyectos. El PMI (instituto de dirección de proyecto) contempla que la correcta prevención de siniestros puede reducir los problemas de los proyecto por casi un 90 por ciento. Términos importantes para el conocimiento de riesgo incluyen: • Riesgo: de acuerdo con el Diccionario de la Universidad de Webster5, un riesgo es una exposición para la oportunidad de lesión o pérdida; un peligro. Poniendo esto en el contexto de dirección de proyecto, la guía para el cuerpo de dirección de proyecto de conocimientos (Guide de PMBOK) 6 define el riesgo como "Un evento incierto o la condición de un evento que si ocurre, tiene un efecto seguro o en contra sobre los objetivos de un proyecto." •

Riesgos conocidos y desconocidos: los riesgos pueden ser ambos conocidos y desconocidos. Los riesgos conocidos son aquellos que pueden ser identificados y dirigido por el equipo de proyecto. Los riesgos desconocidos no son identificados fácilmente y pueden ser llevados proactivamente; por lo tanto, son direccionados típicamente a través de una contingencia sobre la base de la información histórica o por el criterio del experto, o la experiencia de los miembros de los equipos.

•

El riesgo del negocio versus. Riesgo de proyecto: el riesgo del negocio se concentra en cómo puede ser afectada por el proyecto la empresa, mientras que el riesgo de proyecto es enfocado en las cosas que pueden afectar el éxito del proyecto. Aunque debe ser considerado durante la planificación de la prevención de siniestros, el riesgo de la empresa no está bajo el control directo del director de proyecto. El riesgo de proyecto, por otro lado, está dentro del control del director de proyecto y debe ser el foco para la prevención de siniestros de los procesos.

5. Webster’s College Dictionary (New York: Random House, Inc., 1991). 6. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 3rd edition (Pennsylvania: Project Management Institute, 004) 70


•El riesgo negativo versus. Riesgo positivo: aunque los riesgos son típicamente visto como los impactos negativos a un proyecto, algunos pueden ser positivos. Dentro del contexto de la dirección de proyecto los riesgos negativos son comparados a las amenazas para el éxito del proyecto. Una amenaza de huelga en la empresa naviera podía plantear un riesgo crítico a un proyecto si está programado para ser repartido los equipos de computación en el momento oportuno por la firma. El competidor principal de una organización podría plantear una amenaza (el riesgo negativo) si ha acelerado su programa de lanzamiento, creando una necesidad urgente para usted cubrir (o sobrepasar) sus requisitos de programa, por lo tanto, aunque no tan común, un proyecto también podría tener riesgos seguros. Éstos son también conocidos como las oportunidades. Por ejemplo, asignar recursos adicionales para conocer la amenaza del competidor puede hacerse una oportunidad para el equipo de proyecto acelerar la entrega que al final beneficiará los objetivos de proyecto.

71


Fuentes de Riesgo para el Proyecto Proyecto

Tecnicos Requerimientos

Tecnológicos Complejidad e interface Rendimiento y confiabilidad Calidad

Externos

Organizacionales

Subcontratos y proveedores

Dependencia Project

Regulatorio

Mercado

Cliente

Tiempo

Recursos

Funding

Priorización

Gestión de Proyecto

Estimaciones

Planificación

Control

Comunicación

Estructura de Ruptura de Riesgo Figure 60: Fuentes de Riesgo para el Proyecto

Una RBS (estructura de falla de riesgo) es un enfoque útil para suministrar la estructura e identificar y categorizar los riesgos para el proyecto. El RBS es un diagrama jerárquico que ayuda constituir y categorizar los riesgos de alto nivel. Esencialmente, suministra una herramienta visual de ayudar rápidamente a empezar el proceso de planificación de riesgo. A comienzos del proyecto, los equipos pueden identificar categorías de alto nivel que son tan poco común para su tipo de proyecto o el uso de información organizativa existente en la historia previa de los proyecto, por ejemplo. El RBS debe ser reconsiderado y actualizado durante todo el proyecto. Algunas categorías de riesgo comunes que pueden ser incluidas en un RBS son:

72

•

Técnico, la calidad, o el rendimiento: la nueva tecnología sin probar

•

Apariencia: requisitos reguladores, los asuntos legales, los mercados y las condiciones económicas

•

Organizativo (interior): Dependencias de proyecto críticas, recursos limitados, priorización poco clara de financiamiento o no adecuada y falta del enfoque de dirección

•

La dirección de proyecto: la no- adhesión para los métodos reconocidos y los procesos de PM


Tolerancia al riesgo de los Colaboradores El nivel de tolerancia al riesgo del grupo de colaboradores equipara a cuánto una persona O la organización es capaz de tolerar un riesgo. El nivel de tolerancia del grupo de colaboradores representa la influencia más grande sobre cómo deben ser direccionados los elementos seguros de un proyecto.

ID

Colaborador

Rol

Impacto

Influencia

Tolerancia al Riesgo Necesidades Responsabilidades

1 2 3 4 5

Figure 61: Tolerancia al riesgo de los Colaboradores

Como antes señalamos, los grupos de colaboradores del proyecto pueden, y deber tener influencias importantes sobre un proyecto. Por lo tanto, el nivel de tolerancia del grupo de colaboradores (cuánto está dispuesto a tolerar un riesgo la persona o la organización) influye cómo deben ser direccionados los elementos seguros del proyecto. Los jefes de proyecto deben tener un buen entendimiento de sus niveles de tolerancia para abordar los riesgos suficientemente y priorizar su respectiva importancia cuando se relaciona con el éxito del proyecto. Una técnica para determinar los niveles de tolerancia de riesgo es clasificar la tolerancia por niveles de grupos de colaboradores. Usar una diagrama como uno el de la Figura 61 provee una herramienta para clasificar los umbrales de riesgo del grupo de colaboradores respectivos.

Nota Los líderes del proyecto deben revisar esta tabla continuamente en el proyecto, porque los niveles de tolerancia de los colaboradores pueden cambiar durante el proyecto.

73


Identificación de los Riesgos Tormenta de Ideas Método Delphi Entrevistas Identificación Causa Raíz Análisis SWOT

Figure 62: Identificación de los Riesgos

La experiencia de los miembros de los equipos es tradicionalmente la técnica de identificación de riesgo más común. Este método, sin embargo, es limitado por la memoria humana, la disponibilidad de recurso, y la participación previa de participantes. Otras técnicas útiles incluyen:

74

•

Tormenta de ideas: con la orientación de un facilitador dedicado y material disponible como el RBS, el equipo de proyecto puede desarrollar una lista bastante exhaustiva de los riesgos.

•

Método Delphi: a través del uso de un cuestionario, un facilitador puede establecer un consenso de los riesgos críticos, anónimamente de un grupo de expertos. El facilitador recoge y compila la realimentación experta y lo recircula al grupo (otra vez, anónimamente). Después de un par de repeticiones y comentarios, el equipo tiene una lista exhaustiva de los riesgos que no ha sido influido por una persona o grupo de las personas y puede ser considerado imparcial.

•

Entrevistas: Siendo accesibles, los miembros de equipo de proyecto experimentados SMEs (expertos de tema (subject matter experts)), y grupos de presión claves pueden ser un origen excelente para la identificación de riesgo. Ésta es una de las fuentes más comunes de los riesgos potenciales para cualquier proyecto.

•

Identificación de causa raíz: muchas veces los elementos colaterales o residuales de los riesgos son identificados a expensas de la causa raiz. La identificación de la causa raiz ayuda a los participantes a aislar y documentar la causa principal para las amenazas potenciales o las oportunidades para el proyecto.

•

Análisis SWOT: para proveer una opinión más exhaustiva en los riesgos potenciales, los equipos pueden analizar el SWOT (las fuentes de fortaleza, los defectos, las oportunidades, y las amenazas (strengths, weaknesses, opportunities, and threats)) al proyecto. Este proceso puede ayudar a ampliar la oportunidad de la perspectiva de riesgo.


Clasificación de riesgo Después de que los riesgos han sido identificados, cada riesgo tiene que ser priorizado de acuerdo con su probabilidad respectiva y consecuencia al proyecto. Este proceso es sabido como la clasificación de riesgo.

La Probabilidad, el Impacto y la Detectabilidad La Probabilidad = el riesgo de poder ocurrir El impacto = la consecuencia del evento de riesgo Detectabilidad = la habilidad de averiguar la existencia de un evento de riesgo

Figure 63: Probabilidad, Impacto y Detectabilidad

La Probabilidad = La Probabilidad de Ocurrencia Aunque cada organización o proyecto pueden definir la probabilidad de período de cubrir sus propias necesidades, el significado general del período cuando se relaciona con la prevención de siniestros es la probabilidad de un riesgo que existe. ¿Cuál es la probabilidad de este riesgo que exista durante el curso del proyecto? Las variables secundarias también deben ser consideradas cuando se determina la probabilidad de cada riesgo. Por ejemplo, la probabilidad de que un huracán afectaría un proyecto de construcción de un centro vacacional de playa podría ser baja durante los meses de invierno. Por otro lado, la probabilidad es incrementada significativamente durante el fin de período de verano.

El Impacto = La Consecuencia Del Evento El impacto, de la misma manera que la probabilidad, puede ser definido para cubrir las necesidades de la organización o del proyecto. En general, sin embargo, el impacto está relacionado con la consecuencia de un evento de un riesgo que ocurre, es decir, ¿Cuál es la consecuencia a los objetivos de proyecto si el riesgo existe en realidad? La ocurrencia de cualquier evento de riesgo puede afectar más de un objetivo del proyecto; por lo tanto, su impacto tiene que ser considerado para todos los elementos del proyecto. 75


Detectabilidad = La Habilidad de Averiguar la Presencia del Evento Riesgo Uno de los elementos que más pasamos por alto es la habilidad de determinar que un riesgo ha existido o que su ocurrencia es inminente. La habilidad de averiguar o descubrir la existencia o la presencia de un evento de riesgo es conocida como la detectabilidad de un riesgo. Aunque el equipo de proyecto podría tener un buen entendimiento de la probabilidad y el impacto de un riesgo, el equipo podría estar poco claro sobre su presencia. La detectabilidad de un riesgo también debe ser descompuesta en factores cuando se determinar su importancia en conjunto.

Nota Probabilidad e impacto que marca un tanto deben ser examinados con regularidad durante todo el proyecto, como la relativa probabilidad o consecuencia de los riesgos podrían cambiar cuando sigue el proyecto. Por ejemplo, algunos riesgos pueden constituir un impacto más alto en etapas posteriores del proyecto Versus en las etapas tempranas.

76


Puntuación de los Riesgos La fórmula riesgo lograr es una fórmula matemática Usada para determinar la importancia de un riesgo. Factores de la fórmula: P = la probabilidad I = el impacto D = detectabilidad Ejemplo de fórmula: P x I (usada más común, citada en la guía para el PMBOK) P × I × D (estándar, incluyendo detectabilidad) Figure 64: Puntuación de los Riesgos

La importancia de un riesgo no puede ser con exactitud resuelta fundada estrictamente sobre su probabilidad respectiva, impacto, o detectabilidad. Una combinación de todos estos elementos debe ser descompuesta en factores cuando se determina la importancia del riesgo al proyecto. Hay algunos tipos diferentes de las fórmulas que pueden ser incluidas cuando se determina la importancia. La fórmula más común promocionada por PMI es: Valor del riesgo = P x I Donde P = la probabilidad e I = el impacto Con la introducción de detectabilidad, la fórmula estándar puede ser ajustada: Valor del riesgo = P x I x D Donde P = probabilidad, I = el impacto, y D = de detectabilidad Algunas organizaciones deciden ajustar el peso de variables específicas dentro de la fórmula. Por ejemplo, algunos equipos de proyecto pueden considerar que el impacto del riesgo sea más que su probabilidad o detectabilidad cuando determinan su importancia al éxito del proyecto. Los factores de la ecuación pueden desviarse de proyecto a proyecto, estos deben ser acordados y aplicados constantemente.

77


Herramientas para Clasificar los Riesgos

Matriz de Clasificación de Riesgos Grafo de Clasificación: P × I × D

4

11 / (4)

6/ (8)

3/ (12)

1/ (16)

64

3

13 / (3)

8/ (6)

4/ (9)

2/ (12)

48

2

15 / (2)

10 / (4)

7/ (6)

5/ (8)

1

16 / (1)

14 / (2)

12 / (3)

9/ (4)

1

2 3 Impacto

4

Suposiciones

56 Score

Probabilidad

Tabla de Clasificación: P x I

40 32 24 16 8

1

2

3

4

5

6

7

8

9

ID del Riesgo

Probabilidad x Impacto Los riesgos son clasificados en orden numérica inverso. En caso de un empate, el puntaje con el impacto más grande es clasificado más alto.

Figure 65: Matriz de Clasificación de Riesgos

Los equipos de proyecto pueden usar la matriz de clasificación de riesgo para refinar y distinguir la importancia de los riesgos de proyecto a posterior. Cuando es usada la fórmula de puntuación, algunos riesgos pueden terminar con un puntaje igual. En tal caso, la matriz de clasificación de riesgo puede ayudar a los equipos a priorizar los riesgos más altos. Figure 65 provee dos ejemplos de clasificación de riesgo. Éstos ilustran dos maneras diferentes como los riesgos pueden ser clasificados sobre la base de la fórmula de puntuación escogida por el equipo de proyecto.

78


Disparadores de Riesgos

Se ha detectado un Evento. Por favor refiérase a su gestión de riesgo para implementación de estrategia.

Figure 66: Disparadores de Riesgos

Los disparadores son las señales de que un riesgo ha ocurrido o está a punto de existir. Los disparadores pueden ser determinados durante las fases de identificación o valoración de riesgo. A veces los disparadores son referencias o señales de advertencias.

Ejercicio Tormenta de Ideas

79


Estrategias De Respuesta De Riesgo Evitar: cambie o ajuste el plan de dirección de proyecto, los objetivos, el alcance, los gastos, los programa o la calidad. se usa a comienzos del proyecto o cuando la flexibilidad está presente

Transferencia: la propiedad de la amenaza es cambiada a terceras partes más eficaz para abordar los riesgos financieros

Mitigación: reducir la probabilidad o el impacto de un riesgo o aumente la detectabilidad de un evento de riesgo. Considerar cuando están disponibles opciones alternativas

Aceptación: dese cuenta de que el evento de riesgo podría ocurrir y se preparar para Consecuencias. la mayoría lo usa a menudo cuando las otras respuestas de riesgo son demasiado suntuosas o El riesgo no puede ser reducido de cualquier otra manera Figure 67: Estrategias De Respuesta De Riesgo

Las respuestas de riesgo son las opciones escogidas por el equipo de proyecto para minimizar amenazas (los riesgos negativos) y aumentar oportunidades (los riesgos seguros) para el proyecto. Este proceso sigue a la valoración de riesgo y es requerido para direccionar los riesgos por prioridad. Las estrategias de respuesta deben estar alineadas de acuerdo con la importancia del riesgo, y deben ser en el momento oportuno, realístico y objetivo. Algunas opciones diferentes pueden necesitar ser examinadas para condicionar la estrategia de respuesta apropiada. Algunas respuestas comunes a las estrategias incluyen:

80

•

Evitar: en la esencia, las estrategias de evitar los riesgos implican cambiar el plan de dirección de proyecto o ajustar los objetivos de proyecto, el alcance, programa, gastos, la calidad para que eviten el riesgo totalmente. Esta estrategia es típicamente usada a comienzos del proyecto o cuando el equipo de proyecto tiene la flexibilidad de cambiar elementos críticos del plan.

•

Transferencia: con la transferencia del riesgo, la amenaza y su propiedad respectiva son cambiadas a otra parte. Esta estrategia es más eficaz para abordar los riesgos relacionados con el área financiera y trae un costo de prima a la parte que generalmente acepta el riesgo. Ejemplos podrían incluir el uso del seguro, los bonos y las garantías.

•

Mitigar: La Mitigación del riesgo es el atenuante que implica reducir la probabilidad o el impacto de un riesgo, o aumentar la detectabilidad de un riesgo a un (umbral) nivel aceptable. Pasando a un proveedor más confiable, incrementar el alcance de un plan de prueba, o incluir una tecnología (menos complicada) más demostrada son ejemplos del atenuante de riesgo.

•

Aceptar: porque es infrecuente eliminar todos los riesgos posibles para un proyecto en particular, la aprobación de riesgo podría ser una estrategia aceptable. La aprobación de riesgo es más usada a menudo con los riesgos que no pueden ser reducidos de cualquier otra manera, cuestan demasiado para mitigar, trasladar, o evitar, o son de importancia baja.


Reservas De Contingencia Calculadas Usar EMV, qué reserva de contingencia deber ser asignado a los siguientes riesgos? ( reserva de contingencia = P x I): Gerente de proyecto deja la organización probabilidad ‹ 25% El impacto ‹ = $40,000 para reemplazar y volver a capacitar La infraestructura de la red requiere la versión actualizada completa La probabilidad ‹ = 50 % (el coste); 20 días (el programa) El impacto ‹ = $50,000 para recursos de instalación de la red Figure 64: Reservas De Contingencia Calculadas

Debido a que las reservas de contingencia son relacionadas con los riesgos de proyecto potenciales típicamente, usted debe saber cómo calcularlos. EMV (el valor monetario esperado) es un método usado determinar qué cantidad de dinero (o, en algunos casos, el tiempo) debe ser puesto para explicar los eventos de riesgos claves. Para calcular el EMV, usted multiplica la probabilidad ( P la probabilidad) de un evento de riesgo y su respectiva consecuencia (el impacto) al proyecto. La suma de todos los resultados se compara con la reserva de contingencia recomendada del proyecto. EMV =

Probabilidad (porcentaje probable)

x

Impacto (cantidad de dinero o tiempo)

81


Reservas de Contingencia: Usando EMV Riesgos del Proyecto Risk Gerente déjà el Proyecto

Probabilidad y 30%

Impacto $15,000

Hardware Incompatible

25%

$50,000

Necesidad de Consultor de Seguridad

75%

$24,000

Nueva prueba de software requerida

50%

$10,000

Monto

TOTAL Figure 65: Reservas de Contingencia: Usando EMV

Usando la fórmula para EMV, calcule la cantidad de reserva de contingencia recomendada, para estos riesgos potenciales del proyecto de TI.

10 10.Adquisición y Fuentes. Temas de la Sección •

Adquisición y dirección de Fuentes

•

Construya o compre

•

Documentos de adquisición

•

Requisitos de contrato y términos legales

•

Tipos de contrato

•

Usar la técnica de diagrama de árbol de decisión

•

Analizar tipos de contrato para entregables

Ejercicio


Adquisición y Fuentes de Dirección Para la mayoría de los proyectos, no es poco común mirar fuera de la organización para solicitar ayuda y repartir los recursos en un proyecto con éxito. La adquisición y la dirección involucran el comprar bienes y servicios fuera de la organización, incluyendo la definición de bienes y servicios requeridos, la documentación de requisitos, la identificación de fuentes potenciales, y llevar los aspectos legales del compromiso. Con el crecimiento de la subcontratación en las industrias, la adquisición y los conocimientos de dirección son una capacidad persistente imperativa para cualquier proyecto.

Rol del director de proyecto Adapte el compromiso para cubrir las necesidades del Proyecto Defina el alcance, los requisitos y las responsabilidades del producto o servicio a ser atribuido a una fuente Incorpore la planificación de la gestión de riesgos en los compromisos de los procesos Explique el proceso de adquisición en el programa de proyecto Figure 70: Rol del Gerente de Proyecto

El director de proyecto tiene un papel esencial en el proceso de la adquisición. Por lo tanto, es importante que el director de proyecto esté comprometido en el proceso lo más temprano posible en el proyecto. Algunas de las responsabilidades del director de proyecto en la adquisición y fuentes del proceso son puestas en una lista en la figura70.

84


Construya o compre Uno de los desafíos más comunes que las organizaciones de TI esta cuando se enfrentan con las restricciones de recurso. El hecho es que hay cantidades limitadas del tiempo, dinero, y recursos para producir todo lo requerido para un proyecto. La organización de entrega debe determinar si debe comprar o desarrollar entregables seguros para el proyecto. La organización debe determinar si comprar los artículos o los servicios costará mayor o menor cantidad que producirlos internamente. Cuando se valora el coste para comprar entregables, la organización debe considerar que tanto los costes directos como costes indirectos, asi como el coste de los recursos se direccionen en el proceso de compras. También hay factores más allá del coste, como la habilidad técnica de la organización para hacer el trabajo, la capacidad de las instalaciones y el personal disponibles de la organización. La organización también debe considerar la naturaleza del dueño y/o la propiedad intelectual de los aspectos del producto o el servicio que está siendo valorado.

Análisis de árbol de decisión EMV 40% software adquirido $50,000

Fills need

$

No impact

$ 60% Does not fill need

Purchase or code software

$

$200,000 Impact

80% Works

Codigo de software $120,000

Path value

$

No impact

$ 20% Does not work

$30,000 Impact

$ Figure 71: Arbol de Decision

Un análisis de árbol de decisión es una herramienta útil para determinar si se debe construir o comprar. Es una manera de comparar opciones diferentes y sus impactos asociados así como sus consecuencias. Mientras diagramemos las posibles opciones y las consecuencias, el equipo determinara un valor esperado para cada alternativa que ayuda a resultar en la mejor alternativa para el proyecto. El ejemplo de diagrama de árbol de decisión en Figure 71 compara las opciones de comprar el software disponible o escribir la clave interiormente de una organización. Este árbol retrata los resultados varios, las probabilidades relacionadas, y los impactos respectivos.

85


Notas

Documentos de Compra RFP IFB o RFB RFQ

Figura 72: Documentos de Compra

Los documentos de adquisición son creados por la organización para solicitas las propuestas para entregables de posibles vendedores. Los documentos de adquisición pueden incluir la información como el alcance del trabajo a realizarse, los términos de contrato propuestos, la información de formación para vendedores, como son procedimientos para responder, los criterios de evaluación que serán usados para escoger a un vendedor, y las formas para que el vendedor use cuando va a presentar una respuesta. Las más comunes clases de documentos de adquisición en la industria incluyen:

86

•

RFP (solicitud de la propuesta): Usado para recibir una propuesta detallada sobre precio y sobre cómo estará consumado el trabajo y quién lo hará

•

IFB (invitación para el intento) o RFB (la solicitud para el intento): Un Pedido para solicitar un precio para hacer un trabajo

•

RFQ (la solicitud para la cita): un pedido para una cita por el artículo, como por la hora o por pieza


Requisitos de contrato y términos legales

Ofrézcase Aprobación Capacidad legal Consideración Propósito legal Privacidad Figure 73: Terminos legales y requerimientos del contrato

La vasta mayoría de la adquisición y las fuentes bajo las que los compromisos se realizan son administradas por un contrato. El contrato está en lugar de proteger todas las partes (comprador y vendedor) legalmente. Un contrato legal debe incluir los siguientes elementos: •

Ofrézcase: ésta es una invitación de hacer un trato. La propuesta es de tiempo limitado.

•

Aprobación: el trato debe ser aceptado dentro del plazo. Una contraoferta crea un nuevo acuerdo.

•

Capacidad legal: las partes que entran en el acuerdo son competentes y tienen la autoridad legal de hacerlo.

•

Consideración: algo es dado a cambio de otra cosa.

•

Propósito legal: el propósito del contrato debe ser legal.

Otra consideración legal importante en la esfera de la adquisición de proyecto de TI y fuentes de contratos es la privacidad, una relación contractual directa entre dos partes (directas). Si un director de proyecto contrata A de la compañía cuando un contratista para parte de un proyecto, y A de la compañía subcontrata el trabajo a B de la compañía, el director de proyecto no puede ir a B de la compañía directa y legalmente con asignaciónes de tareas porque A de la compañía tiene una relación contractual con B de la compañía, no con la organización del director de proyecto.

87


Tipos de Contratos

Riesgo del Comprador

FP

FPI

CPAF

T&M

CPIF

CPFF

CPPC

Riesgo del Vendedor Figure 74: Tipos de Contratos

Si se determina que está en los mejores beneficios de la organización obtener recursos (sean humano o capital) fuera de la organización, el director de proyecto, o la persona responsable de conseguir recursos exteriores, debe seleccionar el tipo apropiado de contrato que cubrirá mejor las necesidades del proyecto. Hay algunos tipos de contratos que pueden ser usados sobre la base de la situación. El tipo del contrato escogido podría contener un más alto nivel de riesgo intrínsecamente al comprador o el vendedor. La carga del riesgo para cada parte dependerá del tipo de contrato es reflejada en el diagrama en la figura74. Los tipos de contrato examinados aquí incluyen lo siguiente: •

Contratos de precio fijos

•

Contratos de Costo reembolsables

•

Contratos de tiempo y materiales

Contratos de precio fijos •

FP (Precio fijo): con un contrato de FP, un FP específico es negociado sobre un alcance bien definido del trabajo.

•

FPI (precio fijo mas incentivos): un FPI es un contrato de precio fijo en el que una bonificación, o el incentivo, es brindada para exceder el rendimiento del contrato, como entrega a domicilio temprano. Con un FPI, el comprador quiere el producto temprano o con las características adicionales realmente, pero el vendedor no estará de acuerdo con eso así que el comprador brinda un incentivo. (Incentivos) ayudar a alinear los objetivos de los compradores y los vendedores. A la inversa contratos de precio fijos también pueden incluir una forma de pena si los objetivos de proyecto en el tiempo, el coste, o la calidad no son cubiertos de acuerdo con las expectativas. Por ejemplo, un contrato de precio fijo podía incluir una previsión para penas financieras a ser tasado todas las semanas que un proyecto esté retrasado.

88

Contratos de Costos reembolsables En los contratos de costos reembolsables, el comprador paga al vendedor por costes verdaderos más unos honorarios o porcentajes para la ganancia. Los gastos están formados por los costos directos y costes indirectos. Los costos directos son esos gastos directamente atribuibles al proyecto, como los sueldos de miembros de proyecto. Los costes indirectos, también llamados el coste de hacer la empresa, son un reparto de la sobrecarga al proyecto, como sueldos ejecutivo o gastos de instalaciones. Típicamente, los costes indirectos están calculados sobre la base de unos porcentajes de costos directos. los contratos de costos reembolsables se usan cuando hay un alto riesgo e incertidumbre sobre el proyecto, o cuando el comprador está comprando la pericia y puede describir lo que quieren, no el que hacer solamente. El contrato de coste reembolsable incluye: •

CPFF (Costo más honorarios fijos): el vendedor es reembolsado por todos gastos más unos honorarios fijos que representa la ganancia. Los honorarios son estables, mientras que los gastos varían. Ésta es la forma más común de contrato de coste reembolsable.

•

CPAF (Honorarios de premio de costo más honorarios): el vendedor es compensado cuando parte de el contrato está completo.

•

CPIF (Honorarios de incentivo de costo más honorarios): una bonificación, o el incentivo, es brindada para exceder el rendimiento del contrato, como entregar un producto en menor tiempo.

•

CPPC (porcentajes de costo más honorarios de gastos): los compradores pagan todos gastos más unos porcentajes de gastos como unos honorarios. Es ilegal que el gobierno estadounidense use este tipo de contrato. El contrato de CPPC es un riesgo malo para compradores.

Contratos de tiempo y materiales Los Contratos de tiempo y materiales incluyen: •

T& M (el tiempo y los materiales): también llamado contratos de precio de unidad, los contratos de T& M son un cruce entre contratos de precio fijos y contratos de costo reembolsables. De la misma manera que un contrato de coste reembolsable, el precio total del contrato es desconocido a la época en que el contrato es creado. De la misma manera que un contrato de FP, el comprador y el vendedor están de acuerdo con el precio por adelantado por unidad, si él está contratado por el precio de hora o por el precio de artículo, por ejemplo, un cargo de $120 por la hora para el trabajo de un diseñador de la red en que este tipo de contrato es usado cuando el comprador quiere tener un control mas pequeño, cuando el alcance del trabajo no sea conocido, y para servicios a corto plazo, como un contrato a corto plazo para conseguir trabajo empezó ahora mismo hasta que un contrato a mayor plazo podía ser negociado.


11 11.Metodologías y Marcos Referenciales en Proyectos. Tópicos de la Sección •

Metodologías de Gestión de Proyectos Genéricas

•

Metodologías y Procesos para Desarrollo de Software

Ejercicios •

No hay para esta sección


Metodologías Genéricas de Gestión de Proyectos Stage-Gate® OPM3 Camino Critico

Figure 75: Metodologias Genericas de Gestion de Proyectos

Durante los veinte años anteriores, el número de metodologías de dirección de proyecto ha crecido en una rata exponencial en el mundo de los negocios. Casi cada organización ha intentado integrar una metodología genérica o personalizada con la esperanza de que solucionará todos sus problemas de dirección de proyecto. La verdad es, sin embargo, es que ninguna metodología podría existir y satisfaga a todos. Hay docenas, sino centenares, de supuestos metodologías de dirección de proyecto sin marca registrada. Obviamente, no tenemos el lujo de analizar todas ellas durante este curso. Sin embargo echaremos una mirada más cerca a tres metodologías, una combinación de las más comunes y aquellas que son prometedoras en la industria. Estas metodologías son puestas en una lista en la figura75.

Stage-Gate Idea screen Gate 1

Discovery stage

Second screen Stage 1

Scoping

Gate 2

Go to development Stage 2

Build business case

Gate 3

Go to testing Stage 3

Gate 4

Development

Postlaunch review

Go to launch Stage 4

Testing and validation

Gate 5

Stage 5

Launch

Product Development Institute (www.prod-dev.com) Figure 76: Stage-Gate

El proceso de Stage-Gate®, registrado por PDI (instituto de desarrollo de producto), es descrito como "Un mapa de carreteras conceptual y de operaciones para cambiar de lugar un proyecto nuevo – una idea de producto, un lanzamiento." Un método de desarrollo de producto ampliamente usado, el proceso de Stage-Gate® divide el Esfuerzo en etapas para ser ordenar en distintas serie que culminan con una toma de decisión de dirección. 8. Robert G. Cooper and Scott J. Edgett, “Stage-Gate Process,” Product Development Institute, Inc., http://www.prod-dev.com/stage-gate.shtml (accessed June 9, 2005).

92


Relacionado así con el desarrollo de producto, este proceso está a menudo empleado sobre los proyectos alineados para traer un nuevo producto al mercado. Con Stage-Gate, los equipos de proyecto deben terminar un set de tareas prescritas, o entregables, en cada escenario con éxito antes de obtener la aprobación de la dirección para seguir al próximo escenario.

Process improvement stages

Modelo de Madurez de Gestión de Proyectos Organizacionales Continuously improve

Control

Measure

Standardize

OPM3 Construct PMI (www.pmi.org)

Portfolio management

Program management

Project management

Organizational Project Management Figure 77: Organizational Project Management Maturity Model

En 2003, después de cinco años de colaboración y el desarrollo, el PMI divulgó su propio modelo de vencimiento de dirección de proyecto, OPM3 (Modelo De Madurez De Gestión De Proyectos Organizacionales). OPM3 no es un camino específico, pero si una base diseñada para permitir que las organizaciones escojan las mejores prácticas que se presentan para hacerlo, específicamente se centró en las necesidades de dirección de proyecto. OPM3 está basado en la premisa de que las competencias y capacidad específicas deben existir dentro de la organización para poder culminar proyectos con éxito, constantemente, y de manera previsible. OPM3 Toma el marco de proceso para la dirección de proyecto establecida en el PMBOK, en el cuál están: iniciando, planeando, ejecutar, controlar, y cerrar, y extender más allá del dominio lo que transmite la dirección en otros dominios muy importantes de la empresa, que son dirección de programa y gerencia de portafolios. Es importante notar que la planificación estratégica es el contexto central y la entrada para todos estos dominios. El modelo de OPM3 incluye las etapas básicas de la mejora de proceso para servir de un fundamento y así aumentar la madurez de dirección de proyecto de una organización. Éstas etapas incluyen: 1. Normalizar 2. Medidas 3. Control 4. Mejora constante

93


Cadena Critica CCPM (dirección de proyecto de cadena exigente) es una aplicación del TOC (teoría de las restricciones) a los proyectos. El TOC, que fue desarrollado por Eli Goldratt, es una filosofía de dirección implicada sobre la noción de que todas organizaciones tienen un objetivo fundamental y que el objetivo define por qué existe la organización. Cualquier cosa que obstruye la habilidad de la organización en conseguir mayor cantidad de su objetivo es llamado una restricción. En la disciplina de dirección de proyecto, estas restricciones constituyen las áreas de alto riesgo que pueden resultar en el fracaso de proyecto. La dirección de proyecto tradicional usa un camino crítico. El camino crítico identifica la serie de las tareas que definen la duración mínima a tiempo para el proyecto. El método de camino crítico, por otro lado, mira la secuencia más larga de las tareas en el proyecto en relación con tanto tiempo como recursos. Comúnmente, los proyectos son planificados con la creencia de que mientras más temprano se comienzan, más temprano estarán terminados y que las Estimaciones optimizarán el rendimiento de proyecto con un alto grado de seguridad incorporado. En otras palabras, es común para los equipos de proyecto de TI amortiguar a su vez y costear las Estimaciones para cada tarea o actividad. Este crea una cantidad desmedida de amortiguador del proyecto esencialmente de nivel, y así las Estimaciones del proyecto se ponen mucho más grandes que lo que puede ser suficiente. La mayoría de las personas creen que optimizar cada parte de un sistema resultará en que un sistema funcione en la eficiencia óptima. Esta aseveración es inconsistente con CCPM. Un sistema optimizado se concentrará en la capacidad de su restricción y asegurará que todas partes río arriba y río abajo del sistema tienen capacidades superiores a esa restricción. En la práctica de CCPM, el enfoque principal y la energía del director de proyecto se centran sobre las áreas de la represión. En otras palabras, cada parte de no restricción del sistema debe operar con menor eficiencia que la restricción con el propósito de que tendrá capacidad de reserva para manejar las fluctuaciones. Esta reserva puede ser aplicada a las áreas de la represión prudentemente sobre una base de sus necesidades. CCPM, aunque revolucionario, requiere de un modo de pensar global para que cambie cuando se relaciona con planear y calcular proyectos. Con este método, los miembros de equipo y dirección de proyecto deben promover un ambiente que se adhiera a Estimaciones de tiempo y objetivos de coste para todas las actividades de proyecto constantemente igual.

94


Metodologías y Procesos para Desarrollo de Software

XPM Waterfall (SDLC) RAD RUP CMMI

Figure 79: TI Project Management Methodologies

La industria de TI ha sido un líder global en el desarrollo y la puesta en práctica de la mejor apariencia de Prácticas en la dirección de proyecto. Por consiguiente, la disciplina de dirección de proyecto de TI ha contraído y desplegado números incontables de las metodologías de dirección de proyecto queriendo mejorar el éxito de los proyectos de TI. Algunas de estas metodologías se han desvanecido mientras otras han sobrevivido. Varias de las metodologías de dirección de proyecto de TI más comunes se muestran en una lista en la Figure 79 y son examinados en esta sección

Dirección de proyecto extrema XPM (la dirección de proyecto extrema) es una forma de dirección de proyecto ágil, adaptable para dar el visto bueno a solucionar los problemas de la empresa que se concentran en la comunicación, la colaboración, la entrega, y el cambio. XPM es abierta, elástica, y el enfoque indeterminado para el software y proyectos de desarrollo de sistema que se concentran en el recurso humano y los aspectos de grupo de presión del proyecto. Está diseñado para dirigir el proyecto correctamente mas que concentrarse en las fechas finales de reunión, que son considerado irrealista a menudo en la empresa, de acuerdo con XPM. Características de XPM incluyen: •

Diseño simple

• Enfoque iterativo, empareja la programación y permite pequeños lanzamientos en intervalos frecuentes • Equipo de desarrollo, la garantía de calidad, y los recursos de la empresa son colocados en la misma habitación

95


Cascada Desarrollo de cascada, también conocido como el (ciclo vital de desarrollo de sistemas) de SDLC, es un enfoque para el desarrollo de software que rompe un proyecto en fases finitas. Cada fase es llevada a cabo por orden, y cada una depende de la completación de las fases precedentes. Con el desarrollo de Cascada, cada porción del trabajo de proyecto es valorado por separado y es llevado a cabo por equipos diferentes típicamente. Aunque pueden ser acordados de manera diferente en diferentes organizaciones, algunas fases estándares de la Cascada incluyen: •

Concepto

•

Planificación

•

Análisis

•

Diseño

•

Desarrollo

•

Prueba e instalación

•

Mantenimiento

Algunas características del método de Cascada incluyen lo siguiente: •

Usar mejor cuando la organización quiere todo documentado y quiere forzar todos cambios propuestos a través de dirección de cambio de alcance

•

Requiere la participación del usuario durante la planificación, el análisis, y la prueba

•

El enfoque más seguro y un enfoque muy estructurado

•

Mejor llevados para los proyectos por directores de proyecto más experimentados

Desarrollo de Aplicación Rápido RAD (el desarrollo de aplicación rápido) es un sistema de proyecto de desarrollo de software diseñado para permitir que los equipos desarrollen programas trabajando rápidamente. Uno de los dogmas básicos de RAD es concentrarse en proyectos más pequeños que pueden ser iniciados rápidamente y concluido con entregables tangibles. En la esencia, RAD anima a los equipos a dividir el proyecto en artículos de pequeños tamaños o más manejables. En el ambiente de RAD, la creación de prototipos está comúnmente empleada para ayudar a acelerar el proceso de desarrollo. Los proyectos de desarrollo de Web se s prestan a RAD, dado que el desarrollo de proyectos que se diseñaron para implementar procesos en lotes no podría ser tan propicio para este método. Debido a su naturaleza rápida y más flexible, RAD es usado para organizaciones de proyecto que pueden adaptarse al cambio eficazmente mejor. Las características de RAD incluyen:

96

•

Mayor difícil de aplicar a proyectos más grandes debido a la complejidad o interrelaciones

•

La participación de los usuario requerida en la planificación, el análisis, la prueba, y las fases de creación de prototipos

•

La naturaleza cíclica y procesos de dirección de proyecto menos rígidos requieren a un director de proyecto más experimentado


Proceso unificado Racional RUP (el proceso unificado racional) es un proceso de ingeniería de software, creado por las sociedades anónimas de software racionales, ahora una división de IBM, que se centra en el desarrollo de proyectos grandes de software. Está diseñado para minimizar, eliminar problemas de desarrollo de software comunes, como los siguiente prácticamente: •

Dirección de requisitos ad hoc

•

Comunicación ambigua e imprecisa

•

Arquitectura frágil

•

Complejidad abrumadora

•

Las contradicciones inadvertidas en requisitos, diseños, y puestas en práctica

•

Prueba insuficiente

•

Valoración subjetiva de status de proyectos

•

El fracaso de atacar los riesgos

•

Propagación de cambio incontrolado

•

Automatización insuficiente

La base de RUP es centrada en la constitución de seis mejores prácticas en el ambiente de desarrollo de software. La seis mejores prácticas incluyen: •

Desarrolle iterativo de software

•

Gestione requisitos

•

Use arquitectura basada en componentes

•

Haga un modelo del software visualmente

•

Verifique la calidad de software

•

Control de Cambios para el software

Modelo Integrado de Madurez de Capacidad En los comienzos de 1990s, el SEI (Instituto De Ingeniería De Software) desarrolló el (Modelo de Madurez de Capacidad) CMM con el objetivo de mejorar el éxito de la industria de ingeniería de software de par en par. La repetición actual de este modelo es conocida como el CMMI (Modelo Integrado de Madurez de Capacidad). El SEI es un centro de investigación y desarrollo federalmente financiado y patrocinado por el Ministerio de Defensa de USA y es alojado en Carnegie Mellon University. CMMI es un método de mejora de proceso que provee un juego de mejores prácticas que aborda la productividad, el rendimiento, los costes y la satisfacción de grupo de colaboradores. Enfatiza tanto en la ingeniería de sistemas como en la ingeniería de software así como la integración necesaria para desarrollar y mantener actualizado el producto total.

97


Notas

CMMI está estructurado para guiar a las organizaciones a través de unos cinco Proceso de madurez. Éstos cinco niveles y sus características asociadas incluyen: •

Inicial: el proceso imprevisible, mal controlado y reactivo

•

Gestionado: se procesar caracterizado para proyectos y es a menudo reactivo

•

Definido: se procesar caracterizado para la organización y es previsor

•

Cuantitativamente dirigido: el proceso es medido y controlado

•

Optimizar: el enfoque está sobre la mejora de proceso ininterrumpida

El SEI ha sido un líder global en el desarrollo de software, como muchas metodologías han sido decoradas después de los modelos de CMM

98


12 12.Controlar y Dirigir el Cambio. Temas de sección •

Cambios de proyecto

•

Control de Cambiar integrado

•

Proceso de Control de Cambiar

•

Herramientas de Control de Cambiar

•

Desarrollar un plan de dirección de Cambiar

Ejercicio

99


Cambios de proyecto Solicitud de Cambio

Enchapado de oro (Gold Plating)

Influencia de Alcance (Scope Creep):

Dibujo 80: los cambios de proyecto

Los cambios sobre un proyecto pueden ocurrir por muchas razones. Los cambios pueden nacer desde los miembros de un equipo, grupos de presión, el director de proyecto, dirección de la compañía, y el ambiente económico, o ellos pueden resultar de los datos de medición de rendimiento o de los movimientos correctivos. Contrario a la creencia común en la industria de TI, no todos cambios para un proyecto son malos. A decir verdad, el cambio de proyecto puede ser un método útil de mejorar un producto o el servicio o una manera de conseguir un proyecto en marcha. Es importante distinguir entre las clases de cambios que pueden afectar un proyecto. Las clases de cambios incluyen lo siguiente: •

Solicitud de Cambio: los pedidos de Cambios representan las preguntas formales de grupos de presión clave para modificar elementos del proyecto. Los pedidos de Cambios pueden ser iniciados debido a los cambios del mercado o como consecuencia de nuevas investigaciones no disponible más temprano en el proyecto. Los pedidos de Cambios son considerados un cambio aceptado para un proyecto si son documentados y si son aprobados por la dirección, el patrocinador o el cliente.

•

Enchapado de oro (Gold Plating): el enchapado de oro es un término usado para dar extras a un cliente fuera del alcance del acuerdo. Estos extras no añaden valor al proyecto típicamente, y pueden ser las causas principales de las distracciones de proyectos muy importantes. El enchapado de oro no es poco común en el desarrollo de software. El equipo de programación puede programar las características adicionales y la funcionalidad respecto a la aplicación que no eran parte de los requisitos originales.

•

Influencia de Alcance (Scope Creep): Influencia de Alcance está representado por los cambios no autorizados o incontrolados para el proyecto.

Enchapado de oro e influencia de alcance no aumentan la probabilidad del éxito para un proyecto. Son indicativos que un proyecto esta fuera de control. Ni el enchapado de oro ni la fluencia de alcance son elementos planificados en un proyecto; por lo tanto, incrementan el riesgo y la probabilidad de falla para el proyecto.

100


Qué diferencia a las solicitudes de cambio de la influencia de Alcance? Las solicitudes de cambios siguen un proceso de control de cambios integrado; por lo tanto, el equipo de proyecto debe considerar el impacto del cambio al proyecto cuidadosamente antes de la aprobación de una solicitud de cambio.

101


Control de Cambio integrado

1. Reconocer que un cambio ha sido pedido o Ha ocurrido. 2. Medir el impacto del cambio. 3. Evaluar las soluciones alternativas o las opciones para facilitar la necesidad.

4. Comunique el impacto potencial a los grupos de presión a las soluciones de proyecto recomendadas por el equipo. 5. Comunique el cambio y el plan actualizado al cliente, si es necesario. Figura 81: el control de Cambio integrado

Los cambios pueden afectar los puntos de partida de medición de rendimiento del proyecto, que incluyen el plan de proyecto, el programa, o el punto de partida de costo. Si un cambio pedido afecta alguna de estas áreas, deben ser actualizados. El control de cambio integrado representa los cambios que resultan de procesos de control y mantienen la integridad de los puntos de partida de medición de rendimiento. Es imperativo que las políticas de control de cambio y los procedimientos del proyecto sean definidos a comienzos del proyecto y aplicados constantemente. Durante el proceso de control de cambio integrado, el equipo de proyecto debe seguir los pasos de procesos documentados de la organización, como se muestra en la figura81.

102


Proceso de Control de Cambios Documente el proceso de recibir Valore e implemente las solicitudes de cambio

¿Qué?

¿Quién? ¿Cuándo? ¿Cómo?

¿Dónde? Dibujo82: el proceso de Control de Cambiar

El sistema de control de cambio consta de los procedimientos formales de ser usado cuando se soliciten y gestiones solicitudes de cambio. La documentación asociada con el cambio, las respuestas de sistema de control; el quién, qué, dónde, cuándo, y cómo hacer son preguntas relacionadas con los cambios de proyecto. El sistema de control de cambio incluye la siguiente información: •

Describe el proceso formal para recibir y evaluar las solicitudes de cambios, asi como todos los cambios deben ser enviados por escrito

•

Describe el nivel de la autoridad necesaria para aprobar los cambios

•

Suministra una manera de seguir la trayectoria en que todos las solicitudes de cambio se han generado y así ver cómo cambian los estados de los mismos manteniéndolos documentados, por ejemplo, un cambio de estado en un servicio

•

Puede definir un grupo responsable de evaluar las solicitudes de cambio, posiblemente incluyendo el director de proyecto, el patrocinador, el cliente, y los expertos. Algunos nombres comúnmente usados para que este grupo pueden ser: -

CCB (Junta de control de cambio)

-

ERB (Junta de revisión de ingeniería)

-

TRB (junta de revisión técnica)

-

TAB (junta de valoración técnica)

103


Cambios de Emergencia o Arreglos No todos los cambios incluyen el lujo del tiempo en que dejará el proceso para un cambio deliberado; por lo tanto, los distintos procedimientos deben ser documentados para los cambios de emergencia. Por ejemplo, un cambio urgente puede ocurrir y no poder esperar hasta la próxima reunión programada del CCB. En este caso, los procedimientos deben definir las circunstancias que permiten que el director de proyecto haga un cambio inmediatamente y seguir evidentemente con la forma de solicitud para un cambio formal la que presentó al CCB después.

104


Herramientas de Control de Cambios Es imperativo que todos los colaboradores comprendan el proceso de cambio formal asociado con el proyecto. Las herramientas como diagramas de flujo y el diario de control de cambio comunican tanto el proceso como el estado de los cambios que están considerados para el proyecto.

Diagrama de flujo de Gestión de Cambios

Dibujo83: diagrama de flujo de dirección de Cambiar

Un componente aún útil simple del documento de proceso de control de cambio es un diagrama de flujo, como se muestra en la figura83.

105


Diario de Control de Cambio Proyecto

Dog-Gone Monitoring System

Project #

004-11-2015

Gerente de Proyecto

Lorraine Klein

Patrocinante

James Strickland

Documentos del Proyecto

KnowledgeSafe: Port 8

Actualizado al

05-28-2015

Descripción Fecha Fecha ID del Cambio Prioridad Originado Entrada Asignada Evaluador

Status

Fecha Incluido de en Rev. Decision #

Integrate the ability to control the home's outdoor sprinkler system through the Dog-Gone Monitoring 1 System.

4

Jennifer Parker

5-18

5-22

Casey Zane

Approved

5-24

2

Accelerate the market launch by two weeks in order to meet the primary retailer's Veterans Day / preChristmas 2 sale.

3

James Strickland

5-21

5-25

Lorraine Klein

In review

TBD

TBD

3 Dibujo84: diario de Control de Cambio

El diario de control de cambio es una plantilla que permite que el director de proyecto capture, cargue, siga la trayectoria y mantenga el estado de solicitudes de cambio de proyecto. El diario de control de cambio debe, en un mínimo, incluir los siguientes atributos: • 106

El identificador de la solicitud de cambio: el identificador usado por el equipo de


proyecto para estar al día con la solicitud •

La descripción del cambio: un resumen usado para describir la naturaleza del cambio

•

Prioridad: la prioridad del cambio, basado en las definiciones predeterminadas

•

Creador: la persona o organización que pidió el cambio

• La fecha a entrar: la fecha en que el solicitud de cambio fue presentado o entrado en el diario •

Fecha señalada: la fecha atribuir a una fuente de información para examinar, valorar, o implementar

•

Evaluador: la persona responsable de examinar el cambio y determinar el impacto al proyecto

•

Estado: el estado del pedido de cambio

•

Fecha de la decisión: la fecha el sencillo pedir estar aprobado, negado, o pospuesto

•

Incluído en la revision #: la revisión del producto o el servicio que contendrá el cambio, si aplica

107


108

13 13.Garantía y Control de Calidad.

Temas de la sección •

Calidad de proyecto

•

Teorías de dirección de calidad

•

Herramientas y técnica de calidad

•

Prueba de proyecto

•

Analizar el rendimiento de los datos

Ejercicio


Calidad de proyecto Definición Conformidad para requisitos Saludable para el uso

Distinciones Prevención Inspección

Beneficios Retrabajo, gastos La productividad, la satisfacción Dibujo85: la calidad de proyecto

110


La calidad es una de la triple restricción fundamental de los elementos del modelo de la triple restricción. La dirección de calidad supone asegurarse de que el proyecto cubra las necesidades que fue originalmente creado para cubrir, es decir, las necesidades para el producto o el servicio del proyecto y para la dirección del proyecto mismo. Esencialmente, la dirección de calidad en la esfera de proyecto representa la habilidad del equipo para satisfacer las expectativas del grupo de colaboradores. Aunque el PMBOK resume que el propósito de la dirección de calidad es asegurar "Que el proyecto satisfará las necesidades para las que fue creado 1 y no más, el nivel de la conformidad podría ser diferente por cada organización o industria. Las características de la calidad y la dirección de calidad, tanto como los beneficios de aplicar procesos de calidad incluyen lo siguiente: •

Calidad de proyecto: para satisfacer las expectativas del cliente, una combinación tanta de conformidad para requisitos como la buena salud para el uso debe ser lo esperado. La conformidad para requisitos quiere decir que el proyecto produjo el producto o el servicio previsto. La buena salud para el uso quiere decir que el producto o el servicio producido por el proyecto satisfacen las necesidades legítimas.

•

La prevención versus. Inspección: El adagio de que una onza de prevención es digna de una libra de cura resuena en todos los ambientes. Es preferible prevenir los errores antes de que ocurran, y la planificación tiene un papel esencial en la prevención de los problemas. Realísticamente, sin embargo, los problemas de calidad existen en el mundo de paso rápido y son muy complicados en la dirección de proyectos. Las inspecciones, aunque no ideales, proveen una garantía adicional de ayudar a minimizar el número de los errores de producto que llegan al usuario final.

 

Beneficios de las prácticas de calidad: El proceso de calidad documentado, y constantemente aplicado puede causar beneficios inmediatos al proyecto. Dirección de calidad suficiente ayuda a reducir la cantidad de reelaboración y sus costes asociados mientras ayuda al aumento de la productividad y la satisfacción de grupo de colaboradores. Hay beneficios indirectos relacionados con la calidad de un proyecto, como la moral de equipo elevada, las buenas relaciones públicas, la credibilidad mejorada, y el potencial incrementado para el siguiente trabajo, especialmente en un guión de escenario de contrato.

1

Instituto de dirección de proyecto, una guía para el cuerpo de dirección de proyecto de conocimientos: Guide de PMBOK, la 3rd edición (Pensilvania: instituto de dirección de proyecto, Inc., 2004), 179. 111


Teorías de dirección de calidad JIT

TQM

ISO

9000

Deming

Kaizen

Dibujo86: teorías de dirección de calidad

Típicamente, las organizaciones que se adhieren a una política de dirección de calidad tratan de aplicarlo (cuando deben) a sus proyectos de TI. Algunas teorías de dirección de calidad de la empresa, las filosofías, y los métodos están presentes en la disciplina de dirección de proyecto de TI.

Justo a Tiempo Con la técnica JIT (justo a tiempo), la idea son reducir gastos de existencias teniendo partes o materias primas a repartir cuando son necesitados y no antes. Para aplicar esta técnica de trabajo deben existir controles de calidad estrictos en lugar de coordinar la necesidad y la entrega de materiales a tiempo. Si las piezas llegan demasiado temprano, los gastos de existencias se elevan. Si llegan demasiado tarde, podrían dar como resultado un retraso de trabajo o la paralización total, lo que incrementa los gastos y afecta el programa de proyecto. En el mundo de dirección de proyectos, esta filosofía puede ser aplicada a la adquisición de equipo o recursos humanos, que debe ser atribuido a una fuente para cubrir las necesidades del proyecto. Con la técnica de JIT, el proyecto no incurriría en gastos relacionado con equipos en espera o teniendo miembros de equipo esperando para realizar su trabajo.

112


Gestión Total de Calidad TQM (la dirección de calidad total) es un proceso que anima a las compañías y empleados a concentrarse en la mejora ininterrumpida, mejorando así la calidad de sus hábitos y productos.

ISO 9000 ISO 9000 es un patrón creado por la ISO (la organización internacional para estandarización). Hay muchas variaciones de la certificación de ISO 9000, pero con cada uno, el objetivo es asegurarse de que una compañía establezca procesos de calidad y luego siga dichos procesos.

Deming W. Edwards Deming es un consultor que trabajó con industrias japonesas. Sobre la base de su trabajo, creó un programa de 14 puntos para la calidad, y sugirió que 85 por ciento del coste de la calidad fuera la responsabilidad de la dirección. La calidad debe ser aprovisionada en los materiales y funcionar desde muy temprano en el proyecto. En cuanto surge un problema en el nivel del trabajador, es demasiado tarde hacer mucho sobre él (ella / eso), cuando el origen del problema está frecuentemente sin el control de los trabajadores. Por ejemplo, si la dirección decide contratar a programadores juniors para ahorrar dinero, la prueba puede descubrir no sólo los números más altos de defectos para corregir en el producto, sino también problemas de lógica que pueden tener un impacto más grande en el producto final. La decisión tomada por la dirección para usar programadores menos experimentados directamente afectó la calidad del producto. En otro ejemplo, si la dirección decide comprar equipo de red de un distribuidor sin probar para ahorrar costes de equipo, esta decisión puede presentar nuevos riesgos adicionales, ya que la habilidad con respecto a los requisitos de puesta en funcionamiento específicos del producto del nuevo distribuidor es desconocida.

Kaizen El objetivo es hacer 100 mejoras de 1 % cada una, En vez de 1 mejora de 100 %. 100

100

70

40 1

1

Kaizen, también conocido como la mejora ininterrumpida, es una técnica japonesa, y es una de las filosofías más populares hoy. Kaizen fomenta concentrarse en las mejoras pequeñas, ininterrumpidas en vez de solo grandes. La palabra kaizen está formado por dos partes, kai, el significado para modificar, y zen, el significado para mejorar o hacer mejor. En Japón, kaizen es sólo una palabra que representa la mejora ininterrumpida. Con Kaizen, el objetivo es hacer 100 mejoras de 1 por ciento cada vez en vez de 1 mejora de 100 por ciento.

113


Herramientas de calidad y técnica Diagrama de flujo de proceso 1. Identificar Producto y necesidad del mercado

2. Prepárese Resumen de proyecto

3. Prevalezca Aprobación de dirección

4. Determinar Necesidad del cliente

7. Desarróllese 5. Funcione Análisis competitivo 6. Desarróllese Empresa / plat. Estrategia

Requisitos de producto

8.Desarróllese Concepto de producto

12. desarróllese Est de coste

9. D esarróllese

10. Valorar &

Estrategias de operaciones

Proveedores exigentes selectos

11. Prepárese

15. Conducta

Mapa de carreteras de producto

Evaluación de diseño de concepto

13. Prepárese Proyecte & arriesgue mgt. Plan

14. Prepárese Caja de la empresa

16. Conducta Evaluación de salida de fase

preliminar.

Dibujo88: diagrama de flujo de proceso

Un diagrama de flujo de proceso es una técnica útil para incrementar la probabilidad de calidad en un proyecto. Esta técnica ayuda a equipos de proyecto a retratar los pasos de proceso o la circulación de trabajo relacionada con elementos de un proyecto con exactitud. Los diagramas de flujo de proceso pueden ser usados para ilustrar los pasos involucrados en producir un entregable o terminar un proceso de workflow humano.

Diagrama de Fishbone (Espina de Pescado) Diagramas de Fishbone, también referido como el diagrama de causa-efecto, ilustra y puede ayudar a determinar cómo los factores varios relacionan los problemas potenciales con la causa. El nombre diagrama de fishbone viene del hecho de que el diagrama terminado se parece al esqueleto de un pez. Cada rama, o hueso, del diagrama señala las posibles causas de un problema. Cuando todas las ramas son llenadas, los efectos individuales y combinado pueden ayudar a desarrollar una solución y reducir el problema o el defecto. El diagrama permite la organización de las ideas y apoya la consideración ordenada de los factores que resultarán en cierto resultado.

Tabla de Control Las tablas de Control son visualizaciones gráficas que retratan los datos de rendimiento con el tiempo y ayudan a determinar si un proceso está controlado fuera de control. Los resultados que están dentro de una extensión aceptable predeterminada o umbral son estimados en control o dentro de niveles de calidad aceptables. Aquellos que caen aparte del alcance aceptable son considerados fuera de control. La excepción para estas reglas es encontrada en la regla de los 7. La regla de los 7 estipula que las muestras que caen dentro de los límites de control pueden ser consideradas fuera de control si siete o más muestras en fila caen arriba o debajo de la media, como se muestra en la figura 91. Esta condición debe ser examinada para determinar la causa, cuando puede indicar que está ocurriendo una tendencia. 114


Prueba de Proyecto de TI

Unidad Sistema Integración Aprobación

Dibujo92: la prueba de proyecto de IT g La prueba de proyecto de TI es una forma de inspección de calidad. El propósito principal de la prueba de proyecto de TI es verificar que la solución, como el software, el equipo físico, o una red, cubra los requerimientos del cliente dichos y las necesidades de grupo de colaboradores. El objetivo es asegurar que los defectos de producto repartidos al cliente son eliminados o reducidos significativamente. En TI, hay varios niveles y etapas de prueba. Lo más común es incluir: •

Prueba de unidad: durante la prueba de unidad, los miembros del equipo de proyecto evalúan los componentes individuales del producto. En este escenario de la prueba, los miembros de equipo aseguran que el componente específico cubre los requisitos funcionales y técnicos.

•

Prueba de sistema: la prueba de sistema se las arregla con los aspectos de equipo físico o los equipos del producto principalmente. Durante esta fase, el equipo de proyecto verifica que el hardware de computadora o los componentes de conexión en red funcionen como requieren y esperaran.

•

Pruebas de Integración: durante las pruebas de integración, los componentes individuales del producto son evaluados en un ambiente exhaustivo. En otras palabras, el software, el equipo físico, y los artículos de conexión en red de la solución son traídos en conjunto para la prueba final.

•

Prueba de aprobación: la prueba de aprobación sirve como la actividad final de verificación de pruebas. Esta prueba puede ser hecha en múltiples repeticiones y etapas, como la comprobación interna, la prueba beta, o en un ambiente piloto de la organización.

115


116


14 14.Cierre de Fase y de Proyecto. Temas de sección •

Procesos de cierre de Fase y de Proyecto

•

Las lecciones aprendidas

•

Informes de Fase y de proyecto

•

Desarrollar un informe de proyecto final

Ejercicio

117


Procesos de cierre de Fase y de Proyecto Liquidación de contrato Cierre Administrativo

Dibujo93: Procesos de cierre de Fase y de Proyecto

Hay dos procesos de dirección de proyecto principales relacionados con la fase de cierre. Estos procesos son: liquidación de contrato y cierre administrativo. Aunque suenan al mismo tipo de proceso, difieren tanto en su aplicación como en el respectivo tiempo de entrega oportuno.

Liquidación de contrato Verificación del servicio o del Producto Auditorías fuentes y

/

adquisición Aprobación Formal del contrato Reporte Final del contrato Figura 94: liquidación de contrato

Registros de los contratos Archivados

El cierre del contrato finaliza con el establecimiento de los términos del contrato. En un proyecto , el cierre del contrato es donde el trabajo del contrato, como subcontratar externos, es verificado asegurando que todo el trabajo fue terminado como se especificó y que los registros han sido actualizados y archivados de acuerdo a las reglas establecidas. La liquidación de contrato es llevada a cabo solamente una vez, al final del contrato. Las actividades relacionadas con la liquidación de contrato son mostradas en la figura 94.

118


Cierre Administrativo Verificación del servicio o del producto Actualizaciones de los registros del proyecto Reporte de fase o del proyecto final Aprobación formal del proyecto Las lecciones aprendidas Registros de fases o archivar el proyecto Actualizaciones de los recursos del proyecto La celebración!!

Dibujo95: el cierre administrativo

El cierre administrativo es llevado a cabo al final de cada fase o al final del proyecto. Este proceso ocurre si los objetivos planteados fueron conseguidos o la fase o el proyecto fueron rescindidos prematuramente. Las actividades relacionadas con el cierre administrativo son mostradas en la figura95.

119


Las Lecciones Aprendidas ¿Qué salió bien? ¿Qué salió mal? ¿Cuáles son algunas ideas y recomendaciones para mejorar? ¿Qué debe ser conservado y reusado?

?

???

Figura 96: las lecciones aprendidas

Aunque es uno de los aspectos más descuidados y pasados por alto en la dirección de proyecto de TI, el proceso de lecciones aprendidas puede suministrar a una organización la entrega de un proyecto con un fundamento fuerte para las prácticas de dirección de proyecto eficaces. El proceso de las lecciones aprendidas es la reunión, la diseminación, evaluación, y archivo de la historia del proyecto. Está diseñado para permitir que la organización del proyecto capte la siguiente información:

120

•

Cosas que se hicieron bien: historias de éxito del proyecto

•

Cosas que se hicieron mal: los problemas o los asuntos enfrentados sobre el proyecto

•

Las oportunidades para la mejora: las ideas y las recomendaciones para futuras iniciativas

•

Mejores Prácticas: materiales, documentación, y procesos que deben ser conservados y reusado dentro de la organización


Informes de Fase y de Proyecto

Notas

Informes de Progreso y del Proyecto

Informe de semáforo

/

Peligro Entregables o artículos claves están fuera de tiempo.

Precaución

Siga

Entregables o artículos claves están en peligro de estar fuera de tiempo.

Entregables o artículos claves están a tiempo.

Figura 97: el progreso y el señalamiento de proyecto

Una de las maneras más eficaces de capturar y mantener la información de proyecto útil es mantener las prácticas de señalamientos simples y consecuentes. Haciéndolo, la organización crea un método eficaz de entrega de proyecto para presentar un plan de estado claro para el proyecto. Una técnica común de señalamiento útil es el informe de semáforo. Esta técnica de informe integra el plan rojo, amarillo y verde para entregar y comunicar el respectivo estado de un proyecto en cualquier momento durante la vida del proyecto.

121


Informe final de proyecto Resumen Resultados Valoración de criterios de éxito Lecciones aprendidas y recomendaciones Valoración y evaluación del equipo de proyecto Artículos de acción Firma y Aceptación

Dibujo98: informe de proyecto finalt

El informe final de proyecto es un entregable crítico para todo proyecto, como este suministra a la organización con una historia exhaustiva del proyecto y sus éxitos asociados, los desafíos, y las lecciones aprendidas. Desafortunadamente para muchas organizaciones de TI, el informe de proyecto final está a menudo descuidado debido a la asignación inmediata de los recursos o reasignación hacia la fase final de un proyecto. Un diseño ideal para el informe final incluye lo siguiente:

122

•

Resumen: ésta es una descripción de las metas, los objetivos y la historia del proyecto.

•

Resultados: esto es una descripción de qué ha sido entregado y producido como consecuencia del proyecto.

•

Valoración de criterios de éxito: esto es un resumen de los resultados de los criterios de éxito definidos al principio del proyecto. ¿El proyecto consiguió los objetivos dichos?

•

Lecciones aprendidas y recomendaciones: ¿qué tan bien nos fue? ¿Qué puede ser mejorado como consecuencia del proyecto? ¿Qué tiene que ser done ir hacia adelante?

•

Valoración de equipo de proyecto y evaluación: esto es una valoración de los miembros de equipo de proyecto y los grupos colaboradores claves, la información de desarrollo de competencia, y las recomendaciones para los miembros de equipo.

•

Artículos de acción: esto es una descripción o la lista de artículos que tienen que existir en cuanto el proyecto es concluido.

•

Cerrar y aprobación: esto es la firma y la aprobación formal del proyecto.


Tabla de Contenido 01.Proyectos Fallidos y Culminados. .............................................................................................................................3 Un estudio del éxito y las fallas de los proyectos ......................................................................................................4 Razones por las que un Proyecto Fracase .................................................................................................................5 Razones de Éxito en los Proyectos .............................................................................................................................6 ¿Proyectos de TI: Qué los hace diferentes?...............................................................................................................7 Comparación de las características de Proyectos de TI y no TI .................................................................................8 02.Fundamentos de Gerencia de Proyectos. .................................................................................................................9 Introducción ............................................................................................................................................................10 Diseño del Curso ......................................................................................................................................................11 Gerencia de Proyectos Básica ..................................................................................................................................12 ¿Qué es un Proyecto? ..........................................................................................................................................12 Proyectos vs. Programas ..........................................................................................................................................13 Ciclo de Vida de la Gerencia de Proyectos...............................................................................................................14 El Ciclo de Vida del Proyecto vs. El Ciclo de Vida de la Gerencia del Proyecto ....................................................15 IPECC y el Ciclo de Vida del Producto ..................................................................................................................16 IPECC y el Ciclo de Vida de Proyectos en TI .........................................................................................................17 Áreas de Conocimientos en la Gestión de Proyectos ..............................................................................................18 Triple Limitaciones de la Gestión de Proyectos .......................................................................................................19 Organizaciones de los Proyectos .............................................................................................................................20 Organización Funcional........................................................................................................................................20 Organización Proyectizada ..................................................................................................................................21 Organización Matricial .........................................................................................................................................22 Habilidades y Títulos del Gerente de Proyectos ......................................................................................................23 03.Iniciación del Proyecto............................................................................................................................................25 Introducción al inicio del Proyecto ..........................................................................................................................26 Elementos de la Iniciación del Proyecto ..................................................................................................................26 Selección del proyecto y priorización ..................................................................................................................27 Desarrollo de Caso de Negocio ............................................................................................................................28 Análisis de los Impulsores ....................................................................................................................................29 Project Charter.....................................................................................................................................................30 04.Definición de los Alcances del Proyecto. ................................................................................................................33 123


Visión Del Alcance....................................................................................................................................................34 Declaración de Alcances ..........................................................................................................................................35 Requerimientos: Definiciones y Recolección ...........................................................................................................36 Estructura de Descomposición del Trabajo .............................................................................................................37 Diccionario EDT ........................................................................................................................................................37 Entregables, Sub-Entregables, yPaquetesdeTrabajos .......................................................................................................38 05.Gestión del Tiempo y Programación. .....................................................................................................................39 Descomposición en el Tiempo .................................................................................................................................40 Definición de Actividades ........................................................................................................................................40 Secuenciando las Actividades ..................................................................................................................................41 Estimación de las Duraciones de las Actividades.....................................................................................................42 Diagrama de Red .....................................................................................................................................................44 Camino Crítico .........................................................................................................................................................44 Comienzo mas Temprano ....................................................................................................................................45 Fecha más Tardía .................................................................................................................................................46 06.Planificación de los Recursos. .................................................................................................................................47 Identificación de los Recursos Requeridos ..............................................................................................................48 Matriz de Roles y Responsabilidades .......................................................................................................................48 Matriz de Asignación de Recursos ...........................................................................................................................49 Gestión del Staff ......................................................................................................................................................49 Calendario de Recursos .......................................................................................................................................49 Calendario de un Recurso para un Equipo de Trabajo ........................................................................................50 Restricciones en los Recursos ..................................................................................................................................51 07.Control y Gestión de Costos. ..................................................................................................................................53 Técnicas de Estimación de Costos ............................................................................................................................54 TiposdeEstimaciones ..................................................................................................................................................55 Gestión de Contingencia y Reservas ........................................................................................................................56 Gestión y Control de Costos .....................................................................................................................................57 Análisis del Valor Ganado ....................................................................................................................................57 Controlando y Gestionando los Costos: Análisis de Valor Ganado ......................................................................58 08.Gestión de Comunicaciones. ..................................................................................................................................61 124


Gestión de las Expectativas de los Involucrados .....................................................................................................62 Consideraciones para la Comunicación Eficaz .........................................................................................................63 Líneas de Comunicación ..........................................................................................................................................64 Formas de Comunicación.........................................................................................................................................65 Gestión del Plan de Comunicaciones .......................................................................................................................66 Reporte de Estatus del Proyecto .............................................................................................................................67 09.Gestión de Riesgo del Proyecto. .............................................................................................................................69 Lo Esencial en la Gestión de Riesgo de Proyecto .....................................................................................................70 Fuentes de Riesgo para el Proyecto.........................................................................................................................72 Tolerancia al riesgo de los Colaboradores ...............................................................................................................73 Identificación de los Riesgos ....................................................................................................................................74 Clasificación de riesgo..............................................................................................................................................75 La Probabilidad, el Impacto y la Detectabilidad ......................................................................................................75 La Probabilidad = La Probabilidad de Ocurrencia ................................................................................................75 El Impacto = La Consecuencia Del Evento ...........................................................................................................75 Detectabilidad = La Habilidad de Averiguar la Presencia del Evento Riesgo .......................................................76 Puntuación de los Riesgos .......................................................................................................................................77 Herramientas para Clasificar los Riesgos .................................................................................................................78 Disparadores de Riesgos ..........................................................................................................................................79 Estrategias De Respuesta De Riesgo ........................................................................................................................80 Reservas De Contingencia Calculadas......................................................................................................................81 Reservas de Contingencia: Usando EMV ...............................................................................................................82 10.Adquisición y Fuentes. ............................................................................................................................................83 Adquisición y Fuentes de Dirección .........................................................................................................................84 Rol del director de proyecto ....................................................................................................................................84 Construya o compre ................................................................................................................................................85 Requisitos de contrato y términos legales...............................................................................................................87 Tipos de Contratos ...................................................................................................................................................88 Contratos de precio fijos......................................................................................................................................88 Contratos de Costos reembolsables ....................................................................................................................89 Contratos de tiempo y materiales .......................................................................................................................89 11.Metodologías y Marcos Referenciales en Proyectos. ............................................................................................91 Metodologías Genéricas de Gestión de Proyectos ..................................................................................................92 Stage-Gate ...........................................................................................................................................................92 125


Modelo de Madurez de Gestión de Proyectos Organizacionales ........................................................................93 Cadena Critica ......................................................................................................................................................94 Metodologías y Procesos para Desarrollo de Software ...........................................................................................95 Dirección de proyecto extrema ...........................................................................................................................95 Cascada ................................................................................................................................................................96 Desarrollo de Aplicación Rápido ..........................................................................................................................96 Proceso unificado Racional ..................................................................................................................................97 Modelo Integrado de Madurez de Capacidad .....................................................................................................97 12.Controlar y Dirigir el Cambio. .................................................................................................................................99 Cambios de proyecto .............................................................................................................................................100 Control de Cambio integrado ................................................................................................................................102 Proceso de Control de Cambios .............................................................................................................................103 Cambios de Emergencia o Arreglos .......................................................................................................................104 Herramientas de Control de Cambios ...................................................................................................................105 Diagrama de flujo de Gestión de Cambios ........................................................................................................105 Diario de Control de Cambio .............................................................................................................................106 13.Garantía y Control de Calidad. ..............................................................................................................................109 Calidad de proyecto ...............................................................................................................................................110 Teorías de dirección de calidad .............................................................................................................................112 Justo a Tiempo ...................................................................................................................................................112 Gestión Total de Calidad ....................................................................................................................................113 ISO 9000 .............................................................................................................................................................113 Deming...............................................................................................................................................................113 Kaizen ................................................................................................................................................................113 Herramientas de calidad y técnica ........................................................................................................................114 Diagrama de flujo de proceso ............................................................................................................................114 Diagrama de Fishbone (Espina de Pescado) ......................................................................................................114 Tabla de Control ................................................................................................................................................114 Prueba de Proyecto de TI ......................................................................................................................................115 14.Cierre de Fase y de Proyecto. ...............................................................................................................................117 Procesos de cierre de Fase y de Proyecto .............................................................................................................118 126


Liquidación de contrato .....................................................................................................................................118 Cierre Administrativo .........................................................................................................................................119 Las Lecciones Aprendidas ......................................................................................................................................120 Informes de Fase y de Proyecto ............................................................................................................................121 Informes de Progreso y del Proyecto ....................................................................................................................121 Informe de semáforo .........................................................................................................................................121 Informe final de proyecto ..................................................................................................................................122

127

Gestion de Proyectos Basados en El PMBOK - Manual

Recommend Documents