Este documento resume las estadísticas de éxito y fracaso de proyectos de software desde 1994. Aproximadamente el 30% de los proyectos analizados han tenido éxito, cumpliendo con el presupuesto, plazos y satisfacción de los usuarios. Los factores que aumentan las probabilidades de éxito incluyen proyectos más pequeños, involucramiento de usuarios y experiencia del gerente de proyecto. Cuando los proyectos fallan, a menudo es debido a no involucrar a las partes interesadas, alejarse de los
FUNIBER-Daniela Ochoa-Factores de éxito y fracaso en proyectos IT-Estadísticas en la industria del software
1. Factores de éxito y fracaso en proyectos IT
Estadísticas en la industria del software
Desde 1994 se viene publicando un informe bianual1 que analiza los proyectos de
software y los categoriza como éxitos o fracasos en función de las tres restricciones
base de un proyecto: alcance, presupuesto y plazos. A partir del 2015, en lugar del
alcance se tomó en cuenta el nivel de satisfacción como factor determinante; es decir,
si se cumple con el presupuesto, se entrega dentro de la fecha acordada y se obtienen
resultado satisfactorios, el proyecto es considerado un éxito.
Si tomamos los porcentajes de éxito desde el año 2000, de los 50.000 proyectos
analizados, los valores porcentuales oscilan entre un 28% (2000) y un 39% (2012) de
proyectos exitosos. En el último análisis (2015), un 29% fue considerado exitoso.
Al revisar estos valores, es curioso ver cómo el porcentaje de proyectos considerados
éxito y el porcentaje considerados fracaso, no ha variado mayormente a pesar de los
avances en la profesionalización de la gestión de proyectos y la formalización de los
procesos metodológicos que se han dado estos últimos años.
En la década de los 80, salió un artículo que comparaba el desarrollo de software con la
construcción de un puente; la premisa era simple: el puente debe construirse con un
tiempo específico, un presupuesto específico, y no caerse; de la construcción de
software se esperaba lo mismo. Sin embargo, en la actualidad, ante la flexibilidad
exigida al diseño de software, las expectativas de los involucrados y la evolución de los
recursos tecnológicos queda muy obsoleta esa premisa base.
Cuando un proyecto de software fracasa, es muy probable que se pase de largo el
análisis de la causa; todo lo contrario, lo más común es que se empiece a trabajar en lo
que sigue en la agenda incluso bajo la sombra de fracasos, suspensiones o cancelaciones
de proyectos anteriores; pero si analizáramos cada fracaso y buscáramos un patrón
entre esas razones, encontraríamos que, a menudo, los puntos de partida están en no
involucrar a las personas interesadas, alejarse de la estrategia y los objetivos, y perder
de vista la evolución del conflicto o la necesidad que dio origen al proyecto.
Cuando vemos las estadísticas, parece que no hay garantías para el éxito; en 20 años de
análisis y reportes hay una diferencia muy pequeña en la evolución de esos
porcentajes2; sin embargo, los números son muy claros en tres aspectos:
las probabilidades de éxito de un proyecto chico son mucho mayores que las de un
proyecto grande, por lo tanto, dividamos cuando sea necesario, sin perder de vista la
visión global y el objetivo final; involucremos a los usuarios, cuando los usuarios se
comprometen con el proyecto y participan activamente en el desarrollo, la solución
1 Reporte del caos, Standish group (2017). Recuperado de: http://www.standishgroup.com/outline
2 2004: 29%; 2006: 35%; 2008: 32%; 2010: 37%; 2012: 39%; 2014: 29%.
2. final estará muy cerca de sus expectativas. Y es primordial la experiencia del gestor del
proyecto, solo así podemos identificar a tiempo las competencias que se necesitan, los
riesgos que puedan darse, y considerar todos los parámetros que afectan el ambiente,
los recursos y la evolución de cada proyecto.
Hay muchos otros factores a considerar si queremos terminar un proyecto dentro de
las tres restricciones bases que mencionamos al principio: desde las herramientas
tecnológicas, habilidades técnicas e infraestructura, hasta las metodologías ágiles y la
madurez emocional de cada equipo del trabajo; y deberíamos empezarlos a construir
desde las diferentes aristas de la industria del software.
Daniela Ochoa Mejía
FUNIBER – Fundación Universitaria Iberoamericana.