principios de project management, 2006 1 project management 2: 9 Áreas del conocimiento procesos de...
TRANSCRIPT
Principios De Project Management, 2006
1
Project Management
2: 9 Áreas del Conocimiento
Procesos de un Proyecto
Principios De Project Management, 2006
2
Gestión de las Adquisiciones
Principios De Project Management, 2006
3
Gestión de las Adquisiciones
• Procurement significa adquirir bienes y/o servicios desde una fuente externa– “compras u outsourcing”
Principios De Project Management, 2006
4
¿Por qué Outsource?
• Reducir costos fijos y recurrentes
• Para permitir que la organización del cliente se centre en su negocio de base
• Accesar habilidades y tecnologías
• Proveer flexibilidad
• Para aumentar responsabilidad
Principios De Project Management, 2006
5
Gestión de Adquisiciones• Procurement planning: determinando qué solicitar y
cuando• Planificación de la solicitud: documentando requisitos
e identificar fuentes potenciales del producto• Solicitudes: obteniendo citas, ofertas o propuestas,
como sea apropiado• Selección de fuente: el elegir entre de vendedores
potenciales• Administración del contrato: manejo de la relación
con el vendedor• Liquidación del contrato: terminación y
establecimiento del contrato
Principios De Project Management, 2006
6
Gestión de Adquisiciones del Proyecto: Procesos y Salidas
Principios De Project Management, 2006
7
Adquisiciones: Herramientas y Técnicas
• Hacer o comprar análisis (construir vs comprar)
• Determinándose si un producto o un servicio particular se debe hacer o realizar dentro de la organización o comprárselo a algún otro. Implica a menudo análisis financiero.
• Expertos• Internos y externos, pueden proporcionar entradas
valiosas en decisiones de adquisición
Principios De Project Management, 2006
8
Ejemplo: Hacer o Comprar
• Asumir que puedes arrendar un artículo que necesitas para un proyecto para $150/día. Comprar el artículo, el coste de inversión es $1.000, y el coste diario sería otro $50/día.
• ¿Cuanto tiempo tomará para que el coste de la contrato de arrendamiento sea igual que el coste de compra?
• ¿Si necesitas el artículo por 12 días, debes arrendarlo o comprarlo?
Principios De Project Management, 2006
9
Solución: Hacer o Comprar• Configurar una ecuación donde el “hacer” es igual a la
“compra”• En este ejemplo, utilizar la ecuación siguiente. “d” es el
número de los días para utilizar el artículo.$150d = $1,000 + $50d
• Solucionar “d” como sigue:d = 10 días
• El coste de la contrato de arrendamiento es igual que el coste de compra en 10 días
• Si necesitas el artículo por > 12 días, entonces comprarlo
Principios De Project Management, 2006
10
Tipos de Contratos
• Precio fijo o suma global: implica un precio total fijo para un producto o servicio bien definido
• Coste reembolsable: implica el pago al vendedor para los costes directos e indirectos
• Contratos de Tiempo y de materiales: híbrida el precio fijo y el coste reembolsables, de uso frecuente por los consultores
• Contratos de precio unitario: requiere que el0 comprador pague al vendedor una cantidad predeterminada por la unidad de servicio
Principios De Project Management, 2006
11
Contratos de costo reembolsable• Coste más el honorario incentivo (Cost plus incentive
fee (CPIF))– El comprador paga al vendedor costes adecuados al funcionamiento
más un honorario predeterminado y una prima incentiva
• Coste más honorario fijo (Cost plus fixed fee (CPFF))– El comprador paga al vendedor costes adecuados al funcionamiento
más un pago honorario fijo basado generalmente en un porcentaje de costes estimados
• Coste más el porcentaje de costes (Cost plus percentage of costs (CPPC))– El comprador paga al vendedor costes adecuados al funcionamiento
más un porcentaje predeterminado basado en costes totales
Principios De Project Management, 2006
12
Tipos de contrato contra riesgo
Principios De Project Management, 2006
13
Enunciado del TrabajoStatement of Work (SOW)
• Una descripción del trabajo requerido para el proyecto
• Fija las “condiciones de borde”
• SOW vs. CSOW (Contract SOW)– Último: utiliza lenguaje legal como parte de un
escenario de oferta competitiva
• Puede ser utilizado en el contrato final - tener cuidado, ser específico, estar claro
Principios De Project Management, 2006
14
Continuación SOW
• Hecho típicamente después de la aprobación (después del “vamos”)
• Pueden ser múltiples versiones– 1. Lista de entregables para un RFP– 2. Versión obligatoria del contrato
Principios De Project Management, 2006
15
Plantilla SOWI. Alcance del trabajo: Describir el trabajo que se hará en detalle. Especifica el
hardware y el software implicado y la naturaleza exacta del trabajo.
II. Localización del trabajo: Describir donde el trabajo debe ser realizado. Especificar la localización del hardware y del software y donde la gente debe realizar el trabajo.
III. Período del funcionamiento: Especificar cuando se espera que el trabajo comience y termine, horas de trabajo, número de las horas que se pueden facturar por la semana, dónde el trabajo debe ser realizado, y la información relacionada con el horario. Sección opcional de “remuneración”.
IV. Horario de Entregables: Enumerar los entregables específicos, describirlos detalladamente, y especificar cuando son liberados.
V. Estándares aplicables: Especificar cualquier compañía o estándar específico de la industria que sean relevantes para realizar el trabajo. A menudo hay una sección de Supuestos también.
VI. Criterios de la aceptación: Describir cómo la organización del comprador se determinará si el trabajo es aceptable.
VII. Requisitos especiales: Especificar cualquier requisito especial tal como certificaciones de hardware o de software, grado mínimo o nivel del personal, requisitos de viajes, documentación, pruebas, soporte, y así sucesivamente.
Principios De Project Management, 2006
16
Project Management
Planificación
Principios De Project Management, 2006
17
Gestión del Alcance
Principios De Project Management, 2006
18
Gestión del Alcance
• Planificación del Alcance
Principios De Project Management, 2006
19
Carta del Proyecto
• Una descripción del proyecto de alto nivel :– Necesidades del negocio, producto, supuestos
• Precede a menudo al SOW
• A menudo 2-4 páginas (puede ser más largo)
Principios De Project Management, 2006
20
Carta del Proyecto
• Contorno típico– Descripción
• Necesidades del negocio• Objetivos• Método o acercamiento
– Alcance general del trabajo– Bosquejo de Calendario y Presupuesto– Roles & responsabilidades– Supuestos
Principios De Project Management, 2006
21
Exploración del Concepto Planificación
• La Fase del “Por qu锕 No es una fase “obligadamente formal”
– Llamada a veces la fase “pre-proyecto”
• Recolección de ideas para el proyecto• Justificación del Proyecto
– ROI (Return On Investment)– Análisis Costo-beneficio– Matriz del Portfolio del Proyecto
• Planificación y Estimaciones iniciales
Principios De Project Management, 2006
22
Exploración del Concepto
• Posiblemente incluye Procurement Management:• Selección de proveedor• Gestión de Contratos
• Se forma el equipo inicial– Incluso el PM si no está listo
• Identificar al patrocinador del Proyecto– Contacto primario para realizar las aprobaciones y
tomar decisiones• Salidas Potenciales de la Fase:
– Documento Conceptual, Descripción del Producto, Propuestas de Plan, SOW, Carta del Proyecto
Principios De Project Management, 2006
23
Requisitos
• La Fase del “Qué”
• Entradas: SOW, Propuestas de Plan
• Salidas: – Documento de Requisitos (Req Doc)– Primer punto de partida para el Proyecto– Aprobación de requisitos y Firma final
• La tarea más difícil de esta fase.
Principios De Project Management, 2006
24
Requisitos
• Tal vez la fase más importante y difícil
• El error clásico es hacer “cambios de última hora”
Principios De Project Management, 2006
25
Requisitos
• Características– Conflicto de intereses: diseñadores vs. cliente– Guerra de “tira y afloja” potencial:
• Desacuerdos en características y estimaciones
• Especialmente en contratos a precio fijo
– Cambios de requisitos frecuentes
• La Planificación del proyecto ocurre en paralelo
Principios De Project Management, 2006
26
Requisitos
• Los requisitos son las capacidades y condiciones a las cuales el sistema – y más ampliamente, el proyecto – debe adecuarse.
Principios De Project Management, 2006
27
2 Tipos de Requisitos
– Funcionales (conductual)– Características y capacidades
– No-funcionales ( “técnicas” o todo lo demás)– Utilidad
» Factores humanos, ayuda, documentación– Confiabilidad
» Tasa de fallas, recuperabilidad, disponibilidad– Funcionamiento
» Tiempos de respuesta, rendimiento, uso de recursos– Soporte
» mantención– Operaciones: administración de sistemas, instalación– Interfaz: integración con otros sistemas– Otros: legales, hardware
Principios De Project Management, 2006
28
Reuniones iniciales
• Reunión de lanzamiento del proyecto
• Reunión Brainstorming del proyecto– Clarificar metas, alcance, supuestos– Refinar estimaciones
• Reunión WBS
Principios De Project Management, 2006
29
Análisis y Diseño
• Las fases del “Cómo”
• Entradas: Documento de Requisitos
• Salidas: – Especificaciones Funcionales– Documento de diseño detallado– Prototipo (se puede hacer con los requisitos)– Plan actualizado (estimaciones mejoradas;
nuevo punto de partida)
Principios De Project Management, 2006
30
Análisis y Diseño
• Características– Estructura de Equipos y asignaciones listas– Atrasos producto de cambios en los requisitos,
nueva información o ideas tardías– Requerimientos in factibles– Problemas de recursos
Principios De Project Management, 2006
31
Desarrollo
• La fase del “Hacer”
• A menudo las fases de Diseño e Integración se traslapan– Es para achicar el programa total– El PM necesita coordinar esto
Principios De Project Management, 2006
32
Desarrollo
• Otras actividades relacionadas– Completar el diseño– Inicio de la integración– Testeo individual de los diferentes
componentes– Prueba de la mejor configuración– Actualización del plan del proyecto– Manejar la gestión del Alcance y la gestión del
Riesgo
Principios De Project Management, 2006
33
Desarrollo
• Características– La presión aumenta
– Personal de alto nivel
– A menudo ralentiza la operación
• Asuntos– Cambios de último minuto
– Coordinación de equipos
– Sobre carga de comunicación
– Gestión de sub-contratistas
Principios De Project Management, 2006
34
Integración y Pruebas
• Evolución de la fase de desarrollo
• Es bueno hacerlo como 2 fases en paralelo– Integración parcial y pruebas iniciales
• Como inicio se construye una versión incompleta
• Se agregan más componentes progresivamente
Principios De Project Management, 2006
35
Integración y Pruebas
• Las pruebas se realizan principalmente con un equipo de Asistencia de Calidad (Quality Assistance)
• Integración:– Top-down– Bottom up– Generalmente se prefiere top-down
Principios De Project Management, 2006
36
Integración y Pruebas
• Pruebas– Prueba de integración– Load & Stress testing– Alpha & Beta testing– Prueba de aprobación
• Otras actividades– Presupuesto final, gestión del riesgo,
entrenamiento, preparativos de instalación, reducción de personal
Principios De Project Management, 2006
37
Integración y Pruebas
• Características– Aumento de la presión– Sobre tiempo– Posibles conflictos con el cliente acerca de las
características del producto– Frustración por fallas inesperadas– Sobrepaso de presupuesto– Problemas en la aprobación del cliente
• Expectativas, contrato con precio fijo
Principios De Project Management, 2006
38
Planificación
• “Los planes no son nada. Pero la planificación es todo .” Gen. Dwight Eisenhower
Principios De Project Management, 2006
39
Planificación
• Comienzo preliminar del planeamiento en el día uno
• No debe ser conducido “en secreto”
Principios De Project Management, 2006
40
Primeros Pasos de la Planificación
• Identificar el alcance y los objetivos del proyecto • Identificar el ambiente de organización del
proyecto• Analizar las características del proyecto • Identificar los productos y las actividades del
proyecto • Esfuerzo de la estimación para cada actividad • Identificar el riesgo • Asignar los recursos • Repasar y comunicar el plan
Principios De Project Management, 2006
41
Documentos
• Planificación
• Producto o servicio
Principios De Project Management, 2006
42
Planificación
• Alcance
• Estimación
• Riesgo
• Cronograma
• Controlar la estrategia
Principios De Project Management, 2006
43
Plan de Proyecto
Principios De Project Management, 2006
44
Cuestiones del Proceso
• Es deseable un proceso bastante sofisticado sin incurrir en muchos gastos indirectos
• Recordar, los proyectos son a menudo más grandes de lo que primero aparentan
• Es más fácil aflojar demasiado los procesos que agregar más después
Principios De Project Management, 2006
45
Project Management
WBS, Estimación & Cronograma
Principios De Project Management, 2006
46
Estimación
• “Las predicciones son duras, especialmente sobre el futuro”, Yogi Berra
• 2 tipos: ¿Afortunado o pésimo?
Principios De Project Management, 2006
47
Planificación, Estimación, Cronograma
• ¿Cuál es la diferencia?
• Plan: Identificar las actividades. No se especifican las fechas de comienzo y de término.
• Estimando: Determinación del tamaño y de la duración de actividades.
• Calendario: Agrega fechas específicas del comienzo y del término, relaciones, y recursos.
Principios De Project Management, 2006
48
Planificación del proyecto: Un programa de 12 pasos
1) Fijar la meta y el alcance
2) Seleccionar el ciclo de vida
3) Fijar la forma del org./team
4) Comenzar la selección del team/equipo
5) Determinar los riesgos
6) Crear la WBS
7) Identificar las tareas
8) Estimar el tamaño
9) Estimar el esfuerzo
10) Identificar dependencias de las tareas
11) Asignar recursos
12) Calendarizar el trabajo
Principios De Project Management, 2006
49
Cómo programar el tiempo
• 1. Identificar “qué” se necesita para hacerlo– Work Breakdown Structure (WBS)
• 2. Identificar “cuanto” (el tamaño)– Técnicas de estimación de tamaño
• 3. Identificar la dependencia entre tareas– Gráfico de Dependencia, Diagrama de red
• 4. Estimar la duración total del trabajo a realizar– La Cronograma actual
Principios De Project Management, 2006
50
WBS y Estimación
• Qué se siente si se pregunta:– “¿Cuánto durará el proyecto?”
• ¿No hay una respuesta fácil que sea correcta?
• Por lo menos no si se fuera un cliente real de un proyecto verdadero
• ¿Cómo se puede administrar este asunto?
Principios De Project Management, 2006
51
Particionando el Proyecto
• Necesitas descomponer tu proyecto en pedazos manejables
• TODOS los proyectos necesitan este paso• Divide y Conquista• ¿Cómo ayudan estas particiones?
Principios De Project Management, 2006
52
Elementos de un Proyecto• Un Proyecto es: funciones, actividades, tareas
Principios De Project Management, 2006
53
Work Breakdown Structure: WBS• Es una lista jerárquica de las actividades de trabajo
del proyecto• Hay 2 formatos
– De contorno– Árbol Gráfico (Carta Organizacional)
• Usa un sistema de numeración decimal– Ejemplo: 3.1.5– 0 es típicamente el nivel superior
• Incluye– Desarrollo, gestión., tareas de soporte del proyecto
• Muestra relaciones como “está contenido en”• No muestra dependencias ni duraciones
Principios De Project Management, 2006
54
WBS
• Contract WBS (CWBS)– Los primeros 2 o 3 niveles– Seguimiento de alto nivel
• Project WBS (PWBS)– Es definido por el Project Manager y los
miembros del team– Tareas ligadas a los entregables– Seguimiento de los niveles inferiores
Principios De Project Management, 2006
55
La WBS completa
• Hasta 6 niveles (usualmente 3-6) como sigue
• Los 3 niveles superiores pueden ser usados por el cliente para reportes
• Diferentes niveles se pueden aplicar a diferentes usos– Ejemplo: Nivel 1: autorizaciones; 2: presupuestos; 3:
calendarios
Principios De Project Management, 2006
56
Ejemplo de carta WBS
Principios De Project Management, 2006
57
Ejemplo WBS de contorno0.0 Sitio Web de Retail1.0 Project Management2.0 Requisitos3.0 Análisis y Diseño4.0 Desarrollo del software del sitio
4.1 Diseño y Creación HTML4.2 Software
4.2.1 Implementación de Base de Datos4.2.2 Desarrollo de Middleware4.2.3 Subsistemas de Seguridad4.2.4 Engine del catálogo4.2.5 Procesamiento de transacciones
4.3 Gráficas e Interface4.4 Creación de Contenido
5.0 Pruebas y Producción
Principios De Project Management, 2006
58
Tipos de WBS• WBS de Procesos
• Ejemplo: Requerimientos, Análisis, Diseño, Testing• Típicamente usado por los PM
• WBS de Producto • Ejemplo: Motor Financiero, Sistema de Interfaz, DataBases• Típicamente usado por gerentes de ingeniería
• WBS Híbrida: mezcla de los dos anteriores• No es usual esto• Ejemplo: Fases del ciclo de vida en los niveles altos con
componentes o características específicas dentro de las fases• Análisis racional: Los procesos producen los productos o
servicios
Principios De Project Management, 2006
59
WBS de Producto
Principios De Project Management, 2006
60
WBS de Procesos
Principios De Project Management, 2006
61
WBS de contorno con Gantt
Principios De Project Management, 2006
62
WBS de los Grupos de Procesos PMI
Principios De Project Management, 2006
63
Tipo de WBS
• Alternativas con uso menos frecuente– WBS Organizacional
• Investigación, Diseño de Producto, Ingeniería, Operaciones
• Puede ser útil para los proyectos altamente cros-funcionales
– WBS Geográfica• Puede ser útil con teams distribuidos
• Team Santiago, Team Puerto Montt, Team Norte
Principios De Project Management, 2006
64
Formas de Presentación
• Vista Camino Crítico
• Vista Progreso
Principios De Project Management, 2006
65
Formas de Presentación
• Vistas Horas y Costos
• Vista Planificación
Principios De Project Management, 2006
66
Paquetes de Trabajo• Término genérico para las tareas discretas con resultados
finales definibles• Típicamente son las “hojas” del árbol• La regla del “un – dos”
• A menudo: 1 o 2 personas por 1 o 2 semanas• Bases para supervisar y reportar progresos
• Se puede enlazar a items presupuestarios (charge numbers)• Recursos (personal) asignado
• Idealmente es mejor corto que largo• Se necesita estimar las acciones en progreso más largas• Estos son más subjetivos que “ya hechos”• Por ejemplo: 2 a 3 semanas máximo para proyectos de
software• 1 día mínimo (puede ser medio día)• Tampoco deben ser pequeños, como para mini-gestionar
Principios De Project Management, 2006
67
WBS
• Lista de Actividades, no de cualquier cosa• La lista de items puede ser de múltiples fuentes
– SOW, propuestas, brainstorming, stakeholders, team
• Describe actividades usando “bullet language”– Etiquetas con alta significancia pero concisas
• Todas las ramas del WBS no tienen que ir al mismo nivel
• No hay que planear más detalladamente de lo que se puede gestionar
Principios De Project Management, 2006
68
WBS y su Metodología• El PM debe “mapear” las actvidades para elgir el ciclo de
vida• Cada ciclo de vida tiene diferentes conjuntos de
actividades• Las actividades de procesos de integración ocurren en
todas las fases– Planificación, configuración, testing
• Las fases correspondientes a Operaciones y a Mantenimiento normalmente no están en el plan (son considerados post-proyecto)
• Los Entregables de las tareas varían según metodología
Principios De Project Management, 2006
69
Técnicas de WBS
• De Arriba hacia Abajo (Top-Down)• De Abajo hacia Arriba (Bottom-Up)• Analogía• Onda Rodante (Rolling Wave)
– 1st paso: ir 1 a 3 niveles de profundidad– Recopilar más requisitos o data– Agregar detalles más adelante
• Postearlo en una pared
Principios De Project Management, 2006
70
Técnicas de WBS
• Top-down– Empezar en el nivel más alto
– Desarrollo incrementando sistemáticamente el nivel de detalle
– Mejor si• El problema se entiende bien
• La Tecnología y la Metodología no son nuevas
• Esto es similar a un proyecto o problema anterior
– Pero también se aplica a la mayoría de las situaciones
Principios De Project Management, 2006
71
Técnicas de WBS
• Bottom-up– Empezar las tareas desde el nivel más bajo– Agregado dentro de los sumarios y documentos
de más alto nivel– Contras
• El consumo de Tiempo (se desperdicia)• Necesita más requisitos completos
– Pros• Detallado
Principios De Project Management, 2006
72
Técnicas de WBS
• Analogía– La WBS se hace sobre la base de un proyecto “similar”
– Se usa una plantilla
– La Analogía también se puede usar como base para estimaciones
– Pros• Se basa en experiencia actual y pasada
– Contras• Necesita de un proyecto comparable
Principios De Project Management, 2006
73
Técnicas de WBS
• Brainstorming (reuniones de reflexión)– Genera todo tipo de actividades que se crea son
necesarias de hacer– Agruparlas en categorías
• Las técnicas Top-down y Brainstorming pueden ser usadas en una misma WBS
• Recordar conseguir a la gente que estará involucrada en el trabajo
Principios De Project Management, 2006
74
WBS – Base de Muchas Cosas
• Calendariazción de la Red
• Costos
• Análisis de Riesgo
• Estructura Organizacional
• Control
• Medidas
Principios De Project Management, 2006
75
Pautas de WBS Parte 1
• Debe ser fácil de entender• Algunas compañías tienen estándares corporativos para estos
esquemas• Algunos artículos o items a nivel superior, como el Project
Management están en la WBS para cada proyecto– Otros varían por proyecto
• Lo que a menudo molesta más es lo que generalmente “está perdido o no visto”.
• Hay que analizar hasta que se pueda generar mediciones exactas de tiempo y costo
• Asegurar cada elemento correspondiente a un Entregable.
Principios De Project Management, 2006
76
Pautas de WBS Parte 2
• ¿Cuán detallado debe ser?– No tan detallado como el plan Final en MS-Project– Cada nivel no debería tener más de 7 items– Debe poder evolucionar en el tiempo
• ¿Qué herramienta se puede usar?– Excel, Word, Project– Herramienta de Diagramación de Cartas
Organizacionales (Visio, etc)– Aplicaciones comerciales especializadas
• Re utilizar una “plantilla” si es que se tiene unna
Principios De Project Management, 2006
77
Estimaciones, Cálculos
• Muy difícil de hacer, pero requerido a menudo• Creado, usado y refinado durante
– Planificación Estratégica– Estudio de Viabilidad y/o SOW– Propuestas, ofertas– Evaluación del proveedor y del sub-contratista– Planificación del Proyecto (iterativamente)
• Procesos Básicos1) Estimar el tamaño del producto2) Estimar el esfuerzo (horas-hombre)3) Estimar la Cronograma– NOTA: No todos estos pasos se realizan siempre explícitamente
Principios De Project Management, 2006
78
Estimaciones, Cálculos
• Recordar: una “estimación exacta” es un oxímoron• Estimar cuánto tiempo tomará…
– ¿Qué bases o referencias se usan para hacerlo?
– ¿Suficiente experiencia?
– Posiblemente una probabilidad “promedio”
– Para la mayoría de los proyectos en telecomunicaciones no hay un “promedio”
• La mayoría de las estimaciones en proyectos IT son erradas entre un 25 a 100%
Principios De Project Management, 2006
79
Cono de la Incertidumbre
Principios De Project Management, 2006
80
Estimaciones, Cálculos
• Tamaño: – Proyectos pequeños, varianza del 7% con
respecto a las estimaciones de requerimientos– Medianos, 22% de varianza– Grandes, 38% de varianza– Muy grandes, 51% de varianza
Principios De Project Management, 2006
81
Metodologías de Estimación
• Top-down• Bottom-up• Analogy• Juicio Experto• Método Paramétrico o Algorítmico
– Se usan fórmulas y ecuaciones
Principios De Project Management, 2006
82
Estimación Top-down
• Basado en las características generales del proyecto– Algunos de los otros pueden ser “tipos” de Top-Down
(Analogy, Juicio Experto y métodos Algorítmicos)• Ventajas
– Fácil de calcular– Eficaz en los inicios (como estimación de costos
iniciales)• Desventajas
– Algunos modelos son cuestionables o pueden no encajar con los requisitos
– Es menos preciso porque no de fija en los detalles
Principios De Project Management, 2006
83
Estimación Bottom-up
• Crea una WBS• Se agregan desde “abajo hacia arriba”• Ventajas
– Funciona bien si las actividades son bien sabidas y entendidas
• Desventajas– Las actividades específicas no siempre se conocen
– Consume más tiempo
Principios De Project Management, 2006
84
Juicio Experto
• Hecho por alguien con experiencia reciente en un proyecto similar
• Se tiene un “ Estimadivinador”
• La exactitud depende de su expertise “real”
• Las aplicaciones comparables deben ser elegidas con exactitud– Ser sistemático
Principios De Project Management, 2006
85
Estimación por Analogía
• Usa proyectos pasados– Debe ser suficientemente similar (tecnología, tipo, organización)– Encontrar atributos comparables (ej: número de inputs/outputs)
• Ventajas– Está basado en datos históricos actuales
• Desventajas– Dificultad para ‘coincidir’ tipos de proyectos– Los datos anteriores pudieron haber sido mal medidos– Cómo medir las diferencias - no son los dos exactamente iguales
Principios De Project Management, 2006
86
Cuestiones de la Estimación
• Las estimaciones de la calidad se necesitan tempranamente pero la información es limitada
• Las mejores estimaciones se basan en experiencia previa • Políticas de estimación:
– Se puede anticipar un “corte” dado por la gerencia superior
• Para muchos proyectos IT hay poco o ninguno– Cambio de las tecnologías– Datos históricos inasequibles dentro de la organización– Amplia variación en las experiencias y tipos de
proyectos
Principios De Project Management, 2006
87
Sobre y Sub Estimación
• Cuestiones de Sobre Estimación– El proyecto no será financiado
• Las estimaciones conservadoras que garantizan el éxito 100% pueden significar la probabilidad de financiamiento de cero .
– Ley de Parkinson: El trabajo se amplía para tomar el tiempo dado un plazo
– Peligro del alargamiento de la característica y del alcance
• Cuestiones de Sub Estimación– Inhabilidad de satisfacer plazos– Problemas de moral y otras motivaciones del team
Principios De Project Management, 2006
88
Pautas de Estimación
• ¡Estimar iterativamente!– Proceso de refinamiento gradual
– Hacer las mejores estimaciones en cada etapa de la planificación
– Refinar las estimaciones y ajustar los planes iterativamente
– Los planes y las decisiones se pueden refinar en respuesta
– Balance: demasiadas revisiones vs demasiados pocos
Principios De Project Management, 2006
89
“Presentación” de Estimaciones• El cómo se presenta las estimaciones puede tener un tremendo
impacto• Técnicas
• Calificadores Más-o-menos– 6 meses +/-1 mes
• Rangos– 6-8 meses
• Cuantificación del riesgo– +/- con información adherida– +1 mes de equipos nuevos que no trabajan según lo esperado– -2 semanas de retraso al emplear más técnicos
• Casos– Mejor / Planificado / Actual / Peor cases
• Fechas gruesas– Q3 07
• Factores confidenciales– Abril 1 – 10% de probabilidad, Julio 1 – 50%, etc.
Principios De Project Management, 2006
90
Otros factores de Estimación
• Tener en cuenta tiempo para las cosas que “no son del proyecto” y para las tareas comunes– Reuniones, llamadas telefónicas, uso de
Internet, días de enfermedad
• Hay herramientas comerciales de estimación disponibles– Típicamente necesitan una configuración
basada en datos previos o históricos
Principios De Project Management, 2006
91
Otras Notas de Estimación
• Recordar: “manejar las expectativas”
• Ley de Parkinson– “El trabajo se amplía para llenar el tiempo
disponible”
• El síndrome del estudiante– Dilación del trabajo hasta el último momento
(abarrotar el tiempo)
Principios De Project Management, 2006
92
Project Management
Scheduling / Programación / Cronogramar
Principios De Project Management, 2006
93
Gestión del Tiempo
Principios De Project Management, 2006
94
Las Fases de los Procesos Iniciales
• Planificación Inicial: • El Porqué
– SOW (Enunciado del Trabajo), Cartas
• El Qué/Cómo (parcial/1st paso)– WBS (Estructura de Desglose del Trabajo)– Otros documentos de planificación
» Plan de Desarrollo, Gestión del Riesgo.
• El estimar• Tamaño (cantidad/complejidad) y Esfuerzo (duración)• Iterar
• El cronogramar o programar• Comienza junto con las primeras estimaciones • Iterar
Principios De Project Management, 2006
95
Programar
• Una vez que se saben las tareas (del WBS) y el tamaño/esfuerzo (de la estimación): entonces se programa
• Objetivos primarios• El mejor tiempo• Menor costo• Menor riesgo
• Objetivos secundarios• Evaluación de las alternativas de cronograma• Uso eficaz de recursos• Buenas comunicaciones
Principios De Project Management, 2006
96
Terminología
• Precedencia: • Una tarea que debe ocurrir antes de que otra se dice
que tiene precedencia de la otra
• Concurrencia:• Las tareas concurrentes son las que pueden ocurrir
al mismo tiempo (en paralelo)
• Adelanto y demora• Retraso entre las actividades
• Tiempo requerido antes o después de una tarea dada
Principios De Project Management, 2006
97
Terminología
• Milestones o hitos– Tienen una duración de cero– Identificar los puntos críticos en el cronograma– De uso frecuente en los tiempos de “revisión” o
de “entrega”
Principios De Project Management, 2006
98
Técnicas del Cronograma
– Análisis matemático• Diagramas de Red
– PERT
– CPM
– Cartas• Carta de Hitos
• Carta Gantt
Principios De Project Management, 2006
99
Diagramas de Red
• Desarrollado en los 1950’s
• Una representación gráfica de las tareas necesarias para terminar un proyecto
• Visualiza el flujo de tareas y de relaciones
Principios De Project Management, 2006
100
Análisis matemático
• PERT– Program Evaluation and Review Technique
• CPM– Critical Path Method
• A veces confundidos
• Todos son modelos usando diagramas de red
Principios De Project Management, 2006
101
Ejemplo MS Project
Principios De Project Management, 2006
102
Critical Path
• “El sistema específico de las tareas secuenciales de las cuales la fecha de la terminación del proyecto depende ”– o “la trayectoria completa más larga ”
• Todos los proyectos tienen un camino crítico
• Acelerar las tareas no críticas no acortan directamente el cronograma
Principios De Project Management, 2006
103
Ejemplo Critical Path
Principios De Project Management, 2006
104
CPM
• Critical Path Method– El proceso para determinar y optimizar el
camino crítico
• Las tareas No-CP pueden comenzar antes o tarde sin afectar la fecha de término
• Note: El camino crítico puede cambiar a otro mientras se acorte la corriente
• Debe ser hecho en conjunto por el equipo de trabajo y por el gerente funcional
Principios De Project Management, 2006
105
4 Tipos de dependencia de tareas
• Dependencia Mandatoria• La naturaleza del trabajo dicta una orden
• Dependencia Discrecional• Determinado por el equipo de la gerencia de
proyecto
• Proceso guiado
Principios De Project Management, 2006
106
4 Tipos de dependencia de tareas
• Dependencia Externa• Dependiente por factores externos al proyecto
mismo
• Dependencia de Recursos• Dos tareas dependen del mismo recurso
Principios De Project Management, 2006
107
Relaciones de dependencia de las tareas
• Finish-to-Start (FS)– B no puede empezar hasta que A termine– A: construir reja; B: pintar reja
• Start-to-Start (SS)– B no puede empezar hasta que A empieza
• Finish-to-Finish (FF)– B no puede terminar hasta que A termine– A: instalar cables; B: inspección eléctrica
• Start-to-Finish (SF)– B no puede terminar hasta que A empieza (raro)
Principios De Project Management, 2006
108
Diagramas de Red
• Ventajas– Muestra bien las precedencias– Revela interdependencias que no se muestran en otras
técnicas– Permite calcular el camino crítico– Permite hacer ejercicios tipo “que pasa si”
• Desventajas– El modelo por defecto asume que los recursos son
ilimitados • Se necesitas incorporar esto a mano (la dependencia de
recurso) al determinar la trayectoria crítica “verdadera” – Difícil de seguir en proyectos grandes
Principios De Project Management, 2006
109
PERT
• Program Evaluation and Review Technique• Basado en la idea que las estimaciones son
inciertas – Por lo que usa rangos de duración– Y la probabilidad de caer en un rango dado
• Usa un “valor eesperado” (o peso promedio) para determinar las duraciones
• Utilizar los métodos siguientes para calcular las duraciones previstas, después utilizarlos como entrada a tu diagrama de la red
Principios De Project Management, 2006
110
PERT
• Empieza con 3 estimaciones– Optimista
• Ocurriría probablemente 1 vez en 20
– Más probable• Valor modelo de la distribución
– Pesimista• Podría exceder la probabilidad de 1 vez en 20
Principios De Project Management, 2006
111
Fórmula PERT
• Combinado para estimar una duración de la tarea
Principios De Project Management, 2006
112
Fórmula PERT
• El intervalo de confianza puede ser determinado • Basado en una desviación estándar del tiempo
previsto • Usa una curva “campana” (distribución normal)
• Para el uso del camino crítico completo
Principios De Project Management, 2006
113
Ejemplo PERT
• El intervalo de confianza de P2 es 4 veces más ancho que para P1 para una probabilidad dada
• Ej: 68% de probabilidad de 9.7 a 11.7 días (P1) vs. 9.5-13.5 días (P2)
Descripción Planificador 1 Planificador 2
m 10d 10d
a 9d 9d
b 12d 20d
Tiempo PERT 10.16d 11.5d
Std. Dev. 0.5d 1.8d
Principios De Project Management, 2006
114
PERT
• Ventajas– Una cuenta para la incertidumbre
• Desventajas– Intensivo en tiempo y labor
– El supuesto de recursos ilimitados es un gran problema
– Carece de la propiedad funcional de estimar
– Utilizado sobre todo en proyectos grandes y complejos
• Conseguir el software PERT para que lo calcule por ti
Principios De Project Management, 2006
115
CPM vs. PERT
• Ambos utilizan diagramas de red
• CPM: determinístico
• PERT: probabilístico
• CPM: una estimación, PERT, tres estimaciones
• PERT es poco frecuente
Principios De Project Management, 2006
116
Carta de Hitos
• A veces llamado una “carta de barras”
• Carta Gantt simple
Principios De Project Management, 2006
117
Carta de Barras
Principios De Project Management, 2006
118
Carta Gantt
Principios De Project Management, 2006
119
Carta Gantt
• Desventajas– No muestra bien las interdependencias– No hay incertidumbre de una tarea dada (como lo hace
PERT)• Ventajas
– Entendido fácilmente – Creado y mantenido fácilmente
• Nota: El software ahora demuestra dependencias entre tareas en las cartas de Gantt – En “viejos” días las cartas de Gantt no mostraron estas
dependencias; cartas de barra típicamente no lo hacen
Principios De Project Management, 2006
120
Reducción de la duración del proyecto
• ¿Cómo se puede acortar el cronograma?
• Vía– Reduciendo alcance (o calidad)– Agregando recursos– Concurrencia (realizar las tareas en paralelo)– Sustitución de activitdades
Principios De Project Management, 2006
121
Técnicas de Compresión
• Acortar la duración total del proyecto• Crashing
• Mirar los tradeoffs entre costo y tiempo• La ganancia de compresión más grande con menor costo• Agregar recursos a las tareas del camino crítico• Limitar o reducir los requerimientos (alcance)• Cambiar la secuencia de las tareas
• Fast Tracking• Traslapo de las fases, de las actividades o de las tareas que
serían de otra manera secuenciales • Involucrar algún riesgo• Puede causar retrabajar
Principios De Project Management, 2006
122
Project Management
Riesgo
Principios De Project Management, 2006
123
Gestión del Riesgo
Principios De Project Management, 2006
124
Gestión del Riesgo
• Problemas que no han sucedido todavía
• Algunos son cuidadosos de tener relación con malas noticias– Nadie quiere ser el mensajero– O ser visto como un “preocupador”
• Se necesita definir una estrategia temprana en el proyecto
Principios De Project Management, 2006
125
Gestión del Riesgo
• Identificación, Análisis, Control
• Meta: evitar una crisis
• Gestión del riesgo. vs. Gestión de Proyectos– Para un específico vs. todos los otros proyectos– Proactivo vs. reactivo
Principios De Project Management, 2006
126
Riesgo del proyecto
• Caracterizado por:– Incertidumbre (0 < probabilidad < 1)– Una pérdida asociada (dinero, vida, reputación,
etc)– Manejable – alguna acción puede controlarlo
• Exposición al riesgo – Producto de probabilitdad y pérdida potencial
• Problema– Un riesgo que se ha materializado
Principios De Project Management, 2006
127
Tipos de Riesgo
• Riesgos del cronograma• Compresión del cronograma (cliente, marketing,
etc.)
• Riesgo de costos• Presupuesto no razonable
• Riesgos de los requisitos• Incorrecto• Incompleto• Poco claro o inconsistentes• Volátil
Principios De Project Management, 2006
128
Tipos de Riesgo
• Riesgos de la calidad
• Riesgos operationales
• “Errores Clásicos”– Son hechos a menudo
Principios De Project Management, 2006
129
Procesos de gestión del Riesgo
Risk Management
Risk Assesment
Risk Control
Risk Identification
Risk Analysis
Risk Prioritization
Risk Management Planning
Risk Resolution
Risk Monitoring
Principios De Project Management, 2006
130
Identificación de Riesgos
• Tratar de que el team se involucre en el proceso– No se hacen las cosas “solo”
• Producir una lista de riesgos con el potencial de interrumpir el cronograma del proyecto
• Usar un checklist o recurso similar para idear posibles riesgos
Principios De Project Management, 2006
131
Análisis de Riesgo
• Determinar el impacto de cada riesgo• Exposición al riesgo (Risk Exposure. RE)
• “Impacto del Riesgo”
• RE = Probabilidad de pérdida * tamaño de pérdida
• Ej: el riesgo es “Instalaciones no están listas a tiempo ”– Probabilidad es 25%, tamaño es 4 semanas, RE es 1 semana
• Estadísticamente son “valores esperados”
• La suma de todos los RE’s da el overrun esperado– El cual es pre-gestión del riesgo
Principios De Project Management, 2006
132
Priorización del Riesgo
• Regla 80-20
• A menudo buscar los riesgos con gran pérdida arriba– O items de alta probabilidad
• Posibilidad de grupo ‘riesgos relacionados’
• Ayuda a identificar los riesgos que se pueden ignorar
Principios De Project Management, 2006
133
Tipos de Desconocido
• Conocido desconocido– Información que sabes que alguien tiene
• Desconocido desconocido– Información que todavía no existe
Principios De Project Management, 2006
134
Control del Riesgo
• Plan de Gestión del Riesgo
Principios De Project Management, 2006
135
Resolución del Riesgo
– Eludir el riesgo• No hacer
• Relegar a otro grupo
– Suponer el riesgo• No hacer cualquier cosa sobre él
• Aceptar que puede ocurrir
• Estar pendiente del riesgo
Principios De Project Management, 2006
136
Resolución del Riesgo
– Control del problema• Desarrollar planes de contingencia
– Transferencia del riesgo• A otra parte del proyecto ( o del team)• Moverlo fuera del camino crítico
– Adquisición de conocimiento• Investigar
– Ej: hacer un prototipo
• Comprar información o experiencia acerca de él• Hacer investigación
Principios De Project Management, 2006
137
Monitoreo del Riesgo
• Lista de los Riesgos Top 10• Ranking
• Ranking anterior
• Semanas en la lista
• Nombre del riesgo
• Status de la resolución del riesgo
• Una buena práctica de bajos gastos
Principios De Project Management, 2006
138
Comunicación del Riesgo
• No estar asustado de comunicar los riesgos
• Usar el juicio para balancear– Que se venga el cielo abajo vs distribuir
información
Principios De Project Management, 2006
139
Gestión de RRHH
Principios De Project Management, 2006
140
Plan de gestión del Staff
• Incluye– Qué roles se necesitan, cuantos, cuando, quienes– Asignación de recursos– Timing: Fechas de Inicio/Parada– Objetivos de Costo/salario (si hay contratación)
• Directorio del Proyecto– Simplemente una lista de los involucrados con la info
de contacto
• Tamaño del team: A menudo dictado por el presupuesto como por otros factores
Principios De Project Management, 2006
141
Estructura del Team
• 1st: ¿Cuál es el objetivo del team?– Resolución de problemas
• Complejo, problemas poco definidos• Enfocados en 1-3 cuestiones específicas• Ej: Arreglar un defecto de transmisión WiMax• Sentido de la urgencia
– Creatividad• Desarrollo de nuevos productos
– Ejecución táctica• Plan bien definido de despliegue• Tareas bien enfocadas y roles específicos
Principios De Project Management, 2006
142
Modelos de Team
• Dos filosofías– Descentralizada/democrática– Centralizada/autocrática
• Variación– Controlada Descentralizada
Principios De Project Management, 2006
143
Modelos de Team
• Team de negocio– Modelo más común– Líder técnico + team (resto team a igual status)– Jerárquico con un contacto principal– Adaptable y general– Variación: Team Democrático
• Todas las decisiones hechas por todo el team
Principios De Project Management, 2006
144
Modelos de Team• Team con Jefe-programador
• de IBM en los 70’s • ‘team quirúrgico ’• Coloca una súper estrella en lo alto
– Otros se especializan alrededor de él/ella» Co-pilot or alter-ego» Administrador» Ejecutor» Mensajero
• Problemas» Difícil para documentar» Problemas de Ego: Superestrella y/o team
• Puede ser apropiado para proyectos creativos o de ejecución táctica
Principios De Project Management, 2006
145
Modelos de Team
• Team SWAT• Equipo altamente experto
• Las habilidades se emparejan firmemente con la meta
• Los miembros trabajan a menudo juntos
Principios De Project Management, 2006
146
Modelos de Team
• Grandes teams– La comunicación se incrementa
multiplicativamente• Al cuadrado del número de personas
• La comunicación debe ser formalizada
– Siempre usa una jerarquía– Reducir las unidades a los tamaños óptimos del
equipo• Siempre menos de 10, en promedio
Principios De Project Management, 2006
147
Tamaño del Team
• ¿Cuál es el tamaño óptimo del equipo? • Depende
• Líder técnico + cooperadores ( 4 – 6 personas)
• Los proyectos pequeños inspiran una identificación más fuerte
• Aumenta la cohesión
Principios De Project Management, 2006
148
Matriz de Asignación de Responsabilidades
• Una herramienta de planificación de recursos• Quien hace Que • Puede servir para planificación y para seguimiento• Identifica autoridad, responsabilidad, “cuentas a
pagar”• Quien: puede ser individual, team o un
departamento
Principios De Project Management, 2006
149
Gestión de las Comunicaciones
Principios De Project Management, 2006
150
Técnicas de Recolección de Requisitos
• Entrevistas• Análisis de Documentos • Brainstorming• Taller de requisitos• Hay más…
Principios De Project Management, 2006
151
Técnicas de entrevista
– Buena práctica: usar preguntas ‘libres de contexto’
• Una pregunta que no sugiere una respuesta
• Preguntas de alto nivel, tempranas para obtener características “globales” del problema y de la solución
• Aplicable a cualquier proyecto/producto
Principios De Project Management, 2006
152
Preguntas libre de Contexto
• Preguntas del proceso, del producto y de la meta
• Procesos– ¿“Quién es el cliente del proyecto X”?
– ¿“Cuál ies la razón para este proyecto”?
• Producto– ¿“Qué problemas puede solucionar este sistema”?
– ¿“Qué problemas puede crear este sistema”?
• Meta– ¿“Son relevantes estas preguntas”?
– ¿“Hay alguien que pueda dar respuetas satisfactorias”?
– ¿“Hay alguien que quiera responderme”?
Principios De Project Management, 2006
153
Análisis de Documentos
• Repaso de los documentos existentes• Planes de negocio
• Estudios de mercado
• Contratos
• Statements of work (SOW)
• Guías existentes
• Análisis de sistemas y procedimientos existentes
Principios De Project Management, 2006
154
Brainstorming
• Generación y reducción de ideas• Típicamente a través de reuniones de grupo• Buenas prácticas de generación
• Minimizar la crítica y el debate– Editar los hechos al final de la reunión o después
• Ir por cantidad• Mutar o combinar ideas
• Buenas prácticas de reducción• Votación con un umbral (N votos/persona)• Mezclar ideas• Aplicación de criterios • Dar puntaje con una fórmula de pesos
Principios De Project Management, 2006
155
Talleres de requisitos
• Típicamente 1-5 días• ¿Quienes? Varios. Stakeholders, clientes, etc• Pros
– Bueno para concensuar la construcción del proyecto– Construir comité de participantes– Puede disminuir el costos de muchas reuniones– Proporciona estructura a la captura y análisis de procesos– Puede involucrar a clientes a través de los bordes de la
organización– Puede ayudar a identificar prioridades y cuestiones discutibles
Principios De Project Management, 2006
156
Otros tips de comunicación
• Reuniones– Tratarlos como una herramienta: diseñarlos
– Boy scout: “Estar Preparados”
– Lo más pequeña posible – pero no muy chicas
– Hacerlas fuertes• Publicar una agenda con anterioridad
• Publicar un sumario después
– Generar una lista de “cosas relacionadas”
– Pueden ser formal/informal, Programadas/ad-hoc
Principios De Project Management, 2006
157
Otros tips de comunicación
• Manejar expectativas– No olvidar preguntárselo a las personas
– Escuchar
– Tomar decisiones explícitamente o implícitamente
• Revisiones técnicas– Los requisitos pueden ser malo por ser: inadecuados o
poco claros• Cantidad y calidad
– Las revisiones ayudan con el último
Principios De Project Management, 2006
158
Control del Proyecto
• Esfuerzo en curso para mantener el proyecto sobre ruedas • 4 actividades primarias:
– 1. Planificación del funcionamiento• Un cronograma y control de procesos
– 2. Medida del status del trabajo hecho• Actual
– 3. Comparación con la línea base• Variaciones
– 4. Tomar acciones correctivas como sea necesario• Respuesta
• El prerrequisito de un buen control es un buen plan.
Principios De Project Management, 2006
159
Control del Proyecto
• “Control”• Poder, autoridad, dominación. No!• Guía de una línea de conducta para satisfacer un objetivo. Sí.
• Principios• El trabajo es controlado, no los trabajadores
– El control ayuda a los trabajadores a ser más efectivos y eficientes
• Control basado en el trabajo terminado– Usar entregables concretos
• Balance– Nivel apropiado entre demasiado y muy poco– Incluye:
» Micro-administración vs. negligencia» Mucho seguimiento vs muy poco
Principios De Project Management, 2006
160
Monitoreo del Progreso
• Las 3 preguntas clave para el Monitoreo del Progreso– ¿Cuál es el status actual?– Si existe una variación, ¿Cuál es la causa?– ¿Qué se ha hecho al respecto?
• Respuestas posibles• 1. Ignorar• 2. Tomar acciones correctivas• 3.Revisar el plan
Principios De Project Management, 2006
161
Monitoreo del Progreso
• Tasas de monitoreo– Diario, semanal, mensual– Si el problema ocurre – se hace un ajuste
• Puede que se tenga que monitorear las áreas problemáticas más de cerca
• Por algunos períodos de tiempo• Casi siempre hay más de un área bajo escrutinio
cercano
• Reporte de status– Parte del plan de gestión de comunicaciones
Principios De Project Management, 2006
162
Reporte de Status
• Desde el team al PM, desde PM a los interesados
• Formato típico para lo último – Sumario– Cumplimientos para este período (hecho)
• Tareas, hitos, etc
– Plan para el próximo período (a hacer)– Análisis del riesgo y repaso– Cuestiones y acciones
• Puntapié para las actualizaciones semanales– Notas de Email, para tener el briefing de las reuniones– Más frecuente durante las crisis
Principios De Project Management, 2006
163
Gestión de Costos
Principios De Project Management, 2006
164
Análisis de Valor GanadoEarned Value Analisys
Project Management
Principios De Project Management, 2006
165
Objetivos
• Necesidad del VG
• Por qué utilizar VG
• Componentes del VG
Principios De Project Management, 2006
166
Gerencia de Proyectos
• ¿Cuándo se va a terminar el proyecto?• ¿Cuánto dinero se ha gastado hasta el
momento?• ¿Cuánto va a costarnos finalmente el proyecto?
Principios De Project Management, 2006
167
¿Por qué surgen estas preguntas?
• 70% de los proyectos TIC– Tienen sobrecostos– Se atrasan
• 52% de los proyectos– Terminan un 189% sobre el presupuesto inicial
• Otros nunca terminan
Principios De Project Management, 2006
168
Estimación de % terminado
• % del presupuesto gastado
• % del trabajo realizado
• % del tiempo transcurrido
Subjetivo, incompleto, falsas conclusiones
Principios De Project Management, 2006
169
¿Qué es más importante?
• Saber si se está dentro del cronograma?
• Saber si se está dentro del presupuesto?
• Saber cuanto trabajo se ha realizado?
EV integra las tres preguntas!!!
Principios De Project Management, 2006
170
Valor Ganado, Earned Value
• El EV es conocido por los gerentes de proyecto sólo al preparar PMP
• Es la simplificación de acrónimos PMP:– BCWP EV– ACWP AC– BCWS PV
Principios De Project Management, 2006
171
Valor Ganado, Earned Value
• Método basado en la comparación de los costos reales del proyecto contra los costos planeados.
• El concepto de VG viene de la idea que cada entregable de un proyecto tiene un costo planeado, su “valor”. Cuando el entregable se termina el “Valor” se “Gana” para el proyecto.
Principios De Project Management, 2006
172
Valor Ganado, Earned Value
• Esta comparación (costos) es común. El paso que se agrega es “comparar el costo real contra el costo planeado del trabajo terminado”.
• Este paso hace que VG sea poderoso y objetivo.
Principios De Project Management, 2006
173
¿Cómo se logra esto?
• Al hacer el Work Breakdown Structure (WBS) se hace una aproximación intuitiva de cómo planear y desplegar un proyecto.
• WBS es una carta que despliega la estructura de un proyecto mostrando como éste es organizado dentro de fases y niveles de detalle.
• Se divide el trabajo en tareas suficientemente pequeñas para evitar el problema de estimar un porcentaje de terminación.
Principios De Project Management, 2006
174
Ejemplo WBS
• Cada tarea individual no gana valor sino hasta que se haya terminado.
Principios De Project Management, 2006
175
Lo que más importa es...
• ...saber de verdad “Como van los proyectos”.
• Así se identifican los problemas lo más pronto posible para tomar acciones correctivas rápidas y efectivas.
Principios De Project Management, 2006
176
El interés radica en...
• La utilidad básica del VG es administrar los riesgos de los costos asociados a los proyectos.
• Entre más rápido se de cuenta que tiene un problema, más posibilidades hay para actuar y mitigarlo.
Principios De Project Management, 2006
177
¿Por qué el VG es un valor objetivo?
• Por que es una medida objetiva de cuánto trabajo se ha realizado con base en el Valor Planeado.
• O sea, lo que se obtuvo por lo que se gastó!
Principios De Project Management, 2006
178
Conceptos
• El método de VG requiere algunas prácticas claves para su éxito:– Identificar cada entregable del proyecto.– Desarrollar un cronograma para la terminación
de cada entregable.– Asignar un valor a cada entregable.
Principios De Project Management, 2006
179
Datos, para la toma de Decisiones
• Atraso en el cronograma– ¿Qué tan crítico es el cronograma?– ¿Puede permitirse trabajar tiempo extra para
recuperarse?– ¿Existe alguna innovación tecnológica que pueda
acelerar los procesos?
• Exceso de costos– ¿Puedo reprogramar alguna tarea?– ¿Hay alguna tarea que se pueda eliminar?
Principios De Project Management, 2006
180
Definiciones
• PV - BCWS: Costo Presupuestado del Trabajo Programado– Costo planeado de la cantidad total de
trabajo programado a ser realizado para una fecha propuesta.
Principios De Project Management, 2006
181
Definiciones
• AC - ACWP: Costo real del Trabajo Realizado– Costo incurrido para llevar a cabo el
trabajo que se ha realizado hasta la fecha.
Principios De Project Management, 2006
182
Definiciones
• EV – BCWP: Costo presupuestado del Trabajo Realizado– El costo planeado (no real) para
completar el trabajo que se ha realizado.
– Es un porcentaje del presupuesto total igual al porcentaje del trabajo realmente terminado.
Principios De Project Management, 2006
183
Otros conceptos de VG
• BAC – Presupuesto a la Terminación– Es la suma de todos los presupuestos
asignados a un proyecto.
• Fecha de Estado o Fecha a Hoy– Es el punto en el tiempo utilizado para el
análisis.
Principios De Project Management, 2006
184
Métricas Derivadas
• SV: Variación de Programación (EV – PV)– Es una comparación entre la cantidad de trabajo
realizado durante un período de tiempo dado y lo que se había programado para ser ejecutado.
– Una variación negativa significa que el proyecto está atrasado en el cronograma.
• CV: Variación de Costos (EV – AC)– Es una comparación entre el costo presupuestado del
trabajo realizado y el costo real.– Una variación negativa significa que el proyecto está
atrasado en el cronograma.
Principios De Project Management, 2006
185
Métricas de Desempeño y Análisis de índices
• SPI: Índice de desempeño de programación– .
– Muestra el valor del trabajo realizado comparado con lo que se había planeado.
– =1 : proyecto a tiempo
– >1 : proyecto adelantado respecto del cronograma
– <1 : proyecto retrasado respecto del cronograma
PV
EVSPI
Principios De Project Management, 2006
186
Métricas de Desempeño y Análisis de índices
• CPI: Índice de desempeño de costos– .
– Muestra cuantas unidades de dinero de trabajo se obtuvieron para la cantidad de unidades de dinero gastadas en el trabajo.
– =1 : proyecto dentro del presupuesto– >1 : proyecto está debajo del presupuesto– <1 : proyecto está encima del presupuesto
AC
EVCPI
Principios De Project Management, 2006
187
Métricas de Desempeño y Análisis de índices
• CSI: Índice Costo - Programación– .
– Entre más se aleje CSI de 1,0, menor es la posibilidad de que el proyecto se recupere.
– 0,9 < CSI < 1,2 : OK– 0,8 < CSI < 0,9 o 1,1 < CSI < 1,3 : Chequear– CSI < 0,8 o CSI >1,3 : Alerta Roja
SPICPICSI
Principios De Project Management, 2006
188
Implementación
• El proceso del VG:
Principios De Project Management, 2006
189
Cómo se establece un sistema de VG
...la receta1. Definir el WBS para dividir el proyecto en
porciones manejables.2. Identificar las actividades a programar que
representen todo el proyecto.3. Asignar el costo a ser gastado en cada
actividad.4. Programar las actividades en el tiempo.5. Crear la línea base y confirmar que el plan es
aceptable.
Principios De Project Management, 2006
190
Cómo usar un sistema de VG
1. Actualizar el cronograma reportando el progreso de las actividades.
2. Ingresar el costo real de las actividades.
3. Hacer los cálculos de VG e imprimir los reportes y gráficas.
4. Analizar los datos y escribir el reporte de desempeño.
Principios De Project Management, 2006
191
Monitoreo
• Análisis de resultados– Análisis de variaciones: Muestra como va
progresando el proyecto y las tendencias ya que tiene en cuenta el tiempo y costos consumidos comparados con los planeados.
– Análisis de índices: Muestra qué tan eficientemente está operando el proyecto.
Principios De Project Management, 2006
192
Seguimiento al VG
• Proyecto– El VG se establece inicialmente a nivel de
proyecto (nivel más alto de WBS) y luego se hereda al resto de los nodos.
• WBS– Los métodos de cálculo del VG pueden
cambiar para cada parte del WBS en cada nivel.
Principios De Project Management, 2006
193
Medición del trabajo realizado
• Método 50/50– 50% del paquete de trabajo se “gana”
cuando el trabajo comienza, y el 50% restante cuando se termina el paquete.
• Método 0/100– 0% del paquete de trabajo se “gana” cuando
el trabajo comienza, y el 100% restante cuando se termina el paquete.
Principios De Project Management, 2006
194
Project Management
Integración y Calidad
Principios De Project Management, 2006
195
Calidad
Principios De Project Management, 2006
196
Integración y Pruebas
• Integración/Pruebas• Momento común para traslapes de cronograma y
actividades
• A veces la Integración/Pruebas se piensan como una sola fase
• Progresivamente se agrega funcionalidad• El team de Aseguramiento de la Calidad
(QA) trabaja en paralelo con el equipo de diseño
Principios De Project Management, 2006
197
Integración
• Top Down• El sistema Core se implementa primero
• Luego se combinan los sistemas menores, como en “cáscara”
• “Trozos” se usan para arreglar secciones incompletas– Eventualmente reemplzaría algunos de los módulos actuales
• Bottom Up• Empieza con módulos individuales
• Las unidades individuales (después de las pruebas individuales) se combinan en sub sistemas
• Los subsistemas se combinan luego en el todo
Principios De Project Management, 2006
198
Validación y Verificación
• V & V
• Validación– ¿Se está construyendo lo solicitado?
• Verificación– ¿Se está construyendo lo solicitado de buena
forma?– Testing– Inspección
Principios De Project Management, 2006
199
Test Plans
• Quality Assurance Plan– Debe estar completo cerca de los
requerimientos
Principios De Project Management, 2006
200
Test Plans
• Estándar de la organización– Propósito– Documentos de referencia– Gestión– Documentación– Standards, prácticas, convenciones, métrica
• Medidas de calidad
• Prácticas de testing
Principios De Project Management, 2006
201
Flujo de Testing del proyecto
• Testeo de unidades
• Testeo de Integración
• Testeo del sistema
• Testeo de aceptación del cliente
Principios De Project Management, 2006
202
Testing de Integración
• Testing de interfaces entre componentes
• Primer paso después del Testeo de Unidades
• Los componentes pueden funcionar bien solos, pero pueden fallar cuando se juntan
• Los defectos pueden existir en un módulo, pero se pueden manifestar en otro
Principios De Project Management, 2006
203
Testeo del Sistema
• Testing del sistema completo
Principios De Project Management, 2006
204
Testeo de aceptación del cliente
• El último hito en la fase de pruebas• Prueba del cliente última para su aprobación• A veces sinónimo de beta tests• El cliente está satisfecho cuando el proyecto
(sistema completo) cumpla sus requerimientos• De acuerdo con “criterios de la aceptación”
– Idealmente definidos antes de que el contrato sea firmado
– Usar condiciones cuantificables y medibles
Principios De Project Management, 2006
205
Hitos del Testing Externo
• Alpha 1st, Beta 2nd
• Durante las últimas fases de pruebas
Principios De Project Management, 2006
206
Hitos del Testing Externo
• Valor del Beta Testing• Testing en el mundo real• Marketing
• No determinar características basadas en él• Muy tarde!
• Beta testers deben ser “reclutados”• Requiere el rol de un “Beta Manager”• Todo esto debe ser programado por el PM
Principios De Project Management, 2006
207
Parando el Testing
• ¿Cuando hay que parar?• Raramente están los defectos “arreglados” en el
lanzamiento• Ir por todos los defectos Críticos/Altos/Medios• A menudo, ocurre cuando el tiempo se acaba• Firma final
• Por: clientes,ingenieros, gerente proyecto, gerente producto, etc
Principios De Project Management, 2006
208
Roles de QA
• QA Manager• Contrata el QA team; crea los test plans; selecciona
herramientas; gerencia el team• Salario EEUU: $50-80K/año, $50-100/hr
• Ingeniero de Pruebas• Realiza los tests funcionales• Salario EEUU: $35-70K/año, $40-100/hr
• Administrador de Sistema• Mantiene las funciones de QA, pero no es miembro oficial del
QA team
• Documentador (escritor)
Principios De Project Management, 2006
209
Calidad
Principios De Project Management, 2006
210
Metodología PMI