¿Hay que librarse de esta metodología?
Búsqueda del compromiso, coordinación y relaciones
Después de 40 años de esfuerzo sostenido, la mayoría de los informes indican que más de la mitad de los proyectos de desarrollo de sistemas sufren retrasos, son cancelados o son considerados como fracasos por los usuarios comerciales. Cuando personas competentes obtienen resultados deficientes una vez tras otra, hay que someter a escrutinio su actividad.
Las empresas y organizaciones se mueven entre dos extremos. La tradición sistemática ha sido creada en torno a métodos como el ciclo de vida de desarrollo del software o SDLC (Software Development Life Cycle), la ingeniería de software asistida por ordenador o CASE (Computer Aided Software Engineering), la en otro tiempo influyente BSP (Business Systems Planning) de IBM, el análisis y determinación del tamaño de proyectos mediante puntos funcionales y el Method/I de Andersen Consulting. La tradición de relación, por su parte, ha dado lugar a la utilización de prototipos, el Joint Application Development de IBM y el groupware.
Estos elementos no se combinan bien entre sí. El enfoque sistemático se convierte con demasiada facilidad en una burocracia de gestión de proyectos y olvida el lado organizacional de la implementación, especialmente al no mirar más allá del proyecto mismo para considerar también la educación, el soporte técnico y la implementación. En el enfoque de relación, por su parte, se deja con frecuencia de considerar la necesidad de un control altamente disciplinado del trabajo técnico. Además, una iniciativa compleja, como un sistema de planificación de recursos de empresa o ERP, requiere muchos subproyectos, equipos, relaciones y agendas de actividad, tanto técnicos como organizacionales.
El éxito demanda que todos estos elementos encajen bien unos con otros. Sin embargo, por lo general, el equipo de trabajo que diseña el modelo de datos físicos no toma en consideración las futuras necesidades de personal, al equipo de usuarios no le preocupa la configuración de los servidores, y los programadores de sistemas no se mantienen en comunicación con el equipo comercial que trabaja en simplificar y racionalizar los procesos comerciales cliente-proveedor. El resultado es que todo el mundo piensa que su parte del proyecto cumple con las fechas establecidas, cuando la realidad es que el proyecto se encuentra en su totalidad al borde del desastre.
Nuevas ideas
Existen sistemas basados en la Web que puede ser la luz al final del túnel. Uno de ellos es ActionWorks Express de Action Technologies, basado en ideas y recomendaciones sobre cómo las unidades o departamentos TI pueden transformar sus empresas, relaciones y beneficios.
Express recuerda la revolución de las hojas electrónicas, creada por Visicalc y acelerada por Lotus 1-2-3. Visical dio lugar a una nueva forma de pensar sobre presupuestos y planificación financiera. De forma similar, Express es un marco o framework mental y de procesos, para ver la gestión de proyectos como la coordinación de un conjunto total de compromisos que incluyen muchos tipos de equipos, prioridades y variedades de trabajo. Las tareas técnicas son parte de esta combinación, y todas ellas deben ser consideradas y resueltas desde una perspectiva de arriba abajo respecto a la forma en que encajan entre sí, y de abajo arriba en términos de sus requerimientos individuales, naturaleza y necesidad de estructura vs. flexibilidad.
Este producto incorpora un punto de vista importante: Para un desarrollo de software y una integración de sistemas con éxito se requiere una gestión de compromisos adquiridos, no una gestión de proyecto. Las compañías deberán re-comenzar sus procesos TI en torno a compromisos técnicos y organizacionales y en torno a las relaciones entre ellos. Generalmente, los compromisos en tecnología están definidos y determinados por especificaciones de diseño, planes de fechas y productos a suministrar.
Aunque todo esto continúa siendo necesario, los compromisos organizacionales y sus inter-relaciones con los componentes de tecnología están definidos más bien por relaciones, comunicación e interacción. Esto significa un seguimiento de las negociaciones, acuerdos mutuos, re-negociaciones, sincronización e interdependencias, aspectos que con frecuencia son pasadas por alto por los directores de proyecto y por sus herramientas.
La gestión de los compromisos requerirá una reestructuración o renovación de las herramientas. Las herramientas tradicionales –SDLC, CASE, BSP y groupware– incorporan el modelo de proceso consistente en sistemas, ingeniería y estructura. La nueva corriente en el área de los negocios es la coordinación de relaciones, cadena de suministro, alianzas, equipos de trabajo, etc. Esa es la dirección que debe seguir la Tecnología de la Información y su “caja de herramientas”.
Hay que liberarse de toda la actitud mental y de todo el aparato que rodea a la gestión de proyectos. El mensaje respaldado por la propia Tecnología de la Información sobre la re-ingeniería de procesos era que las empresas tenían que transformar radicalmente los procesos que afectan más a las relaciones con los clientes. Y la organización TI debe transformar los procesos que más afectan a los beneficios que produce, a su credibilidad y a sus relaciones con los clientes. Si se sustituyen los proyectos, la gestión y los planes de fechas por compromisos, coordinación y relaciones, la transformación se habrá puesto en marcha.
Las empresas y organizaciones se mueven entre dos extremos. La tradición sistemática ha sido creada en torno a métodos como el ciclo de vida de desarrollo del software o SDLC (Software Development Life Cycle), la ingeniería de software asistida por ordenador o CASE (Computer Aided Software Engineering), la en otro tiempo influyente BSP (Business Systems Planning) de IBM, el análisis y determinación del tamaño de proyectos mediante puntos funcionales y el Method/I de Andersen Consulting. La tradición de relación, por su parte, ha dado lugar a la utilización de prototipos, el Joint Application Development de IBM y el groupware.
Estos elementos no se combinan bien entre sí. El enfoque sistemático se convierte con demasiada facilidad en una burocracia de gestión de proyectos y olvida el lado organizacional de la implementación, especialmente al no mirar más allá del proyecto mismo para considerar también la educación, el soporte técnico y la implementación. En el enfoque de relación, por su parte, se deja con frecuencia de considerar la necesidad de un control altamente disciplinado del trabajo técnico. Además, una iniciativa compleja, como un sistema de planificación de recursos de empresa o ERP, requiere muchos subproyectos, equipos, relaciones y agendas de actividad, tanto técnicos como organizacionales.
El éxito demanda que todos estos elementos encajen bien unos con otros. Sin embargo, por lo general, el equipo de trabajo que diseña el modelo de datos físicos no toma en consideración las futuras necesidades de personal, al equipo de usuarios no le preocupa la configuración de los servidores, y los programadores de sistemas no se mantienen en comunicación con el equipo comercial que trabaja en simplificar y racionalizar los procesos comerciales cliente-proveedor. El resultado es que todo el mundo piensa que su parte del proyecto cumple con las fechas establecidas, cuando la realidad es que el proyecto se encuentra en su totalidad al borde del desastre.
Nuevas ideas
Existen sistemas basados en la Web que puede ser la luz al final del túnel. Uno de ellos es ActionWorks Express de Action Technologies, basado en ideas y recomendaciones sobre cómo las unidades o departamentos TI pueden transformar sus empresas, relaciones y beneficios.
Express recuerda la revolución de las hojas electrónicas, creada por Visicalc y acelerada por Lotus 1-2-3. Visical dio lugar a una nueva forma de pensar sobre presupuestos y planificación financiera. De forma similar, Express es un marco o framework mental y de procesos, para ver la gestión de proyectos como la coordinación de un conjunto total de compromisos que incluyen muchos tipos de equipos, prioridades y variedades de trabajo. Las tareas técnicas son parte de esta combinación, y todas ellas deben ser consideradas y resueltas desde una perspectiva de arriba abajo respecto a la forma en que encajan entre sí, y de abajo arriba en términos de sus requerimientos individuales, naturaleza y necesidad de estructura vs. flexibilidad.
Este producto incorpora un punto de vista importante: Para un desarrollo de software y una integración de sistemas con éxito se requiere una gestión de compromisos adquiridos, no una gestión de proyecto. Las compañías deberán re-comenzar sus procesos TI en torno a compromisos técnicos y organizacionales y en torno a las relaciones entre ellos. Generalmente, los compromisos en tecnología están definidos y determinados por especificaciones de diseño, planes de fechas y productos a suministrar.
Aunque todo esto continúa siendo necesario, los compromisos organizacionales y sus inter-relaciones con los componentes de tecnología están definidos más bien por relaciones, comunicación e interacción. Esto significa un seguimiento de las negociaciones, acuerdos mutuos, re-negociaciones, sincronización e interdependencias, aspectos que con frecuencia son pasadas por alto por los directores de proyecto y por sus herramientas.
La gestión de los compromisos requerirá una reestructuración o renovación de las herramientas. Las herramientas tradicionales –SDLC, CASE, BSP y groupware– incorporan el modelo de proceso consistente en sistemas, ingeniería y estructura. La nueva corriente en el área de los negocios es la coordinación de relaciones, cadena de suministro, alianzas, equipos de trabajo, etc. Esa es la dirección que debe seguir la Tecnología de la Información y su “caja de herramientas”.
Hay que liberarse de toda la actitud mental y de todo el aparato que rodea a la gestión de proyectos. El mensaje respaldado por la propia Tecnología de la Información sobre la re-ingeniería de procesos era que las empresas tenían que transformar radicalmente los procesos que afectan más a las relaciones con los clientes. Y la organización TI debe transformar los procesos que más afectan a los beneficios que produce, a su credibilidad y a sus relaciones con los clientes. Si se sustituyen los proyectos, la gestión y los planes de fechas por compromisos, coordinación y relaciones, la transformación se habrá puesto en marcha.
