2: 9 Áreas del Conocimiento Procesos de un Proyecto

2: 9 Áreas del Conocimiento Procesos de un Proyecto
Project Management 2: 9 Áreas del Conocimiento Procesos de un Proyecto Principios De Project Management, 2006

Gestión de las Adquisiciones
Principios De Project Management, 2006

Gestión de las Adquisiciones
Procurement significa adquirir bienes y/o servicios desde una fuente externa “compras u outsourcing” Principios De Project Management, 2006

Principios De Project Management, 2006
¿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

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

Gestión de Adquisiciones del Proyecto: Procesos y Salidas

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

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

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

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

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

Tipos de contrato contra riesgo

Enunciado del Trabajo Statement 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

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

Plantilla SOW Principios De Project Management, 2006

Planificación Principios De Project Management, 2006

Gestión del Alcance Principios De Project Management, 2006

Gestión del Alcance Planificación del Alcance Principios De Project Management, 2006

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Planificación “Los planes no son nada. Pero la planificación es todo .” Gen. Dwight Eisenhower Principios De Project Management, 2006

Planificación Comienzo preliminar del planeamiento en el día uno No debe ser conducido “en secreto” Principios De Project Management, 2006

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

Documentos Planificación Producto o servicio Principios De Project Management, 2006

Planificación Alcance Estimación Riesgo Cronograma Controlar la estrategia Principios De Project Management, 2006

Plan de Proyecto Principios De Project Management, 2006

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

WBS, Estimación & Cronograma
Project Management WBS, Estimación & Cronograma Principios De Project Management, 2006

Estimación “Las predicciones son duras, especialmente sobre el futuro”, Yogi Berra 2 tipos: ¿Afortunado o pésimo? Principios De Project Management, 2006

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

Planificación del proyecto: Un programa de 12 pasos
Fijar la meta y el alcance Seleccionar el ciclo de vida Fijar la forma del org./team Comenzar la selección del team/equipo Determinar los riesgos Crear la WBS Identificar las tareas Estimar el tamaño Estimar el esfuerzo Identificar dependencias de las tareas Asignar recursos Calendarizar el trabajo Principios De Project Management, 2006

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

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

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

Elementos de un Proyecto
Un Proyecto es: funciones, actividades, tareas Principios De Project Management, 2006

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

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

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

Ejemplo de carta WBS Principios De Project Management, 2006

Ejemplo WBS de contorno
0.0 Sitio Web de Retail 1.0 Project Management 2.0 Requisitos 3.0 Análisis y Diseño 4.0 Desarrollo del software del sitio 4.1 Diseño y Creación HTML 4.2 Software 4.2.1 Implementación de Base de Datos 4.2.2 Desarrollo de Middleware 4.2.3 Subsistemas de Seguridad 4.2.4 Engine del catálogo 4.2.5 Procesamiento de transacciones 4.3 Gráficas e Interface 4.4 Creación de Contenido 5.0 Pruebas y Producción Principios De Project Management, 2006

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

WBS de Producto Principios De Project Management, 2006

WBS de Procesos Principios De Project Management, 2006

WBS de contorno con Gantt

WBS de los Grupos de Procesos PMI

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

Formas de Presentación
Vista Camino Crítico Vista Progreso Principios De Project Management, 2006

Formas de Presentación
Vistas Horas y Costos Vista Planificación Principios De Project Management, 2006

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

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

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

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

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

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

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

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

WBS – Base de Muchas Cosas
Calendariazción de la Red Costos Análisis de Riesgo Estructura Organizacional Control Medidas Principios De Project Management, 2006

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

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

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ásicos Estimar el tamaño del producto Estimar el esfuerzo (horas-hombre) Estimar la Cronograma NOTA: No todos estos pasos se realizan siempre explícitamente Principios De Project Management, 2006

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

Cono de la Incertidumbre

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

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

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

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

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

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

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

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

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

“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

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

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

Scheduling / Programación / Cronogramar
Project Management Scheduling / Programación / Cronogramar Principios De Project Management, 2006

Gestión del Tiempo Principios De Project Management, 2006

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 Principios De Project Management, 2006

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

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

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

Técnicas del Cronograma
Análisis matemático Diagramas de Red PERT CPM Cartas Carta de Hitos Carta Gantt Principios De Project Management, 2006

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

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

Ejemplo MS Project Principios De Project Management, 2006

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

Ejemplo Critical Path Principios De Project Management, 2006

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

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

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

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

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

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

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

Fórmula PERT Combinado para estimar una duración de la tarea Principios De Project Management, 2006

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

Ejemplo PERT Descripción Planificador 1 Planificador 2 m 10d a 9d b 12d 20d Tiempo PERT 10.16d 11.5d Std. Dev. 0.5d 1.8d 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 días (P2) Principios De Project Management, 2006

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

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

Carta de Hitos A veces llamado una “carta de barras” Carta Gantt simple Principios De Project Management, 2006

Carta de Barras Principios De Project Management, 2006

Carta Gantt Principios De Project Management, 2006

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

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

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

Riesgo Principios De Project Management, 2006

Gestión del Riesgo Principios De Project Management, 2006

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

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

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

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

Tipos de Riesgo Riesgos de la calidad Riesgos operationales “Errores Clásicos” Son hechos a menudo Principios De Project Management, 2006

Procesos de gestión del Riesgo

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

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

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

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

Control del Riesgo Plan de Gestión del Riesgo Principios De Project Management, 2006

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

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

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

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

Gestión de RRHH Principios De Project Management, 2006

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

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

Modelos de Team Dos filosofías Descentralizada/democrática Centralizada/autocrática Variación Controlada Descentralizada Principios De Project Management, 2006

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

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

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

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

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

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

Gestión de las Comunicaciones

Técnicas de Recolección de Requisitos
Entrevistas Análisis de Documentos Brainstorming Taller de requisitos Hay más… Principios De Project Management, 2006

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

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

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

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

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

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

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

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

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

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

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

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 , para tener el briefing de las reuniones Más frecuente durante las crisis Principios De Project Management, 2006

Gestión de Costos Principios De Project Management, 2006

Análisis de Valor Ganado Earned Value Analisys
Project Management Análisis de Valor Ganado Earned Value Analisys Principios De Project Management, 2006

Objetivos Necesidad del VG Por qué utilizar VG Componentes del VG Principios De Project Management, 2006

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

¿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

Estimación de % terminado
% del presupuesto gastado % del trabajo realizado % del tiempo transcurrido Subjetivo, incompleto, falsas conclusiones Principios De Project Management, 2006

¿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

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

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

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

¿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

Ejemplo WBS Cada tarea individual no gana valor sino hasta que se haya terminado. Principios De Project Management, 2006

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

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

¿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

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

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

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

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

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

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

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. Principios De Project Management, 2006

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 Principios De Project Management, 2006

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 Principios De Project Management, 2006

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 Principios De Project Management, 2006

Implementación El proceso del VG: Principios De Project Management, 2006

Cómo se establece un sistema de VG ...la receta
Definir el WBS para dividir el proyecto en porciones manejables. Identificar las actividades a programar que representen todo el proyecto. Asignar el costo a ser gastado en cada actividad. Programar las actividades en el tiempo. Crear la línea base y confirmar que el plan es aceptable. Principios De Project Management, 2006

Cómo usar un sistema de VG
Actualizar el cronograma reportando el progreso de las actividades. Ingresar el costo real de las actividades. Hacer los cálculos de VG e imprimir los reportes y gráficas. Analizar los datos y escribir el reporte de desempeño. Principios De Project Management, 2006

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

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

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

Integración y Calidad Principios De Project Management, 2006

Calidad Principios De Project Management, 2006

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

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

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

Test Plans Quality Assurance Plan Debe estar completo cerca de los requerimientos Principios De Project Management, 2006

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

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

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

Testeo del Sistema Testing del sistema completo Principios De Project Management, 2006

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

Hitos del Testing Externo
Alpha 1st, Beta 2nd Durante las últimas fases de pruebas Principios De Project Management, 2006

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

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

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

Calidad Principios De Project Management, 2006

Metodología PMI Principios De Project Management, 2006

2: 9 Áreas del Conocimiento Procesos de un Proyecto

Presentaciones similares

Presentación del tema: "2: 9 Áreas del Conocimiento Procesos de un Proyecto"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

2: 9 Áreas del Conocimiento Procesos de un Proyecto

Presentaciones similares

Presentación del tema: "2: 9 Áreas del Conocimiento Procesos de un Proyecto"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback