Los criterios para el éxito de un proyecto de TI
El 69% de los proyectos tecnológicos fracasa, según The Standish Group
Hay una tradición en la dirección de proyectos de TI que establece que un proyecto es un éxito si se cumple en plazo, sin pasarse del presupuesto y con las funciones requeridas. Cumplir esos parámetros es bastante complicado. De hecho, un estudio realizado por The Standish Group señala que sólo el 29% de los proyectos tiene éxito.
Un estudio elaborado por The Standish Group muestra, tras analizar retrospectivamente 72 proyectos de TI en 57 empresas distintas desde 1999, que proyectos que habían cumplido todos los criterios tradicionales para considerarlos un éxito (tiempo y dinero) habían acabado, pese a todo, en fracaso porque no supieron atraer a los usuarios potenciales o porque no implicaron demasiados beneficios para la empresa. Estos casos se denominan por la consultora “éxitos fallidos”, ya que el proyecto cumplía con todos los requisitos, pero no consiguió integrarse en los procesos financieros de la compañía, con lo que, al final, pasaron desapercibidos. Según explicó el CIO de una gran empresa, “la aplicación funciona al 100% cuando hay una participación del 100% y al 0% cuando lo utiliza un 95%”.
Del mismo modo, algunos proyectos, que se podrían considerar un fracaso según los parámetros tradicionales de TI, pueden acabar siendo exitosos porque, pese a sus problemas de coste o tiempo, el sistema triunfa entre su audiencia potencial o acaba dando unos beneficios inesperados.
Nuevos principios
Muchas veces, puede que el verdadero impacto de un proyecto no se llegue a apreciar hasta mucho tiempo después de que se complete su implantación. Según la consultora Standish Group, en un proyecto, más allá de las tradicionales medidas de tiempo y coste, deben aplicarse otros criterios para determinar su éxito, como son el grado de utilización del sistema o servicios, y de beneficio, donde el proyecto influye directamente en un aumento de la eficiencia de la empresa. Otro criterio es la formación, que el proyecto aumente los conocimientos de los participantes y prepare mejor a la organización de cara a futuros retos.
En el informe realizado por Standish Group se pone de manifiesto que, tras analizar a todos los involucrados (jefes de proyecto, sus equipos, patrocinadores del proyecto, altos ejecutivos y usuarios), los tres criterios principales por los que éstos juzgaban el éxito de un proyecto fueron producto, uso y valor, respectivamente. Por contra, el gasto ocupó el último lugar del ranking. Ninguno de los grupos mencionaron la formación (prepararse para el futuro) entre sus tres criterios principales, aunque todos ellos sugirieron que esta formación era un asunto de, al menos, una importancia moderada. Aunque los jefes de proyecto y los miembros de sus equipos parecían estar más preocupados por llevar a cabo el proyecto según las características requeridas (a tiempo y sin salirse del presupuesto), los usuarios estaban más preocupados de si el sistema se podría usar tal y como se pretendía. Es difícil asumir esta perspectiva durante el curso del proyecto. Los asuntos que preocupan más a los usuarios son, uso y valor, no pueden resolverse hasta que el proyecto está completo en su sentido tradicional. Si maximizar la satisfacción general de los afectados e involucrados por el proyecto es importante, los altos ejecutivos deberían centrarse más en los criterios de producto, uso y valor.
Esta es la razón por la que es crucial que los CIOs revisen los proyectos tanto durante como después de la implantación si quieren crear y mantener una tasa de éxito a largo plazo. De esta forma, las retrospectivas deberían llevarse a cabo después de alcanzar cada objetivo principal dentro de los grandes proyectos, y una o dos semanas después de su finalización. El análisis de los beneficios debería llevarse a cabo más tarde, cuando se aprecie de forma legítima su impacto en el negocio.
Las ventajas de mirar atrás
Muchas veces las retrospectivas ofrecen una variedad de ventajas potenciales. Las revisiones permiten a los participantes ver más allá de sus impresiones personales del proyecto y presentan una visión más amplia del impacto en la organización. Las revisiones también dan la oportunidad de hacer mejoras en los procesos, procedimientos e intenciones, en vez de tratar cada proyecto como algo único, olvidando o ignorando las lecciones de los anteriores. Es posible estimar y planificar mejor los futuros proyectos, dado que las revisiones recogen datos históricos acerca del tiempo y el esfuerzo real que requirieron y su verdadero alcance. Finalmente, estas revisiones tienen un aspecto humano imposible de cuantificar. Si un proyecto funcionara mal, los profesionales podrían reconocer y reparar sus problemas personales en la relación de trabajo para que los futuros lo hicieran mejor. Si el proyecto acaba en éxito, la revisión le permite a uno deleitarse en lo que ha hecho bien antes de lidiar con el siguiente problema.
Las revisiones de proyectos llevan más allá el concepto de la planificación temporal de un proyecto. Los directores de éstos deben negociar las ventajas y los obstáculos entre proceso (tiempo y coste) y resultado (uso, formación y beneficio comercial). El documento inicial del proyecto debería incluir patrones de éxito, la guía de camino debería permitir mediciones en tiempo real, y la retrospectiva del proyecto debería documentar los resultados reales para obtener, como conclusión, la satisfacción general de todos los involucrados.
Un estudio elaborado por The Standish Group muestra, tras analizar retrospectivamente 72 proyectos de TI en 57 empresas distintas desde 1999, que proyectos que habían cumplido todos los criterios tradicionales para considerarlos un éxito (tiempo y dinero) habían acabado, pese a todo, en fracaso porque no supieron atraer a los usuarios potenciales o porque no implicaron demasiados beneficios para la empresa. Estos casos se denominan por la consultora “éxitos fallidos”, ya que el proyecto cumplía con todos los requisitos, pero no consiguió integrarse en los procesos financieros de la compañía, con lo que, al final, pasaron desapercibidos. Según explicó el CIO de una gran empresa, “la aplicación funciona al 100% cuando hay una participación del 100% y al 0% cuando lo utiliza un 95%”.
Del mismo modo, algunos proyectos, que se podrían considerar un fracaso según los parámetros tradicionales de TI, pueden acabar siendo exitosos porque, pese a sus problemas de coste o tiempo, el sistema triunfa entre su audiencia potencial o acaba dando unos beneficios inesperados.
Nuevos principios
Muchas veces, puede que el verdadero impacto de un proyecto no se llegue a apreciar hasta mucho tiempo después de que se complete su implantación. Según la consultora Standish Group, en un proyecto, más allá de las tradicionales medidas de tiempo y coste, deben aplicarse otros criterios para determinar su éxito, como son el grado de utilización del sistema o servicios, y de beneficio, donde el proyecto influye directamente en un aumento de la eficiencia de la empresa. Otro criterio es la formación, que el proyecto aumente los conocimientos de los participantes y prepare mejor a la organización de cara a futuros retos.
En el informe realizado por Standish Group se pone de manifiesto que, tras analizar a todos los involucrados (jefes de proyecto, sus equipos, patrocinadores del proyecto, altos ejecutivos y usuarios), los tres criterios principales por los que éstos juzgaban el éxito de un proyecto fueron producto, uso y valor, respectivamente. Por contra, el gasto ocupó el último lugar del ranking. Ninguno de los grupos mencionaron la formación (prepararse para el futuro) entre sus tres criterios principales, aunque todos ellos sugirieron que esta formación era un asunto de, al menos, una importancia moderada. Aunque los jefes de proyecto y los miembros de sus equipos parecían estar más preocupados por llevar a cabo el proyecto según las características requeridas (a tiempo y sin salirse del presupuesto), los usuarios estaban más preocupados de si el sistema se podría usar tal y como se pretendía. Es difícil asumir esta perspectiva durante el curso del proyecto. Los asuntos que preocupan más a los usuarios son, uso y valor, no pueden resolverse hasta que el proyecto está completo en su sentido tradicional. Si maximizar la satisfacción general de los afectados e involucrados por el proyecto es importante, los altos ejecutivos deberían centrarse más en los criterios de producto, uso y valor.
Esta es la razón por la que es crucial que los CIOs revisen los proyectos tanto durante como después de la implantación si quieren crear y mantener una tasa de éxito a largo plazo. De esta forma, las retrospectivas deberían llevarse a cabo después de alcanzar cada objetivo principal dentro de los grandes proyectos, y una o dos semanas después de su finalización. El análisis de los beneficios debería llevarse a cabo más tarde, cuando se aprecie de forma legítima su impacto en el negocio.
Las ventajas de mirar atrás
Muchas veces las retrospectivas ofrecen una variedad de ventajas potenciales. Las revisiones permiten a los participantes ver más allá de sus impresiones personales del proyecto y presentan una visión más amplia del impacto en la organización. Las revisiones también dan la oportunidad de hacer mejoras en los procesos, procedimientos e intenciones, en vez de tratar cada proyecto como algo único, olvidando o ignorando las lecciones de los anteriores. Es posible estimar y planificar mejor los futuros proyectos, dado que las revisiones recogen datos históricos acerca del tiempo y el esfuerzo real que requirieron y su verdadero alcance. Finalmente, estas revisiones tienen un aspecto humano imposible de cuantificar. Si un proyecto funcionara mal, los profesionales podrían reconocer y reparar sus problemas personales en la relación de trabajo para que los futuros lo hicieran mejor. Si el proyecto acaba en éxito, la revisión le permite a uno deleitarse en lo que ha hecho bien antes de lidiar con el siguiente problema.
Las revisiones de proyectos llevan más allá el concepto de la planificación temporal de un proyecto. Los directores de éstos deben negociar las ventajas y los obstáculos entre proceso (tiempo y coste) y resultado (uso, formación y beneficio comercial). El documento inicial del proyecto debería incluir patrones de éxito, la guía de camino debería permitir mediciones en tiempo real, y la retrospectiva del proyecto debería documentar los resultados reales para obtener, como conclusión, la satisfacción general de todos los involucrados.
