Suponiendo que existe un riesgo operativo de TI, como la falta de copias de seguridad durante la entrega de una solución, ¿se consideraría un riesgo del proyecto y, de ser así, cómo clasificaría los riesgos?
¿Tiene esto la capacidad de afectar la finalización exitosa de su proyecto? si es así, es un riesgo. No estoy seguro de que dividir los riesgos en "operativos" y "proyecto" me ayude a cerrar el proyecto con éxito. Un riesgo es cualquier cosa desconocida que podría afectar el cronograma, el costo, la calidad o el alcance de mi proyecto. La falta de copias de seguridad no es un riesgo per se. La ausencia de copias de seguridad significa que:
Dado que no hay copias de seguridad SI ocurre un evento que degrada o destruye cualquiera de mis datos, ENTONCES podría perder una cantidad predecible de tiempo/esfuerzo/recursos para remediar la interrupción. En algunos casos, esto podría resultar en el fracaso total de mi proyecto. La probabilidad de una interrupción se cuantifica fácilmente, la cantidad de tiempo dedicado a la remediación es relativamente fácil de predecir. El costo de hacer copias de seguridad es predecible y relativamente pequeño. Por lo tanto, mi plan de mitigación es imponer copias de seguridad.
Dado que mi personal de TI está ignorando las mejores prácticas simples en respaldo, SI están ignorando otras mejores prácticas ENTONCES mi capacidad para ejercer el control de mi proyecto se ve significativamente disminuida. Los planes de mitigación deben incluir un análisis de por qué el personal de TI está ignorando las copias de seguridad y qué otros procedimientos son defectuosos y qué impacto podría tener esto. Este es un ejemplo de un riesgo en el que el análisis de riesgos reduce significativamente el riesgo.
Nunca he sido fanático de clasificar los riesgos. La gestión de riesgos no es una meta, es una herramienta para ayudar a cerrar el proyecto con éxito. Elimina todo lo que no ayude a cerrar el proyecto.
En mi opinión, la forma de pensar sobre esto es que los riesgos en el Registro de riesgos del proyecto se relacionan con el riesgo de los objetivos del proyecto. En otras palabras, cosas que podrían suceder que le impidan entregar el proyecto a tiempo, costo y calidad y particularmente en contra de los criterios de aceptación.
Entonces, en su caso (¡dependiendo de cuál sea realmente su proyecto!), la falta de copias de seguridad operativas no sería un riesgo para el proyecto. En realidad, la "falta de copias de seguridad" no es un riesgo en absoluto, es una descripción de una situación y debe expresarse "Debido a la falta de copias de seguridad operativas, existe el riesgo de [algún efecto o consecuencia]".
Habiendo dicho todo eso, parte de un proyecto de entrega de software generalmente es para asegurar el soporte posterior a la producción y el traspaso operativo. Si la falta de copias de seguridad operativas pudiera comprometer ese lado de la entrega, entonces podría ser un riesgo del proyecto...
Tanto Marv como Mark tienen excelentes respuestas para esto, pero quiero agregar algo sobre la clasificación de riesgos. Estoy de acuerdo con Mark en que la gestión de riesgos no es el fin sino el medio para lograr un fin y mantenerlo simple y directo son dos grandes reglas; sin embargo, la clasificación de riesgos y otras reglas de documentación de riesgos más formales pueden no ayudar a su proyecto actual, pero son excelentes aportes para proyectos FUTUROS y lecciones aprendidas y tal vez incluso se conviertan en proyectos en sí mismos. Por lo tanto, según el tamaño y la complejidad de su proyecto actual y los planes para proyectos futuros, la creación de políticas de gestión de riesgos más formales, que es un costo, puede ser útil para la organización a largo plazo.
Clasificaría este riesgo tal vez como "operativo", "proceso" o "política".
motivado