¿Qué
es RIESGO?
Riesgo en los negocios es...
“El nivel de exposición a la incertidumbre que la empresa
debe de entender y manejar efectivamente para ejecutar sus estrategias para
lograr sus objetivos y además crear valor”
Riesgo en proyecto es...
“Un evento o acción que si ocurre (puede no ocurrir), tendrá
un efecto negativo o positivo sobre el proyecto”.
Riesgo en actividades de decisión...
Es causado por falta de conocimiento preciso sobre las
condiciones futuras de los negocios, desarrollos de la tecnología, fondos en
los proyectos, etc.
El riesgo tiene 3 elementos:
- Evento.
- Probabilidad.
- Cantidad a
arriesgar.
¿Qué
nos permite la Gestión de Riesgos en la práctica?
• Generar conciencia de que existe el riesgo y que debe ser gestionado
• Alinear e integrar al equipo de proyecto con respecto a las respuestas al riesgo
• Detectar más riesgos, e identificar a los responsables de alertar sobre los disparadores
• Evaluar mejor los riesgos
• Estar mejor preparado ante la activación de los riesgos
• Tener un plan de proyecto más sólido
• Generar conciencia de que existe el riesgo y que debe ser gestionado
• Alinear e integrar al equipo de proyecto con respecto a las respuestas al riesgo
• Detectar más riesgos, e identificar a los responsables de alertar sobre los disparadores
• Evaluar mejor los riesgos
• Estar mejor preparado ante la activación de los riesgos
• Tener un plan de proyecto más sólido
Técnica de Identificación del Riesgo.
•
Lluvia de
ideas.
•
Análisis
FODA (SWOT).
•
Revisión
de Documentos.
•
Técnica
de los 6 sombreros.
•
Técnica
Delphi.
•
CSM
(Crawford Slip Method).
•
Listas de
verificación (Check lists).
Administración de Riesgos.
A
lo largo de la vida de los proyectos, se tienen que administrar los riesgos,
los riesgos identificados deberán ser registrados en el repositorio de cada
proyecto.
Es
responsabilidad del Administrador de Proyectos actualizar la herramienta de
administración de proyectos en la parte de administración de riesgos al momento
de que un riesgo es identificado por cualquier persona del equipo de trabajo.
Antes de iniciar el análisis de riesgos el equipo de
trabajo y el administrador de proyectos deben de revisar este documento y
validar la política de administración de riesgos. Si por las características
del proyecto el equipo de trabajo llega al acuerdo de modificar algunos de los
parámetros especificados en la política,
se debe de documentar el cambio y la razón del cambio en la sección de
Estrategia de Administración de Riesgos en el Plan Integral de Proyectos.
El análisis de riesgos se debe de
hacer desde el inicio del proyecto, el administrador de proyectos debe de
coordinar actividades propias para analizar e identificar riesgos desde el
inicio del proyecto, esto se hace en la parte de requerimientos iniciales y en
la planeación del proyecto así como también debe de coordinar las actividades
necesarias para que en conjunto con el equipo de trabajo determinen el impacto
y la probabilidad de ocurrencia de los riesgos identificados y donde validen
según la estrategia de administración de riesgos si se requieren planes de
mitigación y contingencia para cada uno de los riesgos identificados.
Dentro de este análisis inicial
de riesgos el administrador de proyecto en conjunto con el equipo de trabajo
debe de revisar los riesgos organizacionales para determinar si aplican o no al
proyecto. Si alguno aplica se debe de registrar en la herramienta de
administración de riesgos, se debe de especificar su impacto y probabilidad de
ocurrencia y se debe de obtener el nivel de criticidad. Con esta información se
debe de revisar si el riesgo según la estrategia requiere plan de mitigación y
contingencia, deben de revisar si los
planes propuestos en el documento de riesgos organizacionales aplican para el
proyecto, si aplican el administrador de proyectos debe de documentarlos en la
herramienta, si no aplican deben de desarrollar los planes para el riesgo.
Durante el monitoreo del
proyecto, se detecta un riesgo este debe de ser comunicado inmediatamente al
administrador de proyectos (puede ser de forma verbal o por mail) y este debe
de agregarlo a la herramienta de administración de riesgos poniendo la fecha y
la persona que detecto el riesgo.
El riesgo debe de ser revisado a
mas tardar en la siguiente junta de avances y junto con el equipo de trabajo se
deben de determinar los parámetros del riesgos y se deben de especificar los
planes de mitigación y contingencia si según la estrategia se requiere.
Los riesgos deben de ser
revisados dentro de las juntas de avance que se tiene como parte de las
actividades de monitoreo y control.
Para cada plan de mitigación debe
de existir un responsable de ejecutar el plan de mitigación y se debe de
registrar desde que se especifico el plan de mitigación la fecha o las fechas
en que se planea ejecutar el plan de mitigación, esta actividad se debe de
registrar en la lista de pendientes como origen del pendiente de “Riesgos”.
Durante las juntas de avance como parte de monitoreo y control en la
sección de monitoreo de riesgos se deben de revisar las actividades pendientes
con origen riesgos y se deben de registrar el avance que se haya tenido en las
actividades asociadas a riesgos.
Si el riesgo fue mitigado debe de cambiarse su estatus a mitigado de igual
forma si ya no hay probabilidad de ocurrencia debe de ponerse como cerrado.
Si el riesgo se presenta se debe poner la actividad en la lista de
pendientes de la persona responsable de ejecutar el plan de contingencia para
su posterior monitoreo.
Análisis de Riesgos.
Especifica como
serán analizados los riesgos para determinar los más importantes en impacto y
probabilidad.
La técnica a
utilizar para el análisis de riesgo consiste en determinar la Severidad. La
La severidad
tendrá tres clasificaciones:
Severidad
|
Estado
|
Valor Obtenido
del Producto (Probabilidad x Impacto)
|
Muy Alto
|
Rojo
|
Mayor o Igual
13
|
Alto
|
Naranja
|
Menor a 13 y Mayor o igual a 9
|
Moderado
|
Amarillo
|
Menor a 9 y Mayor o igual a 5
|
Bajo
|
Verde
|
Menor a 5 y
Mayor o igual a 3
|
Muy Bajo
|
Azul
|
Menor a 3 y
Mayor o igual a 1
|
La probabilidad
de ocurrencia será definida con una escala de
1 a
5 y el Impacto en Alcance, Costo, Tiempo ó Calidad será definida en una escala
de 1 a 5.
Dichos criterios deberán ser llenados bajo un juicio de expertos.
Especifica la
relación Riesgos analizados por el método de Severidad y ordenados por la posición que ocupan de mayo a menor.
Rank
|
Riesgo
|
Probabilidad (P),
Impacto (I),
Severidad (P x I)
|
|||
Evento
|
Consecuencia
|
(P)
|
(I)
|
(P
x I)
|
|
Identificar y definir las acciones (Como aceptación, Transferencia,
evitación ó mitigación) para responder al riesgo que se tenga identificado,
manejando atender de forma definitiva a los riesgos más altos. Adicionalmente
se debe identificar el responsable de la acción, el responsable y la acción a
realizar como plan de contingencia.
Evento Riesgo
|
|
Id Riesgo
|
|
Accción de Respuesta
|
|
Descripción de la Respuesta
|
|
Responsible de la Respuesta
|
|
Fecha de Identificación
|
|
Plan de Contingencia
|
|
Responsible Contingencia
|
Ejemplos de Riesgos.
En las siguientes lista se presentan algunos de los riesgos identificados de forma inicial en un Proyecto:
Administración del proyecto.
1.
Omisión,
No comunicación o Mala Calidad de los Planes del proyecto.
2.
Omisión
ó Desvíos del proceso de Control de Cambios.
3.
Debilidad
en la aplicación del proceso de Auditorias y revisión de avances.
4.
No
aplicación del Plan de Comunicación.
5.
Definición
imprecisa de tareas clave o ejecución errónea de las mismas.
6.
Debilidad
en la aplicación de la metodología para el control del proyecto.
7.
No
administración de la configuración de todos los entregables en el proyecto.
8.
Asignación
de recursos que no esté alineada con los roles que en cada caso se deben
desempeñar.
9.
Cambios
en el alcance del proyecto sin un proceso de control de cambios.
10.
Entregas
fuera de tiempo de las aprobaciones de documentos y demás entregables del proyecto que requieran pasar
por el proceso de validación y aprobación.
Ciclo de Vida del Proyecto.
1.
Aprobación
y desarrollo con ambigüedades, sin limitaciones claras y sin exactitud de
especificaciones en los entregables de Análisis del Negocio, Identificación de
Requerimientos, Casos de Uso, Reglas de Negocio, Casos de Prueba y Documentos
de Diseño.
2.
Construcción
fuera de estándares.
3.
Diseño
inadecuado de la aplicación que genere bajo performance, con limitantes y/o
proporcione resultados inesperados en la explotación de los datos.
4.
Evidencias
de pruebas incompletas o no existentes en la fase de construcción.
5.
Casos
de Prueba no alineados a los criterios de aceptación del usuario o no dictados
por ellos.
6.
Aplicación
ineficiente o incompleta en la etapa de certificación de pruebas del usuario.
7.
Omisión
de puntos en el proceso de Check-list de liberación.
8.
Omisión
de ambiente de desarrollo.
9.
Omisión
de un ambiente de Pruebas para Aseguramiento de la calidad.
Datos.
1. Mala Calidad de los datos maestros cuya corrección (o procedimiento de
corrección) no sea gestionada antes del inicio de operación.
2.
Errores
u omisiones en las reglas de homologación en los archivos origen.
3.
Tiempo
insuficiente dedicado a la limpieza y validación de datos.
4.
Falta
de previsión de qué componentes de información del mercado cambien y en
consecuencia puedan alterar partes ya construidas en el sistema.
5.
Cambios
en los layouts o reglas contenidas en los orígenes de datos.
6.
Mala
calidad en las cifras control.
7.
Entregas
fuera de tiempo de los archivos origen e información en general.
8.
Errores
en la definición de reglas de negocio
para la transformación y carga de los datos por parte de los usuario clave.
Infraestructura / HW / SW.
1.
Retraso
o imprecisiones en la Compra
y configuración de Hardware y su integración a la infraestructura existente en
caso de requerir nuevo hardware.
2.
Dimensionamiento
inadecuado de las capacidades de la infraestructura vs. los volúmenes
información y la oportunidad / frecuencia en que se requieren los resultados.
3.
Administración
no optima en el performance de la base de datos.
4.
Cantidad
de licencias inadecuado para el desarrollo del sistema.
5.
Uso
de tecnologías de software no adecuadas para procesos de tipo Inteligencia de
Negocios.
Recursos.
1.
Tiempo
insuficiente dedicado a la limpieza y validación de datos.
2.
Falta
de disponibilidad por parte de los USUARIOS para proporcionar / validar datos o
documentación.
3.
Conflicto
de recursos en caso de que módulos del proyecto involucren a los mismos
usuarios, tanto por parte de negocio como por parte de IS.
4.
Eficiencia
en la aplicación de la comunicación en el proyecto.
5.
Definición
de autoridad en el Gerente del Proyecto sobre el Proyecto.
6.
Renuncia
ó ausencia por enfermedad y/o causas mayores de algún participante en el
proyecto.