¡Lo sabemos desde hace 500 años: gestionar la creación de un nuevo sistema es una tarea ardua!

LA EXPERIENCIA HA DEMOSTRADO QUE la gestión de riesgos debe ser una preocupación crítica para los gerentes de proyectos, ya que los riesgos no gestionados o no mitigados son una de las principales causas del fracaso de los proyectos. Lo que conocemos, lo planificamos, y generalmente tenemos éxito. Sin embargo, sin mitigación, los riesgos introducirán caos y fracaso en un proyecto que de otro modo estaría bien planificado y gestionado. Este artículo aborda la identificación, la estrategia de mitigación y la planificación de contingencias, y la gestión continua de los riesgos del proyecto. Está diseñado para proporcionar técnicas adicionales para los gerentes de proyectos en ejercicio y crear conciencia sobre la gestión de riesgos entre sus patrocinadores.

Numerosos textos abordan la gestión de riesgos y los métodos estadísticos para calcular una serie de "estimaciones" que consideran el riesgo de duración de las actividades en una red de tareas de un proyecto. El software de gestión de proyectos y otras herramientas ayudan a lidiar con los problemas operativos de la sobreasignación de recursos. Sin embargo, algunas de las técnicas asumen que los riesgos se identifican y pueden abordarse de manera uniforme aumentando el plazo del proyecto o los recursos. Estas suposiciones no siempre son válidas.

Gestionar un proyecto exitoso es como caminar por una cuerda floja, un complejo acto de equilibrio lleno de distracciones competidoras. El equilibrista exitoso tiene años de práctica y comienza su entrenamiento en una cuerda "baja". Se presta mucha atención a la configuración de los cables de soporte y los postes de apoyo para proporcionar una tensión predecible a la cuerda alta. Además, se requiere una intensa concentración en la tarea en cuestión e ignorar a las ruidosas multitudes. Un aspirante a equilibrista que no ha adquirido competencia a través de la experiencia y que no ha configurado adecuadamente el entorno de la cuerda floja seguramente caerá.

De igual manera, es raro el gerente de proyectos que puede lidiar con los riesgos inherentes, distracciones y complejidades de la gestión de proyectos sin planes y procesos detallados. Desafortunadamente, la gestión de riesgos no siempre se aborda con el rigor de otros procesos de gestión de proyectos: gestión del alcance/cambio, gestión de problemas, resolución de conflictos, desarrollo de entregables basados en desgloses de trabajo y programación.

Con el tiempo, muchos gerentes de proyectos aprenden a gestionar el riesgo mediante la negación, eludir y tratar de protegerse. Desarrollan varios patrones de comportamiento para defenderse del impacto del fracaso basado en riesgos, tales como:

• Agregar tiempo, dinero o recursos de contingencia no justificados al plan del proyecto; es decir, "colchonear" la estimación.
• Señalar con el dedo y culpar a otros.
• Pedir perdón y renegociar el alcance cuando ocurre lo "desconocido".
• Tomar atajos en las actividades de aseguramiento de la calidad en un intento de evitar el impacto del riesgo o perder hitos.
• Eliminar entregables de infraestructura, como capacitación o documentación de metadatos.
• Reaccionar con un comportamiento de "es solo una de esas cosas" y esperar que el cliente lo acepte.

El problema con estos comportamientos es que no hay aprendizaje y, por lo tanto, tienden a repetirse. Todos los patrones de comportamiento anteriores son reactivos, conducen a fallos en el proyecto y debilitan la credibilidad y confianza del gerente de proyectos. No sugiero que no existan circunstancias imprevistas que puedan impactar seriamente un proyecto. Sin embargo, hay pasos que un gerente de proyectos puede y debe tomar para mitigar y minimizar el impacto de fallos predecibles basados en riesgos.

Antes de explorar los pasos hacia una gestión exitosa de riesgos del proyecto, es útil examinar las características de algunos entornos de proyectos. El gerente de proyectos se selecciona entre las filas de "hacedores" exitosos. Correspondientemente, la membresía en un equipo de proyecto se considera un reconocimiento positivo del trabajo y éxito pasados. Naturalmente, la planificación del equipo del proyecto y las percepciones del entorno son positivamente enfocadas (es decir, el gerente de proyectos y los miembros del equipo son individuos optimistas y positivos que creen que pueden hacer cualquier cosa, sin considerar el tiempo o los recursos). Esto no implica fracaso, ya que muchos proyectos se completan exitosamente gracias a los esfuerzos sobrehumanos de unos pocos individuos. Sin embargo, el exceso de optimismo representa un enfoque de gestión "Pollyanna" y puede llevar al desastre.

Durante las fases de propuesta y planificación del proyecto, el gerente de proyectos se basa en su experiencia personal pasada, el equipo del proyecto y la comunidad de clientes para desarrollar un plan de proyecto. Generalmente, se llevan a cabo una serie de sesiones de lluvia de ideas para definir objetivos y metas, fijar los límites del proyecto (alcance), cuantificar los entregables, desarrollar un enfoque del ciclo de vida del proyecto y establecer el calendario, los hitos, el presupuesto y los recursos. Este es el punto en el ciclo de vida del proyecto donde se deben identificar los riesgos y desarrollar estrategias de mitigación; sin embargo, esto a menudo no ocurre. Existen muchas razones para no dedicar el tiempo y la energía a examinar cuidadosamente los riesgos:

• Cuantificar los riesgos podría llevar a la no financiación del proyecto.
• El cliente no quiere dedicar tiempo y energía.
• El cliente no cree que los riesgos sean reales.
• El cliente quiere un plan simple.

Creo que también hay otra fuerza subyacente en juego. Las tendencias sociológicas de nuestra sociedad y la filosofía actual de construcción de equipos enfatizan la necesidad de ser positivos: los problemas son oportunidades; los riesgos son desafíos a superar; los pensamientos negativos son socialmente reprimidos. En este entorno, enfatizar los riesgos es ser etiquetado como un pensador negativo y no contribuyente, casi un paria. Es como si hubiéramos olvidado un instinto básico de supervivencia: la aversión al riesgo. Nuestra evolución desde la sabana africana fue un proceso sistemático de aprendizaje para evitar riesgos. El comportamiento adverso al riesgo es un rasgo de supervivencia y debe incluirse como un factor de equilibrio, incluso en la civilización sofisticada de hoy.

Hay pasos proactivos positivos para gestionar el riesgo. Cuando se practican de manera consistente dentro de una organización, estos pasos proactivos pueden formar la base de una metodología formal de gestión de riesgos de proyectos. En mi experiencia, los riesgos pueden dividirse en dos clases: riesgos reconocibles y suposiciones no gestionadas.

Clasificación y Mitigación de Riesgos Reconocibles

Los riesgos reconocibles son aquellos que pueden identificarse durante las actividades de planificación y contratación del compromiso. En su mayoría, son altamente visibles e inmediatamente aparentes para todos (o al menos alguien) involucrados en el proyecto. Ejemplos típicos incluyen nueva tecnología, restricciones de recursos financieros, limitaciones de recursos de personal, cambios en los procesos empresariales. Históricamente, se han implementado estrategias de mitigación para estos tipos de riesgos.

Desafortunadamente, las estrategias de mitigación pueden introducir riesgos propios. Por ejemplo, si el proyecto requiere la introducción de una nueva tecnología, la capacitación podría incluirse en el plan del proyecto como una estrategia de mitigación de riesgos. Sin embargo, si bien la capacitación es necesaria para adquirir nuevas habilidades, generalmente no es suficiente. A menudo se requiere coaching, mentoría o al menos la disponibilidad de un practicante experimentado para asegurar la transferencia de habilidades y competencia en un corto período. Por lo tanto, sería aconsejable incluir un plan de contingencia para un experto o consultor en el lugar, en caso de que surja la necesidad.

Se sigue que a medida que se identifican los riesgos, se debe desarrollar e implementar un plan de mitigación de riesgos. Además, se debe incluir un plan de contingencia para los riesgos altos, con una circunstancia o medida desencadenante definida para invocarlo. Puede que no sea necesario planificar la acción de contingencia en detalle en este momento; sin embargo, es importante saber qué debe planificarse en función de un desencadenante adecuado (es decir, un conjunto de señales de advertencia). Continuando con el ejemplo de riesgo de nueva tecnología, si no se cumplen las medidas de productividad anticipadas, se llama al experto.

Las estrategias de mitigación de riesgos y los planes de contingencia cuestan tiempo, dinero y recursos para desarrollarse e implementarse. Raro es el proyecto donde se manifiestan todos los riesgos y se desencadenan todos los planes de contingencia. Además, los patrocinadores del proyecto a menudo no quieren dedicar tiempo (dinero) a la planificación detallada de la mitigación de riesgos. Por consiguiente, puede ser más apropiado establecer un presupuesto general de mitigación de riesgos como un porcentaje de los costos proyectados en general, en lugar de detallar el costo de cada estrategia de mitigación de riesgos identificada y plan de contingencia. La experiencia de la industria sugiere un presupuesto de contingencia del 5 por ciento para identificar y rastrear riesgos. Además, sugiero al menos un presupuesto de contingencia del 5 por ciento para la mitigación de riesgos no planificados y presupuestados en detalle.

Técnicas de Identificación de Riesgos

Para gestionar adecuadamente los riesgos, primero deben ser "descubiertos". Dos técnicas comunes para lograr esto son la evaluación de riesgos basada en la experiencia y la evaluación de riesgos basada en la lluvia de ideas.

Evaluación de Riesgos Basada en la Experiencia

La marca de un gerente de proyectos exitoso, un sobreviviente tanto organizacional como personalmente, es la capacidad de aprender de la experiencia. El impacto de los riesgos no mitigados encontrados en proyectos anteriores está impreso indeleblemente en la psique del gerente de proyectos y se recordará en proyectos futuros. ¿Por qué no está este recurso de conocimiento más fácilmente disponible para el nuevo gerente de proyectos?

Como gerente y consultor interno para una gran organización de atención médica durante muchos años, experimenté de primera mano el aprendizaje continuo requerido por los nuevos gerentes de proyectos. Al examinarlo, me di cuenta de que un contribuyente importante al fracaso de los gerentes de proyectos no iniciados era su ingenuidad sobre la gestión de riesgos. Inevitablemente eran productores de alto nivel, motivados para tener éxito, conocedores del negocio y bien considerados en toda la organización. ¿Por qué no todos tuvieron éxito? Sugiero que muchos neófitos en la gestión de proyectos fracasaron o decidieron no seguir una carrera en gestión de proyectos porque la organización se impacientó con la curva de aprendizaje requerida para mitigar adecuadamente el riesgo o el estrés de reaccionar a los riesgos provocó un agotamiento prematuro. Si la experiencia en la gestión de riesgos de los gerentes de proyectos experimentados y exitosos estuviera fácilmente disponible para los nuevos, el agotamiento y el fracaso podrían minimizarse. ¿Cómo se puede lograr esto?

Los textos de gestión de proyectos, los seminarios y las metodologías basadas en consultoría enfatizan la importancia de las revisiones de cierre de proyectos como oportunidades para aumentar la base de conocimientos de la organización. Desafortunadamente, las actividades de cierre, aunque frecuentemente se describen en el plan del proyecto, a menudo solo se ejecutan de manera superficial. Siempre hay demasiado por hacer, un nuevo proyecto para comenzar o una nueva prioridad que abordar. No obstante, incluso si la cultura organizacional minimiza la importancia de las revisiones de cierre de proyectos, los gerentes de proyectos deberían tomar la iniciativa de documentar sus experiencias de gestión de riesgos durante los proyectos y compartirlas proactivamente con otros gerentes de proyectos. Esta experiencia puede formar el comienzo de una lista de verificación de riesgos del proyecto para ayudar a examinar los riesgos potenciales del proyecto y los planes de mitigación y contingencia previos.

Además, las organizaciones de consultoría, los requisitos de la ISO y los métodos del Modelo de Madurez de Capacidades del Instituto de Ingeniería de Software enfatizan la importancia de la definición de procesos, la implementación consistente y la mejora continua para aumentar la efectividad organizacional. Esto también debería aplicarse a la gestión de riesgos del proyecto. Si una organización se toma el tiempo para documentar los riesgos y sus estrategias de mitigación, revisarlos al cierre del proyecto (exitoso o no) y compartirlos a través de un repositorio de conocimientos fácilmente disponible, los nuevos gerentes de proyectos y la propia organización tendrán más éxito.

Evaluación de Riesgos Basada en la Lluvia de Ideas

Las sesiones de lluvia de ideas facilitadas con las partes interesadas del cliente, los miembros del equipo del proyecto y el personal de apoyo de la infraestructura son la técnica principal utilizada para definir riesgos y sus estrategias de mitigación y planes de contingencia. El proceso define los riesgos en una columna, la(s) estrategia(s) de mitigación en una segunda columna y los planes de contingencia potenciales en una tercera columna. Se pueden identificar múltiples estrategias de mitigación o planes de contingencia para los riesgos. Usando esta técnica, se puede determinar fácilmente dónde la organización está expuesta a un riesgo no mitigado. Este tipo de sesión facilitada también se conoce como "análisis de campo de fuerzas".

Clasificación de Riesgos

En el mundo real, no hay dinero ni tiempo ni recursos para tratar con todos los riesgos; por lo tanto, la administración debe elegir qué riesgos tendrán planes de estrategia de mitigación y contingencia desarrollados e implementados para ellos. Para permitir esto, es importante desarrollar un enfoque objetivo para clasificar los riesgos y establecer prioridades. Un enfoque es examinar cada riesgo y clasificarlo según los siguientes tres factores: categoría de riesgo, severidad o impacto en la finalización exitosa de un hito del proyecto y probabilidad o probabilidad.

La predefinición de categorías de riesgo proporciona una forma de clasificar los riesgos para su inclusión en la base de conocimientos de la organización. Aunque cada organización debería establecer sus propias categorías de riesgo según sus necesidades especiales, he encontrado útiles siete categorías de riesgo: riesgo de gestión del alcance/cambio, riesgo operativo, riesgo financiero, riesgo de gestión de proyectos, riesgo estratégico, riesgo tecnológico y suposición fallida.

Tabla 1. Matriz de Factor de Severidad de Riesgo a Factor de Probabilidad

Construir una matriz de intersección de severidad y probabilidad de riesgo alta, media y baja proporciona una forma simple y directa de cuantificar numéricamente el riesgo (ver Tabla 1). No se requieren técnicas de análisis numérico más sofisticadas para establecer dónde se deben aplicar los recursos para desarrollar estrategias de mitigación de riesgos y planes de contingencia adecuados.

Dentro de cualquier organización, ciertas categorías de riesgo pueden representar mayores riesgos para el fracaso del proyecto. Por ejemplo, algunas organizaciones pueden tener mucha experiencia en la introducción de nueva tecnología y, por lo tanto, entender cómo manejar los riesgos tecnológicos. Por otro lado, otra organización que no ha introducido nueva tecnología durante algún tiempo puede necesitar ser especialmente cuidadosa al hacerlo. Por lo tanto, las propias categorías de riesgo pueden tener factores de ponderación asignados para modificar las calificaciones de factores de riesgo de severidad/probabilidad. Estos factores de ponderación pueden ayudar a cuantificar el riesgo general del proyecto, pero no son un sustituto de una estrategia de mitigación de riesgos adecuada y una planificación de contingencias.

La severidad del riesgo se relaciona con el impacto en el proyecto y el negocio si el riesgo se manifiesta, y debe calificarse para una evaluación objetiva. Aunque se pueden definir esquemas de calificación de severidad numérica más complejos, he encontrado suficiente usar una escala simple de alta-media-baja definida de la siguiente manera:

• Alta. Sin mitigación, los objetivos del proyecto están en peligro.
• Media. Sin mitigación, un entregable/hito está en riesgo.
• Baja. Ningún entregable/hito está actualmente en riesgo, pero un problema merece ser observado y es un candidato para la mitigación activa.

La probabilidad de riesgo a menudo se indica por una suposición errónea de disponibilidad de recursos y habilidades o por un problema de sincronización y tiempo. Al igual que con la severidad del riesgo, una escala de calificación de probabilidad simple alta-media-baja generalmente es suficiente para una evaluación objetiva:

• Alta. Sin mitigación y monitoreo, la finalización del entregable/hito del proyecto interrumpirá el camino crítico del proyecto.
• Media. Sin mitigación y monitoreo, la finalización del entregable/hito del proyecto entrará en el camino crítico del proyecto.
• Baja. Ningún entregable/hito del proyecto está en riesgo a menos que las demoras se vuelvan excesivas; por lo tanto, debe documentarse y monitorearse.

La combinación de estos elementos conduce a la matriz de severidad del riesgo vs. probabilidad mostrada en la Tabla 1. Existen matrices más detalladas y sofisticadas en uso por muchas empresas y contenidas en muchas herramientas de soporte de software de gestión de proyectos. Sin embargo, sugiero que se podrían lograr resultados significativos con este nivel mínimo de complejidad. Además de cuantificar la severidad y la probabilidad del riesgo, se deben considerar otras medidas objetivas del riesgo; es decir, cuando sea posible, se debe examinar y cuantificar el grado de impacto en el costo, el cronograma y la calidad del entregable.

Evaluación y Planificación de la Estrategia de Mitigación de Riesgos y Plan de Contingencia

La Tabla 1 proporciona un punto de partida objetivo para la elección. Primero, todos los riesgos con alta severidad o probabilidad (calificación del factor de severidad/probabilidad [SPR] de 3 o 2) deben ser examinados en detalle. Deben tener una estrategia de mitigación desarrollada e incluida en el plan y presupuesto del proyecto. Si tanto los factores de severidad como de probabilidad son altos (SPR de 3), entonces se debe considerar un plan de contingencia detallado con presupuesto. Si solo un factor es alto (SPR de 2), entonces probablemente sea apropiado delinear una estrategia de contingencia con un desencadenante y dejar los detalles de planificación hasta que se desencadene la contingencia.

Para las áreas con al menos una severidad o probabilidad media (SPR de 1), se deben desarrollar estrategias de mitigación. Luego, si el monitoreo muestra un aumento en el riesgo durante el proyecto, se debe considerar un plan de contingencia. Aquellos riesgos con severidad y probabilidad bajas (es decir, SPR de 0) deben tener una métrica establecida para permitir el monitoreo. Es decir, el riesgo debe tratarse como una suposición del proyecto y abordarse de la misma manera.

Después de desarrollar estrategias de mitigación y contingencia para los riesgos, es responsabilidad del gerente del proyecto y de la persona asignada como responsable proporcionar un monitoreo continuo y una evaluación del estado del riesgo. Para un monitoreo efectivo, se debe identificar una medida de éxito para la estrategia de mitigación y un evento desencadenante que identifique cuándo se debe invocar el plan de contingencia. Es la métrica de éxito de la mitigación y el evento desencadenante los que se rastrean. Además, el gerente del proyecto, los miembros del equipo y las partes interesadas deben estar atentos a nuevos riesgos a lo largo del ciclo de vida del proyecto.

Suposiciones No Gestionadas

En contraste con los riesgos identificables, las suposiciones no gestionadas no son visibles ni aparentes como riesgos, por lo que pueden ser las más peligrosas. Creo que son introducidas por la cultura organizacional y que cuando están presentes sin ser reconocidas en el entorno del proyecto provocan percepciones incorrectas y optimismo irrealista.

Las suposiciones son un hecho. Cada clase de gestión de proyectos y metodología nos dice que documentemos nuestras suposiciones y las verifiquemos con el cliente u otras fuentes. Sin embargo, ¿gestionamos nuestras suposiciones? Sugiero que no. Típicamente, cuando una suposición resulta incorrecta o un cambio en el entorno la invalida, "damos la alarma" y volvemos al comportamiento reactivo. ¿Es esto lo mejor que podemos hacer? ¡No! Las suposiciones deben gestionarse de manera similar a los riesgos, porque son una nueva fuente de riesgo. Para evitar sorpresas, las suposiciones sobre el proyecto también deben documentarse y monitorearse para garantizar que las circunstancias cambiantes no invaliden las suposiciones y las transformen en riesgos. Para cada suposición que definimos y documentamos, se puede definir una métrica para probar su precisión continua. Al establecer medidas para nuestras suposiciones y monitorearlas, podemos desarrollar proactivamente planes de contingencia que se activen cuando ocurran cambios.

Un colega me dio recientemente un ejemplo típico de no gestionar suposiciones: una agencia estatal estaba adquiriendo un sistema de imágenes de documentos para ayudar a modernizar y automatizar su proceso de cuentas por pagar. La suposición básica era que el proveedor de integración podría proporcionar fácilmente a la agencia un diseño e implementación de aplicación para optimizar el proceso empresarial. Desafortunadamente, este no fue el caso, y el plazo del proyecto comenzó a alargarse a medida que el proveedor se vio obligado a proporcionar varios diseños iterativos. Esta suposición no gestionada fue reconocida a tiempo, por lo que el proyecto tuvo éxito; sin embargo, se perdió mucho tiempo y se generó ansiedad en el patrocinador antes de que se tomara una acción correctiva.

¿Qué podría haberse hecho para evitar esta situación? Durante la acción correctiva, se reconoció que una medida objetiva del progreso del proveedor de integración habría sacado a la luz el problema mucho antes. Por ejemplo, si se hubiera especificado contractualmente un límite de tiempo o de iteración, entonces se habría desencadenado una acción correctiva antes. El equipo del proyecto discutió posibles acciones correctivas:

• Identificar y contratar a un consultor experimentado en imágenes de documentos de cuentas por pagar.
• Permitir más iteraciones de diseño en el plan del proyecto, ya que este era un proyecto piloto.
• Diferenciar entre requisitos mínimos del sistema y del proceso y características deseables.

Al examinar la suposición subyacente, definir una métrica apropiada y delinear acciones correctivas, el proyecto podría haber procedido sin el estrés generado por no reconocer que las suposiciones son riesgos que deben gestionarse.

Técnicas de Identificación de Suposiciones

Las suposiciones del proyecto derivan de tres fuentes: suposiciones basadas en la experiencia previa de gestión de proyectos, aquellas identificadas mediante lluvia de ideas y riesgos identificados que tienen tanto una baja severidad como una baja probabilidad.

Suposiciones Basadas en la Experiencia

No solo la experiencia previa en gestión de proyectos proporciona al gerente del proyecto una fuente para la identificación y planificación de riesgos, sino que también proporciona conocimientos sobre suposiciones que son válidas dentro de una organización y tipos de proyectos. Por ejemplo, la experiencia puede mostrar que cualquier esfuerzo de implementación de nueva tecnología debe tener un factor de contingencia de costos del 25 por ciento o que la disponibilidad del patrocinador puede cambiar rápidamente durante el curso de un proyecto. Adecuadamente documentadas, estas son suposiciones razonables. Sin embargo, deben ser monitoreadas y rastreadas para garantizar su justificación continua.

Identificación de Suposiciones Basada en la Lluvia de Ideas

Usando la misma técnica de lluvia de ideas descrita para la identificación de riesgos, se pueden identificar suposiciones, definir una métrica para monitorear su aplicabilidad continua y examinar posibles estrategias de mitigación.

Convertir Riesgos Bajos en Suposiciones

La actividad de evaluación y planificación de la estrategia de mitigación de riesgos y del plan de contingencia enfatiza que los riesgos de baja probabilidad y baja severidad deben tener una métrica de monitoreo establecida para ellos. Una vez hecho esto, los riesgos pueden reclasificarse como suposiciones y rastrearse en consecuencia.

Evaluación de Suposiciones

Habiendo documentado las suposiciones e identificado una métrica de monitoreo y una posible estrategia de mitigación, corresponde al gerente del proyecto y a la persona responsable verificar periódicamente la métrica de monitoreo y asegurarse de que no haya ocurrido un cambio ambiental. Si las circunstancias cambian una suposición a un riesgo, se debe invocar el proceso de gestión de riesgos establecido.

Gestión de Riesgos de Empresa/Programa

Además de establecer la gestión de riesgos del proyecto, se debe considerar un proceso de gestión de riesgos a nivel empresarial o programático. Es común que varios proyectos de desarrollo importantes se lleven a cabo simultáneamente en una organización. Además, pueden encontrarse riesgos similares en estos proyectos. Si los riesgos del proyecto se evalúan, entonces se convierte en un proceso simple y mecánico resumirlos y examinar las implicaciones organizacionales del riesgo en todos los proyectos.

En mi experiencia, si varios proyectos han identificado riesgos altos similares (SPR de 2 o 3), entonces el impacto potencial en la organización en su conjunto es muy alto, incluso si las dependencias entre proyectos son bajas. Correspondientemente, múltiples riesgos medios del proyecto (SPR de 1), aunque no necesariamente sean de la mayor preocupación para un proyecto individual, representan un mayor riesgo agregado para la organización.

Por ejemplo, si varios proyectos están introduciendo simultáneamente nuevas tecnologías similares en la organización (como cliente/servidor), entonces cada proyecto puede calificar el riesgo como alto o medio, dependiendo del conjunto de habilidades del equipo del proyecto y la mentalidad de aversión al riesgo. Los clientes pueden solo ver o creer en un riesgo medio a bajo, si es que lo hay, ya que el mercado de proveedores ha exagerado exitosamente la "simplicidad" de la tecnología. Es fácil imaginar (y demostrar por experiencia pasada) que muchos o la mayoría de estos esfuerzos de nueva tecnología encontrarán dificultades y las organizaciones se verán obligadas a ejecutar estrategias de mitigación de riesgos y planes de contingencia.

Si los riesgos individuales del proyecto con sus estrategias de mitigación se examinaran desde una perspectiva empresarial, ciertamente se les daría mayor peso. Además, la organización puede entonces actuar como un todo. Por ejemplo, un proyecto piloto que evalúe la nueva tecnología para establecer sus límites y utilidad podría ser aconsejable y ejecutarse antes de que cada proyecto proceda. Esto proporcionaría lecciones aprendidas y evitaría el costoso impacto de la mitigación de riesgos individuales del proyecto y el posible fracaso.

UNA GESTIÓN EXITOSA DE RIESGOS DEL PROYECTO aumentará significativamente la probabilidad de éxito del proyecto. Identificar los riesgos y suposiciones del proyecto, documentarlos e incluirlos en el plan y los procesos generales del proyecto es una actividad justificable. Sugiero que es una actividad necesaria. Al cierre del proyecto, la experiencia en riesgos y suposiciones del proyecto debería integrarse en el repositorio de conocimientos de gestión de proyectos de la organización. Esta base de conocimientos puede servir en proyectos futuros como punto de partida para la identificación y análisis de riesgos. Los gerentes de proyectos nuevos y experimentados pueden utilizar estas experiencias del mundo real para reducir la preocupación y la carga, y aumentar la probabilidad de éxito.

Fuente: Traducción y adaptación del artículo 'Risk management: the undiscovered dimension of project management'del PMI.