Gestión de Riesgos práctica

7

Cuando estudias alguna metodología de gestión de proyectos, de servicios o de casi cualquier sistema de gestión siempre aparece la gestión de riesgos. Más o menos todas las guías la implementan de la misma manera: identificación, clasificación y/o cuantificación y toma de decisiones. En el PMBOK la importancia es tal que le dedican un área entera de conocimiento. El caso es que después toca aplicar lo estudiado en la gestión de un proyecto concreto, y ahí es donde la gran mayoría de los gestores de TI fallan. La gestión de riesgos se convierte en un proceso burocrático que hay que hacer porque o bien nos lo exige el cliente, nuestra PMO o dirección. Pero realmente no aporta valor. ¿Qué es lo que falla?. Voy a hacer un repaso de lo que yo creo que debe ser una gestión de riesgos que aporte valor y no una aplicación directa de la teoría. Si lo que buscas es una explicación de los procesos del PMBOK del área de gestión de riesgos para prepararte para el PMP, este no es el sitio.

La historia habitual

Cuando comienzas a gestionar proyectos por primera vez, lo de los riesgos no va contigo. Existe una gestión de riesgos implícita en las personas, ya que de vez en cuando le vemos las orejas al lobo. La gestión de riesgos es ad hoc, sobre la marcha. Cuando un miembro del equipo te dice “¡Cuidado con esto que se nos va de las manos!” estás haciendo una gestión de riesgos, pero no lo sabes. El problema es que no eres metódico por lo que realmente no te preparas para lo que pueda venir y tu reacción no pasa de ponerle un par de velas a Santa Rita. Con este sistema de gestión de riesgos implícita, la experiencia es un grado. Los gestores más experimentados y con equipos experimentados, verán riesgos y se prepararán para ellos. Pero cuando le cambias un poco el entorno de trabajo, o los condicionantes del proyecto o servicio, las sorpresas aparecen. Al fin y al cabo muchos de nosotros somos gestores por accidente.

A continuación llega a ti el concepto de gestión de riesgos. Puede ser que te venga porque lo leas por Internet, porque te lo enseñan en un curso, porque tu jefe o tu PMO te dice que hay que aplicar gestión de riesgos, …; no importa el origen. El caso es que de repente llega a ti un conocimiento sobre gestión de riesgos y ves el potencial de gestionarlos correctamente. El problema es que el 99% de la literatura y formación sobre gestión de riesgos que puedes encontrar por ahí es muy formal. La gran mayoría de formadores no han hecho una gestión de riesgos bien hecha en su vida. No digo que no haya buenos formadores de gestión de riesgos, sino que muchos de ellos se enfocan en enseñarte la teoría de la gestión de riesgos o en prepararte para un examen sobre gestión de riesgos. El resultado es que sales de allí con ganas de aplicar la gestión de riesgos, pero sin tener ni idea.

Ya sea con ganas de aplicar la gestión de riesgos o porque nos obliga dirección a tener una gestión de riesgos, comenzamos a aplicarla. Aquí se producen los errores comunes como son:

  • Gestionar riesgos al inicio del proyecto y luego olvidarse de la gestión de riesgos.
  • No gestionar riesgos hasta que el proyecto se acerca a su fecha de fin programado con pocas garantías de cumplirse, y entonces empezar a identificar riesgos, cuando ya podríamos empezar a hablar de hechos consumados.
  • Identificar riesgos y quedarse en una lista de lo que podría ir mal.
  • Definir riesgos abstractos, poco concretos y difíciles de manejar.
  • Lista definida sólo por el gestor y sin colaboración del equipo. No comunicar la lista a los interesados.

Cualquiera de estos fallos, hace que la gestión de riesgos se convierta en una tarea burocrática que nos permite decir: “He gestionado los riesgos”, pero que realmente no aporta ningún valor al proyecto.

Así pronto se pierde la fe en la gestión de riesgos y pasamos a mínimos. Hacemos el mínimo que nos exige el cliente o la dirección para aparentar que gestionamos riesgos, cuando realmente no los gestionamos.

¿Significa esto que la gestión de riesgos no sirve para nada? ¿Qué nos han engañado desde el PMI y resto de organizaciones? Por supuesto que no. Lo que pasa es que hay que hacerlo bien. Vamos a ver algunas recomendaciones que os doy para que vuestra gestión de riesgos no sea una tarea burocrática y sí que aporte valor.

Recomendación 1: Riesgos concretos

No sirve de nada incluir un riesgo en un proyecto que sea “Repetir el trabajo por requisitos mal definidos”. No vamos a obtener nada de analizar esto. Sólo nos servirá para que en el caso de que suceda poder decir “Os lo dije que podría pasar”. Y la gestión de riesgos no debe ser un pliego de descargo de responsabilidades del gestor del proyecto. Debe aportar valor al proyecto.

Los riesgos deben ser concretos ante situaciones claras que vemos que pueden pasar. Por ejemplo: “Se ha definido que los usuarios tengan un único campo de teléfono, pero vemos probable que cuando entreguemos quieran un listado de teléfonos por usuarios.” Esto es un riesgo concreto que el analista funcional ha detectado cuando tomaba los requisitos. Le han dicho un sólo teléfono, pero no ha quedado convencido, por lo que lo pone en un riesgo. Esta situación si que se puede tratar, cuantificar y preparar. Aquí si que podemos decir cosas como que en el caso de materializarse tendremos dos días de retraso y 500 € de sobrecoste. Y también podemos prepararnos.

Otros ejemplos de riesgos concretos:

  • El departamento de finanzas no ha opinado y dirección no nos deja que opine. Es posible que esto implique cambios en el módulo de facturación, tras la puesta en producción.
  • Hay previsto un cambio de versión de SAP, por lo que la integración podría cambiar antes de que acabe el proyecto.
  • No sabemos si la versión de JBOSS escogida será compatible con nuestra librería java.

Lo mismo para servicios. La gestión de riesgos en servicios es una parte vital de los sistemas de gestión de la seguridad de la información (SGSI). No me sirve un riesgo como “Ataque hacker a uno de nuestros sistemas”.  Si me sirven riesgos como:

  • La versión de Exchange está desactualizada y no se publican actualizaciones. Si aparece un ataque de día 0, no podremos protegernos.
  • El LDAP descansa sobre discos no replicados. Una rotura de disco tiraría el servicio.

Recomendación 2: Todo el mundo opina

La gestión de riesgos es tarea de todo el equipo, incluso de todos los interesados. Esto lo dice en los manuales de gestión de riesgos, pero no siempre se aplica. Todo el mundo tiene que poder comunicar riesgos. Es una forma muy sana de aunar el conocimiento y la experiencia del equipo. Por lo tanto hay que plantearse una gestión de riesgos pública en la que todos vean la lista de riesgos.

Esto entrará en conflicto con una recomendación posterior, la de ocultar riesgos propios. Es cuestión de encontrar un equilibrio.

Recomendación 3: Soluciones prácticas a los riesgos

Identificar riesgos no sirve de nada si no se actúa sobre ellos. No voy a entrar en si los riesgos se pueden contener, transferir, asumir, … vamos a lo práctico. Hay dos cosas a hacer siempre ante un riesgo:

  • Actuar antes de que pase
  • Actuar después de que pase

La primera opción consiste en tomar acciones para:

  • La probabilidad de que suceda sea menor o incluso nula
  • En el caso de que suceda el impacto sea menor.

La segunda consiste en preparar:

  • Un plan de actuación que minimice el tiempo de respuesta.
  • Medidas alternativas para paliar el efecto (como tener reservas)

Así que yo recomiendo por cada riesgo plantearse cómo nos prepararemos y qué haremos si sucede. Y de la misma manera que a la hora de identificar los riesgos, hay que ser concretos, prácticos y realistas. Tienen que ser cosas que aporten valor.

Por ejemplo, para los riesgos que he incluido anteriormente:

[first_third]Riesgo[/first_third] [second_third]Preparación[/second_third] [last_third]Respuesta[/last_third]

[first_third]El campo de teléfono puede convertirse en una lista[/first_third] [second_third]Incluir una marca-comentario en el código en todo lo que tiene que ver con ese teléfono. Incluir una reserva de 100 €.[/second_third] [last_third]Utilizar la marca para identificar rápidamente qué cambiar. Utilizar la reserva.[/last_third]

[first_third]Versión de JBOSS puede no ser compatible[/first_third] [second_third]Incluir una tarea inicial que asegure la compatibilidad. Ampliar las reservas de contingencia en 300 €. [/second_third] [last_third]Usar reservas[/last_third]

[first_third]Cambio de SAP previsto[/first_third] [second_third]Convocar reunión con el equipo técnico de SAP. Incluir al responsable del servicio de SAP en la lista de interesados. Pedir que nos incluyan en la lista de interesados del proyecto de cambio de versión.[/second_third] [last_third][/last_third]

[first_third]Finanzas cambia requisitos tras la puesta en producción[/first_third] [second_third]Comunicar el riesgo a dirección. Dejar claro en el alcance la exclusión de cambios de requisitos por parte de finanzas tras la puesta en producción.[/second_third] [last_third]Plantearlo como un nuevo proyecto y defender la exclusión aceptada.[/last_third]

De esta manera estamos actuando gracias a la gestión de riesgos. Es decir, al preguntarnos “¿Qué podemos hacer para evitarlo o reducirlo?” estamos decidiendo tomar medidas que no habríamos tomado de no existir la gestión de riegos. Si no tenemos una gestión de riesgos práctica en marcha, el analista funcional no habría sabido donde poner el comentario de “me piden un teléfono, pero me veo cambiándolo en el momento que lo vean.” No nos habríamos enterado y no seríamos capaces de preparar una respuesta. Ahora el programador conocerá el riesgo y preparará el código para el cambio si luego se lo piden. Así minimizamos el coste de ese cambio si se produce.

Recomendación 4: Ocultar riesgos propios

Los proyectos no pasan sólo en una organización. Podemos tener un proyecto que se vende a un cliente, con lo que tendremos claramente dos empresas. Pero incluso en el caso de una sola empresa podemos tener múltiples departamentos. O puede ser TI y Negocio como dos estructuras diferentes. El caso es que los riesgos de uno, no son los del otro. Esto implica tener más de una lista de riegos o marcar determinados riesgos como propios. Por ejemplo, en el ejemplo del riesgo “Finanzas cambia requisitos tras la puesta en producción” hay un claro tono de queja hacia dirección. No podemos publicar este riesgo como tal a dirección, por muy interesado que sea del proyecto. Así tenemos que tener una lista interna (del equipo, del gestor, de TI, …) y una externa. A veces incluso más de dos listas.

Es un error que veo a menudo el tener una sola lista de riesgos, y que luego haya riesgos que se omiten, porque no se pueden comunicar a determinados interesados. Si este es el caso, hay que tener más de una lista.

Yo, que trabajo con proyectos externos, lo soluciono añadiendo un campo más a la lista de riesgos: Comunicación al cliente. En ese campo pongo la frase que le diré al cliente sobre ese riesgo. Por ejemplo, puedo tener un riesgo que es “El cliente no sabe muy bien cómo debe realizar la aprobación de expedientes y los representantes funcionales no parecen conocer muy bien los procesos de negocio” No puedo decirle eso al cliente, porque estoy poniendo verde a sus representantes funcionales y los tendré como gato panza arriba. Mi respuesta es: “Comunicar el riesgo al cliente a ver si incluye a alguien que pueda definirlo mejor o que por lo menos sepa que podemos retrasarnos. Mover el desarrollo a fase inicial, para que pueda revisarse en otra fase. Incluir de serie el coste de una revisión en fase dos”. En caso de que suceda “Retrasarnos y explicar al cliente que se ha materializado el riesgo que le comunicamos”. Y para la columna Comunicación al cliente “La complejidad de la aprobación nos hace pensar que es probable un cambio tras el desarrollo, por lo que lo plantearemos de forma iterativa en dos fases. Incluir a personal que actualmente hace la aprobación nos ayudaría a minimizar este riesgo.”

Así consigo hacer mi gestión de riesgos y alinearla con lo que el cliente considera como riesgo.

Recomendación 5: Gestión de riesgos viva

El gestor debe ser “el pesado de los riesgos”. En cada reunión o informe de seguimiento tienen que aparecer. Periódicamente tiene que preguntar si se ven riesgos nuevos. No hay que dejar que se mueran y pierdan valor. Hay que mantenerlos vivos.

Mantenerlos vivos implica revisar la lista cada cierto tiempo. ¿Siguen teniendo sentido? ¿Han cambiado las cosas? Este es un ejercicio que puede hacer una sola persona, pero que ante la duda deberá consultar al resto.

Mantenerlos vivos también implica ir identificando riesgos de forma continua. La cultura de comunicar riesgos cada vez que se le ven las orejas al lobo debe existir en tu equipo. Y eso se consigue siendo un pesado.

Recomendación 6: No categorizar

Aquí es cuando se me echan al cuello los puristas. A ver si os convenzo.

Categorizar es definir unas categorías para los riesgos en varias dimensiones como podría ser la probabilidad, el impacto o la respuesta; y después asignar a cada riesgo un valor en esas dimensiones. Por ejemplo, podemos categorizar los riesgos según la probabilidad como:

  • Casi imposible
  • Posible
  • Probable
  • Casi seguro

Hacer una categorización puede ayudar a definir un nivel de riesgo con matrices del estilo: impacto grave y probabilidad posible es de alto riesgo. Y eso puede servir para ver en qué riesgos podemos enfocarnos más. Hacer este trabajo puede estar bien cuando tenemos cientos de riesgos y queremos dar una vista estructurada de los mismos a niveles superiores. Pero en la práctica me he encontrado, que aunque chulo, aporta poco valor. Hablamos de TI, no de construcción, por lo que la lista de riesgos del proyecto rara vez superará los 50. Lo normal es tener entre 10 y 20 riesgos identificados.

Lo que ya no admito es categorizar la respuesta. Hace no mucho estuve involucrado en un proyecto en el que participé en, pero no dirigí, la gestión de riesgos. En ese proyecto se cometieron varios errores, como iniciar la gestión de riesgos a un mes de la finalización del proyecto, no tener un responsable claro de esta gestión de riesgos o incluir riesgos genéricos. Pero una de las cosas que menos me gustaron fue categorizar la respuesta al riesgo entre las siguientes opciones:

  • Contener
  • Mitigar
  • Asumir
  • Transferir
  • Eliminar

En las reuniones de seguimiento, cuando llegábamos a los riesgos, alguien exponía uno. Entonces se preguntaban ¿Qué hacemos? y decidían cual de las opciones. Y ahí se quedaba. ¿De que me sirve decidir “Contener” si luego no hago nada.

Resumiendo, creo que categorizar lleva a dejar de hacer cosas más importantes por creer que ya las sustituimos.

Antes de pasar a la siguiente recomendación, aclarar que aquí no me refiero a crear una estructura de desglose de riesgos (RBS) . Esto puede ser útil, para ordenarlos. Pero no debe ir más allá de eso. El desglose sólo nos sirve para ordenar la lista, no para aportar información y obviar las otras partes críticas. Así podemos tener una estructura que nos desglose los riesgos entre riesgos derivados de mala toma de requisitos, riesgos tecnológicos, riesgos de expectativas, etc. Pero no una RBS que en el fondo esté categorizando el impacto, la acción o la probabilidad.

Recomendación 7: No cuantificar

Ahora a los puristas les comienza a dar urticaria. ¿Qué dice este loco? ¿Se está cargando un proceso entero del PMBOK? Pues sí, y sigo vivo.

Cuantificar es medir, en coste económico, el impacto de un riesgo.

Somos gestores de TI, no de la construcción. En la construcción hay mucha tradición para medir costes. Te coges un libro sobre puentes y tienes tablas con costes, riesgos, fórmulas para cuantificarlos, etc. En cambio en TI no tenemos prácticamente nada. Se intenta hacer cosas en esa dirección, como los puntos de función, pero la realidad es que todavía estamos en pañales. Y al ritmo que cambia este negocio, es posible que nunca lleguemos a ese nivel de madurez.

Por lo tanto, intentar poner cifras puede ser tarea muy difícil. En algunos casos puede ser claro y fácil de calcular. En esos casos podemos incluirlo en la definición del riesgo. En otros en cambio será muy complicado.

Ojo! que no estoy diciendo que no debamos describir el impacto del riesgo. Eso sí que es buena práctica. Pero obcecarnos en poner una cifra económica creo que no es buena idea. Al menos al principio. Una vez ya tengamos una gestión de riesgos práctica y útil podemos intentar cuantificar los riesgos. Pero de primeras, recomiendo olvidarse.

EDITO (29/04/2015): A raíz de un comentario creo que es necesario puntualizar que no hablo de prohibir la cuantificación. Si es fácil y sentillo cuantificar el riesgo, no está de más tener esa información en la descripción del riesgo. Como digo en el comentario, prefiero saber que hablamos de un retraso de 4 a 7 días que de un retraso a secas. Pero lo que no aconsejo es rebanarse los sesos intentando dar cifras cuando realmente no podemos o cuando son sólo tiradas al aíre. Y mucho menos en dinero. Resumiendo, si sé que el riesgo me ocasionará pérdidas por 1.000 €, pues lo pongo. Pero si no lo sé, no me invento una cifra o pierdo tiempo calculándola.

Recomendación 8: No es un pliego de descargo

La gestión de riesgos no debe en ningún momento plantearse como un pliego de descargo por si las cosas van mal. La triste realidad es que en los casos que yo veo, y por lo que me dicen mis conocidos del sector, es la práctica común. La gestión de riesgos se puede utilizar (y se utiliza) como pliego de descargo de la siguiente manera:

  • Detecto que algo puede salir mal.
  • Aviso de que puede salir mal en la gestión de riesgos y transfiero responsabilidad.
  • Cuando sale mal entono el famoso: “!Ya os avisé de que podía pasar y nadie me hizo caso!”

Esto no ayuda a la organización. Por lo que no es buena práctica. Una cosa es que entre organizaciones consigas transferir a otra organización el impacto. Pero incluso en esos casos hay que dejar claras las intenciones y que la otra organización entienda que es ella la que está aceptando el riesgo.

Lo confieso, la primera vez que me obligaron a rellenar riesgos en un proyecto, yo también lo vi como un pliego de descargo. Ahora sé que no es buena idea.

Conclusión

La gestión de riesgos debe ser algo útil para la organización. No hay que perderse en burocracias y hay que ir directamente a casos concretos y prácticos. Hay que mantenerla viva, sin dejar que quede obsoleta y olvidada.

Espero que estos consejos os sirvan. ¿Estás de acuerdo? ¿Tienes otros consejos? ¿Te ha servido? No te olvides de dejar tu comentario.

 

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

7 comments

  1. Alfredo Urrutia 21 Abril, 2015 at 23:32 Responder

    Magnifico artículo. Me he visto reflejado en muchos de los casos descritos.
    Lo voy a imprimir para leerlo periódicamente hasta que vea que me la gestión de riesgos es algo que ya haga de forma natural.

    • Jose M. Huerta 22 Abril, 2015 at 07:53 Responder

      Lo complicado ya no es hacerlo tú, sino convencer a los que te rodean de que se debe hacer así. Y tener que aguantar que le llamen “el pesado de los riesgos”. Gracias por el comentario.

  2. Javier Carro 29 Abril, 2015 at 00:55 Responder

    Muy bueno por realista y práctico.
    Con lo que menos estoy de acuerdo es con lo de no cuantificar: a menudo precisamente el impacto de un riesgo es reworking o retraso, que viene a ser lo mismo, y eso se puede cuantificar, y suele ser muy interesante cuantificarlo, “sencillamente” en días (lo cual probablemente impactará en otros proyectos que pueden estar esperando a que acabe el presente).

    • Jose M. Huerta 29 Abril, 2015 at 07:19 Responder

      Gracias por el comentario Javier. A lo mejor no lo he dejado claro, pero con lo de no cuantificar, me refiero a la recomendación del PMBOK deintentar cuantificar en dinero el impacto del riesgo. Por supuesto que estoy de acuerdo contigo en que si es posible definir el impacto, lo hagamos. Incluso si es en moneda. Pero no obcecarnos en intentar dar siempre un número en moneda, para luego poder tomar decisiones. Siempre es mucho mejor decir, “Nos retrasaremos de 4 a 7 días” que decir “nos retrasaremos” para describir el riesgo.
      Gracias por la matización.

Post a new comment

Te puede interesar...

Puntos de historia

Una técnica relativamente moderna para ayudar a la estimación en proyectos de desarrollo.