Definición: La identificación de riesgos es el proceso de determinación de riesgos que podrían impedir que el programa, la empresa o la inversión alcancen sus objetivos. Incluye documentar y comunicar la preocupación.
Palabras clave: riesgo, identificación de riesgos, gestión de riesgos
Roles de MITRE SE & Expectativas: Se espera que los ingenieros de sistemas de MITRE (SEs) que trabajan en programas gubernamentales identifiquen riesgos que podrían afectar el proyecto y el programa. Se espera que escriban y revisen declaraciones de riesgo que sean claras, inequívocas y respaldadas por evidencia.
Antecedentes
La identificación de riesgos es el primer paso crítico del proceso de gestión de riesgos descrito en la Figura 1.
El objetivo de la identificación de riesgos es la identificación temprana y continua de eventos que, si ocurren, tendrán un impacto negativo en la capacidad del proyecto para alcanzar los objetivos de rendimiento o capacidad de resultados. Pueden proceder de dentro del proyecto o de fuentes externas.
Hay varios tipos de evaluaciones de riesgo, incluidas evaluaciones de riesgo de programas, evaluaciones de riesgo para respaldar una decisión de inversión, análisis de alternativas y evaluaciones de incertidumbre operativa o de costos. La identificación de riesgos debe coincidir con el tipo de evaluación requerida para apoyar la toma de decisiones basada en el riesgo. Para un programa de adquisición, el primer paso es identificar las metas y objetivos del programa, fomentando así un entendimiento común en todo el equipo de lo que se necesita para el éxito del programa. Esto da contexto y limita el alcance mediante el cual se identifican y evalúan los riesgos.
Identificación de riesgos en el Programa de Ingeniería de Sistemas
Hay múltiples fuentes de riesgo. Para la identificación de riesgos, el equipo del proyecto debe revisar el alcance del programa, las estimaciones de costos, el cronograma (para incluir la evaluación de la ruta crítica), la madurez técnica, los parámetros clave de rendimiento, los desafíos de rendimiento, las expectativas de las partes interesadas frente al plan actual, las dependencias externas e internas, los desafíos de implementación, la integración, la interoperabilidad, la compatibilidad, las vulnerabilidades de la cadena de suministro, la capacidad para manejar amenazas, las desviaciones de costos, las expectativas de eventos de prueba, la seguridad, la seguridad y más. Además, los datos históricos de proyectos similares, las entrevistas con las partes interesadas y las listas de riesgos proporcionan información valiosa sobre las áreas para considerar el riesgo.
La identificación de riesgos es un proceso iterativo. A medida que el programa avance, se obtendrá más información sobre el programa (por ejemplo, diseño específico) y la declaración de riesgos se ajustará para reflejar el entendimiento actual. Se identificarán nuevos riesgos a medida que el proyecto avance a lo largo de su ciclo de vida.
Mejores prácticas y experiencia adquirida
Riesgo operacional. Comprenda la naturaleza operativa de las capacidades que está apoyando y el riesgo para los usuarios finales, sus misiones y sus operaciones de las capacidades. Comprender la necesidad/misión operativa (consulte el tema de Desarrollo de conceptos de la Guía de Ingeniería de Sistemas) le ayudará a apreciar la gravedad de los riesgos y el impacto que podrían tener para los usuarios finales. Esta es una parte crítica del análisis de riesgos, es decir, comprender el impacto en el mundo real que puede ocurrir si surge un riesgo durante el uso operativo. Por lo general, los usuarios operativos están dispuestos a aceptar algún nivel de riesgo si son capaces de cumplir su misión (por ejemplo, garantía de misión), pero usted necesita ayudar a los usuarios a comprender los riesgos que están aceptando y evaluar las opciones, saldos y alternativas disponibles.
madurez Técnica. Trabajar y aprovechar la industria y el mundo académico para comprender las tecnologías que se consideran para un esfuerzo y la probable transición de la tecnología a lo largo del tiempo. Un enfoque es trabajar con los proveedores en virtud de un acuerdo de confidencialidad para comprender las capacidades y hacia dónde van, de modo que se pueda evaluar el riesgo.
Elementos no relacionados con el desarrollo (NDI). NDI incluye artículos comerciales listos para usar y gubernamentales listos para usar. Para gestionar el riesgo, considere la viabilidad del proveedor de NDI. ¿El proveedor tiene cuota de mercado? ¿El proveedor tiene una longevidad adecuada en comparación con sus competidores? Cómo aborda el proveedor los problemas de capacidad y las correcciones de versiones, etc.? ¿Cuál es la base de usuarios para el NDI en particular? ¿Puede el proveedor demostrar el NDI, preferiblemente en un entorno similar al de su cliente? ¿Puede el gobierno utilizar el NDI para crear un prototipo? Todos estos factores ayudarán a evaluar el riesgo de la viabilidad del NDI y del proveedor. Busque respuestas a estas preguntas de otro personal de MITRE que haya trabajado en el área o que haya utilizado el NDI que se está evaluando.
Controladores de adquisición. Enfatice los facilitadores de capacidad críticos, en particular los que tienen alternativas limitadas. Evaluar y determinar los principales impulsores de una adquisición y enfatizar su riesgo asociado en la formulación de recomendaciones de mitigación de riesgos. Si un aspecto particular de una capacidad no es crítico para su éxito, se debe evaluar su riesgo, pero no es necesario que sea el enfoque principal de la gestión de riesgos. Por ejemplo, si existe un riesgo para una interfaz de usuario propuesta, pero el mercado tiene numerosas alternativas, el éxito del enfoque propuesto es probablemente menos crítico para el éxito general de la capacidad. Por otro lado, es probable que una característica de seguridad de la información sea crítica. Si sólo un enfoque alternativo satisface la necesidad, debe hacerse hincapié en él. Determine los principales impulsores del éxito evaluando las necesidades y los diseños, y determinando las alternativas que existen. ¿Está una solución única en el camino crítico hacia el éxito? Asegúrese de que los análisis de ruta crítica incluyan todo el ciclo de ingeniería del sistema y no solo el desarrollo (es decir, el desarrollo del sistema, en sí, puede ser «pan comido», pero el despliegue en una situación operativa activa puede ser un riesgo importante).
Utilice la evolución de la capacidad para gestionar el riesgo. Si los requisitos particulares impulsan la implementación de capacidades que son de alto riesgo debido a un desarrollo único, necesidades de rendimiento al borde de la envoltura, etc., los requisitos deben ser discutidos con los usuarios por su criticidad. Es posible que la necesidad se posponga y que la comunidad de desarrollo evalúe cuándo podría satisfacerse en el futuro. Ayude a los usuarios y desarrolladores a medir el riesgo (y el impacto de costos y programación) que una capacidad en particular debe asumir en comparación con los requisitos para recibir capacidades menos riesgosas antes. Al desarrollar sus recomendaciones, considere la viabilidad técnica y el conocimiento de los éxitos y fracasos de la implementación relacionados para evaluar el riesgo de implementarla ahora en lugar de en el futuro. Al aplazar las capacidades, tenga cuidado de no caer en la trampa de posponer el fracaso final negociando éxitos fáciles a corto plazo para un futuro de múltiples requisitos de alto riesgo que pueden ser esenciales para el éxito general.
Parámetros clave de rendimiento (KPPs). Trabajar en estrecha colaboración con los usuarios para establecer KPPs. El riesgo general de cancelación de programas puede centrarse en el incumplimiento de KPPs. Colaborar con los usuarios para asegurar que los parámetros respondan a las necesidades de la misión y sean técnicamente viables. Los parámetros no deben ser tan indulgentes que se puedan cumplir fácilmente, pero no deben satisfacer las necesidades de la misión; tampoco deben ser tan estrictos que no se puedan cumplir sin un gran esfuerzo o tecnología avanzada, cualquiera de los cuales puede poner en riesgo un programa. Busque resultados de operaciones anteriores, experimentos, evaluaciones de rendimiento e implementaciones de la industria para ayudar a determinar la viabilidad del rendimiento.
Dependencias externas e internas. Tener una perspectiva empresarial puede ayudar a los adquirentes, administradores de programas, desarrolladores, integradores y usuarios a apreciar el riesgo de las dependencias de un esfuerzo de desarrollo. Con la aparición de enfoques orientados a los servicios, un programa se volverá más dependiente de la disponibilidad y el funcionamiento de los servicios proporcionados por otros que tienen la intención de utilizar en los esfuerzos de desarrollo de su programa. Trabajar con los desarrolladores de servicios para garantizar que se están creando servicios de calidad, y se ha pensado en el mantenimiento y la evolución de esos servicios. Trabaje con el personal del programa de desarrollo para evaluar los servicios disponibles, su calidad y el riesgo que tiene un programa al usar y confiar en el servicio. Del mismo modo, existe un riesgo asociado con la creación del servicio y el no uso de servicios de otro esfuerzo empresarial. Ayude a determinar los riesgos y los beneficios potenciales de crear un servicio interno para el desarrollo con posiblemente una transición al servicio empresarial en algún momento futuro.
Integración e Interoperabilidad (I& I). I& Casi siempre será un factor de riesgo importante. Son formas de dependencias en las que se ha considerado que el valor de integrar o interoperar anula sus riesgos inherentes. Técnicas como la arquitectura de federación empresarial, las capacidades componibles bajo demanda y los patrones de diseño pueden ayudar al gobierno a planificar y ejecutar una ruta para navegar por los riesgos I&I. Consulte la sección de Ingeniería Institucional de la Guía de Ingeniería de sistemas para obtener artículos sobre técnicas para abordar los riesgos asociados a I&I.
Seguridad de la información. La seguridad de la información es un riesgo en casi todos los desarrollos. En parte, esto se debe a la singularidad de las necesidades y requisitos del gobierno en esta esfera. Parte de esto se debe a las dificultades inherentes para contrarrestar los ataques cibernéticos. Crear capacidades defensivas para cubrir el espectro de ataques es desafiante y arriesgado. Ayudar al gobierno a desarrollar enfoques de resiliencia (por ejemplo, planes de contingencia,respaldo / recuperación, etc.).). Permitir el intercambio de información entre sistemas en operaciones de coalición con socios internacionales presenta desafíos técnicos y cuestiones de política que se traducen en riesgos para el desarrollo. Los problemas de seguridad de la información asociados con la gestión de la cadena de suministro son tan amplios y complejos que incluso mantener una conciencia rudimentaria de las amenazas es un enorme desafío.
Nivel de habilidad. La habilidad o el nivel de experiencia de los desarrolladores, los integradores, el gobierno y otras partes interesadas pueden generar riesgos. Esté atento a las habilidades insuficientes y llegue a toda la corporación para llenar cualquier vacío. Al hacerlo, ayude a educar a los miembros del equipo gubernamental al mismo tiempo que está aportando habilidades y experiencia corporativas.
Riesgos de coste. Los programas generalmente crearán una estimación de costos del gobierno que considere el riesgo. A medida que desarrolla y refina los riesgos técnicos y de otro tipo del programa, las estimaciones de costos asociados también deben evolucionar. La estimación de costos no es una actividad de una sola vez.
Información histórica como guía para la identificación de riesgos. La información histórica de programas gubernamentales similares puede proporcionar información valiosa sobre los riesgos futuros. Busque información sobre desafíos y riesgos operativos en varias lecciones aprendidas de operaciones, informes posteriores a la acción, resúmenes de ejercicios y resultados de la experimentación. Los clientes a menudo tienen repositorios de estos para acceder. Los líderes gubernamentales normalmente comunicarán sus necesidades y desafíos estratégicos. Comprenda y tenga en cuenta estos factores en su evaluación de las capacidades más importantes que necesita su cliente y como base para las evaluaciones de riesgos.
Con frecuencia se dispone de datos históricos para ayudar a evaluar el riesgo a partir de evaluaciones de rendimiento pasadas y lecciones aprendidas de programas de adquisición y contratistas. En muchos casos, el personal de MITRE ayudará al gobierno a preparar información sobre la actuación profesional para una adquisición determinada. El AF tiene una Guía de Evaluación del Desempeño Anterior (PPEG, por sus siglas en inglés) que identifica el tipo de información a capturar que se puede usar para futuras selecciones de fuentes gubernamentales . Este repositorio de información puede ayudar a proporcionar información de antecedentes de problemas anteriores y de dónde podrían surgir de nuevo, tanto para el tipo particular de actividad de desarrollo como para los contratistas particulares.
Hay numerosas evaluaciones técnicas para productos de proveedores a las que se puede acceder para determinar el riesgo y la viabilidad de varios productos. Un repositorio MITRE de evaluaciones de herramientas es el Almacén de herramientas de análisis que contiene orientación y experiencia con herramientas analíticas. El uso de recursos como estos y la búsqueda de otros que hayan probado productos y técnicas en prototipos y experimentos pueden ayudar a evaluar los riesgos de un esfuerzo en particular.
Cómo escribir un riesgo a una práctica recomendada . Un protocolo de mejores prácticas para escribir una declaración de riesgo es la construcción Condición-Si-Entonces. Este protocolo se aplica a los procesos de gestión de riesgos diseñados para casi cualquier entorno. Es un reconocimiento de que un riesgo, por su naturaleza, es probabilístico y que, si se produce, tiene consecuencias no deseadas.
¿Qué es la construcción Condición-Si-Entonces? La condición refleja lo que se conoce hoy en día. Es la causa raíz del evento de riesgo identificado. Por lo tanto, la Condición es un evento que ha ocurrido, está ocurriendo actualmente, o ocurrirá con certeza. Los eventos de riesgo son eventos futuros que pueden ocurrir debido a la Condición presente. A continuación se muestra una ilustración de este protocolo.
El Fi es el evento de riesgo asociado con la Afección presente. Es de vital importancia reconocer el Fi y la Condición como un dual. Cuando se examina conjuntamente, puede haber formas de intervenir directamente o remediar la raíz (Condición) subyacente del evento de riesgo, de modo que las consecuencias de este evento, si ocurre, ya no amenacen el proyecto. El Fi es la porción probabilística de la declaración de riesgo.
El Then es la consecuencia, o conjunto de consecuencias, que afectarán al proyecto del sistema de ingeniería si se produce el evento de riesgo. En la Figura 2 se ilustra un ejemplo de una construcción de Condición-Si-Entonces.
Anime a los equipos a identificar los riesgos. La cultura de algunos proyectos y programas gubernamentales desalienta la identificación de riesgos. Esto puede deberse a que las actividades de gestión de riesgos de seguimiento, vigilancia y mitigación de los riesgos se consideran gravosas e inútiles. En esta situación, puede ser útil hablar con los equipos sobre los beneficios de identificar riesgos y la incapacidad de manejarlo todo en sus cabezas (p. ej., determinar la prioridad, quién debe participar, acciones de mitigación). Asistir a los equipos gubernamentales en la ejecución de un proceso que equilibre la inversión de gestión con el valor de los resultados del proyecto. En general, se logra un buen equilibrio cuando el alcance, el calendario y los objetivos de costos del proyecto se cumplen o se mitigan con éxito mediante planes de acción, y el equipo del proyecto cree que las actividades de gestión de riesgos proporcionan valor al proyecto. La representación entre equipos es una necesidad; los riesgos no deben ser identificados por un individuo, o estrictamente por el equipo de ingeniería de sistemas (revise las fuentes de riesgo anteriores).
Considere los factores organizacionales y ambientales. Los factores organizacionales, culturales, políticos y otros factores ambientales, como el apoyo de las partes interesadas o las prioridades de la organización, pueden representar tanto o más riesgo para un proyecto que los factores técnicos por sí solos. Estos riesgos deben ser identificados y mitigados activamente a lo largo de la vida del proyecto. Las actividades de mitigación podrían incluir el monitoreo de mandatos legislativos o cambios de emergencia que podrían afectar la misión del programa o proyecto, cambios organizacionales que podrían afectar las necesidades de los usuarios o la utilidad de la capacidad, o cambios en el apoyo político que podrían afectar la financiación. En cada caso, considere el riesgo para el programa e identifique opciones de acción para discutirlas con las partes interesadas. Para obtener información adicional, consulte el artículo Planificación de Mitigación de Riesgos, Implementación y Monitoreo de Progreso.
Incluir a las partes interesadas en la identificación de riesgos. Los proyectos y programas generalmente tienen múltiples partes interesadas que aportan varias dimensiones de riesgo a los resultados. Entre ellos figuran los operadores, que podrían verse abrumados por los nuevos sistemas; los usuarios, que podrían no estar debidamente capacitados o temer por sus puestos de trabajo; los supervisores, que podrían no apoyar una nueva capacidad porque parece disminuir su autoridad; y los encargados de formular políticas, que están preocupados por la aprobación legislativa y los costos. Además, es importante incluir a todas las partes interesadas, como las autoridades de certificación y acreditación que, si se pasan por alto inadvertidamente, pueden plantear riesgos importantes más adelante en el programa. Las partes interesadas pueden ser muy conscientes de varios factores ambientales, como la legislación pendiente o el apoyo a programas políticos que pueden plantear riesgos para un proyecto que son desconocidos para el gobierno o el equipo del proyecto MITRE. Incluir a las partes interesadas en el proceso de identificación de riesgos para ayudar a detectar estos riesgos.
Escriba declaraciones de riesgo claras. El uso del formato Condición si es entonces ayuda a comunicar y evaluar una declaración de riesgo y a desarrollar una estrategia de mitigación. La causa raíz es la Condición subyacente que ha introducido el riesgo (por ejemplo, un enfoque de diseño podría ser la causa), el Fi refleja la probabilidad (por ejemplo, la evaluación de la probabilidad de que ocurra la parte del Fi de la declaración de riesgo), y Luego comunica el impacto al programa (por ejemplo, mayores recursos para apoyar las pruebas, un calendario adicional y la preocupación por cumplir con el rendimiento). La estrategia de mitigación es casi siempre mejor cuando se basa en una declaración de riesgos claramente articulada.
Espere modificaciones en la declaración de riesgos a medida que se desarrolle la estrategia de evaluación y mitigación de riesgos. Es común refinar las declaraciones de riesgo una vez que el equipo evalúa el impacto. Al evaluar y documentar el impacto potencial del riesgo (costo, cronograma, técnico o cronograma), la comprensión y la declaración del riesgo pueden cambiar. Por ejemplo, al evaluar un impacto de riesgo de un error de programación de software, la declaración de riesgo podría perfeccionarse para incluir la fecha de caducidad necesaria y / o una aclaración adicional del impacto (por ejemplo, si el software xyz no se entrega en marzo de 2015, no habrá tiempo suficiente para probar los intercambios de interfaces antes de la Prueba Limitada del Usuario).
No incluya la declaración de mitigación en la declaración de riesgos. Tenga cuidado de no caer en la trampa de tener la declaración de mitigación introducida en la declaración de riesgo. Un riesgo es una incertidumbre con un posible impacto negativo. Algunos llegan rápidamente a la conclusión de la mitigación del riesgo y, en lugar de identificar el riesgo que debe mitigarse (con opciones de mitigación identificadas), identifican el riesgo como un enfoque de diseño subóptimo. Por ejemplo, una declaración de riesgo podría ser: Si el contratista no usa XYZ para la prueba, la prueba fallará. La preocupación es realmente la suficiencia de la prueba. Si el contratista no realiza la prueba con resultados medibles para su análisis, el programa puede no pasar la prueba limitada del usuario. El uso de XYZ puede ser una opción de mitigación para reducir el riesgo de suficiencia de la prueba.
No saltar a una estrategia de mitigación antes de evaluar la probabilidad de riesgo y el impacto. Un riesgo puede refinarse o modificarse con un análisis más detallado, lo que podría afectar a cuál puede ser la mitigación más eficiente/deseada. Los ingenieros a menudo se lanzan a la solución; lo mejor es pasar al siguiente paso discutido en el artículo Evaluación de Impacto de Riesgos y Priorización para descomponer y comprender el problema primero. En última instancia, esto conducirá a una estrategia que esté estrechamente alineada con la preocupación.
Referencias & Recursos
- El Instituto MITRE, 1 de septiembre de 2007, Modelo de Competencias de Ingeniería de Sistemas MITRE (SE), Versión 1, pp. 10, 40-41.
- Garvey, P. R., 2008, Analytical Methods for Risk Management: A Systems Engineering Perspective, Chapman-Hall/CRC-Press, Taylor & Francis Group (Reino Unido), Boca Raton, Londres, Nueva York, ISBN: 1584886374.Fuerza Aérea de los Estados Unidos, enero de 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315.305(a).
- U. S. Air Force, enero de 2008, Air Force Past Performance Evaluation Guide (PPEG), IG5315. 305 (a).
Referencias adicionales & Recursos
Listas de verificación del Equipo Técnico de Análisis y Gestión de Riesgos MITRE E520, Comprobaciones de Riesgos, Análisis de Riesgos y Documentos de Gestión.
Project Management Institute, A Guide to the Project Management Body of Knowledge, (Guía PMBOK), Cuarta Edición, ANSI/PMI 99-001-2008, pp.273-312, consultado el 2 de marzo de 2010.
SEPO, «Proceso Estándar / Pasos del Proceso, Paso 2: Identificar riesgos & Peligros», Kit de herramientas de Gestión de Riesgos MITRE SEPO, consultado el 5 de mayo de 2010.
