2. inicio de un proyecto. contenido 1.procesos de dirección de proyectos 2.la gestión de la...

2.

Inicio de un Proyecto

Contenido

1. Procesos de dirección de proyectos

2. La gestión de la integración de proyectos

3. El Alcance del proyecto

Ing. Raúl Alvarado Rodríguez

2

Procesos de Dirección de Proyectos

• La dirección de proyectos es la aplicación de conocimientos,

habilidades, herramientas y técnicas a las actividades del proyecto

para satisfacer los requisitos del mismo. La dirección de proyectos se

logra mediante la ejecución de procesos, usando conocimientos,

habilidades, herramientas y técnicas de dirección de proyectos que

reciben entradas y generan salidas.


3


− Seleccionar los procesos apropiados dentro de los Grupos de

Procesos de la Dirección de Proyectos (también conocidos como

Grupos de Procesos) que sean necesarios para cumplir con los

objetivos del proyecto.

− Usar un enfoque definido para adaptar las especificaciones del

producto y los planes de tal forma que se puedan cumplir los

requisitos del proyecto y del producto.

− Cumplir con los requisitos para satisfacer las necesidades, deseos

y expectativas de los interesados

− Equilibrar las demandas concurrentes.


4

• Factores críticos de éxito:


• La dirección de proyectos es una tarea integradora. La integración

de la dirección de proyectos exige que cada proyecto y proceso de

productos esté correctamente alineado y conectado con los otros

procesos, a fin de facilitar su coordinación.


5

Procesos de dirección de proyectos

• Estos procesos se dividen en cinco grupos, definidos como los

Grupos de Procesos de la Dirección de Proyectos:

a. Grupo de Procesos de Iniciación

b. Grupo de Procesos de Planificación

c. Grupo de Procesos de Ejecución

d. Grupo de Procesos de Seguimiento y control

e. Grupo de Procesos de Cierre.


6


• Estos procesos se presentan como elementos discretos con

interfaces bien definidas. Sin embargo, en la práctica, se superponen

e interactúan. La mayoría de los practicantes con experiencia en

dirección de proyectos reconocen que hay más de una manera de

gestionar un proyecto.

• Un concepto subyacente a la interacción entre los procesos de

dirección de proyectos es el del ciclo planificar-hacer-revisar-actuar

(conforme a la definición de Shewhart, modificada por Deming):

Planificar

Actuar

Hacer

Revisar


7


• La naturaleza integradora de los Grupos de Procesos es más

compleja que el ciclo básico planificar-hacer-revisar-actuar.

• Sin embargo, el ciclo mejorado puede aplicarse a las interrelaciones

dentro de un mismo Grupo de Procesos y entre Grupos de Procesos:

“Planificación” corresponde al componente “planificar” del ciclo

planificar-hacer-revisar-actuar. “Ejecución” corresponde al

componente “hacer”, y “Seguimiento y Control” corresponde a los

componentes “revisar y actuar”.

Planificación

Ejecución

Iniciación

Cierre

Procesos deseguimiento y control


8

Grupos de procesos de dirección de proyectos

1. Grupo de Procesos de Iniciación.

Define y autoriza el proyecto o una fase del mismo.

2. Grupo de Procesos de Planificación.

Define y refina los objetivos, y planifica el curso de acción requerido

para lograr los objetivos y el alcance pretendido del proyecto.

3. Grupo de Procesos de Ejecución.

Integra a personas y otros recursos para llevar a cabo el plan de

gestión del proyecto para el proyecto.

4. Grupo de Procesos de Seguimiento y Control.

Mide y supervisa regularmente el avance, a fin de identificar las

variaciones respecto del plan de gestión del proyecto, de tal forma

que se tomen medidas correctivas cuando sea necesario para

cumplir con los objetivos del proyecto.


9

Grupos de procesos de dirección de proyectos

5. Grupo de Procesos de Cierre.

Formaliza la aceptación del producto, servicio o resultado, y

termina ordenadamente el proyecto o una fase del mismo.


10

Grupos de Procesos de Dirección de Proyectos


11

Grupos de Procesos de Dirección de Proyectos


12

Grupos de procesos de Iniciación

• Los procesos de iniciación, por lo general, se realizan fuera del

ámbito de control del proyecto por la organización o por los procesos

del programa o del portafolio, lo cual puede hacer borrosos los

límites del proyecto en lo que se refiere a entradas iniciales del

proyecto.

• Pe, antes de comenzar con las actividades del Grupo de Procesos de

Iniciación, se documentan las necesidades o requisitos de negocio de

la organización.

Planificación

Ejecución

Iniciación Cierre

Procesos deseguimiento y control

Entradasdel proyecto

Productosentregablesdel proyecto

Registro del proyecto

Usuariosfinales

Activos delos procesos

Iniciador/ Patrocinad

or del proyecto

Límites del proyecto


13


Grupos de procesos de Planificación

DesarrollarPlan de Gestión

del proyecto

Planificaralcance

Definiralcance

Crear EDTEstimar

recursos deactividades

Planificarriesgos

Estimarcostos

Identificarriesgos

PrepararPresupuesto

de costos

Análisis cualitativo de

riesgos

PlanificarRRHH

Análisis cuantitativo de

riesgos

PlanificarCalidad

Planificar compras y

adquisiciones

Planificarcomunicacione

s

Planificarrespuesta a

riesgos

Planificarcontratación

Definiractividades

Estimarduración de actividades

Desarrollarcronograma

Establecersecuencia

de actividades

G. P.Ejecució

n

G. P.Ejecució

n

G. P.Seg. y Con.

G. P.Iniciación


15

Grupos de procesos de Ejecución

G. P.INICIACIÓN

G. P.PLANIFICACIÓN

G. P. SEGUIMIENTO Y

CONTROL

G. P. de CIERRE

Distribuir informació

n

Seleccionar

vendedores

Dirigir y gestiona

r ejecució

n del proyecto

Asegurar

calidad

Adquirir equipo del proyecto

Desarrollar equipo

del proyecto

Solicitar respuesta

s de vendedore

s


16

Grupos de procesos de Seguimiento y control

Grupo de procesos de Ejecución

Grupo de procesos de

Cierre

Grupo de procesos de

Iniciación

Grupo de procesos de Planificación

Verificar alcance

Controlar alcance

Controlar cronogra

maControlar

costos

Controlar

calidadGestionar equipo del proyectoInformar

rendimiento

Gestionar a

interesadosSeguimiento y

control de riesgos

Administrar contrato

Supervisar y

controlar el trabajo

del proyecto

Control integrado

de cambios


17

Grupos de procesos de Cierre

Grupo de procesos de Seguimiento y

Control

Grupo de procesos de Planificación

Grupo de procesos de Ejecución

Cerrar proyecto

Cierre del contrato

Interacciones entre procesos

• Los Grupos de Procesos de Dirección de Proyectos están

relacionados por los resultados que producen. La salida de un

proceso, por lo general, se convierte en una entrada a otro proceso o

es un producto entregable del proyecto.


18

Triangulo de grupo de procesos de dirección de proyectos


19

• La Tabla siguiente refleja la correspondencia de los 44 procesos de

dirección de proyectos en los cinco Grupos de Procesos de Dirección

de Proyectos y las nueve Áreas de Conocimiento de la Dirección de

Proyectos.

• Cada uno de los procesos de dirección de proyectos requeridos se

muestra en el Grupo de Procesos en el cual se lleva a cabo la mayor

parte de la actividad. Por ejemplo, cuando un proceso que

normalmente se lleva a cabo durante la planificación se revisa o

actualiza durante la ejecución, sigue siendo el mismo proceso que se

realizó durante el proceso de planificación y no constituye un nuevo

proceso adicional.


20


Procesos de un área de conocimiento

4. Gestión de la integración del proyecto

5. Gestión del alcance del proyecto

6. Gestión del tiempo del proyecto

Grupo de procesos de dirección de proyectos

INICIACIÓN PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO CONTROL

CIERRE

• Desarrollar acta de constitución del proyecto

• Desarrollar enunciado de alcance de proyecto preliminar

• Desarrollar el Plan de Gestión del proyecto

• Dirigir y gestionar la ejecución del proyecto

• Supervisar y controlar el trabajo del proyecto

• Control integrado de cambios

• Cerrar proyecto

• Planificar alcance

• Definir alcance

• Crear EDT

• Verificar alcance

• Controlar alcance

• Definir actividades

• Establecer secuencia de act.

• Estimar recursos de actividades

• Estimar duración de act.

• Desarrollar cronograma

• Controlar cronograma


21


7. Gestión de los costos del proyecto

8. Gestión de la calidad del proyecto9. Gestión de los recursos humanos del proyecto

• Estimación de costos

• Preparación de costos

• Asegurar calidad

• Controlar costos

• Planificar calidad

• Controlar calidad

• Planificar recursos humanos

• Gestionar el equipo del proyecto

• Adquirir equipo del proyecto

• Desarrollar equipo del proyecto

10. Gestión de comunicaciones del proyecto

• Planificar las comunicaciones

• Informar el rendimiento

• Gestionar a los interesados

• Distribuir la información


22





CIERRE

11. Gestión de los riesgos del proyecto

12. Gestión de adquisiciones del proyecto

• Planificar la gestión de riesgos

• Identificar riesgos

• Análisis cualitativo de riesgos

• Análisis cuantitativo de riesgos

• Planificación de la respuesta a los riesgos

• Solicitar respuestas de vendedores

• Selección de vendedores

• Seguimiento y control de riesgos

• Planificar las compras y adquisiciones

• Planificar la contratación

• Administrar contrato

• Cerrar• contrato


23





CIERRE

La gestión de la integración de proyectos

• La Gestión de la Integración en Proyectos, está dedicada a describir

aquellos procesos dedicados a "Integrar", o "conectar" conceptos

que están relacionados con varias áreas de conocimientos. Por

ejemplo, el proceso Preparar el Plan de Gerencia del Proyecto, es un

proceso cuyo objetivo es recolectar los distintos planes de las

diversas áreas de conocimientos, en un plan coherente. Lo mismo

ocurre con los procesos: “Desarrollar el Acta de Constitución

(Charter) del proyecto” y “Desarrollar el Enunciado Preliminar del

Proyecto”.

• Una vez definidos los alcances y definido el plan del proyecto, se

deben ejecutar tres procesos claves: “Dirigir y Gestionar la Ejecución

del Proyecto”, que tiene como objetivos, tomar el plan del proyecto y

ejecutarlo, con el fin de generar los productos entregables del

proyecto. Ing. Raúl Alvarado

Rodríguez24

• “Monitorear y controlar el trabajo del proyecto”, que tiene como

objetivo determinar si es que el proceso de dirigir y gestionar está

siendo ejecutado de acuerdo a lo previsto, y detectar desviaciones.

Al momento de detectar cualquier tipo de diferencia con respecto a

lo planificado, este proceso "recomienda" o "propone" tres tipos de

acciones: cambios, acciones preventivas, y acciones correctivas.

Dichas propuestas son "procesadas" por el siguiente proceso:

“Control Integrado de los Cambios”.

• El Control Integrado de los Cambios, recibe los pedidos o solicitudes

de: cambios, acciones correctivas, o acciones preventivas de todos

los procesos del proyecto. Es una especie de "cerebro" que recibe las

sugerencias generadas en distintos procesos de control, y decide si

es que dichos pedidos o sugerencias deben aprobarse o no. En el

caso de ser aprobados, dicha información se comunica al proceso de

Dirigir y Gestionar la Ejecución del Proyecto, y también al proceso de

Monitorear y Controlar el Trabajo del Proyecto.

Introducción a la administración de proyectos


25

El contenido del plan de gestión del proyecto

1. Justificación del Proyecto

2. Establecimiento del alcance, entregables y objetivos del proyecto

3. Definición de las actividades del proyecto - Estructura de

descomposición del proyecto (EDP)

4. Asignación de recursos y responsabilidades a nivel del EDP

5. Estimación de la duración de cada actividad (poner fecha a cada

actividad)


26

a) Estimación de costes

b) Secuencia de las actividades. Dependencias.

c) Bases para la evaluación de la realización del proyecto

(programa - costes)

d) Principales hitos y fecha objetivo para cada uno

e) Personal requerido o clave

f) Riesgos clave (restricciones y supuestos)

g) Planes auxiliares de dirección de Proyectos

h) Temas abiertos- decisiones pendientes

i) Organigrama del proyecto

5. Estimación de la duración de cada actividad (poner fecha a cada

actividad)

El contenido del plan de gestión del proyecto


27

Los Planes complementarios de Gestión del Proyecto

1. Plan de gestión de integración del

proyecto

2. Plan de gestión del alcance del proyecto

3. Plan de gestión del tiempo

4. Plan de gestión de costos

5. Plan de gestión de la calidad

6. Plan de gestión de los recursos

humanos

7. Plan de gestión de las comunicaciones

8. Plan de gestión de los riesgos

9. Plan de las compras y adquisiciones


28

2. El Plan de gestión del alcance del proyecto

− Definición del enunciado del alcance del proyecto

− Este describe en detalle, los productos entregables del proyecto

y el trabajo necesario para crear tales productos

− La WBS y cómo se mantendrá y aprobará

− Los procesos de verificación y aceptación de los entregables del

proyecto

− Los procesos para el control de cambios del alcance


29

• Es una herramienta de planificación que describe cómo el equipo

definirá el alcance del proyecto, desarrollará el enunciado del

alcance del proyecto detallado, definirá y desarrollará la

estructura de desglose del trabajo (WBS), verificará y controlará

el alcance del proyecto.

• Contenido del Plan de Gestión del Alcance:


• La Definición del Alcance incluye:

− Objetivos del proyecto

− Requisitos del proyecto

− Límites del proyecto

− Criterios de aceptación del producto

− Restricciones del proyecto

− Asunciones del proyecto

− Organización inicial del proyecto

− Riesgos iniciales definidos

− Hitos del programa

− Limitación de fondos

− Estimación del costes

− Especificaciones del proyecto

− Requisitos de aprobaciónIng. Raúl Alvarado

Rodríguez30


• Los procesos de la Planificación del tiempo se han definido en

cada una de las cajas de abajo.

• Instrucciones: Ordene las cajas de forma secuencial, con la

finalidad de poder armar el plan de gestión del tiempo del

proyecto.− Definición de las Actividades

− Secuencia de las Actividades

− Estimación de la Duración de las Actividades

− Estimación de Recursos de las Actividades

− Desarrollo del programa

− Control del programa


31

• Anexo 1: “Gestión de tiempos del proyecto”

3. El Plan de gestión del tiempo del proyecto


• La Gestión de los Costes del Proyecto se ocupa principalmente

del coste de los recursos necesarios para completar las

actividades del programa del proyecto


32

• Anexo 2: “Gestión de costos del proyecto”

4. El Plan de gestión de costos del proyecto


− Métricas de Calidad

− Listas de Control de Calidad

− Plan de Mejoras del Proceso

− Línea Base de Calidad

• La planificación de calidad implica identificar qué normas de

calidad son relevantes para el proyecto y determinar cómo

satisfacerlas.

• Los resultados de la Planificación de la Calidad son:


33

5. El Plan de gestión de calidad del proyecto


• Este plan incluye cómo y cuándo se adquirirán los miembros del

equipo del proyecto, los criterios para eximirlos del proyecto, la

identificación de las necesidades de formación, los planes

relativos a recompensas y reconocimiento.


34

6. El Plan de gestión de los recursos humanos del proyecto


• Incluye los procesos necesarios para asegurar la generación,

recogida, distribución, almacenamiento, recuperación y destino

final de la información del proyecto en tiempo y forma


35

7. El Plan de gestión de las comunicaciones del proyecto


• Los objetivos de la Gestión de los Riesgos del Proyecto son:


36

8. El Plan de gestión de riesgos del proyecto


− Aumentar la probabilidad y el impacto de los eventos

positivos

− Disminuir la probabilidad y el impacto de los eventos

adversos para el proyecto.

• Los procesos de gestión de las adquisiciones incluye:

− Planificar las compras y adquisiciones

Determinar qué comprar o adquirir , y cuándo y cómo hacerlo

− Planificar la contratación

Documentar los requisitos de los productos, servicios y

resultados, e identificando a los posibles vendedores

− Solicitar respuestas de vendedores

Obtener información, presupuestos, licitaciones, ofertas o

propuestas según corresponda.

− Selección de vendedores

Revisar ofertas, elegir entre posibles vendedores, y negociar

un contrato por escrito con cada vendedor.


37

9. El Plan de gestión de las adquisiciones del proyecto


− Administración del contrato

Gestionar el contrato y la relación entre el comprador y el

vendedor, revisar y documentar cuál es o fue el rendimiento

de un vendedor a fin de establecer las acciones correctivas

necesarias y proporcionar una base para relaciones futuras

con el vendedor, gestionar cambios relacionados con el

contrato y, cuando corresponda, gestionar la relación

contractual con el comprador externo del proyecto.

− Cierre del contrato.

Completar y aprobar cada contrato, incluida la resolución de

cualquier tema abierto, y cerrar cada contrato aplicable al

proyecto o a una fase del proyecto.


38


Stakeholders

• Los involucrados o interesados (stakeholders en inglés) son todas

aquellas personas u organizaciones que afectan o son afectadas por

el proyecto, ya sea de forma positiva o negativa. Una buena

planificación de proyectos debe involucrar la identificación y

clasificación de los interesados, así como el estudio y la

determinación de sus necesidades y expectativas.


39

Tipos de Stakeholders

• Aquellos que serán afectados por el proyecto y que pueden ejercer

cierta influencia sobre él, pero que no están directamente

involucrados con la ejecución del trabajo. Ejemplos de este tipo de

interesados son: gerentes afectados por el proyecto, personas que

trabajan en el proceso bajo estudio, departamentos internos que

soportan el proceso (como el departamento de finanzas),

proveedores, la oficina de gestión de proyectos, clientes y el

patrocinador.

• Organizaciones que tienen algún interés en que los resultados del

proyecto cumplan con ciertas regulaciones. Ejemplos de ellos son:

gobiernos nacionales y locales, grupos de protección al ambiente y

entidades gubernamentales.

• El equipo de proyecto.

• El gerente de proyecto Ing. Raúl Alvarado Rodríguez

40

El patrocinador

• El patrocinador (en inglés: executive sponsor) es un papel dentro de

la gestión de proyectos, generalmente el miembro de más rango

dentro de la junta directiva de proyecto. Es uno de los principales

interesados en el proyecto.

• En organizaciones pequeñas (o proyectos pequeños dentro de

organizaciones grandes) el patrocinador puede también ser el

encargado del proyecto. En otras, especialmente donde se utilizan

metodologías como PRINCE2, el patrocinador del proyecto será

típicamente un ejecutivo senior de la corporación (a menudo en o

apenas debajo del nivel de la junta directiva) que será responsable

ante la empresa por el éxito del proyecto.


41

El patrocinador

• Cuando una persona asume tan sólo el rol de patrocinador, ésta

raramente está implicada en el funcionamiento del proyecto. Su

actividad se basa en:− Defender el proyecto.

− Obtener presupuestos para el proyecto.

− Aceptar la responsabilidad de problemas extendidos del

encargado de proyecto.

− Firmar documentos tales como el caso de negocio y el documento

de iniciación del proyecto

• Debido a la necesidad de solucionar problemas inherente al papel de

patrocinador, éste necesita a menudo contar con poder para ejercer

presión dentro de la organización para así superar la resistencia que

se pueda generar en torno al proyecto. Por esta razón el patrocinador

debería ser una persona con gran autoridad ejecutiva y política, y

autoridad innata Ing. Raúl Alvarado

Rodríguez42


43

Factores críticos de éxito de un proyecto

1. Factores críticos de éxito de un proyecto

• Planeamiento

Objetivos

Plazos

Recursos

Reglas

Cambios

Riesgos

Personas

• Estimaciones

• Documentación

• Control y revisión

Productividad

Resultados


44

Definición e interpretación de objetivos de un proyecto

1. Objetivos

• Direccionan el trabajo

• Coordinan los esfuerzos para las prioridades

• Facilitan la comunicación

• Resuelven conflictos

• Miden desempeño y progreso

2. Errores mas comunes en la definición de objetivos

• Intenciones, deseos

• Ambigüedad, abstracción

• Amplitud, dificultad

• Conflictos

• Campañas (proliferación)

• Fines y medios


45

Definición e interpretación de objetivos

3. Características de objetivos bien definidos

• Meta

• Indicadores

• Restricciones


46

Propuesta

1. Cómo nace un proyecto

• Idea Necesidad

• Definición de objetivos

• Levantamiento de datos (nivel macro)

• Planeamiento inicial

• Propuesta


47

Propuesta

2. La propuesta define:

• El servicio/ producto final

• Cubrir los objetivos

• El alcance del proyecto

• El inicio y fin del proyecto

• Los plazos

• La relación costo * beneficio

• Los recursos necesarios

• Las condiciones

• Soporte requerido

• Las responsabilidades de los sectores involucrados

• Actividades a realizar (desde un nivel macro a un nivel de

detalle)

• Definir criterio de aprobación / aceptación del producto


48

Propuesta

La propuesta una vez aprobada, formaliza el inicio del

proyecto y es el contrato por el cual el líder del proyecto

es el responsable. Por lo tanto

No trate de ser un héroe

Si los plazos/ recursos concedidos no fueran suficientes, es

mejor decirlo ya, Ud. tal vez sufra alguna presión, o mucha

presión, o muchísima presión…

Pero si acepta condiciones imposibles, Ud. comienza

derrotado. En algún punto del desarrollo del proyecto el

atraso comenzará a ser obvio. De allí las cosas pueden

comenzar a empeorar, … y mucho.


49

Planeación del proyecto

• El administrador del proyecto, una vez que comienza el proyecto y

recopila la información básica de requerimientos en la fase inicial,

realiza un plan de trabajo especificando los diferentes aspectos en

cuanto a la forma de trabajo, llenando las diferentes secciones del

documento correspondiente.

• Utilizando el ciclo de vida elegido desarrolla el desglose de

actividades en un plan (por ejemplo en un Gantt) al máximo

detalle posible, procurando que las actividades duren en promedio

2 a 3 días, dependiendo del tamaño del proyecto. En proyectos

pequeños las actividades deberían de ser de unas cuantas horas.


50

Planeación del proyecto

• En dicho desglose estima el esfuerzo apoyándose con los recursos

que llevarán a cabo dichas actividades. A las actividades les

asigna responsabilidades y dependencias de acuerdo a la cantidad

de recursos y al ciclo de vida. Para facilitar el desarrollo de este

Gantt se recomienda utilizar un formato ya establecido con las

fases y actividades típicas para el proyecto.

• Una vez desarrollado el plan debería registrar la versión de dicho

plan en el control de versiones correspondiente. Pues, es

importante llevar un control de la evolución del plan. Recordemos

que el plan es algo vivo que está en constante cambio y evolución.


51

Alcance del proyecto

• Es el trabajo que debe ser realizado para entregar el producto del

proyecto con las funciones y características especificadas. El

alcance del proyecto determina qué está y qué no está en el

proyecto, y generalmente es definido en términos de entregables.

Una función importantísima del Gerente de Proyecto en la fase de

estructuración del proyecto es documentar y acordar el alcance

del proyecto con los accionistas, patrocinadores y demás

involucrados


52

¿Cómo hacer para que el proyecto no crezca desmesuradamente?

• Una vez que el equipo del proyecto comienza a construir los

entregables, el principal problema del gerente es cómo manejar el

alcance del proyecto: cómo hacer para que los entregables

conserven su definición original, cómo hacer para minimizar los

cambios en el proyecto.

• En todo proyecto hay cambios al alcance, la pregunta es en qué

medida. En todo proyecto existe una especificación original del

producto o servicio a entregar, y a medida que se avanza existen

modificaciones, agregados, observaciones, que hacen que esta

especificación original varíe e impacte en el trabajo planificado.

Esto sucede en todos los proyectos. Los patrocinadores, gerente y

equipo del proyecto deben asumir desde el primer minuto lo

siguiente: "Habrá modificaciones al alcance“.


53


• Para manejar el alcance correctamente, el gerente de proyecto y

su equipo deben controlar dos dimensiones de las actividades:

primero, las tareas comprendidas en el avance normal del

proyecto, en el cronograma de trabajo. Segundo, los "issues" del

proyecto. Explicaremos qué es cada una de estas dos

dimensiones:

− Avance normal de las tareas

− Issues del proyecto


54


1. Avance normal de las tareas:. Controlar el avance de estas

tareas significa controlar todos los días, todas las semanas, si

las fechas de comienzo y fin de las tareas están siendo

cumplidas, si existen retrasos, en qué tareas existen retrasos,

etc.

2. Issues del proyecto: un issue es un problema, incidente,

requerimiento, error u omisión en el proyecto, que se

manifiesta en el desarrollo del proyecto a medida que se

avanza con el trabajo. Un issue puede tener impacto en el

cronograma (este es el mal caso) o ser una "falsa alarma" si se

pensó que era realmente un problema y no lo era, o se

solucionó sin que afecte al cronograma. Este es el buen caso,

"tuviste suerte", pero todos sabemos que no es muy frecuente

"tener suerte" en los proyectos...


55


• Con respecto a estas dos dimensiones, lo que pasa muchas veces

es que el gerente del proyecto y su equipo "se creen" que están

gerenciando el proyecto, cuando en realidad están solamente

controlando el avance normal de las tareas (dimensión 1). Sucede

que esta dimensión es la parte trivial del control del proyecto, la

parte fácil, mientras que el radar debería estar en la dimensión 2:

debe administrarse la regla y las excepciones, la regla es algo

sobreentendido, lo que debe preocupar son las excepciones.

• También sucede muchas veces que no se tiene el cronograma del

proyecto. En este caso todo el proyecto es un conjunto de

excepciones (issues) que surgen mucho más rápido de lo que el

equipo puede solucionar. Si no se tiene un plan, no se pueden

calcular los desvíos del camino porque no hay camino. Resultará

muy difícil construir los entregables porque todo el proyecto será

una sucesión interminable de issues desde el minuto cero


56


• Regresando al caso más frecuente, en muchos proyectos existe un

plan pero no existe un manejo ordenado de los issues que podrían

atentar contra el desarrollo normal de las tareas. Debe construirse

una lista de issues para manejar el alcance, en donde se

especifiquen cosas como: descripción del problema encontrado,

quién lo reportó, cuantas horas nos llevará solucionarlo o agregar

lo que se requiere, en qué estado está el issue, si está en análisis,

si lo aceptamos, si lo rechazamos, etc. Esta lista debería estar

visible para todos los involucrados en el proyecto.

• Entonces lo que se quiere como gerente del proyecto es "defender

al equipo de los issues", para que puedan desarrollar las tareas

planificadas originalmente. Otra cosa que se quiere como gerente

de proyecto es que el equipo sea nuestro aliado y no nuestro

enemigo en el manejo de los issues.


Que el equipo reporte todos los issues en esta bitácora y que nos

ayude a analizarlos, estimarlos, calcular su costo-beneficio, decidir

si se aceptan o rechazan. Esto también va a servir para

transformar cualquier pedido informal en uno formal, y así

implementar un proceso ordenado, reconocido, legitimado para

administrar el alcance del proyecto.

• Si llegamos a esta situación en el proyecto, se está administrando

el alcance correctamente: una preocupación será manejar la lista

de issues, procesarlos y decidir qué issues se aceptan. Para

aquellos aceptados, debería delegarse su ejecución y reflejar su

impacto en el cronograma.


57


58

Introducción a la Recopilación de Requerimientos

• El líder de proyecto debe utilizar cualquier medio posible para

obtener los requerimientos del sistema. Esto lo realiza en especial

durante la primera fase del proyecto. Aunque es normal que siga

haciéndolo en las demás fases en menor medida, pues difícilmente

se podrán tener los requerimientos totalmente estables ni completos

desde un principio.

• Una de las principales formas de obtener dicha información es

mediante reuniones donde el analista debe guiar la entrevista y

documentar todos los puntos importantes que allí se vayan

mencionando.

• Se deben de analizar los documentos con los que se cuente para

preparar una agenda y cuestionarios para cada entrevista y así

obtener mejores resultados.

• Debe de tomar en cuenta la opinión de los diferentes stakeholders

del proyecto, desde el responsable del área usuaria hasta el usuario

final para obtener los requerimientos más completos posible.


59


• Durante las reuniones se deben de elaborar minutas con los

acuerdos y enviarlas a los participantes para su validación. Si no

responden en un tiempo acordado con sus observaciones se

considerará como aceptado lo allí escrito.

• Se recomienda utilizar mecanismos que faciliten la retroalimentación

y participación de usuarios, como es el caso de modelos, prototipos

no funcionales y casos de uso.

• La información documentada en las minutas no reemplaza a los

documentos formales de requerimientos, como podrían ser la visión,

la especificación y matriz de requerimientos, las especificaciones de

casos de uso o la especificación suplementaria.


60


• Durante la fase preliminar (Concepción en Proceso Unificado, UP)

hay que identificar los requerimientos de alto nivel del sistema en un

documento de Visión y detallarlos en Especificaciones de casos de

uso y especificación suplementaria durante la fase de Análisis (fase

de Elaboración en UP).

• Los requerimientos documentados son la base para que el

administrador realice las estimaciones y el plan del proyecto en

general. Para lo cual necesitará la validación del usuario a todos los

documentos donde se especifiquen los requerimientos.

• El administrador no debería asumir nada. Es importante que se

asegure que está entendiendo correctamente lo que el usuario quiso

decir, por lo que debe validar la información escrita y de preferencia

formalizarla por medio de firmas de aprobación de los usuarios.


61

Requerimientos

Ejercicio de requerimientos: Diseño de tetera

Tome, por ejemplo, el diseño de una simple tetera. El diseñador

tiene que inventar una tetera que encaje con el contexto de su uso.

No debe ser demasiado pequeña. No debe ser difícil de manipular

cuando caliente. No se debe soltar fácilmente por equivocación.

Debe ser fácil de guardar en la cocina. No debe ser difícil al

extraerle el agua. Debe servir el agua limpiamente. No debe dejar

que enfríe el agua rápidamente. El material del que está hecha no

debe ser muy costoso.

Debe soportar la temperatura del agua hirviendo. Debe ser fácil de

limpiar exteriormente. No debe tener una forma que dificulte su

trabajo.


62

No debe ser difícil de ensamblar ya que cuesta horas de mano de

obra. No debe corroerse en cocinas de vapor. Su interior no debe

ser difícil de mantener libre de sarro. No debe ser difícil de llenar

con agua. No debe ser antieconómica al calentar poca cantidad de

agua. Debe tener una forma que sea útil ya que se paga un precio

razonable por el metal del que está hecha. No debe ser difícil de

sostenerla para que no ocasione accidentes a niños o inválidos que

traten de usarla. No debe hervir cuando no tenga agua y se pueda

quemar sin previa advertencia. No debe ser inestable en la hornilla

cuando hierve el agua.

Extracto de NOTES ON SYNTHESIS OF FORM. De Christopher

Alexander.

Requerimientos

Ejercicio de requerimientos: Diseño de tetera (continuación)


63

Desarrollo de la relación del profesional de SI con el cliente

1. Observe al cliente en su actual ambiente

2. Evalúe el sistema informal o sin documentar

3. Ayude al cliente a que se identifique con el nuevo sistema,

discutiéndolo con él.

4. Dé al cliente la visión del nuevo ambiente

5. Dé al cliente la visión del nuevo sistema

6. Considere las posibles restricciones para el desarrollo del sistema:

hardware, software, proyecto (presupuesto), etc.


64

Se desea desarrollar un sistema conversacional llamado SIEE

para ayudar a nuestro personal de colocación de puestos de

trabajo para atender pedidos de nuestros alumnos acerca de

puestos de trabajo disponibles. También debería responder

consultas de compañías acerca de la disponibilidad de

alumnos calificados. Periódicamente, el sistema debería

proveer reportes al administrador de la universidad acerca

del mercado de puestos de trabajo y hacer un seguimiento

del progreso de las mejores ofertas de trabajo. El sistema

también debería prevenir los accesos no autorizados.

Análisis de requerimientos

Sistema de información de empleo estudiantil (SIEE)


65

Análisis de requerimientos (SIEE)

1. Sistema conversacional

• Significado: el tiempo de respuesta del terminal no debería

de exceder a los 10 segundos

2. Ayuda a nuestro personal del centro de colocaciones

• Significado: sólo miembros del centro de colocaciones

estarán autorizados a utilizar el sistema

• Implementaciones:

Colocar los terminales en una sala con sistemas de seguridad

Proveer protección usando passwords, etc.


66


3. Responder consultas de nuestros alumnos acerca de puestos

de trabajo disponibles

• Significado: buscar en la base de datos de puestos de

trabajos disponibles usando el perfil del alumno

interesado.

• Inputs: Consulta de alumno

Base de datos de puestos de trabajos disponibles

Perfil del alumno interesado

• Outputs:

Una relación de puestos de trabajo que concuerde con

el perfil del alumno interesado


67


• Aclaraciones requeridas:

¿”Nuestros” significa que a los alumnos de otras

universidades no se les permitirá el uso del sistema?

¿”Alumnos” significa que a los profesores no se les

permitirá el uso del sistema?


68

Procedimiento de descomposición de requerimientos

1. Estructura de requerimientos

• Numerar cada párrafo, oración, frase

2. Identificar las funciones y restricciones

• Restricciones- Clasificarlas por tipo

Rendimiento

Seguridad

Auditoría

Hardware

Software


69

Procedimiento de descomposición de requerimientos

3. Funciones- Identificar inputs y outputs

• Origen, destino

• Naturaleza

• Frecuencia

• Validez

• Forma

• Rango

4. Especificar el método de transformar los inputs a outputs

5. Documentar usando un lenguaje simple, no usar jerga. Ayudar con

comentarios y notas

6. Determinar las interfases funcionales

7. Determinar el impacto de futuros cambios, si fueran aplicables

8. Iterar hasta que la descomposición se complete


70

Ventajas de la descomposición de requerimientos

1. Permite significativamente la participación del cliente

• Definición de requerimientos/ análisis

• Casos de prueba

• Walk- throughs

• Menos decisiones acerca del producto hechas por los

desarrolladores

• Mejora la cooperación entre el cliente y SI

• La técnica recomendada para familiarizar al usuario es JAD (Joint

Application Development, Desarrollo Conjunto de Aplicaciones )


71


Desarrollo Conjunto de Aplicaciones (Joint Application Development, JAD)

• Es una técnica exploratoria popular que incluye a los usuarios

como participantes activos en el proceso de desarrollo.

• El proceso de JAD se basa en cuatro ideas simples:

La gente que hace un trabajo tiene la mejor comprensión de

ese trabajo.

La gente entrenada en TI tiene la mejor comprensión de las

posibilidades de esas tecnologías.

Los SI y los procesos del negocio trascienden los límites de

cualquier sistema u oficina y afectan el trabajo en

departamentos relacionados. La gente que trabaja en estas

áreas relacionadas tiene una percepción valiosa del papel del

sistema dentro de una comunidad más amplia.

Los mejores SI se diseñan cuando todos estos grupos trabajan

juntos en un proyecto como socios iguales.


72


2. Promueve el control del proyecto en conjunto (cliente y profesionales

de SI)• Facilita la definición de prioridades

• Anticipa la identificación de requerimientos que no son factibles

• Reporte del avance de requerimientos, no por módulos, nio por

codificación

• Seguimiento de atrasos por requerimientos

• Medición de la productividad del cliente

• Fácil entendimiento de parte de la alta gerencia


73

Cómo ayudar al cliente a especificar requerimientos

1. No use términos técnicos ni jerga

2. Genere los requerimientos en forma conjunta

3. Insista que el cliente:

• Especifique cada requerimiento como una pequeña entidad

• Indique métodos de implementación, si es posible

• Provea inputs/ outputs por cada requerimiento funcional

• Clarifique cada término donde sean posibles varias

interpretaciones4. Use diversas técnicas de recolección de datos

• Entrevistas, cuestionarios, etc.

• Observaciones

• Tormenta de ideas

• Prototipos


74

Cómo ayudar al cliente a especificar requerimientos

5. Investigue otras fuentes de datos

• Interfases de sistemas de aplicación instaladas y/o planeadas

• Organizaciones de seguridad y auditoría

• Organigramas, políticas de la empresa

6. Publique la definición de los requerimientos citando:

• Necesidades del cliente

• Expectativas del cliente

• Restricciones


75

Ejemplo de entrevista

1. ¿Qué funciones son realizadas dentro de su organización?

2. ¿Cómo son realizadas?

3. ¿Qué información se requiere para realizarlas?

4. ¿Cuál / quién es el origen?

5. ¿Existen otras organizaciones involucradas?

6. ¿La información necesaria es proporcionada a tiempo? ¿Está en u

formato usable?

7. ¿Qué información es creada durante cada función? ¿Quién la

recibe? ¿Cómo es usada?

8. ¿Qué problemas son enfrentados en la realización de las

funciones? ¿Con qué frecuencia?


76

Ejemplo de entrevista

9. ¿Si los problemas son reducidos o eliminados, qué valor tendría

para usted?

10. ¿Qué cambios de negocio pueden ser anticipados? ¿Qué impacto

tendrán en sus funciones?

11. ¿Qué mediciones o controles usa Ud. para hacer seguimiento de

sus actividades?

12. ¿Qué otras funciones son afectadas por el proceso de su trabajo?

• Incluye los procesos necesarios para

• asegurar la concreción del proyecto en tiempo

Anexo 1: Gestión de tiempos del proyecto

Definiciónde

Actividades

Secuenciade

Actividades

Duración estimada deActividades

DesarrollodelPlan

ControldelPlan

Tiempo


77

Gestión del Tiempo - Secuenciación de actividades


78

Diagrama de red

Actualización de lista de actividades

• Salidas

IF

Gestión del Tiempo - Secuenciación de actividades


79

Lista de Actividades

Requerimientos de recursos

Capacidad de recursos

Información histórica

Restricciones y Supuestos

• Implica determinar el período de tiempo que demandará

• ejecutar cada una de las tareas identificadas.

• Entradas:

Gestión del Tiempo – Estimación de duración de actividades


80

Asesoramiento de expertos

Estimación por analogía

Simulaciones

• Técnicas:



81

Duración estimada de las actividades

Bases de estimación

Lista de actividades actualizada

• Salidas



82

Errores en la estimación de los recursos y los tiempos

• Errores por suponer situaciones similares cuando no lo son.

• Subestimación de ciertas actividades por falta de información.

• Falta de experiencia

• No se considera que un recurso puede ser no renovable ni

sustituible.

• Generalmente se basa en hipótesis falsas por autoengaño.


83

Gestión del Tiempo - Programación de Actividades

Diagrama de red

Duración estimada de actividades

Requerimientos de recursos

Pool de recursos

Calendario

Restricciones y Supuestos

Retrasos y adelantos

• Implica determinar las fechas de inicio y

• finalización para las actividades del proyecto.

• Entradas:


84

Análisis Matemático

Critical Path Method (CPM)

PERT


• Técnicas:

Método heurístico de recursos

Reasignación por análisis de recursos sobre el CPM

Compresión de la duración

Fast tracking:

Crashing:


85

Técnicas Matemáticas

• Calcular fechas teóricas de inicio y finalización para todas las

actividades del proyecto, sin considerar restricciones en los recursos.

• Método del Camino Crítico (CPM):

− Camino crítico: secuencia de actividades que, en conjunto,

determinan la duración del proyecto.

− CPM asume que las duraciones de las actividades se conocen

con exactitud de antemano, y en base a ello realiza un “análisis

de camino crítico”


86

Gestión del Tiempo - Camino crítico

• Un camino es una secuencia de actividades que comienza en una

actividad inicial del proyecto, recorre un conjunto de actividades

que se suceden inmediatamente, y termina en una actividad final

del proyecto.

• El largo de un camino es el tiempo total que lleva recorrerlo.

• Para cualquier red existe un camino de máximo largo de todos los

posibles

• Todo camino cuyo largo es igual al máximo es llamado camino

crítico.


87

¿ Porqué importa el Camino Critico?

• Un retraso en una tarea del camino crítico implica un retraso en la

fecha de terminación del proyecto

• Es posible retrasar actividades que no pertenecen al camino crítico

sin atrasar el proyecto

• Las actividades del camino crítico son aquellas en las que el jefe del

proyecto deberá poner más atención

• Las actividades en el camino crítico no son necesariamente las

actividades más importantes técnicamente del proyecto.


88

Ejemplo de Reglas Básicas para la Estimación

1. No considerar horas extras

2. Sólo un turno de 8 hs. por día, productivo entre 6,5 hs y 7 hs

3. Considerar licencias y feriados

4. Expresar duraciones en días laborables (no semanas)

5. Considerar niveles de experiencia de las personas

6. Considerar necesidades de capacitación

7. Considerar participación en inspecciones de diseño y construcción

8. Considerar participación en revisión de documentos del proyecto

9. Considerar participación en reuniones del proyecto

10.Considerar identificación, almacenamiento y presentación de

mediciones de calidad y del proceso


89

Ejemplo de Reglas Básicas para la Estimación

11.Considerar tiempos de viajes

12.Considerar disponibilidad de hardware, tools y otros recursos

13.Considerar proyecciones realistas de contratación de personal y

proveedores

14.Considerar el soporte a productos ya enviados a clientes

15.Listar suposiciones adicionales no contenidas en esta lista


90

• Salidas


− Información de soporte

− Lista de recursos actualizada

− Plan de introducción de cambios

− Proyecto programado:

o Gantt

o Diagrama de red


91

Gestión del Tiempo – Diagrama de GANTT


92

Milestones “Hitos”

• Indican la finalización de una etapa del proyecto

• Razones para definir milestones:

• evitar que se pierda una visión global del proyecto

• reportar el estado del proyecto hacia “arriba”

• Son indicados en la agenda sinóptica del proyecto

ID Task Name Start

1 Inicio Proyecto Mon 05/01/98

2 Análisis de Requerimientos Mon 05/01/98

3 Análisis Aprobado Fri 30/01/98

4 Objetivos del Producto Mon 26/01/98

5 Documento Objetivos Fri 20/02/98

6 Especificación de Req. Mon 16/02/98

7 SRS Aprobada Fri 27/03/98

8 Diseño y Codificación Mon 09/03/98

9 Código Aprobado Fri 15/05/98

10 Test de Unidad y Función Mon 13/04/98

11 Testeo U&F aprobado Fri 19/06/98

12 Test de Módulo Mon 22/06/98

13 Testeo M aprobado Fri 07/08/98

14 Test del Sistema Mon 10/08/98

15 Testeo Aprobado Fri 16/10/98

16 Empaque y Envío Mon 19/10/98

17 Sistema Disponible Fri 06/11/98

18

05/01

30/01

20/02

27/03

15/05

19/06

07/08

16/10

06/11

W1 W7 W13 W19 W25 W31 W37 W43 W4997 January 1998 April 1998 July 1998 October 199


93

Heurísticas de asignación de recursos

• Resultados del CPM no consideran las restricciones de recursos y

por lo tanto generan sobrecarga de recursos o una distribución de

recursos poco eficiente.

• Son necesarias reglas para nivelar recursos.


94

Perfil (o histograma) de recursos:

• Diagrama de barras que indica la intensidad de uso de cada

recurso.− Resalta las sobrecargas y

− las subutilizaciones.


95

Nivelación de recursos y cronograma

• Etapa 1 - Usar slack

• Una tarea con flotación tiene cierto grado de libertad respecto a

cuando será ejecutada

• Podemos mover el inicio planeado para minimizar la sobrecarga

de recursos

• Etapa 2 - Si podemos modificar la duración del proyecto

• Modificar duración de tareas para nivelar recursos

• Etapa 3 - Reconsiderar:

• Las duraciones estimadas

• 2. El análisis de precedencia

• Etapa 4 - Debemos modificar el alcance o renegociar otras

condiciones.


96

mayo 1997 Curso de Gestión de Proyectos 97

Otras Técnicas Aplicables al Desarrollo de Cronogramas

• Compresión de la duración, técnicas para acortar la duración

del proyecto, sin cambiar su alcance.

− fast tracking (superposición):

− crashing : acortar con más recursos


97

Fast tracking (superposición):

• Ejecutar en paralelo actividades que normalmente se realizarían

secuencialmente:

− Comenzar codificación antes de terminar con el diseño


98

Crashing (acortamiento con + recursos):

• Se analizan compromisos entre cronograma y costos, para obtener la

máxima compresión con el mínimo incremento de costo

• Se define para cada actividad:

− Mi = máxima reducción de duración de actividad i

− Ci = costo asociado con reducción de duración

− Ki = Ci/Mi

− Buscar la actividad en el camino crítico con el menor

Ki.


99

Costo versus duración:


100

Duración total del proyecto:

• Suma de las duraciones de la secuencia de tareas críticas.

• Puede haber caminos críticos paralelos.

• El acortamiento de una tarea critica puede cambiar el camino

crítico.

• La variación de una tarea no crítica puede cambiar el camino crítico

y la duración total.


101

Total del proyecto.

• El costo total es la suma de todos los costos

• Lo que interesa es la relación duración total / costo total.

• Puede haber beneficios por acortar el proyecto que no son de

ninguna tarea sino del proyecto en su conjunto.


102

Control del programa:

• A partir de reportes de desempeño real, o de solicitudes de cambios:

• se mide el desempeño del cronograma

• se modifica (o actualiza), el programa.

• Se toman acciones correctivas

• se registran las lecciones aprendidas.


103

Gestión de Proyectos

Anexo 2: Gestión de costos del proyecto

• Es el proceso conducente a asegurar que el proyecto se completa

dentro del presupuesto asignado.


104

La Gestión de Costos

• Se compone de :

– Planificación de recursos, humanos y materiales.

– Estimación de costos, de esos recursos.

– Presupuestación, juntar los costos de los recursos con las

actividades y el cronograma.

– Control de costos.

• Comparación previsto-real,

• y control de cambios.


105

Costo de ciclo de vida.

• TRADE-OFF: Costo Proyecto vs. Costo Producto

• Resolver en vista del menor costo global:

• “Costeo del Ciclo de Vida.”

• En algunos proyectos el desempeño en rendimiento financiero del

producto está fuera del alcance del proyecto.


106

Cuidados

• La gestión de costos debe servir a todos los interesados del

proyecto

• Distintos interesados tienen distintas ópticas, requieren distintas

medidas.

• Si el desempeño de costos forma parte de sistemas de retribución o

premiación: cuidar la separación de costos controlables y no

controlables.

EVITAR SUBOPTIMIZACIÓN


107

Planificación de Recursos

• Entradas:

• Estructura de Análisis de Trabajo (WBS).

• Información histórica

• Formulación del alcance

• Pool de Recursos

• Políticas de la organización.

• Herramientas:

• Juicios de expertos

• Identificación de alternativas.

• Software de gestión de proyectos.

• Salidas: Requerimientos de Recursos.

• Tipo y cantidad de Recursos requeridos en cada actividad

prevista.


108

Estimación de Costos

• Entradas:

• WBS (ver dependencia costo - tiempo)

• Requerimientos de Recursos

• Tarifas

• Duraciones estimadas

• Información histórica.

• Plan de cuentas.


109

Estimación de Costos

• Herramientas y Técnicas:

• por analogía (top down).

• por modelos parametrizados.

• Por análisis de cada actividad (buttom up).

• Software de Gestión de Proyectos.

• Especialmente para manejar alternativas.

• Los estimados de costos se harán a veces en unidades físicas, pero

siempre en unidades monetarias.


110

Línea base de presupuestación

• Asignación de costos a las actividades programadas y acumulación

en el tiempo (curva S).

• acumulación de costos

• acumulación de reservas, compromisos, créditos…

• acumulación de efectivo a pagar (salidas de caja)

• según distintos interesados.


111

Curva S.


112

Control de Costos

• Monitoreo del desempeño en costos.

• Análisis de variaciones (los porqué)

• en cantidad

• en tarifa (o precio).

• Análisis de consecuencias posteriores.

• Control de cambios

• registros

• autorizaciones

• Información a interesados.


113

Plan de Gestión de Costos

• Cómo manejar variaciones.

• Cuando introducir cambios.

• Quién autoriza cambios.

• Los cambios de presupuesto deberían obedecer a un cambio de

alcance del proyecto, e integrarse en la gestión de cambios del

proyecto.


114

Control de costos

• Represupuestar, si los cambios lo requieren.

• Estimar “Costo a la Finalización (EAC)”:

• Real actual + presupuesto de lo faltante

• Real actual + idem. corregido por factor de desempeño hasta la

fecha.

• Real actual + presupuesto actualizado por cambios en las

condiciones.

• REGISTRAR LECCIONES APRENDIDAS.


115

2. inicio de un proyecto. contenido 1.procesos de dirección de proyectos 2.la gestión de la...

Documents