CHEIN Consultores, S.C.

El Agile Project Management (APM) es un movimiento iconoclasta orientado a revolucionar el mundo de la administración de proyectos y a dejar obsoletos los rígidos esquemas existentes en e mundo de las TI.

¿Podemos seguir pensando que un proyecto resultó ser exitoso porque atendió a detalle todos los requerimientos originales planteados por el usuario final, además de que se concluyó en el tiempo y el presupuesto estimados? ¿Qué pasa entonces si después de un mes de estar operando el nuevo sistema o la nueva propuesta tecnológica, la percepción de los usuarios es que no ganaron mucho porque para ellos no resulta claro cómo es que la nueva propuesta generó valor? ¿Qué pasa si la mayoría de los supuestos que sustentaron la inversión no resultaron verdaderos y el proyecto resulta ser todo un fiasco desde el punto de vista del negocio? Pensemos en supuestos como el número de transacciones esperadas a través de Internet, factor clave para estimar el retorno de inversión o para la definición de la arquitectura e infraestructura de un nuevo sistema (inversión requerida).

Habría que empezar por reconocer que los proyectos de Tecnologías de Información son cada vez más complejos y que su éxito depende, además de elementos técnicos de por si ya complejos, de factores organizacionales y de comunicación dentro de organizaciones vivas que se desenvuelven dentro de un entorno dinámico, volátil y altamente competitivo. Imaginemos por ejemplo, la puesta en operación de un sistema de información para soportar un nuevo proceso de negocios, en donde simultáneamente estaremos cambiando de un plataforma de COBOL, DB2 que funciona sobre un sistema mainframe, hacia una arquitectura WEB de múltiples capas, bajo ambiente Java y Oracle. ¿Cual podría ser el resultado? Imaginemos algunos escenarios:

"El proyecto funciona pero los usuarios están insatisfechos", "Invertimos seis meses en el diseño del sistema del cual no se preveía un costo tan elevado para su implementación", "el proyecto es un caos, los usuarios han cambiado el 60 por ciento de los requerimientos", o peor aún, "el sistema funciona conforme a los requerimientos iniciales pero dificultó la operación del negocio, por lo que no se va a utilizar". Es altamente probable llegar a uno de los escenarios anteriores y la excepción sería que, además de cumplir con los requerimientos definidos y se completara en el tiempo y presupuesto planeado, dejara satisfechas a todas las partes involucradas (ejecutivos y patrocinadores, usuarios y áreas técnicas) y sobre todo generara valor para la organización.

La pregunta clave es ¿por qué si todos reconocemos que la dinámica y rapidez con la que se suceden los cambios dentro de las organizaciones, la complejidad y diversidad de tecnologías y arquitecturas existentes, además del impacto operativo y por tanto financiero de las Tecnologías de Información, han cambiado dramáticamente durante los últimos 15 años, seguimos utilizando en gran medida los mismos modelos de toma de decisiones, planeación y desarrollo de proyectos de TI? ¿Por qué seguimos utilizando el viejo esquema que parte de la base de que al inicio contamos con la información suficiente para definir los requerimientos, que estos no van a cambiar, que podemos medir los riesgos y por tanto generar un plan de trabajo correcto? ¿Por qué formamos e integramos unidades especializadas para ver si "el avance del proyecto se está ejecutando frente a lo planeado (PMO)", aún cuando la realidad nos deja ver que los supuestos originales cambiaron y que el proyecto no va a generar el valor esperado? ¿Quién le dirá esto a los directivos y patrocinadores de proyecto? ¿Quién les informará que el proyecto costará 70 por ciento más de lo originalmente estimado, que la infraestructura de cómputo es insuficiente, que la tecnología originalmente seleccionada no está lo suficientemente madura y que aunque en el brochure del proveedor parece fantástico, la realidad es que no existen técnicos disponibles para dar el soporte técnico necesario? ¿Quién será entonces el responsable de informar esta situación a los directivos, en el momento indicado, para tomar alguna decisión: reencausar el proyecto o definitivamente abortarlo?

Se trata de proporcionar la información necesaria en el tiempo correcto. No cuando el sistema web está ya operando y pocos lo utilizan porque resulta poco práctico para los usuarios, no cuando ya nos gastamos arriba del 50 por ciento del presupuesto en documentar un análisis y diseño que los usuarios rechazaron porque finalmente aprendieron a lo largo de este proceso que requieren nuevas funcionalidades, que cambiaron sus prioridades; no cuando se tomaron decisiones erradas respecto a la arquitectura tecnológica y hay que dar marcha atrás porque resulta impráctica la implantación.

Agile Project Management (APM) es un movimiento que rompe muchos de los paradigmas detrás de los métodos tradicionales de administración de proyectos, como las establecidas por el Project Management Institute (PMI) buscando dar mejores resultados y respuestas oportunas para los tomadores de decisión. "Ser ágil" representa, como lo señala Jim Highsmith, uno de los promotores de este movimiento, la habilidad de crear y responder a los cambios. Preparar el ambiente organizacional y las prácticas de administración de proyectos hacia la innovación, hacia la búsqueda de aquellos cambios que permitan diferenciarnos y anticiparnos frente a nuestros competidores o responder con prontitud frente a ellos. La agilidad nos señala Highsmith, es más una actitud que un proceso, más ambiente que metodología.

El "Manifiesto for Agile Project Managemet" (http://agilemanifiesto.org/) establece los siguientes valores como guía de esta nueva alternativa para la administración de proyectos:

* Individuos e interacciones sobre los procesos y herramientas

* Entrega de funcionalidades sobre actividades regulatorias (Delivering features over complience activities)

*Colaboración del cliente sobre negociación de contratos.

*Responder a los cambios sobre el seguimiento de un plan.

Y no es que las herramientas, los procesos, el cumplimiento de normas, los contratos, o los planes no sean importantes, simplemente es que los elementos del lado izquierdo de cada uno de los enunciados anteriores, son más importantes desde la perspectiva "ágil". ¿Para que gastamos un día de una persona en documentar el diagrama que ayer diseño el equipo de trabajo? Saquémosle una fotografía digital y avancemos más rápido en generar resultados. Ese sería un planteamiento ágil.

En el modelo de Agile Project Management, la ejecución predomina sobre la planeación y el control. En vez de poner énfasis en el desarrollo de planes y programas de trabajo y controlar el avance de los mismos, bajo la óptica de "estamos conforme al plan" o en su defecto tratar de corregir las desviaciones frente a éste, utilizando un esquema secuencial, bajo APM el administrador de proyectos debe crear la visión del producto y guiar al equipo de trabajo para transformar esta visión en realidad. Y bajo un método interactivo, altamente colaborativo en el que los usuarios podrán utilizar y enriquecer los componentes del sistema (funcionando), que recibirán en cada ciclo recorrido, no se valorará el avance frente al plan, sino en cambio el valor que el proyecto está generado ya para los usuarios. Se trata pues de un modelo para generar resultados tangibles bajo ciclos muy cortos (dos a tres semanas), en donde la realidad predomina frente al plan y la meta y factor de éxito del administrador de proyecto se convierte en generar el valor de negocios esperado. La evaluación del avance del proyecto se medirá entonces no analizando una gráfica de gannt que nos ilustre el desfase o cumplimiento de actividades, sino valorando el funcionamiento de piezas de software que ya están funcionando.

Como en la mayoría de los temas alrededor de las TI no existen recetas mágicas o caminos únicos para el éxito de los proyectos. No en todos los casos los principios, conceptos y propuestas detrás de APM nos garantizarán el éxito o siempre resultarán adecuados. Sin embargo, resulta imperante valorar los resultados obtenidos bajo los sistemas tradicionales de administración de proyectos, ser críticos, y considerar un cambio hacia prácticas que está demostrado tener mejores resultados. No estamos diciendo que toda la teoría y metodologías tradicionales de administración de proyectos como las establecidas por el Project Management Institute (PMI) estén fuera de lugar y no deban ser utilizadas, de hecho en muchos sentidos se complementan. Diversas prácticas y herramientas de APM y PMI son las mismas, la diferencia estriba en los supuestos en que se basan y las estrategias que utilizan, de ahí que la instrumentación de esas prácticas y herramientas generarán resultados diferentes.

Pero, entonces ¿Cuando utilizar APM? Todo dependerá del tipo de proyecto y de organización en la que se quiere desarrollar. La experiencia nos señala que bajo alguna o varias de las siguientes condiciones APM resultaría una mejor alternativa frente a las practicas del PMI:

* Proyectos con un alto grado de exploración. Utilización de nuevas tecnologías, que respondan a nuevas iniciativas de negocios y en donde se prevea que los requerimientos serán muy volátiles.

* Proyectos en donde la comunicación con los usuarios/ clientes es considerada como un factor crítico.

* Proyectos en donde las organizaciones son flexibles y prevalece una cultura de innovación. Organizaciones que tienen la habilidad de responder a cambios anticipados o inesperados, creados por sus clientes y/o competencia.

Los valores, principios y herramientas propuestas por los defensores del PMO y que originalmente se pensaron solo para el desarrollo de sistemas (agile software development), son ya una realidad y están siendo instrumentados exitosamente y han ido madurando hasta convertirse en una alternativa real para la administración de proyectos. Sin lugar a dudas estar abiertos y conocer los principios, métodos, herramientas y ventajas de la Administración ágil de proyectos es hoy una obligación que puede generar grandes beneficios para los CIO's y cuerpos de gobernabilidad de TI dentro de las organizaciones. Consideremos un cambio.