En 1986, Alfred Spector, presidente de Transarc Corporation, fue coautor de un documento que compara la construcción de puentes con el desarrollo de software. La premisa: los puentes normalmente se construyen a tiempo, en presupuesto, y no se caen. Por otro lado, el software nunca llega a tiempo o dentro del presupuesto. Además, siempre se descompone. (Sin embargo, la construcción de puentes no siempre tuvo un registro tan estelar. Muchos proyectos de construcción de puentes sobrepasaron sus estimaciones, los plazos, y algunos incluso cayeron). Una de las principales razones por las cuales los puentes llegan a tiempo, dentro del presupuesto y no se caen es por el detalle extremo del diseño. El diseño está congelado y el contratista tiene poca flexibilidad para cambiar las especificaciones. Sin embargo, en el entorno empresarial de rápido movimiento de hoy en día, un diseño congelado no admite cambios en las prácticas comerciales. Por lo tanto, se debe usar un modelo más flexible. Esto podría ser y ha sido utilizado como una razón fundamental para el fracaso del desarrollo. Pero hay otra diferencia entre las fallas del software y las fallas del puente, además de 3.000 años de experiencia. Cuando Cuando un puente se cae, se investiga y se escribe un informe sobre la causa de la falla. Esto no es así en la industria de la computación donde las fallas están cubiertas, ignoradas y / o racionalizadas. Como resultado, seguimos cometiendo los mismos errores una y otra vez. En consecuencia, el objetivo de este último proyecto de investigación en The Standish Group ha sido identificar: · · ·
El alcance de las fallas del proyecto de software Los principales factores que hacen que los proyectos de software fallen Los ingredientes clave que pueden reducir las fallas del proyecto
En los Estados Unidos, gastamos más de $ 250 mil millones cada año en el desarrollo de aplicaciones de TI de aproximadamente 175,000 proyectos. El costo promedio de un proyecto de desarrollo para una gran empresa es de $2.322.000; para una compañía mediana, es $1.331.000; y para una compañía pequeña, es $ 434,000. Muchos de estos proyectos fracasarán. Los proyectos de desarrollo de software están en caos, y ya no podemos imitar a los tres monos: no escuchar fracasos, no ver fracasos, no hablar de fallas. La investigación del Grupo Standish muestra que un asombroso 31.1% de los proyectos serán cancelados antes de que se completen. Resultados adicionales indican que el 52.7% de los proyectos costarán el 189% de sus estimaciones estimaciones originales. El costo de estas fallas y desbordamientos desbordamientos es solo la punta del proverbial iceberg. Los costos de oportunidad perdidos no son medibles, pero podrían ser fácilmente de billones de dólares. Uno solo tiene que mirar a la ciudad de Denver para darse cuenta del alcance de este problema. La falla en la producción de software confiable para manejar el equipaje en el nuevo aeropuerto de Denver está costando a la ciudad $ 1.1 millones por día. Con base en esta investigación, The Standish Group estima que en 1995 las compañías y agencias gubernamentales estadounidenses gastarán $81 mil millones para proyectos de software
cancelados. Estas mismas organizaciones pagarán $59 mil millones adicionales por proyectos de software que se completarán, pero superarán sus estimaciones de tiempo originales. El riesgo siempre es un factor al impulsar la tecnología, pero muchos de estos proyectos fueron tan mundanos como una base de datos de licencias de conducir, un nuevo paquete de contabilidad o un sistema de entrada de pedidos. En el lado del éxito, el promedio es solo 16.2% para proyectos de software que se completan a tiempo y dentro del presupuesto. En las compañías más grandes, las noticias son aún peores: solo el 9% de sus proyectos llegan a tiempo y dentro del presupuesto. E incluso cuando estos proyectos se completan, muchos no son más que una mera sombra de sus requisitos de especificación originales. Los proyectos completados por las compañías más grandes de los Estados Unidos tienen solo aproximadamente el 42% de las características y funciones propuestas originalmente. Las empresas más pequeñas lo hacen mucho mejor. Un total del 78.4% de sus proyectos de software serán implementados con al menos el 74.2% de sus características y funciones originales. Esta información puede parecer descorazonadora, y de hecho, el 48% de los ejecutivos de TI en nuestra muestra de investigación sienten que hay más fallas actualmente que hace solo cinco años. La buena noticia es que más del 50% cree que hay menos o el mismo número de fallas hoy que hace cinco o diez años.
La encuesta realizada por The Standish Group fue lo más exhaustiva posible, sin alcanzar el objetivo inalcanzable de encuestar a todas las empresas con MIS en el país. Los resultados se basan en lo que en The Standish Group definimos como "hallazgos clave" de nuestras encuestas de investigación y varias entrevistas personales. Los encuestados fueron gerentes ejecutivos de TI. La muestra incluyó compañías grandes, medianas y pequeñas en los principales segmentos de la industria, por ejemplo, banca, valores, fabricación, venta al por menor, mayorista, atención médica, seguros, servicios y organizaciones locales, estatales y federales. El tamaño total de la muestra fue de 365 encuestados y representó 8.380 solicitudes. Además, The Standish Group condujo cuatro grupos focales y numerosas entrevistas personales para proporcionar un contexto cualitativo para los resultados de la encuesta. Para los fines del estudio, los proyectos se clasificaron en tres tipos de resolución: · ·
·
Resolución Tipo 1, o éxito del proyecto: el proyecto se completa a tiempo y dentro del presupuesto, con todas las características y funciones especificadas inicialmente. Resolución tipo 2, o proyecto cuestionado: el proyecto está completo y en funcionamiento, pero sobre presupuesto, en el tiempo estimado, y ofrece menos características y funciones de las originalmente especificadas. Resolución tipo 3 o proyecto deteriorado: el proyecto se cancela en algún momento durante el ciclo de desarrollo.
En general, la tasa de éxito fue solo del 16.2%, mientras que los proyectos desafiados representaron el 52.7%, y los perjudicados (cancelados) el 31.1%.
El Grupo Standish segmentó aún más estos resultados por compañías grandes, medianas y pequeñas. Una compañía grande es cualquier compañía con más de $ 500 millones de dólares en ingresos por año, una mediana se define como tener entre $ 200 millones y $ 500 millones en ingresos anuales, y una pequeña empresa es de $ 100 millones a $ 200 millones. Las cifras del fracaso fueron igualmente desalentadoras en empresas de todos los tamaños. Solo el 9% de los proyectos en grandes compañías tuvieron éxito. Con un 16,2% y 28% respectivamente, las empresas medianas y pequeñas tuvieron algo más de éxito. Un 61.5% de todos los proyectos de grandes compañías fueron desafiados (Resolución tipo 2) en comparación con el 46.7% para compañías medianas y el 50.4% para compañías pequeñas. La mayoría de los proyectos, 37.1%, fueron deteriorados y posteriormente cancelados (Resolución Tipo 3) en compañías medianas, en comparación con 29.5% en compañías grandes y 21.6% en compañías pequeñas.
Una de las causas principales de los excesos de costo y tiempo es reiniciar. Por cada 100 proyectos que comienzan, hay 94 reinicios. Esto no significa que 94 de 100 tendrá un reinicio, algunos proyectos pueden tener varios reinicios. Por ejemplo, el proyecto del Departamento de Vehículos Motorizados de California, un escenario de falla resumido más adelante en este artículo, tuvo muchos reinicios.
Igualmente reveladores fueron los resultados de los excesos de costos, los excesos de tiempo y la falla de las aplicaciones para proporcionar las características esperadas. Para proyectos combinados de Tipo 2 y Tipo 3, casi un tercio experimentó sobrecostos de 150 a 200%. El promedio en todas las compañías es el 189% del costo estimado original. El exceso de costo promedio es del 178% para las grandes empresas, el 182% para las medianas y el 214% para las pequeñas.
SOBRECOSTOS Debajo del 20% 21-50% 51-100% 101-200% 201-400% Más del 400%
% DE RESPUESTAS 15.5% 31.5% 29.6% 10.2% 8.8% 4.4%
Para los mismos proyectos combinados desafiados y perjudicados, más de un tercio también experimentó un exceso de tiempo de 200 a 300%. El exceso promedio es 222% del tiempo estimado original. Para las grandes empresas, el promedio es del 230%; para las medianas empresas, el promedio es del 202%; y para las pequeñas empresas, el promedio es del 239%.
SOBREPASOS DE TIEMPO Debajo del 20% 21-50%
% DE RESPUESTAS 13.9% 18.3%
51-100% 101-200% 201-400% Más del 400%
20.0% 35.5% 11.2% 1.1%
Para los proyectos desafiados, se completó más de un cuarto con solo el 25% al 49% de las características y funciones originalmente especificadas. En promedio, solo el 61% de las características y funciones originalmente especificadas estaban disponibles en estos proyectos. Las grandes empresas tienen el peor registro con solo el 42% de las características y funciones en el producto final. Para las medianas empresas, el porcentaje es del 65%. Y para las pequeñas empresas, el porcentaje es del 74%.
%CARACTERISTICAS/FUNCIONES Menos de 25% 25-49% 50-74% 75-99% 100%
% DE RESPUESTAS 4.6% 27.2% 21.8% 39.1% 7.3%
Actualmente, las 365 empresas tienen un total combinado de 3.682 aplicaciones en desarrollo. Sólo 431 o el 12% de estos proyectos son a tiempo y dentro del presupuesto.
El aspecto más importante de la investigación es descubrir por qué los proyectos fallan. Para hacer esto, The Standish Group encuestó a los gerentes ejecutivos de TI por sus opiniones sobre por qué los proyectos tienen éxito. Las tres razones principales por las que un proyecto tendrá éxito son la participación del usuario, el apoyo de la dirección ejecutiva y una declaración clara de los requisitos. Hay otros criterios de éxito, pero con estos tres elementos en su lugar, las posibilidades de éxito son mucho mayores. Sin ellos, la probabilidad de fracaso aumenta drásticamente.
FACTORES DE ÉXITO DEL PROYECTO 1 – Participación del Usuario 2 – Apoyo de la Dirección Ejecutiva 3 – Declaración clara de Requisitos 4 – Planificación Adecuada 5 – Expectativas realistas 6 – Pequeños hitos del proyecto 7 – Personal Competente 8 – Propiedad 9 – Visión y Objetivos Claros 10 – Trabajo duro, personal enfocado 11 – Otros
% DE RESPUESTAS 15.9% 13.9% 13.0% 9.6% 8.2% 7.7% 7.2% 5.3% 2.9% 2.4% 13.9%
A los participantes en la encuesta también se les preguntó acerca de los factores que hacen que los proyectos sean cuestionados.
FACTORES CUESTIONADOS DEL PROYECTO 1 – Falta de entrada del usuario 2 – Requisitos y especificaciones incompletos 3 – Modificación de requisitos y especificaciones 4 – Falta de apoyo Ejecutivo 5 – Incompetencia tecnológica 6 – Falta de Recursos 7 – Expectativas poco realistas 8 – Objetivos poco claros 9 – Marcos de tiempo poco realistas 10 – Nueva tecnología 11 – Otros
% DE RESPUESTAS 12.8% 12.3% 11.8% 7.5% 7.0% 6.4% 5.9% 5.3% 4.3% 3.7% 23.0%
Las opiniones sobre por qué los proyectos están deteriorados y finalmente cancelados clasificaron los requisitos incompletos y la falta de participación del usuario en la parte superior de la lista.
FACTORES DETERIORADOS DEL PROYECTO 1 – Requisitos incompletos 2 – Falta de participación del Usuario 3 – Falta de Recursos 4 – Expectativas poco realistas 5 – Falta de apoyo Ejecutivo 6 – Cambio de requisitos y especificaciones 7 – Falta de planificación 8 – No necesitaba más tiempo 9 – Falta de gestión de TI 10 – Analfabetismo tecnológico 11 – Otros
% DE RESPUESTAS 13.1% 12.4% 10.6% 9.9% 9.3% 8.7% 8.1% 7.5% 6.2% 4.3% 9.9%
