principios de project management, 2006 1 project management 2: 9 Áreas del conocimiento procesos de...

Principios De Project Management, 2006

1

Project Management

2: 9 Áreas del Conocimiento

Procesos de un Proyecto


2

Gestión de las Adquisiciones


3

Gestión de las Adquisiciones

• Procurement significa adquirir bienes y/o servicios desde una fuente externa– “compras u outsourcing”


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


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


6

Gestión de Adquisiciones del Proyecto: Procesos y Salidas


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


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?


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


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


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


12

Tipos de contrato contra riesgo


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


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


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.


16

Project Management

Planificación


17

Gestión del Alcance


18

Gestión del Alcance

• Planificación del Alcance


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)


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


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


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


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.


24

Requisitos

• Tal vez la fase más importante y difícil

• El error clásico es hacer “cambios de última hora”


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


26

Requisitos

• Los requisitos son las capacidades y condiciones a las cuales el sistema – y más ampliamente, el proyecto – debe adecuarse.


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


28

Reuniones iniciales

• Reunión de lanzamiento del proyecto

• Reunión Brainstorming del proyecto– Clarificar metas, alcance, supuestos– Refinar estimaciones

• Reunión WBS


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)


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


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


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


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


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


35


• 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


36


• 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


37


• 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


38

Planificación

• “Los planes no son nada. Pero la planificación es todo .” Gen. Dwight Eisenhower


39

Planificación

• Comienzo preliminar del planeamiento en el día uno

• No debe ser conducido “en secreto”


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


41

Documentos

• Planificación

• Producto o servicio


42

Planificación

• Alcance

• Estimación

• Riesgo

• Cronograma

• Controlar la estrategia


43

Plan de Proyecto


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


45

Project Management

WBS, Estimación & Cronograma


46

Estimación

• “Las predicciones son duras, especialmente sobre el futuro”, Yogi Berra

• 2 tipos: ¿Afortunado o pésimo?


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.


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


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


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?


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?


52

Elementos de un Proyecto• Un Proyecto es: funciones, actividades, tareas


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


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


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


56

Ejemplo de carta WBS


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


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


59

WBS de Producto


60

WBS de Procesos


61

WBS de contorno con Gantt


62

WBS de los Grupos de Procesos PMI


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


64

Formas de Presentación

• Vista Camino Crítico

• Vista Progreso


65

Formas de Presentación

• Vistas Horas y Costos

• Vista Planificación


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


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


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


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


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


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


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


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


74

WBS – Base de Muchas Cosas

• Calendariazción de la Red

• Costos

• Análisis de Riesgo

• Estructura Organizacional

• Control

• Medidas


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.


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


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


78


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


79

Cono de la Incertidumbre


80


• 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


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


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


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


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


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


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


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


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


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.


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


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)


92

Project Management

Scheduling / Programación / Cronogramar


93

Gestión del Tiempo


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


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


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


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”


98

Técnicas del Cronograma

– Análisis matemático• Diagramas de Red

– PERT

– CPM

– Cartas• Carta de Hitos

• Carta Gantt


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


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


101

Ejemplo MS Project


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


103

Ejemplo Critical Path


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


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


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


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)


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


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


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


111

Fórmula PERT

• Combinado para estimar una duración de la tarea


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


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


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


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


116

Carta de Hitos

• A veces llamado una “carta de barras”

• Carta Gantt simple


117

Carta de Barras


118

Carta Gantt


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


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


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


122

Project Management

Riesgo


123

Gestión del Riesgo


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


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


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


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


128

Tipos de Riesgo

• Riesgos de la calidad

• Riesgos operationales

• “Errores Clásicos”– Son hechos a menudo


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


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

http://www.construx.com/doc/chk30.htm

http://www.construx.com/doc/chk30.htm


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


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


133

Tipos de Desconocido

• Conocido desconocido– Información que sabes que alguien tiene

• Desconocido desconocido– Información que todavía no existe


134

Control del Riesgo

• Plan de Gestión del Riesgo


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


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


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


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


139

Gestión de RRHH


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


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


142

Modelos de Team

• Dos filosofías– Descentralizada/democrática– Centralizada/autocrática

• Variación– Controlada Descentralizada


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


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


145

Modelos de Team

• Team SWAT• Equipo altamente experto

• Las habilidades se emparejan firmemente con la meta

• Los miembros trabajan a menudo juntos


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


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


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


149

Gestión de las Comunicaciones


150

Técnicas de Recolección de Requisitos

• Entrevistas• Análisis de Documentos • Brainstorming• Taller de requisitos• Hay más…


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


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


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


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


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


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


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


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.


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


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


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


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


163

Gestión de Costos


164

Análisis de Valor GanadoEarned Value Analisys

Project Management


165

Objetivos

• Necesidad del VG

• Por qué utilizar VG

• Componentes del VG


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?


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


168

Estimación de % terminado

• % del presupuesto gastado

• % del trabajo realizado

• % del tiempo transcurrido

Subjetivo, incompleto, falsas conclusiones


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


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


171


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


172


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


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.


174

Ejemplo WBS

• Cada tarea individual no gana valor sino hasta que se haya terminado.


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.


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.


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


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.


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?


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.


181

Definiciones

• AC - ACWP: Costo real del Trabajo Realizado– Costo incurrido para llevar a cabo el

trabajo que se ha realizado hasta la fecha.


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.


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.


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.


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


186


• 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


187


• 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


188

Implementación

• El proceso del VG:


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.


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.


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.


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.


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.


194

Project Management

Integración y Calidad


195

Calidad


196


• 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


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


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


199

Test Plans

• Quality Assurance Plan– Debe estar completo cerca de los

requerimientos


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


201

Flujo de Testing del proyecto

• Testeo de unidades

• Testeo de Integración

• Testeo del sistema

• Testeo de aceptación del cliente


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


203

Testeo del Sistema

• Testing del sistema completo


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


205

Hitos del Testing Externo

• Alpha 1st, Beta 2nd

• Durante las últimas fases de pruebas


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


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


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)


209

Calidad


210

Metodología PMI

principios de project management, 2006 1 project management 2: 9 Áreas del conocimiento procesos de...

Documents