Riskout International

Hace algunos años, como PM en una multinacional, tomé a cargo un proyecto para un sistema que iba a cambiar fuertemente la forma de trabajar de un sector, y lo que cambió fue mi forma de ver a los proyectos.

En principio, era un sector crítico y el sistema tenía que resolver el día a día, con operaciones de cientos de miles de dólares, y tenía que ser en tiempo real, interactuando con varias fuentes de información externas, ya que trabajaba con cotizaciones en diferentes mercados del mundo.

Esto ya lo hacía complejo, pero aún había más. La metodología de análisis era nueva en la compañía, con una herramienta CASE para el diseño, y el lenguaje seleccionado por mi jefe en ese momento era también nuevo y nunca usado en otro proyecto. A esta altura, podrán imaginarse la complejidad, pero la complicamos un poco más, contratando una consultora externa para el desarrollo, que estaría bajo mi mando.

La relación con el usuario era inmejorable y comenzamos a trabajar en el proyecto.

Las definiciones en la nueva herramienta llevaban mucho tiempo pero la calidad de lo producido era inmejorable. Los primeros documentos llenaron de asombro a muchos, y a decir de la consultora contratada, era la primera vez que le entregaban algo tan bien definido y con tanta profundidad, cosa que repetía mi jefe en cuanta ocasión se presentaba.

Uno podría decir que con este panorama, la probabilidad de un proyecto exitoso era alta, aún a pesar de la complejidad, pero…

Como todos los proyectos de la compañía, se hizo utilizando una metodología de proyecto tradicional (CDS), donde TODO debe estar definido desde el principio. Era fácil porque los documentos de alcance eran exhaustivos, y la conformidad del usuario era total, sin embargo…

Cuando los primeros cambios comenzaron a llegar desde el sector usuario, y comenzaron los procesos burocráticos de la aprobación de esos cambios, los problemas aparecieron. Se tardaba mucho en aprobarlos y si bien la herramienta de diseño era ágil para implementarlos y tenía análisis de impacto, había que generar nuevamente documentación para la consultora contratada, que muchas veces ya estaba trabajando o había terminado, alguno de los módulos a cambiar.

Esto llevaba a procesos de cambio muy largos, muchos con impactos fuertes y mayores costos, lo que hacía que el usuario estuviera cada vez menos proclive a esperar por la aprobación de algo que aún no veía ni podía probar, y que no estaba seguro de que fuera el último cambio sobre el mismo tema por la dinámica del negocio. Los pedidos de cambio disminuyeron, no porque no hicieran falta, sino por la falta de respuesta tangible para el usuario.

Sobre el final, un par de meses antes de la implementación (en un proyecto de 15 meses), se produjo un cambió de gerente en el área y el nuevo, proveniente de la misma función en otra filial más pequeña, decidió utilizar un sistema que él ya había usado en su posición anterior, y por consiguiente, el proyecto fue cancelado.

MORALEJA:

Este era un típico caso para la utilización de metodología ágil de proyectos. Gran complejidad, muchos cambios previsibles en el alcance, nuevas tecnologías, área crítica con necesidades urgentes, entre otros temas.

La metodología ágil nos hubiera permitido tener entregas parciales de partes funcionando en períodos cortos (normalmente 30 días o menos) y esto hubiera descomprimido la labor manual de los operadores y el registro a destiempo, motivándolos mucho sobre el desarrollo del proyecto.

También hubiera permitido ir incorporando los cambios y priorizando los módulos a medida que se avanzara, sin que esto representara una carga burocrática ni un examen permanente para el usuario, dado que el cambio es parte del proceso y no una excepción en este tipo de metodologías. Un ajuste tanto funcional como de prioridades en períodos cortos hubiese generado una excelente dinámica.

Por último, el tener partes funcionando hubiera hecho que todo lo generado tuviera valor para la compañía, y que la decisión de tomar un sistema nuevo, hubiese tenido que compararse contra funciones activas y no una promesa futura, y la nada en la operación.

Fue una lección aprendida, quizás con una pequeña excusa… en ese momento, las metodologías como SCRUM, o Agile Project Management, eran poco conocidas por estas tierras y estaban muy verdes en el mercado global.

Ahora, ya lejos de aquella compañía, en Riskout International hemos diseñado nuestra propia metodología ágil (Agile ROI PM), y preparamos a nuestros clientes en ésta y las mencionadas anteriormente, con muy buenos resultados, la mayoría inmediatos.

Por suerte, podemos decir que no todo tiempo pasado fue mejor…