Ir al contenido principal

Desarrollo de Software: Administración de Riesgos en proyectos de TI

¿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

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 severidad del riesgo será determinada por la multiplicación del valor asignado a la probabilidad de que ocurra y del potencial impacto que pueda tener en el alcance, tiempo, costo y/o calidad.
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.



Entradas más populares de este blog

Desarrollo de Software: EDT (Estructura de desglose de trabajo) o WBS (Work Breakdown Structure)

Definición La EDT es una descomposición jerárquica-orientada a los entregables del proyecto- de los trabajos que ejecutara  el equipo de trabajo, para crear los productos requeridos. Es un paso muy importante en la definición del alcance de un proyecto.
La EDT organiza y define el alcance total del proyecto, mediante la subdivisión de trabajo en piezas más pequeñas y manejables. En cada nivel inferior de la estructura se tiene un incremento en el detalle de los trabajos del proyecto.
El trabajo incluido en el nivel más bajo de la WBS se le denomina paquetes de trabajo, los cuales pueden ser programados, monitoreados y supervisados.

Principios Básicos de una EDT Una unidad de trabajo deberá aparecer en un solo lugar en la EDT .El contenido del trabajo de un elemento de la EDT es la suma de los elementos inferiores.Un elemento de la EDT es responsabilidad de una sola persona , a pesar de que muchas personas pueden estar trabajando en él.El EDT debe ser coherente con la forma en que el tra…

SOFTWARE TESTING (QA DESARROLLO SOFTWARE)

Definición.El área de Pruebas del Software tiene como finalidad el evaluar un atributo o capacidad de un programa o sistema (Requerimientos de Calidad) y determinando que este cumpla con los resultados esperados (Requerimientos Funcionales), mediante el seguimiento de una metodología, procesos y herramientas especiales, durante el proceso del desarrollo del software.
La práctica de Software Quality Services de TASISOFTware tiene como objetivo ayudar a las empresas a: Implementar y mejorar sus circuitos de calidad para minimizar el riesgo de interrupción del negocio.Acelerar los procesos de pruebas.Identificar y corregir las deficiencias en la metodología vigente.Maximizar la calidad de las aplicacionesAumentar la velocidad de la puesta en producción de las mismas.
Nuestros servicios de Calidad, se fundamentan en cuatro pilares: Planeación y Administración de la CalidadPruebas FuncionalesPruebas No FuncionalesControl y MonitoreoPlaneación y Administración de la Cal…

Arquitectura Básica de un Data Warehouse

Concepto Data Warehousing
Data warehousing soporta el procesamiento informático al proveer una plataforma sólida, a partir de los datos históricos para hacer el análisis. Facilita la integración de sistemas de aplicación no integrados. Organiza y almacena los datos que se necesitan para el procesamiento analítico, informático sobre una amplia perspectiva de tiempo.
Un Data Warehouse o Depósito de Datos es una colección de datos orientado a temas, integrado, no volátil, de tiempo variante, que se usa para el soporte del proceso de toma de decisiones gerenciales.
Se puede caracterizar un data warehouse haciendo un contraste de cómo los datos de un negocio almacenados en un data warehouse, difieren de los datos operacionales usados por las aplicaciones de producción.
Base de Datos Operacional Data Warehouse Datos Operacionales Datos del negocio para Información Orientado a la aplicación Orientado al sujeto Actual Actual + histórico Detallada Detallada + más resumida Cambia continuamente E…