Riesgos vs Problemas

risk-register.jpgHace ya muchos años fui asignado a un proyecto cuyo objetivo era desarrollar un sistema que integrara algunas pantallas de aplicaciones ya existentes dentro de un solo flujo de pasos, algo parecido a un workflow o wizard (aplicación que tiene diferentes etapas en las que el sistema recibe información y cuyo orden de captura es importante. También puede verse como una serie de pasos para completar una tarea), dado que los sistemas estaban desarrollados en plataformas diferentes pude anticipar que tendríamos algunos riesgos y problemas que resolver en su momento.

Ambiente del proyecto

Yo trabajaba en una compañía de telecomunicaciones que recientemente había comprado una compañía de TV por cable y tanto nuestros sistemas como los de la nueva compañía habían sido creados para plataformas tecnológicas diferentes .

Iniciamos el proyecto con dos desarrolladores y un analista  quien también participaba de las decisiones técnicas del proyecto. Por parte de la empresa cablera habían asignado a su mejor ingeniero, al de mayor experiencia y antigüedad y a dos de los mejores técnicos de sistemas quienes habían desarrollado su plataforma de aprovisionamiento de información.

Riesgos del proyecto

Por ser un proyecto pequeño decidí no formalizar mucho el ejercicio de identificación de riesgos, además, mi clara inclinación por pensar que el riesgo preponderante eran las múltiples plataformas tecnológicas que debíamos integrar nubló mi ejercicio de análisis y búsqueda de otro tipo de riesgos.

A esas alturas mi risk register contenía sólo un registro y el plan de mitigación no tenía pasos concretos a seguir para evitar, transferir o mitigar el riesgo.

Uno de los sistemas, el más importante, no pertenecía a la compañía en la que yo trabajaba, sino a la filial recién adquirida, así que los riesgos aumentaban en ese punto. Los miembros de la compañía de TV no estaban del todo contentos con la transacción de compra-venta y era claro que también estaban nerviosos (las bolsas de trabajo están llenas de curriculums vitae de empleados  descontentos y nerviosos por el futuro de su compañía).

Adicional a todo esto, las fechas que había establecido la dirección comercial eran muy agresivas, ya que el sistema sería utilizado para aprovisionar información de ventas en las diferentes plataformas para lograr tanto el registro de la información del cliente como la configuración del servicio recién vendido.

El problema

Para hacer más corto el relato, a la altura en la que estábamos haciendo las primeras pruebas de integración de las plataformas, el empleado más importante de la compañía de TV fue sacado del proyecto para atender asuntos pendientes urgentes de su compañía y los empleados de apoyo renunciaron.

La compañía cablera asignó dos ingenieros más al proyecto, pero éstos no conocían las plataformas con las que estábamos trabajando, de tal manera que se anticipaba una larga curva de aprendizaje.

El intento por resolver el problema

En ese momento mi issue log se llenó inmediatamente. La lista de problemas que se había registrado era interminable. Era imposible atender tantos problemas de alta prioridad al mismo tiempo con poco apoyo por parte del equipo técnico y con la presión del equipo ejecutivo quien ya estaba lanzando las primeras campañas publicitarias en las que le ponían fecha al lanzamiento del nuevo servicio “Triple Play” (Telefonía, Internet y TV por cable).

Fueron largas noches de trabajo las que invertimos para resolver todos los problemas que se generaron. La compañía de TV regresó al experimentado ingeniero al proyecto y eso favoreció mucho a la pronta resolución de los problemas.

Lecciones Aprendidas

Después de que la adrenalina bajó me puse a pensar, ¿por qué un proyecto que ciertamente presentaba reto se había convertido en un dolor de cabeza tan pronto? Debía haber una manera de prever los problemas que ocurrirían con cierta anticipación y no tan repentinamente.

Analizando encontré algunos defectos en mi manera de administrar el proyecto, principalmente el de no haber hecho un ejercicio adecuado de administración de riesgos.

La administración de riesgos supone la creación de un registro de riesgos, un análisis cualitativo y cuantitativo de los riesgos, una discriminación de aquellos poco probables de ocurrir o con poco impacto y la creación de planes de mitigación, transferencia o aceptación junto con un plan de contingencia para cuando ocurran.

Con lo anterior quiero decir que independientemente del tamaño y naturaleza del proyecto debemos hacer un análisis de los riesgos y registrar estos en un documento. No importa si el riesgo es pequeño o improbable, como líderes del proyecto necesitamos registrarlos.

Una vez establecido este documento al que llamamos risk register, es necesario analizar qué tan probable es que ocurran esos riesgos y, de hacerlo, cuál sería el impacto para el proyecto. Hay muchas técnicas para hacer esto, pero más bien quiero concentrarme en el siguiente paso que fue el que me provocó más problemas.

Hasta este punto un riesgo puede ser mitigado (reducido su probabilidad de ocurrir), evitado o aceptado, es decir, es posible planear maneras para que su impacto sea menor, su probabilidad sea menor o simplemente planear cómo vamos a afrontar los problemas que surgirán en el momento en el que ocurra.

Cuando un riesgo ocurre esto da lugar a problemas (issues) y es aquí donde tenemos que dejar de administrarlos dentro del registro de riesgos y empezar a manejarlos dentro del log de problemas para  resolverlos de acuerdo a los planes definidos de mitigación y respuesta .

El riesgo de perder a los ingenieros de la compañía de TV por cable se hizo realidad y yo ni si quiera lo había considerado en el risk register. Los problemas afloraron y yo no tenía planes de contingencia. Esto dio a lugar esfuerzos desmesurados, largas noches y descontento en el equipo.

Recomendaciones finales

Antes de terminar este post quiero hacer énfasis en un par de cosas. Aunque considero que dejé claro que hay que analizar todos los riesgos probables dentro de nuestro proyecto, esto no quiere decir que debemos planear como si todos fueran a ocurrir.

Debemos ser prácticos y planear sobre aquellos que son más probables de ocurrir y sobre aquellos cuyo impacto sería mayor en el momento de ocurrir. Por ejemplo, yo no me enfocaría en realizar planes de contingencia para un riesgo que tenga 0.05% de probabilidad de ocurrir y/o cuyo impacto nos obligue solamente a reemplazar un foco con valor de 0.50 pesos, pero definitivamente si registraría el riesgo a manera de documentación.

Otra cosa, los riesgos se administran como eventos probables de ocurrir y mientras haya tiempo para planear en acciones que los eviten o disminuyan, hay que hacerlo, es una inversión. Los problemas se administran como eventos que ya ocurrieron y se espera que se resuelvan de acuerdo con el plan de contingencias.

En resumen, en el mundo ideal no debería haber sorpresas en los proyectos. Los líderes de proyectos son contratados para llevar un proyecto a un término exitoso y con el menor número de sorpresas.

Por Fernando Valdez

5 Responses to “Riesgos vs Problemas”

  1. Hector Says:

    Claro, hay que planear los riesgos. Aunque en esta ocasión que comentas yo veo difícil que cualquiera llegara a planear una contingencia.

    Es decir, aunque el impacto sea grandísimo, ¿qué posibilidad hay de que de tus 3 ingenieros, los 3 se vayan repentinamente?

    Lo más viable y de bajo costo tal vez sería siempre documentar lo que se está haciendo; esperando que los nuevos ingenieros entiendan rapidamente.

  2. Claudio Says:

    El riesgo existía y era visible. Las compañias recién se fundían, si bien se conocía la experiencia de los 3 ingenieros, nunca se había trabajado con ellos, la experiencia misma los convertía en recursos altamente requeridos por otros proyectos (como ocurrió)… pero el mayor de los riesgos es que no se tenía injerencia sobre esos recursos.
    El intento por resolver el problema, a mi entender, no existió, ya que no se hizo nada (o por lo menos no se explica aquí) Un intento podría ser replantear a los superiores los objetivos.
    No se puede “esperar” a que los nuevos entiendan rápidamente, ese es un nuevo riesgo… y peor!… asumiéndolo y dándolo como “resuelto” al dejar a la suerte su resolución.

  3. Carlos Franco Says:

    Normalmente en mi experiencia en implementación de tecnología, el principal problema no suele ser tanto la tecnología a implementar sino el factor humano como en tu caso. Para mi que desde el inicio del proyecto deberías identificar tu key point que fue tu ingeniero y atarlo al proyecto, haciendo entender a tus gerentes respecto a esto. No se puede quitar el pilar principal del edificio y pretender continuar construyendo encima. Los gerentes a no ser que sean del área generalmente conocen poco sobre tecnología y se tiene la falsa creencia que una vez que se compra, se conecta todo y ya funciona, pero cuando luego se desatan los problemas es muy difícil solucionarlo y esto afecta a tu imagen que se debilita. Mas suerte en la próxima. :)

  4. Brenda Says:

    estoy totalmente de acuerdo

  5. JORGE Says:

    Estoy totalmente de acuerdo con Carlos Franco, es por eso de la importancia de la formalización del inicio del proyecto mediante un project charter, ya que en el se asienta en compromiso de todos los stakeholders del proyecto, y de esta forma, preveer riesgos como el planteado de recurso humano clave y condiciones sobre las que se parte como condicionantes y supuestos considerados para el asegurameinto del cumplimiento de los objetivos del proyecto.

Leave a Reply