* Este es un breve ensayo sobre el mundo de la gerencia de proyectos situado específicamente en el área de conocimientos de la gerencia de riesgos en TI, algo de @SAP, un ejemplo aplicado a su metodología Activate con un upgrade de S/4 HANA y una correcta gestión de los riesgos de acuerdo a experiencias y buenas prácticas.

El esotérico mundo del gerente de proyectos que no contempla riesgos

A nivel de proyectos en el mundo TI es difícil a veces encontrarse con una pro-activa gerencia de riesgos.

Parece que pocas veces hay tiempo para sentarse a pensar un rato a pensar en ellos y ver como eventos hipotéticos podrían hacer fracasar el proyecto en el cual nos estamos embarcando.

Para algunos pareciera que es más fácil tratar de barrerlos debajo de la alfombra y seguir con el plan y listo y así crear un plan que es una especie de “camino feliz” en el cual no hay obstáculos en el camino y todo se va a dar por gracia divina o simple suerte del destino.

Rezar o realizar conjuros que eviten la materialización de obstáculos en el camino es más fácil que ser proactivos con la gerencia de riesgos.

Pero la realidad es que son pocos los gerentes de proyectos que no les gusta tomar en cuenta los riesgos y les vaya bien. Pueden tener suerte una vez, pero las estadísticas no mienten.

Chistes aparte, más del 50% de los proyectos TI están destinados a fracasar y nada más que por ese dato deberíamos hacer algo al respecto.

Y los proyectos fracasan principalmente por esto:

  • Falta de interés de la gerencia (Implementador y/o Cliente. Lo más loco que he visto es cuando se da manera simultánea). 
  • Cuando surge de forma intespectiva una drástica reducción de costos (y se corta el flujo donde no es).
  • Una falta de planificación adecuada (sumado a un alcance ambiguo y no definido claramente es algo casi letal para un proyecto). 
  • Errores en la selección de tecnologías (clásico cuando hay mucha improvisación en el medio y se juega sin querer al teléfono descompuesto).
  • Fallas en la gestión de la modificación del alcance (mala negociación).
  • Cronograma de proyecto demasiado optimista ( clásico si un vendedor te arma con anterioridad el Gantt, en lo posible siempre evitar unicornios y hadas al momento de planificar).
  • Exceso de personal en el proyecto ( + gente no significa mejores resultados y es buena practica no colocar recursos no deseados).
  • Mala comunicación ( muy obvio, pero si no hay un plan de comunicaciones estamos mal).
  • Recursos no calificados ( a veces ahorrando en calidad de recursos para abaratar el presupuesto puede terminar saliendo cara la jugada).
  • Mal diseño de las pruebas y/u omitiendo la fase directamente en el peor de los casos.

¿Por que no se hace la gerencia de riesgos entonces?

A veces no se hace por que se considera innecesaria, costosa, una pérdida de tiempo para el proyecto (lo he escuchado), o directamente simple ignorancia e incluso a veces nos hace pasar por paranoicos en muchos escenarios.

Todo bien si no pasa nada…

¿Pero si aparece el cisne negro?

¿Sabemos que hacer y estamos claros que puede ser demasiado tarde para hacer contención de daños?

Ahí vienen entonces los lamentos, tragedias (ruedan cabezas algunas veces) y se buscan culpables para tratar de entender por qué pasó lo que pasó y siempre hay algún iluminado que dice:

¿Y esto no se pudo prevenir?

Lo peor es cuando alguien dice:

Yo me lo temía, yo avise y nadie hizo nada.

Si ese comentario no es sarcasmo, es mejor salir corriendo de ahí. 

Anécdotas de cómo no hacer las cosas estoy seguro que todos tenemos muchas, pero como sabemos el ser humano es el único animal que tropieza no 2 veces sino n veces con la misma piedra y poca veces razona o saca una introspección al respecto para prevenir el hecho de que no le vuelva a pasar.

La realidad caótica del momento

Hoy por hoy la actualidad determina una incertidumbre total a todo nivel en un proyecto. Ya lo pudimos ver con el tema del Covid-19 y la dinámica caótica de las sociedades en las que estamos inmersos.

Tomando como premisa esta realidad, el rol del gerente de proyectos a nivel de la gerencia de riesgos debe de ser alguien bastante paranoico o con un gran sentido de previsión de escenarios hipotéticos de todo tipo, manteniendo más que nunca en alto la premisa de Grove:

“Solo los paranoicos sobreviven”.

El manejo de Riesgos según la escuela del PMI

Según el PMI, se deben cumplir seis factores para que un proyecto tenga éxito, si algunos de esto no se cumple parcial o totalmente podría decirse que hay algo o mucho de fracaso en el resultado final:

  1. Se entrega a tiempo.
  2. Su costo no excede al presupuestado.
  3. Funciona según lo diseñado.
  4. La gente lo usa.
  5. Las personas que financiaron el proyecto están contentas con él.
  6. Cumple con los objetivos que impulsaron el proyecto.

El PMI a nivel de riesgos es bastante claro con la importancia que le da a nivel de área de conocimiento y se puede ver el grado de detalle con el que explota este tema en el siguiente gráfico:

No hay texto alternativo para esta imagen

Solo ver el gráfico a primera vista asusta un poco. Lejos de entrar a hablar de todo lo que comprende los procesos relacionados a esta área de conocimientos dentro de la gerencia de proyectos, la idea es tenerlos en cuenta, saber que existen y el porqué de ellos.

La idea final (y a tener en claro siempre) es generar un brainstorming que nos permite identificar, cuantificar tomando en cuenta el origen de los mismos, su naturaleza y cómo mediar con ellos.

Un correcto manejo del riesgo

No existe proyecto sin riesgos, es algo muy obvio de decir pero que no todos lo tienen muy claro. Por eso es necesario considerarlos y tener claro en qué momento pudieran suscitarse en el ciclo de vida del proyecto para poder mitigarlos.

Esto es independiente de la metodología usada para gestionar el proyecto, es necesario identificarlos antes de armar el cronograma.

Lo principal es priorizar los riesgos de acuerdo a su influencia e impacto en el proyecto.

Una vez identificados hay que irlos eliminando o mitigando en la medida de nuestras posibilidades.

SAP Activate por ejemplo, busca realizar esta identificación de los riesgos en la etapa de Descubrimiento. Es el momento exacto de hacer brainstorming que mencionaba unas líneas atrás.

Los resultados de este proceso deben usarse para crear conciencia entre las partes interesadas del proyecto y que todos estén al tanto del mismo.

La implementación de la Gerencia de Riesgos durante el proyecto

Para realizar las tareas de evaluación y mitigación de riesgos durante las fases del proyecto la idea es seguir un esquema predefinido que nos ayude a identificar los principales riesgos y su aparición futura dentro de lo que es el ciclo de vida del proyecto.

Para verlo un poco más claro voy a tratar de mostrarlo con el ejemplo de un proyecto de Upgrade en S/4 HANA desde el punto de vista de SAP Activate (solo presentado algunos riesgos tomando como punto de partida los aceleradores y macro-actividades por cada fase):

No hay texto alternativo para esta imagen

En la figura se pueden apreciar las 6 fases que contempla la metodología ágil de implementación de proyectos de S/4 de SAP para este tipo de proyectos de Upgrade en particular.

Entonces siguiendo una a una las fases podríamos tener el siguiente análisis:

Descubrimiento:

  • Evaluar e identificar los posibles riesgos inherentes a la modificación del Landscape actual (DES, QAS, PRD etc).
  • Ejecutar a un alto nivel un análisis de impacto en términos de compatibilidades de lo que implicaría el Upgrade (ya estaría asegurado por SAP pero nunca esta demás).
  • Contar con el pool de consultores funcionales disponibles y necesarios que probaran cada módulo de la solución (y con el conocimiento necesario).
  • Consultores técnicos empapados sobre el que, cómo y porqué del Upgrade.

Preparación:

  • Comprobar la factibilidad técnica a nivel de hardware y software presentes.
  • Comprobar la factibilidad funcional y riesgos de parada de servicio y mecanismos de contingencia posibles.
  • Comprobar otros impactos a nivel de Sizing y conectividad de ser requerido en el Landscape.

Exploración:

  • Validación de no afectación de servicio durante los test previos.
  • Planificación y diseño de la gestión de seguridad y accesos respectivos a nuevas funcionalidades (nuevos módulos Fiori, roles, etc).
  • Haber validado la planificación de los test por área funcional.
  • Planificar pruebas de migración en un SandBox.

Realización:

  • Optimización a nivel de pruebas de comprobación, estabilidad y consistencia para la reducción de riesgos y costos.
  • Comprobar a profundidad los factores técnicos y funcionales que puedan tener impactos negativos al negocio.
  • Disponibilidad del ambiente de QAS y ejecución de Upgrade controlado.
  • Preparación del CutOver correctamente.

Despliegue:

  • Asegurar coordinación a nivel de usuarios, equipo del proyecto y disponibilidad del sistema para el fin de semana del Upgrade de Producción para ir a Go-Live.
  • Asegurar y optimizar las variables técnicas asociadas en el proceso del Upgrade para evitar en lo posible las caídas de servicio.
  • Ejecución del ensayo general completado con referencia a tiempos tomados en QAS y SandBox.
  • Ejecución del CutOver sin contratiempos.

Run*:

  • Verificar los indicadores claves de performance técnico (KPIs) y correcto comportamiento del sistema.
  • Garantizar el soporte post Upgrade después del Go-Live para el usuario final designando personal clave para el monitoreo y control. 
  • * = no me gusta traducir esta fase.

Viendo las 6 fases de Activate con solamente algunos de los posibles riesgos a manejar nos damos cuenta de manera muy clara y obvia que son muchos los riesgos a contemplar a la hora de realizar un proyecto de estas características.

Clasificando los riesgos

Una buena estrategia siempre es identificar y clasificar los riesgos para poder medir el impacto durante el proyecto.

Como pudimos ver con el ejemplo anterior son muchos a simple vista, pero cada riesgo implícito dentro de las tareas presentadas pueden derivar en problemas potenciales en el proyecto.

Cada problema que nos encontremos son horas que implicaría su corrección y encauce al baseline original que manejabamos de arranque cuando dimensionamos el alcance.

La buena práctica acá es saber cuánto significa la hora de cada persona involucrada en el riesgo a mitigar para de esta manera ver el impacto de esta solución a nivel de costos derivados en el proyecto. De esta manera tendremos una idea, tomando el presupuesto del mismo, cuál será el porcentaje de incidencia de la aparición de ese riesgo en el proyecto viendo la siguiente tabla de clasificación de los riesgos:

No hay texto alternativo para esta imagen

Luego de hacer el brainstorming de riesgos la idea es clasificarlos de esta manera y al menos con esto vamos a tener una idea de los que se nos puede presentar en el proyecto durante su ciclo de vida.

Esto nos permitirá estar mejor parados tanto ante el cliente como ante nuestro grupo de proyectos, ya que “guerra avisada no mata soldados” pero como bien se sabe este dicho es a veces idealista en la realidad.

Los “riesgos típicos” en proyectos de TI

Estos riesgos que se presentan a continuación son los más frecuentes y a la vez los más generales que se ven en los proyectos. Esto no hace que muchas veces se ignoren y banalicen pensando de que “eso no nos va pasar”.

La mayoría de los riesgos que se enumeran a continuación cuentan con un alto nivel de frecuencia de aparición en proyectos de cualquier tipo.

Sumado a todo esto no olvidemos la complejidad característica de los proyectos tecnológicos y lo que estos implican en términos de su propio desarrollo, derivando en sí otra cantidad de riesgos especializados adicionales haciendo que nuestra matriz de riesgos pueda llegar a crecer de manera exponencial.

A continuación va una lista de riesgos que no son técnicos pero que se presentan naturalmente al llevar proyectos de este tipo que siempre es bueno tenerlos presentes:

  • No tomar el manejo de los cambios enserio y como una tarea crítica en el proyecto.
  • Los factores críticos de éxito no están claros y no son medibles por nadie.  
  • El cronograma de actividades no es realístico.
  • Es el presupuesto destinado es irreal o está basado en presunciones.
  • El proyecto altamente confiado a recursos subcontratados (3eros) para completar tareas claves a tiempo y no hay una forma clara de medir sus progresos.
  • El equipo no tiene mucha experiencia en implementaciones parecidas al proyecto (pocas lecciones aprendidas).
  • No están los roles de los miembros del equipo bien definidos y documentados.
  • No hay claridad en la asignación de tareas a los miembros del equipo de trabajo
  • Poca holgura de tiempo o contingencia dentro del cronograma del proyecto para contrarrestar imprevistos.
  • Poco o nada de un plan de comunicaciones del proyecto.
  • Dedicación exclusiva/parcial del gerente del proyecto para enfocarse en el éxito del mismo.
  • ¿Está siendo bien “gerenciado” el cronograma del proyecto en todas sus fases? Esto es algo clave y que hay que preguntárselo a cada rato hasta que termine el proyecto.
  • La posibilidad de que los recursos claves del proyecto puedan ser cambiados durante el ciclo de vida del proyecto. Contingencias de este tipo nunca están demás.
  • Actividades y tareas pobremente documentadas en las fases iniciales y a veces poco realistas en tiempos de ejecución (más complicado aún cuando se vende un proyecto llave en mano con fecha final y hay que “ajustarse” a eso).
  • El alcance, visión, objetivos y entregables del proyecto no están claramente definidos o entendidos.
  • El cronograma está basado en usar ciertos miembros específicamente, pero estos no están disponibles por X motivo.
  • El proyecto no tiene un soporte a nivel gerencial experimentado (fatal).
  • El esfuerzo es mayor que el estimado. ¿Cómo se negocia con el cliente y se maneja esto?
  • La fecha objetivo fue movida sin hacer los cambios correspondientes ajustando el alcance del producto o los recursos disponibles.
  • Los estándares del proyecto son irreales o no existen. Dejar el alcance abierto produce este tipo de riesgos.
  • Una metodología burocrática (waterfall) que no entregue soluciones parciales acotadas en tiempo y solo al final del proyecto.
  • El control del progreso del proyecto es inexacto y no se sabe en qué parte del proyecto se va, si se va por delante o detrás de lo planificado. Cada quien reporta lo que quiere y no hay seguimiento real de lo que hace cada quien.
  • Los miembros del equipo más calificados no están disponibles para el proyecto.
  • Enfermedades de algún miembro del proyecto y si este ha documentado su solución para que sea fácilmente tomada por algún recurso de relevo.
  • Las asignaciones a los miembros del equipo no corresponden con su experticia.
  • Los miembros del equipo necesitan de un tiempo extra para el aprendizaje de habilidades y nuevos procesos y no se contempló antes.
  • Los miembros del equipo no se acoplan con el proyecto y no dan los resultados esperados.
  • No se utilizan herramientas para el gerenciamiento del proyecto (he visto proyectos llevados con Excel y el “GP” notificando por Whatsapp el estado del mismo.
  • No se proporciona un entrenamiento al usuario final, impidiendo de esta manera que se logre utilizar al máximo el potencial de la solución ofrecida como producto del proyecto.

Para cerrar…

Siempre uno se encuentra con gente que se ríe o subestima este tipo precauciones algo meticulosas a la hora de gerenciar un proyecto.

Es muy posible que para nuestra fortuna pocas veces se susciten estos escenarios posiblemente fatalistas que definen un posible riesgo.

Pero acá aplica la máxima de un comercial de Seguros que dice así:

“Es mejor tenerlo y no necesitarlo, que necesitarlo y no tenerlo”.

Es casi de-facto que las personas que se banalizan la gerencia de riesgos tienen un grado de instrucción muy pobre o excesivamente empírica en lo que respecta el mundo de la gerencia de proyectos, por lo que por salud mental es mejor no prestarles atención.

Al final de todo esto la idea que se busca es contar con un insumo que nos sirva a nosotros como gerentes de proyectos contar con herramienta de defensa ante futuros eventos imprevistos de la mejor manera posible y lograr así un proyecto exitoso en un momento tan caótico como el que vivimos.

Fin.

* Si llegaste al Fin (a pesar de lo largo) gracias por tu lectura y espero te sea útil y bienvenidos los comentarios