Planificación del proyecto
![](/daisy/Materials/img/uoc_masterbrand.png)
Índice
- Introducción
- Objetivos
- 1.¿Qué es un plan de proyecto?
- 2.Procesos de la planificación. La integración del plan
- 3.Planificar el alcance
- 4.Planificar el tiempo
- 5.Planificación de costes
- 5.1.El presupuesto
- 6.Planificar la calidad
- 7.Planificar los riesgos
- 8.Otros componentes de la planificación
- 9.Resumen
Introducción
![Figura 1. Ciclo de vida del proyecto](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_01.gif)
Objetivos
-
Entender la importancia de la planificación de un proyecto, los diferentes tipos de planificación y el enfoque de la planificación orientada a objetivos, en particular el concepto de hito.
-
Qué procesos componen la etapa o grupos de procesos de planificación, cuál es su estructura típica, técnicas y herramientas y los principales productos que se obtienen. El jefe de proyecto tiene a su alcance un conjunto de instrumentos (como una 'caja de herramientas'), que debe seleccionar y aplicar para cada proyecto, según su tamaño, tipología, etc.
-
Conocer en profundidad las herramientas y productos de la planificación en las tres áreas clave (llamadas líneas de base o baselines de la gestión de un proyecto TIC:
-
La planificación detallada del alcance.
-
La planificación de tiempos y la elaboración del calendario de proyecto.
-
La planificación de costes y la elaboración del presupuesto de proyecto.
-
-
Disponer de un conocimiento suficiente del resto de las áreas de conocimiento que deben incluirse en la planificación, con el alcance y profundidad que se determine en cada caso y según el tipo de proyecto:
-
La planificación de la calidad.
-
La planificación de los recursos humanos.
-
La planificación de la comunicación y gestión de las expectativas del cliente.
-
La planificación de riesgos.
-
La planificación de la administración y gestión de compras y contratos.
-
1.¿Qué es un plan de proyecto?
-
Un mapa de ruta estructurado que establece todas las actividades que hay que hacer para alcanzar los objetivos de negocio.
-
Una definición de los tiempos y recursos –tecnológicos y de negocio– necesarios para completar el trabajo.
-
Un mecanismo para monitorizar avances, controlar el alcance y gestionar el proyecto para asegurar los resultados finales dentro del marco del tiempo y presupuesto definidos.
-
Un medio para comunicar los progresos y comprometer a los participantes del proyecto.
![Figura 2. Características de un proyecto planificado](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_02.gif)
1.1.Contenidos del plan
-
Los objetivos y los resultados que se esperan del proyecto, de manera que permita la evaluación del éxito o fracaso del mismo, tal como se han descrito en los capítulos anteriores.
-
Los hitos principales del proyecto, coincidentes con puntos de decisión, entregables, finalización de etapas, etc. Una definición más detallada de hito se establece en los apartados siguientes del capítulo.
-
Los mecanismos de control del alcance del proyecto, y de gestión de cambios en éste.
-
La involucración de los distintos agentes participantes en el proyecto, sus roles y responsabilidades.
-
La definición de las actividades del proyecto, es decir, las tareas o grupos de tareas de las que se compone, los recursos técnicos y humanos necesarios y el resultado o hito que debe obtenerse mediante la realización de estas actividades.
-
El calendario de trabajo, con los tiempos de realización según la fecha de inicio y la fecha de finalización de cada una de las actividades y la de cada uno de los hitos.
-
La organización y el equipo asignado al proyecto, con la matriz de roles y responsabilidades para los diferentes hitos y actividades.
-
El presupuesto del proyecto, con las estimaciones de inversión y coste presupuestadas a partir del consumo de recursos, su previsión de evolución a lo largo del tiempo de duración del proyecto y la previsión de beneficios esperados.
-
El sumario de las asunciones realizadas sobre los riesgos identificados previamente a la implantación del proyecto, su posible impacto sobre el plan de proyecto y el plan de gestión de estos riesgos.
-
La calidad de los trabajos realizados, según los resultados funcionales y operacionales esperados y la definición de las condiciones y principios de aceptación de los mismos.
Los procesos de planificación, según el PMBOK
|
---|
1) Plan de gestión de proyecto
|
2) Plan de gestión del alcance
|
2.1) Recogida de requisitos
|
2.2) Definición detallada del alcance
|
2.3) Creación de la EDT
|
3) Plan de gestión del tiempo
|
3.1) Definición de actividades
|
3.2) Secuenciación de actividades
|
3.3) Estimación de recursos para las actividades
|
3.4) Estimación de duración de las actividades
|
3.5) Elaboración del calendario
|
4) Plan de gestión de costes
|
4.1) Estimación de costes
|
4.2) Elaboración del presupuesto
|
5) Plan de calidad
|
6) Plan de recursos humanos
|
7) Plan de comunicación
|
8) Plan de gestión de riesgos
|
8.1) Plan de gestión de riesgos
|
8.2) Identificación de riesgos
|
8.3) Análisis cualitativo de riesgos
|
8.4) Análisis cuantitativo de riesgos
|
8.5) Plan de respuesta frente a los riesgos
|
9) Plan de administración y compras
|
1.2.La planificación orientada a objetivos
![Figura 3. Secuencia de preparación del plan](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_03.gif)
2.Procesos de la planificación. La integración del plan
![Figura 4. Componentes del proceso de preparación del Plan de gestión de proyecto](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_04.gif)
-
¿Cuál es la finalidad de poner en marcha el proyecto?
-
¿Qué hay que haber conseguido al final del proyecto que no se tenga actualmente: cuáles son los productos (entregables) del proyecto?
-
¿Hay que hacer o entregar algo más, aunque no se haya expresado formalmente?
-
¿Hay algo que esté específicamente excluido del alcance?
-
Las fronteras del proyecto: ¿están claras? ¿cómo afectan otros proyectos al nuestro, o al contrario?
-
Asunciones o restricciones del proyecto: cosas que suponemos que pasarán o no pasarán.
-
Problemas significativos que afectarán al proyecto.
-
Condiciones específicas de ejecución que ha pedido el cliente (por ejemplo, aportación de recursos, trabajar en su casa, relacionarse de una manera o de otra con la organización, etc.).
-
Las líneas base de alcance, coste y tiempo y los planes para gestionar cada una de estas dimensiones y manejar los cambios.
-
El organigrama de proyecto y la matriz de roles y responsabilidades.
-
El plan de comunicación con el cliente y las partes interesadas.
-
El plan de gestión de riesgos.
-
El plan de gestión de configuraciones, versiones, etc.
-
El resto de los planes complementarios o subsidiarios, en función de la importancia o prioridad que tengan en cada trabajo.
![Figura 5. Estados de planificación desde el punto de vista lógico](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_05.gif)
3.Planificar el alcance
3.1.Recogida de requisitos
-
Specific: específicos, sin ambigüedades, ni descripciones difusas.
-
Measurable: cuantificables, tanto como sea posible.
-
Agreed: acordados con los interesados y, en caso de conflicto, con el comprador o director del proyecto por parte del cliente.
-
Realistic: conseguibles dentro de las limitaciones técnicas, de alcance, tiempo y calendario.
-
Traceable: que sea posible su trazabilidad o seguimiento y evaluación del logro, y que se pueda validar su consecución.
-
Testable: esto es especialmente clave, que se pueda probar su consecución internamente y por el usuario en el momento de la operación.
![Figura 6. Componentes del proceso de toma de requisitos según PMBOK](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_06.gif)
-
Requisitos comparados con objetivos de negocio.
-
Requisitos comparados con objetivos del proyecto.
-
Requisitos comparados con hitos, productos y EDT.
-
Requisitos comparados con diseño.
-
Requisitos comparados con construcción.
-
Requisitos comparados con test.
-
Requisitos de alto nivel comparados con requisitos de detalle.
-
Etc.
3.2.Definición detallada del alcance
![Figura 7. Componentes del proceso de definición detallada del alcance](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_07.gif)
-
Descripción actualizada del producto, servicio o resultado y, frecuentemente como anexo, la documentación de requisitos.
-
Criterios de aceptación de los productos.
-
Entregables del proyecto, sean productos, servicios, componentes del proyecto o material complementario (por ejemplo, documentación).
-
Exclusiones del proyecto. Muchos directores de proyecto o compañías de servicio no se atreven a incluir por diferentes razones este apartado que resulta extremadamente crítico. Es una descripción argumentada de lo que no se hará y por qué, que ayuda de forma extraordinaria a gestionar las expectativas de clientes e interesados.
-
Limitaciones y asunciones. Son las condiciones organizativas, de calendario o de presupuesto, bajo las cuales se realizará el proyecto y, en su caso, las condiciones para su modificación. Actualmente, muchos proyectos se hacen bajo presupuestos cerrados, pero se establecen condiciones bajo las cuales el presupuesto puede revisarse. O, al contrario, se hacen 'por administración' (horas dedicadas), pero se establecen unos productos mínimos que deben obtenerse y unas condiciones para sustituirlos.
-
Hitos. Son los estadios o condiciones intermedias por los que el proyecto debe pasar para alcanzar sus objetivos finales. Muchas veces, pero no siempre, están vinculados a la descomposición del proyecto en partes menores (EDT o WBS), a la que nos referiremos a continuación.
-
Las responsabilidades por los hitos. Es la asignación de roles y responsabilidades en el nivel de hitos, es decir, identificar quién o quiénes son responsables de la consecución de cada hito y que otros miembros del equipo o partes interesadas del cliente participan y con qué rol o nivel de responsabilidad.
3.2.1.El Plan de hitos
-
Deben reflejar el qué y no el cómo.
-
Deben ser fáciles de leer y entender para la dirección.
-
Deben ser puntos de decisión.
-
Deben ser concretos y medibles.
-
Deben ser relevantes y limitados en número.
-
Deben ocurrir en periodos de tiempo manejables.
-
Deben señalarse las dependencias con otros hitos.
Ejemplos de formulación de hitos
|
---|
|
|
|
|
|
|
|
|
![Figura 8. Planificación en MS Project de un proyecto de implantación de una solución del portal del ciudadano](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_08.gif)
3.2.2.Matriz de roles y responsabilidades
-
Quién es el responsable de la ejecución de cada hito.
-
Quién toma las decisiones, sólo o juntamente con otros.
-
Quien gestiona los recursos y controla el progreso del trabajo.
-
Quién debe ser informado.
-
Quién debe ser consultado.
-
Quién debe participar.
-
Quién debe dar apoyo o dotar de infraestructura al equipo.
-
Quién asegura la calidad de los resultados.
3.3.Estructura de descomposición del trabajo (EDT)
-
La gestión del proyecto.
-
La toma de requisitos.
-
El diseño de detalle.
-
La construcción.
-
La integración.
-
Las pruebas.
-
La implantación.
-
Planificación del diseño.
-
Diseño lógico.
-
Diseño físico.
-
Especificaciones de seguridad.
-
Especificaciones de interfaz con otros programas.
-
Especificaciones de conversión de datos.
-
Revisiones de usuario.
-
Revisiones de personal técnico.
-
Revisiones de documentación.
Estructura de descomposición del trabajo en un proyecto de despliegue de una red LAN/WAN
|
---|
1) Recoger requisitos
|
1.1) Requisitos de usuario
|
1.2) Requisitos de las estaciones de trabajo
|
1.3) Requisitos de los servidores
|
1.4) Requisitos de la red
|
1.4.1) Routers
|
1.4.2) Switches
|
1.4.3) Circuitos
|
1.4.4) Cableado
|
1.5) Periféricos
|
1.5.1) Impresoras
|
1.5.2) Faxes
|
1.5.3) Escáneres
|
1.5.4) Copiadoras
|
2) Comprar los equipos
|
Mismos componentes que 1.4. y 1.5.
|
3) Instalar los equipos
|
Mismos componentes que 1.4. y 1.5.
|
4) Test
|
4.1) Tests unitarios
|
4.2) Test del sistema (LAN)
|
4.3) Test de integración (WAN)
|
5) Gestión de proyecto
|
5.1) Iniciación y kick-off
|
5.2) Planificación
|
5.3) Ejecución, seguimiento y control
|
5.4) Documentación
|
5.5) Control de cambios
|
5.6) Cierre
|
4.Planificar el tiempo
![Figura 9. Visión general del proceso de planificación del tiempo en PMBOK](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_09.gif)
4.1.Planificar las actividades
![Figura 10](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_08.gif)
-
Cada actividad individual no debería suponer una carga muy grande de trabajo, por ejemplo, un total de 10 a 15 días/hombre.
-
Debería ser fácilmente observable y evaluable si la actividad ha sido completada o no.
-
Debería poderse hacer un control de calidad del resultado de la actividad.
4.2.Estimación de esfuerzos
4.3.Secuencia y duración del trabajo
4.4.Distribución del trabajo y recursos necesarios
Tareas
|
CF
|
US
|
AS
|
AP
|
GP
|
DG
|
Duración
|
Unidad
|
||
---|---|---|---|---|---|---|---|---|---|---|
Desarrollo e implantación del portal
|
|
|
|
|
|
|
|
|
||
|
Diseño del portal
|
|
|
|
|
|
|
|
|
|
|
|
Análisis de requisitos
|
R
|
P
|
I
|
P
|
|
|
10
|
días
|
|
|
Especificación funcional
|
R
|
P
|
I
|
P
|
|
|
5
|
días
|
|
Diseño funcional
|
|
|
|
|
|
|
|
|
|
|
|
Diseño funcional de la estructura del portal
|
R
|
P
|
C
|
P
|
|
I
|
20
|
días
|
|
|
Diseño funcional de los productos y servicios
|
R
|
P
|
C
|
P
|
|
I
|
20
|
días
|
|
|
Diseño de los flujos de trabajo (content workflows)
|
R
|
P
|
C
|
P
|
|
I
|
20
|
días
|
|
|
Diseño de los procesos web
|
R
|
P
|
C
|
P
|
|
I
|
20
|
días
|
|
|
Diseño de la navegación
|
R
|
P
|
C
|
P
|
|
I
|
10
|
días
|
|
|
Diseño gráfico look and feel
|
P
|
P
|
D
|
C
|
|
R
|
15
|
días
|
|
Diseño técnico
|
|
|
|
|
|
|
|
|
|
|
|
Detalle de la arquitectura técnica y seguridad
|
C
|
C
|
R
|
C
|
I
|
|
10
|
días
|
|
|
Diseño técnico de especificaciones por servicio
|
C
|
C
|
P
|
R
|
I
|
C
|
35
|
días
|
|
|
Diseño de las interfaces
|
C
|
C
|
P
|
R
|
I
|
C
|
10
|
días
|
|
Lanzamiento prototipo
|
|
|
|
|
|
|
|
|
|
|
|
Construcción del prototipo
|
R
|
P
|
P
|
R
|
P
|
P
|
5
|
días
|
|
|
Pruebas del prototipo
|
R
|
P
|
P
|
R
|
P
|
P
|
3
|
días
|
GP = Gerente de proyecto
CF = Consultor funcional
US = Usuario
AS = Arquitecto de sistemas
AP = Analista programador
PR = Programador
DG = Diseñador gráfico
|
R = Responsable
P = Participa
C = Es consultado
I = Es informado
D = Está disponible
S = Da apoyo
|
Tareas
|
CF
|
US
|
AS
|
AP
|
GP
|
DG
|
Duración
|
Unidad
|
||
---|---|---|---|---|---|---|---|---|---|---|
Desarrollo e implantación del portal
ción del portal
|
|
|
|
|
|
|
|
|
||
|
Diseño del portal
|
|
|
|
|
|
|
|
|
|
|
|
Análisis de requisitos
|
20
|
20
|
|
10
|
|
|
10
|
días
|
|
|
Especificación funcional
|
10
|
10
|
|
5
|
|
|
5
|
días
|
|
Diseño funcional
|
|
|
|
|
|
|
|
|
|
|
|
Diseño funcional de la estructura del portal
|
40
|
20
|
5
|
20
|
|
4
|
20
|
días
|
|
|
Diseño funcional de los productos y servicios
|
40
|
20
|
5
|
20
|
|
4
|
20
|
días
|
|
|
Diseño de los flujos de trabajo (content workflows)
|
40
|
20
|
5
|
20
|
|
1
|
20
|
días
|
|
|
Diseño de los procesos web
|
40
|
20
|
20
|
20
|
|
|
20
|
días
|
|
|
Diseño de la navegación
|
20
|
10
|
10
|
10
|
|
5
|
10
|
días
|
|
|
Diseño gráfico look and feel
|
10
|
5
|
5
|
5
|
|
20
|
20
|
días
|
|
Diseño técnico
|
|
|
|
|
|
|
|
|
|
|
|
Detalle de la arquitectura técnica y seguridad
|
4
|
2
|
20
|
10
|
|
|
20
|
días
|
|
|
Diseño técnico de especificaciones por servicio
|
20
|
10
|
10
|
70
|
2
|
2
|
35
|
días
|
|
|
Diseño de las interfaces
|
6
|
6
|
10
|
20
|
1
|
2
|
10
|
días
|
|
Lanzamiento prototipo
|
|
|
|
|
|
|
|
|
|
|
|
Construcción del prototipo
|
5
|
1
|
5
|
10
|
10
|
5
|
5
|
días
|
|
|
Pruebas del prototipo
|
3
|
3
|
3
|
6
|
6
|
3
|
3
|
días
|
GP = Gerente de proyecto
CF = Consultor funcional
US = Usuario
AS = Arquitecto de sistemas
AP = Analista programador
PR = Programador
DG = Diseñador gráfico
|
|
|
4.5.Preparación del calendario definitivo
4.5.1.Calendario de hitos
Hito
|
Fecha
|
---|---|
1) La disponibilidad del entorno de desarrollo y de pruebas.
|
18 de marzo
|
2) La aprobación de especificaciones, la aprobación de los diseños funcionales y técnicos.
|
22 de abril
|
3) La aprobación del prototipo.
|
22 de abril
|
4) La aprobación del sistema en el entorno de pruebas.
|
27 de mayo
|
5) La aceptación en el entorno de producción.
|
1 de julio
|
6) La aprobación de la formación completa de usuarios y la documentación técnica de
operación del sistema.
|
1 de julio
|
7) El arranque de la nueva plataforma de portal.
|
7 de julio
|
4.5.2.Calendario completo
M. Andrés Gay; E. Yebes López (2007). Project 2007. Madrid: Anaya Multimedia
5.Planificación de costes
-
La base u objetivo de la medición. Lo más habitual y recomendable es hacerlo al nivel de las EDT, o sea, de las partes o paquetes de trabajo en que hemos dividido el proyecto. Es frecuente y recomendable establecer una cuenta de coste, al menos interna, por EDT, a la que se irán 'cargando' los costes reales incurridos.
-
Una segunda decisión es hasta qué nivel de descomposición llegamos (grupos de actividades, actividades, tareas...), que dependerá principalmente de la experiencia de la organización (y de lo bien que estén documentadas sus 'bases de conocimiento') o del jefe de proyecto o de la clase de trabajo. En todo caso, mientras que la planificación de alcance tiene una visión más estratégica y de arriba abajo (top-down), la planificación de tiempos y costes tiene una dimensión más operativa y táctica y de abajo arriba (bottom-up).
-
Las unidades de medida, que dependen del tipo de recurso. En el caso de los recursos humanos, normalmente se adjudica un coste, precio o tarifa objetivo por unidad de tiempo (hora, día, semana) por persona. En el caso de recursos técnicos, es recomendable disponer de las tarifas o listas de precios para las estimaciones iniciales, y solicitar de varios proveedores su mejor presupuesto.
-
El nivel de precisión de las estimaciones, u orden de magnitud (rough order of magnitude, o ROM), que acostumbra a ser muy alto al comienzo del proyecto (¡de hasta un 50%! en la etapa de iniciación) y se va acotando a medida que el proyecto avanza (entre un 10% y un 20% cuando se prepara el Plan de costes).
-
El nivel de reservas o contingencias necesario para cubrir las incertidumbres (los riesgos) del proyecto. Puede variar de un proyecto a otro, en función del plan de riesgos establecido, al que dedicamos otro apartado en este módulo.
-
Los umbrales de desviación o variaciones aceptables sobre la línea base de coste, fuera de los cuales deberemos hacer sonar alarmas y tomar decisiones mayores respecto al tiempo, alcance, calidad, etc.
-
Los formatos de presentación del presupuesto y de los informes o reporting internos y al cliente, que dependen del tipo de organizaciones (la nuestra y la del cliente) para las que trabajamos.
-
La estimación de costes de proyecto debería cubrir TODOS los costes en los que se incurrirá, también los costes de calidad, comunicación, formación del equipo, etc.
-
La estimación de costes también debería cubrir los costes en los que incurrirá el cliente por causa del proyecto o, al menos, presentarlos en el capítulo de asunciones y limitaciones de la definición de alcance.
-
Los costes de un proyecto (en especial, si incluye el desarrollo o instalación de un producto) deberían incluir todos los costes presentes y FUTUROS, incluidos los de mantenimiento, evolución, formación, etc., en definitiva, lo que se conoce como coste total de la propiedad (total cost of ownership).
1) La utilización de modelos algorítmicos que dan una estimación del coste en función
de un número determinado de variables que influyen en el mismo.
2) El juicio experto en proyectos similares, que aprovecha la opinión de profesionales
que han liderado proyectos similares.
3) La analogía con otro proyecto parecido que sea comparable con el que se plantea.
4) La utilización de los recursos disponibles, en la cual lo que limita el coste es
el volumen de recursos de los que se dispone en cada etapa.
5) El precio ganador, en el que la estimación de los costes no se realiza en función
de las cargas de trabajo, sino de las condiciones del mercado y la competencia.
6) La estimación global descendente (top-down), en la que se intenta fijar un coste general del proyecto a partir de sus características
principales (tamaño, complejidad, dificultad técnica, calidad y fiabilidad, etc.).
7) La estimación ascendente a partir de la desagregación de las actividades en tareas.
|
5.1.El presupuesto
![Figura 11. Formato de presentación de un presupuesto](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_11.gif)
6.Planificar la calidad
![Figura 12. El coste de la calidad](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_12.gif)
-
La misión, objetivos, alcance y enfoque de calidad dentro del proyecto.
-
La organización. Todo el mundo es responsable de la calidad, pero unas personas pueden tener un papel especial de seguro o verificación dentro o fuera del equipo de trabajo y también por parte del cliente (usuarios, personal técnico, etc.).
-
Los procesos de seguro, seguimiento y control de la calidad, en especial los mecanismos de pruebas (testing) de los que hablaremos a continuación, y los mecanismos de no conformidad y corrección.
-
Las métricas o unidades de medición que hay que utilizar en cada caso.
|
|
|
|
|
|
|
|
|
|
|
-
Norma ISO 9126 (1991). Software Engineering Product Quality
-
Norma ISO 12207 (1996). Software Life Cycle Processes
-
Norma ISO 9001 (2000). Quality Management System
7.Planificar los riesgos
![Figura 13](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_13.gif)
7.1.Planificar la gestión de los riesgos
-
Metodología a utilizar.
-
Roles y responsabilidades de los miembros del equipo hacia los riesgos.
-
Presupuesto, recursos destinados a la gestión.
-
Calendario, cada cuándo se revisarán los riesgos a lo largo de la vida del proyecto.
-
Categorías o grupos de riesgos, que servirán para realizar una sistemática identificación de éstos.
-
Normas sobre cómo calcular la probabilidad e impacto, que servirán para objetivizar en alguna medida la forma en que el director de proyecto evaluará los riesgos.
-
Normas sobre la matriz de probabilidad e impacto, cómo ubicar cada riesgo, cuáles considerar, etc.
-
Tipo de tolerancias permitidas.
-
Plantillas para los informes de riesgos.
-
Métodos de seguimiento y control.
7.2.Identificar los riesgos
-
Estimaciones de coste: con respecto a las probabilidades de cumplimiento y las limitaciones de presupuesto.
-
Estimaciones de tiempo: con respecto a las probabilidades de cumplimiento o no de fechas.
-
Ámbito: Empezando por las hipótesis del proyecto, que son una fuente importante de riesgo, también los entregables y los paquetes de trabajo (EDT) pueden ser fuente de riesgos en función de la capacidad para definir claramente el trabajo, y las probabilidad de que aparezcan cambios en el alcance del proyecto.
-
Interesados, especialmente claves para la definición del alcance.
-
Planes de gestión de costes, cronograma, calidad, con respecto a determinadas exigencias o márgenes que los planes pueden aportar.
-
Recursos: cantidad, calidad, disponibilidad, responsabilidad, etc. de los recursos asignados al proyecto.
-
Documentación del proyecto.
|
7.3.Realizar el análisis cualitativo de riesgos
![Figura 14. Matriz de valoración cualitativa de riesgos](http://materials.cv.uoc.edu/daisy/Materials/PID_00215815/html5/img/76527_m4_14.gif)
7.4.Realizar el análisis cuantitativo de riesgos
7.5.Planificar la respuesta a riesgos
-
Evitar, cambiando el plan del proyecto de manera que se elimine la amenaza.
-
Transferir, en este caso no se elimina el riesgo, se encarga a una tercera persona o a una organización el hacerle frente.
-
Mitigar, sean acciones preventivas para mitigar la probabilidad de que pase, o de contingencia para mitigar el impacto.
-
Aceptar, cuando no es posible diseñar respuestas efectivas o éstas no son rentables.
-
Explotar, para asegurarse de que la oportunidad se hará efectiva, modificando el plan del proyecto.
-
Compartir, de forma que a un tercero, más preparado para hacerlo, se le asigna todo o una parte de la oportunidad.
-
Mejorar, de modo que se actúa sobre la probabilidad o el impacto, para incrementar lo que efectivamente ocurra, o el beneficio cuando pase.
-
Aceptar, cuando no se hacen acciones concretas pero se tienen en cuenta por si finalmente sucede.
-
Posibles reasignaciones de recursos a las áreas de mayor riesgo.
-
Variaciones en el plan de actividades, en particular desvincular actividades del camino crítico.
-
Variaciones en el plan de hitos.
-
Incremento de los recursos.
-
Posibles variaciones en el alcance.
-
Variaciones en la fecha de entrega del producto final.
8.Otros componentes de la planificación
-
recursos humanos,
-
comunicación y gestión de interesados,
-
administración de compras y contratos.