Tendencias Científicas
Cuitláhuac Osorio Ayllón, directivo de Cutter Consortium México, en un estudio que publicó en Intermanagers, afirma que 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, propone, 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?”, pregunta. Para encontrar la respuesta invita a que 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 cambiaron el 60% 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, dice Ayllón, 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.
Con la mirada en el pasado
Para Aylló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, cambiaron 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?
Se trata, sostiene, 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% 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.
Contra los viejos paradigmas
Agile Project Management (APM) es un movimiento que rompe muchos de los paradigmas que están 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, recuerda Ayllón a Highsmith, es más una actitud que un proceso, más ambiente que metodología.
El Manifiesto for Agile Project Managemet 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.
¿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 prácticas 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.
Imaginemos, propone, 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?”, pregunta. Para encontrar la respuesta invita a que 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 cambiaron el 60% 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, dice Ayllón, 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.
Con la mirada en el pasado
Para Aylló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, cambiaron 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?
Se trata, sostiene, 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% 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.
Contra los viejos paradigmas
Agile Project Management (APM) es un movimiento que rompe muchos de los paradigmas que están 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, recuerda Ayllón a Highsmith, es más una actitud que un proceso, más ambiente que metodología.
El Manifiesto for Agile Project Managemet 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.
¿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 prácticas 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.
Inicio
Enviar a un amigo
Versión para imprimir
Compartir
Nuevo software enseña estrategias de marketing a través del juego
CIENCIA ON LINE