Cuando nos enfrentamos a proyectos de tecnología que van mas allá del desarrollo de software y usar técnicas como SCRUM, se hace necesario poder identificar RIESGOS.

Para continuar la primera pregunta que deberías hacerte es:

¿Por que debo gestionar los riesgos del proyecto?

Esto con el objetivo de identificar valor por que tomara tiempo y recursos… además pocos se interesan en los riesgos. Lo que si te puedo compartir son algunos que he venido identificando:

• Ayuda a ser proactivos y no reactivos.
• aumenta la probabilidad de éxito del proyecto.
• mejora la calidad del proyecto.
• evita cometer los mismos errores.
• minimiza cambios, retrasos y sobre costos por riesgos.
• comprender la causa de los riesgos.

Pueden existir muchos mas, dependiendo de tu experiencia y participación en proyectos tendrás la habilidad para poder identificar beneficios de esta gestión de riesgos.

Cada integrante de un equipo, puede tener interpretaciones diferentes de riesgo; los pueden considerar buenos, malos, positivos, negativos y de otras formas. Aqui es donde se tiene que interiorizar una definición para tener un entendimiento común, en este caso mostrare la del PMBOOK

“un riesgo de un proyecto es “un evento o condición incierta, que si ocurre, afecta negativa o positivamente a uno o más de los objetivos del proyecto”

Estos objetivos esta directamente relacionados con:

• costo
• tiempo
• calidad
• alcance

Otra definición similar:

ISO 31000: “riesgo es el efecto de la incertidumbre sobre los objetivos”.

La mayoría considera que un riesgo es negativo y el positivo se traduce en oportunidades.

El riesgo negativo responde a ¿qué puede salir mal?, y el riesgo positivo responde a ¿qué oportunidades hay?

(Eso te lo dejo para la reflexión …)

Algunos riesgos típicos en proyectos de tecnología:

• Tecnología no probada.
• Cumplimiento con la arquitectura y normas tecnológicas.
• No estar alineado con estándares técnicos o arquitectura.
• Claridad de alcances y entregables.
• Disponibilidad del personal capacitado para hacer el proyecto.
• Disponibilidad de las TI.
• No alineación con las estrategias o políticas comerciales.
• Apego a las políticas de seguridad.
• Dependencias que el equipo del proyecto no controla.